Created attachment 22833 [details] Sample for pdf 2 ps conversion with bug Original issue was found using Asymptote program, which rely on Ghostscript for measuring text metrics. See https://github.com/vectorgraphics/asymptote/issues/319. During execution of texpath() command Asymptote calls GS several times for creating intermediate pdf and ps files. Until 9.56 everything was working fine with no complains both on Linux and FreeBSD. From the 9.56 things changed, now ps2write device produces ps file without drawing command l, c, m and so on. But Asymptote rely on file internals and should have these commands open (not compressed?). So, read data are further forwarded for calculation and in a verbose mode (asy's flag -vvvv) are printed to console like that: M -0.000488281 -0.00183105C 5.26123 -5.27136 5.26123 -2.38855 2.87061 -0.00183105C -0.000488281 -10.5292 2.87061 -10.5292 5.26123 -8.15808C -5.27002 -5.27136 -5.27002 -8.15808 -2.87939 -10.5292C -0.000488281 -0.00183105 -2.87939 -0.00183105 -5.27002 -2.38855cM 0.0 0.0M -5.27002 96.2286L -2.18799 96.2286L ... With usage of gs 9.56.1 these data lines are not available. So, specific problem is the conversion of a pdf file to ps during Asymptote processing. I've attached pdf file and both output, on for GS 9.54 and 9.56, named t__54.ps and t__56.ps respectively. I was not able to find startup configuration differences between 9.54 and 9.56 for this behavior. If it not a bug, please give a hint how to instruct GS to revert previous behavior.
(In reply to dmitrys99 from comment #0) > During execution of texpath() command Asymptote calls GS several times for > creating intermediate pdf and ps files. Well that sounds like a bad idea, if you are round-tripping the input, you will end up with the 'lowest common denominator'. > From the 9.56 things changed, now ps2write device produces ps file without > drawing command l, c, m and so on. > > But Asymptote rely on file internals and should have these commands open > (not compressed?). Nothing to do with compression. The original PDF file draws test, using a CIDFont. The output from 9.56 draws the same text using a Font (we don't support CIDFont output in ps2write). The output from 9.54 does not contain a font, the text has been drawn using vector linework. > So, specific problem is the conversion of a pdf file to ps during Asymptote > processing. The actual problem is that the command line is using a limited way to get text drawn as linework. The -dNOCACHE switch tells the **PostScript** interpreter not to use a glyph cache, which causes it to draw all the text as linework. In general usage this is undesirable as it is slower. With the pdfwrite family of devices it also produces larger output. It also only works with the PostScript interpreter. In old versions of Ghostscript the PDF interpreter is in fact a PostScript program, so the PostScript interpreter runs the PostScript program which interprets the PDF file. Current versions of Ghostscript have a new PDF interpreter which is written in C, not PostScript. As a result switches which affect the PostScript interpreter do not always affect the new PDF interpreter. However, using -dNOCACHE is an ugly hack; the correct way to get text drawn as linework from the pdfwrite family of devices is to use the control intended for that purpose. https://ghostscript.com/doc/current/VectorDevices.htm#COMMON Look for the -dNoOutpuFonts switch. Since this is a device control it works no matter what the input is; PDF, PostScript, PCL, XPS etc.