Martin Schröder
On 2006-03-15 15:06:43 +0100, Frank Küster wrote:
Martin Schröder
wrote: This will only get you so far. If you want to compare PDFs, you should not test for identical files, but for identical output: Render the PDF to a bitmap (e.g. with ghostscript) and compare the generated bitmaps. Otherwise your test will fail whenever the output of pdfTeX is changed in any way.
That's a point; on the other hand, all I get then is glyphs on a page, but the information about the internal structure is lost: hyperlinks, character information (will a search for "fl" find the fl ligature, or will "ü" be pasted correctly?), etc.
How far will you get with the logfile with a suitable combination of \tracingoutput etc.?
I don't know; I have never delved into font tracing commands. I'm also not sure that this is the best approach, because when we develop a testing framework, we want it to be extensible and easy to use, even for e.g. package authors. If they have a version of their package that produces a particular pdf feature (like a special internal hyperlink pointing to exactly the right place), they want to make sure that future versions don't loose that feature. For this, a suitable pdf file comparison is all that's needed. Parsing the log file might additionally be helpful to find out what's wrong, but it only works if the testing framework already considered this feature. Also, in case I'm one of the developers of this testing framework, I'd rather concentrate on implementing it cleanly, extensible, maintainable, etc., and not so much on learning about pdf internals I didn't need up to now, or pdfTeX-special tracing possibilities. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)