0

The following MNWE fails with TeX Live 2021 onwards.

\documentclass{article}
\usepackage{dictsym}
\begin{document}
  \dsbiological
\end{document}

Compilation ends with

<</usr/local/texlive/2023/texmf-dist/fonts/type1/public/dictsym/dictsym.pfb>>
    !pdfTeX error: pdflatex: builtin glyph names is empty
     ==> Fatal error occurred, no output PDF file produced!

According to David Carlisle's answer, this is because TL 2021 and later adds a glyphtounicode mapping by default, but dictsym is incompatible with this. His workaround involved disabling the mapping globally, but Ulrike Fischer's answer to a later question suggested that adding

\pdfmapline{=dictsym DictSym <dictsym.pfb}

be used instead to 'overwrite and correct the original map lines'. And, indeed, the following MWE works.

\documentclass{article}
\usepackage{dictsym}
\pdfmapline{=dictsym DictSym <dictsym.pfb}
\begin{document}
  \dsbiological
\end{document}

This changes the original map line in two ways.

  1. An = is added at the start (if this survives \pdfmapline).
  2. < replaces << so pdfTeX will embed only a subset of the font rather than the whole thing.

But I am curious about the =, which I could not find documented in pdfTeX's documentation, where the syntax of map file lines is explained. Note that the following MWE also compiles.

\documentclass{article}
\usepackage{dictsym}
\pdfmapline{dictsym DictSym <dictsym.pfb}
\begin{document}
  \dsbiological
\end{document}

Basic testing suggests that it is the change from << to < which makes the difference. While both

\pdfmapline{dictsym DictSym <dictsym.pfb}

and

\pdfmapline{=dictsym DictSym <dictsym.pfb}

work, neither

\pdfmapline{=dictsym DictSym <<dictsym.pfb}

nor the original

\pdfmapline{dictsym DictSym <<dictsym.pfb}

do.

According to this comment, omitting the equals may cause subtler problems, but the use of = isn't common in map files, as far as I've seen. (Perhaps it is specific to \pdfmapline?)

But further testing suggests the = is crucial after all. In some cases I get the same compilation error unless I include this change as well.

So, I'm puzzled on two counts.

  1. What exactly does the additional = do?
  2. How does embedding the entire font versus embedding only a subset interact with the glyphtounicode mapping?

In some cases (if scaled is not used?) the following works, too.

\usepackage{dictsym}
\font\f=dictsym
\pdfnobuiltintounicode \f

but this can't be how I should be using it as it fails otherwise. (I just thought it would be nice to have a transparent workaround.)


Detailed output for MNWE:

This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./prawf.tex
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-01-22>
(/usr/local/texlive/2023/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/local/texlive/2023/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2023/texmf-dist/tex/latex/dictsym/dictsym.sty
(/usr/local/texlive/2023/texmf-dist/tex/latex/psnfss/pifont.sty
(/usr/local/texlive/2023/texmf-dist/tex/latex/psnfss/upzd.fd)
(/usr/local/texlive/2023/texmf-dist/tex/latex/psnfss/upsy.fd))
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/keyval.sty))
(/usr/local/texlive/2023/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./prawf.aux) [1{/usr/local/texlive/2023/texmf-var/fonts/map/pdftex/updmap/pdft
ex.map}] (./prawf.aux) )</usr/local/texlive/2023/texmf-dist/fonts/type1/public/
amsfonts/cm/cmr10.pfb><</usr/local/texlive/2023/texmf-dist/fonts/type1/public/d
ictsym/dictsym.pfb>>
!pdfTeX error: pdflatex: builtin glyph names is empty
 ==> Fatal error occurred, no output PDF file produced!
10
  • 2
    The = is described in the pdftex manual. Search for the syntax of pdfmapfile and pdfmapline (around page28 or so). If means that the new entry replaces an existing one. Feb 3 at 8:31
  • 2
    @UlrikeFischer should I update that old answer with a pdfmapline version do you think? Feb 3 at 10:32
  • 1
    @DavidCarlisle imho simply replacing the map line is the best (and we should perhaps ask Karl if that can't be done directly for the two problematic fonts.) Feb 3 at 12:17
  • 1
    I have mailed the package authors (and Karl) Feb 3 at 12:45
  • 1
    @cfr see Marcel's comment here chat.stackexchange.com/transcript/message/60195236#60195236 Feb 3 at 16:23

0

You must log in to answer this question.

Browse other questions tagged .