taking screenshots - new section for Documentation Guide (was installation guide)

[Karsten Wade]

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