[tex-live] reproducible builds with xetex/xdvipdfmx: /CMapName contains path.

Zdenek Wagner zdenek.wagner at gmail.com
Tue Nov 6 14:36:14 CET 2018


út 6. 11. 2018 v 13:11 odesílatel Ulrike Fischer <news3 at nililand.de> napsal:

> If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
> get an absolute path in the pdf:
>
> /CMapName
>
> /d:-texlive-2018-texmf-dist-fonts-opentype-public-lm-lmroman10-regular.otf,000-UTF16
> 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.

>
> \documentclass{article}
>
> \begin{document}
> \font\test=["lmroman10-regular.otf"] \test abc
> \end{document}
>
> (setting SOURCE_DATE_EPOCH and FORCE_SOURCE_DATE doesn't change the
> output).
>
> --
> Ulrike Fischer
> http://www.troubleshooting-tex.de/



Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20181106/c5aed409/attachment.html>


More information about the tex-live mailing list