Hans Hagen
- pdf itself is moving which may demand additional of different resources being added - the pdftex stream depends on for instance cm directives and font references and there has been changes in this area over time (improvements like collapsing, removing redundant code) - macro packages may change their implementations of annotations, color, graphics and such, which results in different object ordering, numbering and content - macro packages may add/support new features which in turn may result in differences between pdf files; - macro packages may improve/change/patch special things (hz metrics and such) - font resources may change (metrics are normally stable, but the rest may change)
I don't think that these arguments make such tests unuseful. If such changes occur, the tests will fail, and the known-good documents need to be regenerated and manually checked. However, most of the time this will *not* happen, and then the tests would be very helpful.
the best you can do is not to look at the pdf file, but to parse the log for errors, like overfull boxes which can be signals of old/new code doing weird things, missing fonts, map files, encodings and characters.
I don't think the log helps. The log files contain absolute paths, so they would need lots of replacements before you can even start comparing. They contain version information for the packages - but checking whether a new version gives identical results is one of our goals. And renamed files, or splitting a package into different input files loaded by the "master" file, would completely break when we would try to automatically parse the log file. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)