DOCBOOK-APPS: print-oriented styling of document diffs

["Matt G." <matt_g_ at hotmail dot com>]

The most recent message I could find, on the topic, is almost a year old:

> From: Norman Walsh <ndw@nwalsh.com>
> To:   docbook-apps@lists.oasis-open.org
> Date: Mon, 01 Oct 2001 11:52:47 -0400
>
> / Norman Walsh <ndw@nwalsh.com> was heard to say:
> | | I want to generate change bars on printed output.  Can I use | | XSL 
> style sheets to render into PostScript?
> | | Ah, changebars.xsl is an HTML stylesheet. I haven't written a print one
> | yet. Off the top of my head, I can't think of a way to make Jade or
> | XSL FO produce traditional print change bars.
>
> Simple brain cramp on my part. Doing it in FO is pretty easy, at least
> for blocks, one can just use, for example:
>
>  <fo:block border-end-color="black"
>            border-end-style="solid"
>            border-end-width="0.5pt"
>            padding-end="3pt">
>
> That's not going to do the right thing for inlines, but maybe
> something could be worked out. Color could be used, of course, but
> it would be nice to have a b&w solution too.
>
>                                        Be seeing you,
>                                          norm
Is this still the case?  Barring FOP bugs, it seems like it would be rather 
straight-forward to stylize inline content (e.g. strikethrough for removed 
content; overline for added text; special colors for both).

What about diffmk?  Is the 2.0 Java port still available only as beta?  (if 
not, nwalsh.com needs to be updated.)  Was there ever a release of the Perl 
version beyond 1.0?

Pending the answers to the above questions, the docbook.org Wiki page should 
be updated (anyone care to beat me to it?).


Just for fun, I tracked down a windows machine (running MS Word 2K, I 
think), in order to try diffing the RTF output of the DSSSL stylesheets.  I 
built two versions, then opened and saved them both as .doc files.  However, 
when I opened the first draft and ran the comparison tool against the second 
one, the diffs were only correct part way into the the table of contents.  
Beyond that point, the old text was completely gone, and the rest of the 
document was marked as "new" (in spite of the fact that both docs were quite 
similar - especially in the first 40 pages).

Then, I tried opening the second one and comparing against the first.  This 
time, the output was somewhat reasonable.  Of course, the change markings 
were now backwards - strikethrough marked the new content, while ordinary 
highlighting marked the removed/replaced text.


Even if it worked flawlessly, I would still want to have an automated, 
platform-independent means of producing change-marked PDFs.  Also, since 
both much of my documentation includes automatically-generated content, and 
the document source is managed in a CVS repository along side the code it 
describes, incrementally accumulating change bars wouldn't even be an 
option.


Matt Gruenke


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com