[tex-live] reproducible builds with xetex/xdvipdfmx: /CMapName contains path.
zdenek.wagner at gmail.com
Tue Nov 6 15:11:45 CET 2018
út 6. 11. 2018 v 15:01 odesílatel David Carlisle <d.p.carlisle at gmail.com>
> On Tue, 6 Nov 2018 at 13:38, Zdenek Wagner <zdenek.wagner at gmail.com>
> > út 6. 11. 2018 v 13:11 odesílatel Ulrike Fischer <news3 at nililand.de>
> >> If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
> >> get an absolute path in the pdf:
> >> /CMapName
> >> def
> >> Is there a way to avoid this? It makes reproducible pdf testing with
> >> xelatex impossible.
> > It was introduced several years ago. The problem was that the search
> algorithm in XeTeX differed from the search algorithm of xdvipdfmx. Fonts
> may exist in several versions and may be incompatible, it was especially
> the case of FreeFont but other fonts are affected as well. It happened that
> several versions of the same font existed on the computer, XeTeX picked
> one, created xdv and xdvipdfmx built the PDF using another version and the
> result was garbage. The preference rules in all font systems are not only
> complex but quite often not obeyed. The absolute path ensures that XeTeX
> and xdvipdfmx use the same font so if you get garbage, you know why. I do
> not know whether there is a better way how to solve the problem.
> On the face of it that seems a good argument for xetex to put the
> absolute path in the xdv file so xdvipdfmx uses the same font, but
> does that necessarily imply that xdvipdfmx lists the full path in the
> resulting pdf output? If it could at least optionally not do that then
> testing of pdf would be easier to set up with reproducible build
No, PDF contains the font as embedded subset, not its path. The path makes
no sense for PDF viewers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tex-live