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

[Zdenek Wagner]

út 6. 11. 2018 v 15:01 odesílatel David Carlisle <d.p.carlisle at gmail.com>
napsal:

> On Tue, 6 Nov 2018 at 13:38, Zdenek Wagner <zdenek.wagner at gmail.com>
> wrote:
> >
> > ú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.
>
>
> 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
> settings
>

No, PDF contains the font as embedded subset, not its path. The path makes
no sense for PDF viewers.

>
> David
>


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/efa0866c/attachment.html>