- PDFInfo unconditionally puts the creation timeMy preference is the second option.
Will do.
- Source FO line endingsHow about running it through the Canonicalizer from org.apache.xml.security?
Hmhm. There is already a java.io.LineNumberInputStream which normalizes line endings as a side effect of counting them. The problem: it is deprecated and replaced by LineNumberReader (or such). More specifically: digesting is done with raw bytes, on an InputStream. Line endings are characters, and can only be reliably dealt with in a character stream, which means some subclass of Reader. To make it really difficult: it is the XML parser who ultimately decides the source stream encoding.
Life sucks.
I considered doing the checksum in a SAX filter for a short time. This had the added benefit of making XML comments and some other issues which don't influence the rendered result having no influence on the checksum. The drawback: attributes need to be sorted before feeding them into the digester. Any other pitfalls to watch?
I'd still favor the PDF2TIFF with visual diffing approach using GhostScript.
Yeah, but what if something invisible was screwed, or the difference got lost due to pixelation during rendering? Think of off-by-one errors in border placement calculations.
BTW, I've started a few JUnit tests myself (tests for basic functionality of the API and for the IO-related classes).
That's the bottom-up approach. URLresolving, image loading and whatnot could use this too (the current URL utils have bugs).
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
