Re: gs 10.04 will break doc builds again
> It seems that the Ghostscript generated PDF is broken > regardless of LilyPond or extractpdfmark. > > I tested Ghostscript GIT PRERELEASE at > commit 99b48f1992844e30ab4b05dbb2764ba99f7b66f4 > Date: Mon Feb 19 08:33:23 2024 + > . > Here's results. > > ``` > $ cat test.ps > /NimbusSans-Regular findfont 14 scalefont setfont > 50 100 moveto > (Hello World) show > > $ ./gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=test.pdf test.ps > > $ qpdf --check test.pdf > checking test.pdf > PDF Version: 1.7 > File is not encrypted > WARNING: test.pdf: object 6/0: error reading object: integer out of range > converting 889058230272 from a 8-byte signed type to a 4-byte signed type > WARNING: test.pdf (object 9 0, offset 100): stream dictionary lacks /Length > key > WARNING: test.pdf (object 9 0, offset 146): attempting to recover stream > length > WARNING: test.pdf (object 9 0, offset 146): recovered stream length: 82 > File is not linearized > qpdf: operation succeeded with warnings > > $ > ``` Interesting. I cannot reproduce this failure: if I compile current ghostpdl 'master' (commit b809058c5ea0cc5689d8b7c15f191a440c9bb426), everything works fine; your example PS file compiles correctly, and 'qdf --check' (built from current git) passes, too. I'm on a GNU/Linux box in case this matters. Werner
Re: gs 10.04 will break doc builds again
> `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. > [...snip...] > > Sigh. Masamichi-san, please have a look! It seems that the Ghostscript generated PDF is broken regardless of LilyPond or extractpdfmark. I tested Ghostscript GIT PRERELEASE at commit 99b48f1992844e30ab4b05dbb2764ba99f7b66f4 Date: Mon Feb 19 08:33:23 2024 + . Here's results. ``` $ cat test.ps /NimbusSans-Regular findfont 14 scalefont setfont 50 100 moveto (Hello World) show $ ./gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=test.pdf test.ps $ qpdf --check test.pdf checking test.pdf PDF Version: 1.7 File is not encrypted WARNING: test.pdf: object 6/0: error reading object: integer out of range converting 889058230272 from a 8-byte signed type to a 4-byte signed type WARNING: test.pdf (object 9 0, offset 100): stream dictionary lacks /Length key WARNING: test.pdf (object 9 0, offset 146): attempting to recover stream length WARNING: test.pdf (object 9 0, offset 146): recovered stream length: 82 File is not linearized qpdf: operation succeeded with warnings $ ```
gs 10.04 will break doc builds again
`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 Date: Mon Feb 19 08:33:23 2024 + 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
