regression in TeX Live 2023 concerning some math characters

[Vincent Lefevre]

On 2023-11-24 13:07:56 +0100, Vincent Lefevre wrote:
> The name glyphtounicode.tex was chosen on purpose in 2021 in order to
> override the system one when using pdflatex, because the system one
> was triggering a bug in Ghostscript[*]. I've done various tests, and
> though this bug may still be present, Ghostscript seems to generate
> small ToUnicode CMaps for the needed characters (the more complete
> ToUnicode CMap generated by pdflatex is dropped, but it seems useless
> in practice). So they is no longer need for any workaround.
> 
> [*] https://bugs.ghostscript.com/show_bug.cgi?id=704674

Note: This is correct with Ghostscript 10.02.1 from Debian/unstable,
which generates (e.g. via ps2pdf)

<08><08><2295>
<09><09><2296>
<0a><0a><2297>

(corresponding to ⊕, ⊖ and ⊗). But Ghostscript 10.0.0 in Debian/stable
generates an incorrect ToUnicode CMap:

<08><08><00b7>
<09><09><00b8>
<0a><0a><00b9>

yielding

────────────────────────
x′ ; · ; ¸ ; ¹ ; ℓ ; OK.
────────────────────────

with pdftotext (current poppler version).

Note that when no ToUnicode CMaps are generated (which was the case
when my glyphtounicode.tex file was in effect), pdftotext gives:

────────────────────────
x0 ; ⊕ ;

; ⊗ ; ` ; OK.
────────────────────────

(see my initial message in this thread). ⊕ and ⊗ appear correctly
because in the absence of a ToUnicode CMap, poppler uses the glyph
names; and ⊖ doesn't because poppler doesn't have this character
in its database (which is rather strange since it has ⊕ and ⊗).

-- 
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)