[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: print-oriented styling of document diffs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC