`gs` compiled from the current 'master' branch of the 'ghostpdl'
repository makes a doc build fail if 'extractpdfmark' gets used: In
the created `notation.pdf`, Emmentaler fonts are missing in all
included snippets.
The problem seems to be commit
```
commit 99b48f1992844e30ab4b05dbb2764ba99f7b66f4
Author: Ken Sharp <ken.sh...@artifex.com>
Date: Mon Feb 19 08:33:23 2024 +0000
pdfwrite - correct EmbedAllFonts=false and alter font embedding
Bug #707578 "-dEmbedAllFonts=false not behave correct after ghostscript
version 9.55"
The bug title is incorrect. The actual bug is that 9.55 was considering
whether a CIDFont was 'symbolic' for the purposes of embedding, when
EmbedAllFonts=false. This is incorrect, CIDFonts shouldn't be treated
as 'symbolic' at all.
For complicated reasons to do with 'nearest_encoding_index', the PDF
interpreter was correctly not embedding the CIDFonts, but the test in
'font_is_symbolic' was incorrect, so we address that here.
The reason the reporter thinks it should be the other way round was due
to the fact that their test file had all CIDFonts embedded, and all the
Fonts not embedded. After running through pdfwrite this led to a PDF
file where all the fonts are embedded, but the Fonts are substittued.
By setting EMbedAllFonts=false with 9.55 they got the Fonts not embedded
and the CIDFonts embedded, which was what they wanted.
Previously (the old PostScript-based PDF itnerpreter) we couldn't
determine whether a font was embedded in the input, so we couldn't
achieve that. However, now that we have a PDF interpreter which doesn't
rely on PostScript for it's font handling we can.
So the remainder of this commit builds on the embedded detection added
to the PDF interpreter by Chris in the last couple of commits. We now
add the FONT_INFO_EMBEDDED flag to the font_info() call in the
pdf_font_embed_status() function. If EmbedAllFonts is true, the
embedding status is known (PDF interpreter *only*) and the font was
NOT embedded in the input, then we don't embed it in the output. This is
a change in behaviour, previously we would embed a substitute.
Other interpreters should not see a change in behaviour.
```
Sigh. Masamichi-san, please have a look!
Werner
