On Mon, 2004-08-30 at 15:11, Paul W. Frields wrote: > On Mon, 2004-08-30 at 17:40, Karsten Wade wrote: > > That's not what I see on this page: > > > > http://fedora.redhat.com/participate/documentation-guide/s1-xml-tags-screen.html > > You're right. I think I changed this in my usage because the extra > linefeeds were causing the PDF rendering to use WAY too much vertical > space. Would a bug report for that go against xmlto, then? And how does > your recommendation fare for those purposes? Hey, you're doing great if you can even get a PDF. :) I must be doing something in the SGML way that xmlto doesn't like. It sounds like starting with a bug to xmlto would be a good idea; I created a sample XML document that shows all the variations; the source and PDF output can be attached to the bug report: http://people.redhat.com/kwade/fedora-docs/process-docs/xmlto-whitespace-test.pdf I pasted the TXT output below this message, for discussion FWIW, this PDF builds for me, so my non-PDF building docs must have an error of some kind in the XML. I do know that we will need to keep our content on separate lines than the tags. This is a sanity checking device. If you have a code or configuration file: foo { bar { some.call () } } and the first and lines of that are flush with tags, e.g.: <programlisting>foo { bar { some.call () } }</programlisting> it is hard to tell if the code indenting is correct, which matters in many contexts. This simple example is easy to fix, but complex examples are much harder, as I have personally experienced many times. ## begin sample output xmlto test of whitespace usage Karsten Wade Copyright © 2004 Red Hat, Inc. _________________________________________________________ Table of Contents xmlto test xmlto test Here are some self-referential examples: Example 1. Stacked Tags - Source <screen><computeroutput>foo { bar { some.call () } }</computeroutput></screen> Example 2. Stacked Tags - Output foo { bar { some.call () } } Example 3. Stacked and Broke - Source <screen><computeroutput> foo { bar { some.call () } } </computeroutput></screen> Example 4. Stacked and Broke - Output foo { bar { some.call () } } Example 5. All Flush Left - Source <screen> <computeroutput> foo { bar { some.call () } } </computeroutput> </screen> Example 6. All Flush Left - Output foo { bar { some.call () } } Example 7. Only Content Flush Left - Source <screen> <computeroutput> foo { bar { some.call () } } </computeroutput> </screen> Example 8. Only Content Flush Left - Output foo { bar { some.call () } } ## end sample output -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41