2

In a huge book I edit, I sometimes simplify (beautify, or change in some other way) the global macros defined in the preamble via \def or \(new|renew|provide)command and then observe whether the change had any effect on the compilation time and on the output PDF file. For this purpose, I measure the times for compiling the book via \usr\bin\time -p <my compilation command> and compare the file before the changes with the file after the changes with diff -a book_before_the_changes.pdf book_after_the_changes.pdf. When the macro simplification had no effect, the only change diff spits out is a human-readable ACSII timestamp, which I can read off the screen. When the macro simplification did have some effect, diff spits out a bunch of unreadable gibberish, which leads me to examine the situation further by a command such as diffpdf, which takes way, way longer.

Recently, I switched from pdflatex to xelatex, which compresses the output PDF files in such a way that diff -a book_before_the_changes.pdf book_after_the_changes.pdf ALWAYS outputs unreadable gibberish. Is there a way to handle this problem, e.g., by preventing the compression, or by quickly comparing the previous and the current version for meaningful changes via some other utility? If there is such a way, what would it be?

Improve this question
3
  • Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
    – user170109
    Apr 3, 2019 at 19:38
  • I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
    – user170109
    Apr 3, 2019 at 20:01
  • agreed no decompress options in diffutils
    – user170109
    Apr 3, 2019 at 20:06

1 Answer 1

Reset to default
3

You can avoid the compression with a \special:

\documentclass{article}

\special{dvipdfmx:config z 0}
\begin{document}
blbl

\end{document}

The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.

Improve this answer
4
  • Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
    – Ulrike Fischer
    Apr 3, 2019 at 19:54
  • 2
    Also xelatex -output-driver="xdvipdfmx -z 0" can be used. I'm not sure it's possible to act also on object streams.
    – egreg
    Apr 3, 2019 at 19:58
  • @egreg object streams can be set with \special{dvipdfmx:config C 0x40} (see regression-test).
    – Ulrike Fischer
    Apr 3, 2019 at 20:02
  • 1
    Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
    – Ulrike Fischer
    Apr 3, 2019 at 20:44

You must log in to answer this question.