CMap issue in PDF file generated with recent TeX Live + Ghostscript

[Vincent Lefevre]

On 2021-10-30 01:06:54 +0200, Ulrike Fischer wrote:
> But if the core problem is that you are assigning more than one code
> point to the ligature
> 
>  \pdfglyphtounicode{ffi}{0066 0066 0069}
> 
> and that ghostscript can't handle this correctly 

FYI, this bug has now been fixed in Ghostscript (Ghostscript still
cannot handle this when generating the ToUnicode CMap, but now, it
no longer generates a CMap in such a case, so that its generated
PDF file no longer contains an incorrect CMap), but there is still
an issue with (at least)

\pdfglyphtounicode{Scaron}{0160}

which Ghostscript doesn't handle correctly:

  https://bugs.ghostscript.com/show_bug.cgi?id=704681

> then imho an empty glyphtounicode.tex  is only a workaround.

Unfortunately, workarounds yield other issues one day or another.
This has happened recently when using the acmart class, due to
incorrect glyph names in the libertine font. So the new workaround
is to have a glyphtounicode.tex file containing only

\pdfglyphtounicode{f}{0066}
\pdfglyphtounicode{i}{0069}
\pdfglyphtounicode{l}{006C}

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)