Whitespace in PDF output

anne.bovard · ‎Feb 11, 2011

Hi all,

I'm having a problem with Styler expressing whitespace in our PDF output. Please see the following code snippet and attached jpg of the output. When I manually remove the spaces between the para and section end tags, I have no problem. It seems that I should be able to strip the space somehow. I admit that the code is a little messy, but is there a way to ignore the whitespace in our output? We're using a FOSI-based Styler stylesheet. Thank you for your time and attention.

Kind regards,

Anne

SPI-turvalausekkeet<title>SPI-turvalausekkeet</title><conbody>
<section> <title>Johdanto</title>

Varoituksilla osoitetaan
tässä oppaassa vaaroja ja vakavuuden tasoa. Tutustu määritelmiin ja
merkityksiin.

Pocket Vieweriä ei ole tarkoitettu ensisijaiseksi
hälytyslähteeksi.

</section>
<section> <title>Vaarat</title>

Vaaratarkoittaa välitöntä
vaarallista tilannetta, jonka huomioimatta jättäminen johtaa vakavaan
loukkaantumiseen tai kuolemaan. Web Viewerissa ei ole äänihälytyksiä.</p<br/>>

</section>
<section> <title>Varoitukset</title>

VAROITUSVaroitus
tarkoittaa tilannetta, jossa saattaa olla vakavan loukkaantumisen
tai kuoleman mahdollisuus. Web Viewerissa ei ole äänihälytyksiä.</p<br/>> </section>
</conbody>
Johdanto

naglists · ‎Feb 11, 2011

can you submit the dtd fragment for section?

On Fri, Feb 11, 2011 at 6:51 AM, Anne Bovard
<anne.bovard@comtech-serv.com>wrote:

> Hi all,
>
> I'm having a problem with Styler expressing whitespace in our PDF output.
> Please see the following code snippet and attached jpg of the output. When I
> manually remove the spaces between the para and section end tags, I have no
> problem. It seems that I should be able to strip the space somehow. I admit
> that the code is a little messy, but is there a way to ignore the whitespace
> in our output? We're using a FOSI-based Styler stylesheet. Thank you for
> your time and attention.
>
> Kind regards,
>
> Anne
>
> SPI-turvalausekkeet<title>SPI-turvalausekkeet</title><conbody>
> <section> <title>Johdanto</title>

Varoituksilla osoitetaan
> tässä oppaassa vaaroja ja vakavuuden tasoa. Tutustu määritelmiin ja
> merkityksiin.

Pocket Vieweriä ei ole tarkoitettu
> ensisijaiseksi
> hälytyslähteeksi.

</section>
> <section> <title>Vaarat</title>

Vaaratarkoittaa välitöntä
> vaarallista tilannetta, jonka huomioimatta jättäminen johtaa vakavaan
> loukkaantumiseen tai kuolemaan. Web Viewerissa ei ole äänihälytyksiä.</p<br/>> >

</section>
> <section> <title>Varoitukset</title>

VAROITUSVaroitus
> tarkoittaa tilannetta, jossa saattaa olla vakavan loukkaantumisen
> tai kuoleman mahdollisuus. Web Viewerissa ei ole äänihälytyksiä.</p<br/>> > </section>
> </conbody>
> Johdanto
>
>

anne.bovard · ‎Feb 11, 2011

Hi Paul,

Here's the snippet:

Also, two other things to note:

1) I published in another tool (Oxygen) and the whitespace was ignored.

2) I published with the OOTB Styler stylesheets and the whitespace was retained.

Thanks!

Anne

ptc-3050150 · ‎Feb 11, 2011

What are the benefits of having Distiller on the Print Engine vs. just using the built-in Compose to PDF?

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support, Land & Armaments/Global Tactical Systems

ptc-953343 · ‎Feb 11, 2011

I beleive with Distiller you will not get any bookmarks

> What are the benefits of having Distiller on the Print Engine vs. just
> using the built-in Compose to PDF?
>
> John T. Jarrett CDT
> Senior Tech Writer, Integrated Logistics Support, Land & Armaments/Global
> Tactical Systems
>

naglists · ‎Feb 12, 2011

Within the Arbortext environment, it is not a Styler issue, I think the
#PCDATA is telling Editor to respect the whitespace. Can't say why other
parsers/authoring tools do not respect the DTD. Try removing #PCDATA from
section's content model (be sure it's not being brought back in by way of
any of your other entities in the content model) just for a test. Not sure
if it will complain about the whitespace, but it may stop publishing it.

On Fri, Feb 11, 2011 at 8:24 AM, Anne Bovard
<anne.bovard@comtech-serv.com>wrote:

> Hi Paul,
>
> Here's the snippet:
> > %title; | %txt.incl; | %data.elements.incl; | %foreign.unknown.incl;">
>
> Also, two other things to note:
>
> 1) I published in another tool (Oxygen) and the whitespace was ignored.
>
> 2) I published with the OOTB Styler stylesheets and the whitespace was
> retained.
>
> Thanks!
>
> Anne
>
>
>
>
>

naglists · ‎Feb 12, 2011

If bookmarks are still possible, they are not "automatic" or "configuration"
free. May require explicit stylesheet coding rather than leveraging .dcf and
maybe pdfcf (I think that's the right extension) div handling. I can't
remember the subtleties anymore, plus we switched from Print Compose +
Distiller locally to Compose PDF on PE with PDF Direct so long ago, the
differences may now be different.

You will probably get smaller PDFs. (The disparity between PDF Direct and
Distiller output file size is less than it used to be, but still notable.)

You will face a different set of font and character landmines. (Whether or
not you hit them in either instance is determined by how you behaved in a
previous life).

Your software account will be several thousand dollars lighter and you will
have an additional license to manage 😉

Does anyone know / remember if there is a performance difference? Our docs
are short enough that performance is rarely an issue. If you're making
10,000 pages at a go ... you'll want to know the general answer to this
question and run actual tests with your stylesheets and docs, too, before
committing.

ebenton · ‎Feb 14, 2011

Generally it's the making of the PostScript file before it gets distilled to PDF that takes most of the time. The distilling itself is relatively quick.

Years ago, using Print Composer, we noticed that if you did not set your default printer to "Acrobat Distiller" (currently named "Adobe PDF") then the PDF output was suspect, and varied from printer to printer. Apparently the "Acrobat Distiller/Adobe PDF" print driver is a "true" Post Script printer. Not all printers were/are.

anne.bovard · ‎Feb 14, 2011

Hi Paul,

Thanks so much for your reply. You've hit upon the same solution that Paul Grosso offered us offline. Paul explained that

"...any character content--whitespace or not--within a section element is going to be significant. That is, having a space in between the <section> tag and the <title> tag is like having an "x" there, and the composition system will compose that space (just as if it had been a printing character) and you will see an extra line's worth of vertical space. It doesn't matter if you have 1 or 8 spaces, since they will all be on the "same line" of output."

Revising the DTD would definitely be an interesting exercise for testing, but it cannot be our end-solution. At the end of the day, we have bad XML and we need to figure out the origin of those spaces. Paul G. thought that someone might have pretty-printed the files.

Thanks again for your attention and help!

Kind regards,

Anne

ptc-3050150 · ‎Feb 14, 2011

Very interesting comments! Thanks very much for the insight. Sounds like that's a potential morass I have zero good reasons to bother with. And the "time" comment brought up a good point: most of the time involved has to do with preparing to send it TO the Print Engine, not with the PDF creation itself, so even if it did cut the time in half, that would only cut maybe half an hour out from 3-4 hours total - still not enough to make it worth messing with.

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support, Land & Armaments/Global Tactical Systems

ManishaPawar · ‎Feb 15, 2011

Hi

I have created a User Inteface in jsp for sending request to Publisher
Engine. On PE side we have created our own custom datatype and stylesheet
for composing pdf out of the .xml file which I am sending from User
Interface.

on PE side my .xml file getting validate correctly but there is problem
with composition.(I am sending that file for compositon using http post
request) I am not getting where things might be failing. One thing I
obeserved in ACL script is

If document is valid then following piece of code get executed

doc is nothing but the xml file I am sending and getting the error which
is in bold letter.

{
local temp_comp_params[];
local fname =
epicutil::temporary_directory() . "/myGuide_" . getpid() . "_" . doc .
".pdf";
temp_comp_params[ "outputFile" ] =
fname;

if( compose::compose_for_pdf( doc,
temp_comp_params ) == 1)
{

GarethOakes · ‎Feb 15, 2011

Oh how I love dealing with whitespace in XML. Glad I'm not the only one J

-G

ClayHelberg · ‎Feb 15, 2011

Hi Manish-

Your fname file is not getting generated as a result of the composition
failure, it is not the cause of it. From what you've said I can't tell
what's going wrong with your composition call. But you may be able to
get some more useful information by looking at the following things:

a) The transaction archive, available from the main PE application
page. This should store copies of the original request and response as
well as any intermediate files generated during the failed build. You
may also want to change some of the options in your e3config.xml file to
modify what gets saved under what circumstances.

b) The PE log file, usually called "pelog.xml", located in the
Tomcat logs folder. This may have some more detailed information on what
is happening with the composition failures. If you need more detail, you
can change settings in e3config.xml to increase various logging levels.

If you are using 5.4, there is some helpful information on PE
troubleshooting in the Arbortext Help Center. If you search for
"troubleshooting errors", you'll find useful information there. Good
luck!

--Clay

Clay Helberg

Senior Consultant

TerraXML

ManishaPawar · ‎Feb 15, 2011

Hi Clay,

Thanks for the information. I have checked this

Its is saying not request body

Also I checked for path Translated path ....Last e3 directory is not
available on PE server. Does because of this it can fail?

Thanks & Regards,
Manisha

Clay Helberg <chelberg@terraxml.com>
02/15/2011 06:21 PM
Please respond to
-

To
-
cc

Subject
[adepters] - RE: PE Composition Error.

Hi Manish—

Your fname file is not getting generated as a result of the composition
failure, it is not the cause of it. From what you’ve said I can’t tell
what’s going wrong with your composition call. But you may be able to get
some more useful information by looking at the following things:

a) The transaction archive, available from the main PE application
page. This should store copies of the original request and response as
well as any intermediate files generated during the failed build. You may
also want to change some of the options in your e3config.xml file to
modify what gets saved under what circumstances.
b) The PE log file, usually called “pelog.xml”, located in the Tomcat
logs folder. This may have some more detailed information on what is
happening with the composition failures. If you need more detail, you can
change settings in e3config.xml to increase various logging levels.

If you are using 5.4, there is some helpful information on PE
troubleshooting in the Arbortext Help Center. If you search for
“troubleshooting errors”, you’ll find useful information there. Good luck!

--Clay

Clay Helberg
Senior Consultant
TerraXML

ClayHelberg · ‎Feb 15, 2011

It looks to me as if your calling process is not packaging up the POST data properly. If the document is included in the request body then PE should be able to find it.

Clay Helberg

Senior Consultant

TerraXML

ManishaPawar · ‎Feb 22, 2011

Hi All,

Regarding the following issue which I mentioned in the below mail , I have
printed composer log and it showing me below error

[ERROR] [A62020] Stylesheet '' has an extension other than '.style',
'.fos', '.xsl', or '.3f'. Unknown stylesheet type.
[INFO] [A20324] Operation canceled by user.

Anybody knows about this error? Thanks in advance.

Thanks & Regards,
Manisha

Clay Helberg <chelberg@terraxml.com>
02/15/2011 06:21 PM
Please respond to
-

To
-
cc

Subject
[adepters] - RE: PE Composition Error.

Hi Manish—

Your fname file is not getting generated as a result of the composition
failure, it is not the cause of it. From what you’ve said I can’t tell
what’s going wrong with your composition call. But you may be able to get
some more useful information by looking at the following things:

a) The transaction archive, available from the main PE application
page. This should store copies of the original request and response as
well as any intermediate files generated during the failed build. You may
also want to change some of the options in your e3config.xml file to
modify what gets saved under what circumstances.
b) The PE log file, usually called “pelog.xml”, located in the Tomcat
logs folder. This may have some more detailed information on what is
happening with the composition failures. If you need more detail, you can
change settings in e3config.xml to increase various logging levels.

If you are using 5.4, there is some helpful information on PE
troubleshooting in the Arbortext Help Center. If you search for
“troubleshooting errors”, you’ll find useful information there. Good luck!

--Clay

Clay Helberg
Senior Consultant
TerraXML