I prefer Bob's way. How will you know at writing time how much space
will be available for the programlisting? The xsls can change: what if
the page size, font size, or margins change? What if you put a
programlisting inside a table cell or as part of a nested list? If you
reuse content via xincludes or something, you don't know in what context
the programlisting might appear.
If you add the line breaks manually you must either obey the language
(so then you have the extra work of adding the breaks, then testing the
code sample if possible and might have writers monkeying with the code
samples) or you add the breaks and manually add a character indicating
the line was broken for typographical resons, but then you have those
unneeded breaks and extraneous in the html version too, so the user can
no longer cut and paste the code sample from the html verison (our users
like to be able to cut and paste from code listings).
David
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, June 23, 2009 8:02 AM
To: David Cramer
Cc: [email protected]
Subject: RE: [docbook] controlling the line length of
programlisting
Hi David,
Thanks for pointing out this section in Bob Stayton's book.
However, if I'm reading the section correctly,
the breaking of text is done during the build processing.
Wouldn't it be easier if we could alert the writer right away
that he/she needs to edit the programlisting? My software
package has print margin feature, but it is only available in the
text mode.
Any suggestions?
Kate
"David Cramer" <[email protected]>
06/22/2009 03:34 PM
To
<[email protected]>, <[email protected]>
cc
Subject
RE: [docbook] controlling the line length of programlisting
See the following section from Bob Stayton's book about using a
hyphenation character (e.g. an arrow of some kind) to indicate that a
line in a programlisting has been broken for typographical reasons:
http://www.sagehill.net/docbookxsl/FittingText.html#BreakLongLines
<http://www.sagehill.net/docbookxsl/FittingText.html#BreakLongLines>
David
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Monday, June 22, 2009 2:25 PM
To: [email protected]
Subject: [docbook] controlling the line length of programlisting
Has anyone tried to use schematron to enforce the line length of
programlisting?
We want to be able to limit the line-length of our
programlistings when we are authoring.
That is, we need to be informed when a line length in a
programlisting exceeds a number of characters (e.g., 72)
so that we can go in and format the lines properly. E.g., I'm
imagining that this would involve counting the number of characters
before a eol and then comparing
this number against the character limit (72).
If anyone has an alternative suggestion, that would be greatly
appreciated.
Thank you,
Kate
________________________________
Subject: Re: [docbook] prettyprinting code snippets
* From: Hannes Magnusson <[email protected]>
* To: DavePawson <[email protected]>
* Date: Sun, 14 Jun 2009 12:59:31 +0200
________________________________
On Fri, Jun 12, 2009 at 19:01, DavePawson<[email protected]>
wrote:
> Mauricio Tavares wrote:
>>
>> I am writing a an article in which I am including quite a
few xml
>> examples and snippets. I have been using <programlisting> but
was now
>> wondering if there is a way I can prettyprint those snippets.
Anyone?
>
>
> ONly if the code is well laid out in the first place?
> I try to break lines at <= 70 chars to make sure
> it fits on a screen.
>
> If you want code highlighting etc.. sorry no.
When the PHP documentations where using DocBook-XSL we used to
add a
customization layer to add special "tags" around
<programlisting>, and
then post process the output to syntax highlight and format
examples
(php, xml, ..).
For example with <programlisting role="php"><?php..
?></programlisting> the customization layer would generate
"<phpcode><?php.. ?></phpcode>" that was then post processed
with
other applications.
Currently we are using "PhD" (PHP based Docbook Renderer) which
handles all these kinds of things :)
-Hannes
[email protected]
