Discussion:
reproducible builds with xetex/xdvipdfmx: /CMapName contains path.
(too old to reply)
Ulrike Fischer
2018-11-06 12:10:38 UTC
Permalink
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.

\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/
Zdenek Wagner
2018-11-06 13:36:14 UTC
Permalink
Post by Ulrike Fischer
If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
/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.
Post by Ulrike Fischer
\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
David Carlisle
2018-11-06 14:01:46 UTC
Permalink
Post by Ulrike Fischer
If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
/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

David
Zdenek Wagner
2018-11-06 14:11:45 UTC
Permalink
Post by Ulrike Fischer
Post by Zdenek Wagner
Post by Ulrike Fischer
If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
/CMapName
/d:-texlive-2018-texmf-dist-fonts-opentype-public-lm-lmroman10-regular.otf,000-UTF16
Post by Zdenek Wagner
Post by Ulrike Fischer
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.
Post by Ulrike Fischer
David
Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Hironobu Yamashita
2018-11-06 14:16:31 UTC
Permalink
Hi all,
Post by Ulrike Fischer
If I compile the following with xelatex --no-pdf and xdvidfpmx -z0 I
/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.
That issue should have been fixed very recently, in r48418:

* cmap_write.c, tt_cmap.[ch], type0.c: Fixed a bug that CMapName in CMap
resource is not properly written. Not correctly handles PostScript
name and string
objects. Use CMapName constructed from font's BaseFont.

Hironobu Yamashita
David Carlisle
2018-11-06 14:21:11 UTC
Permalink
On Tue, 6 Nov 2018 at 14:16, Hironobu Yamashita
Oh that sounds good, thanks.

David
Ulrike Fischer
2018-11-06 15:00:04 UTC
Permalink
I just tested with the newest xetex from win32tex.org and now get

/CMapName /HEXFDP+LMRoman10-Regular-UTF16 def

So it really looks fixed ;-)
--
Ulrike Fischer
https://www.troubleshooting-tex.de/
David Carlisle
2018-11-06 14:19:37 UTC
Permalink
No, PDF contains the font as embedded subset, not its path. The path makes no sense for PDF viewers.
But that is the whole issue: the PDF does have the path:

hence I fail the pdf test that Ulrike generated on windows, with this diff:

! /CMapName /c:-texlive-2018-texmf-dist-fonts-opentype-public-lm-lmroman12-bold.otf,000-UTF16
def
! /CMapName /-usr-local-texlive-2018-texmf-dist-fonts-opentype-public-lm-lmroman12-bold.otf,000-UTF16
def

David
Loading...