This bug is similar to #686911, but the fix for that problem did not cover this case. I'm opening this bug separately since it is now a customer issue. The attached test file, once distilled to PDF with GS, contains font names like F30, F19, etc, instead of the actual font names.
Created attachment 284 [details] LN-14-HLWX-23-07-HP.gz
This isn't a Ghostscript bug. It's a problem of NewsRoom that generated an embedded document of the original document. It creates font copies replacing FontName, and the original font name is lost. The problem is in the "procset hermes_ps 1.0 3", in the procedure ReEncodeSmall. IMO it is coded with insufficient understadning of the Postscript font machinery and should be fixed. Possibly we could make a special workaround within a week by a customer's request. Closing the bug as invalid. Reopen it if the customer issues a NRE proposal.
Adobe Distiller appears to retain font names with this document. Therefore the previous followup appears wrong. Rather the font name is replaced, it can be accessed through the .OrigFont key, which was implemented recently. But it appears insufficient, because .OrigFont points to an URW font substituted for a standard font, and the original name is lost again. Need to adjust the .OrigFont reference while substituting fonts via Fontmap.
Created attachment 286 [details] An experimental patch Attaching an experimental patch. It allows to access the original font name via .OrigFont key in the font dictionary. The key .OrigFont was introduced for accessing the original font matrix. This patch improves the PDF output but doesn't fix the problem. The improvement is that names like /F11 are changed to /Courier or /Helvetica. However Adobe Distiller writes Excelsior and ExcelsiorInsertio. Here is the bottom of the problem. The Fontmap logics shares a single font instance for all substituted fonts. For example, with the test document the font Courier substitutes both Excelsior and ExcelsiorInsertio, and there is no place for storing both names. Another problem with this patch is that the change to gs_fonts.ps causes a problem with FontMatrix, if the <font> argument of .aliasfont is already defined: the .OrigFont must not be replaced in this case. Thus, this patch is wrong and must not be committed. It is only useful for understanding the nature of the original problem.
Changing the assignment to Ray because it needs a decision about changing the Fontmap logics. My suggestion is to apply gs_resmp.ps methods to implement a new logics of Fontmap, keeping the old syntax of Fontmap. I can do that if the project is approved and assigned to me.
Customer says that the same problems happen when all fonts are present and substitution doesn't happen. Also, they would like a solution as soon as possible.
Created attachment 298 [details] Revised experimental patch This revision to Igor's patched gs_fonts.ps adds an aliased font entry when the font is automatically substituted.
I found what appears to be an oversight in the '.stdsubstfont' procedure. When fonts are substituted due to explicit alias entries in the Fontmap, both the requested font and the actual fonts are created, each with the appropriate Fontname. With my addition, the requested font is aliased as well when automatic substitution is performed. With this additional change to Igor's experimental patch, the font names are passed through pdfwrite to the PDF file (as subset fonts) as expected. Adobe Acrobat Reader shows the font names as subsets as expected. If Igor agrees that this patch is acceptable, he can commit the patch and close the bug. Thus I will reassign the bug back to Igor.
The "Revised experimental patch" fixes the problem with LN-14-HLWX-23-07-HP, but causes regressions : 1. with comparefiles/0.pdf : the PDF refers the substituted fonts, but with no patch it refers same fonts as the original document. 2. with comparefiles/313-01.ps : the test fails. There are multiple other differences with comparefiles/*.pdf , which I did not analyze. Thus the patch should not commit.
The bug 687106 may be related to this problem.
Created attachment 348 [details] A patch for fixing gs_fonts.ps inconsistency In gs_fonts.ps comments about procedure arguments do not correspond to the code. Trying to reconstruct them from the code I detected that some branches are coded with assumptions, which are never satisfied. Analyzing the history, I can see that the intended behavior before the revision Revision 1.24 (Nov 21, 2002) dramatically differ from one after it, and multiple rudiments of the old one never work with the new one. The change was done by Alex for the bug 637424, and approved by Ray. http://www.ghostscript.com/pipermail/gs-code-review/2002-November/003447.html http://www.ghostscript.com/pipermail/gs-code-review/2002-November/003471.html A followup to the bug 637424 says : The standard procedure takes a name and returns another name Where this assumption comes from ?????? It is a documented requirement ? Or Alex guessed it just reading the default implementation in CPSI ? The old code assumes that it ADDS an alias to the stack. The patch broken the old behavior and left several rudimentary code fragments. Now I need to know how to resolve all this. Either we move to the new behavior and remove the rudiments. Or we go back to the old behavior and reopen 637424. Or we try to maintain both cases. Attaching a patch with improved comments to gs_fonts.ps .
Ray suggested to set a new special attribute to the font dictionary, when any invocation of "pop defaultfontname" in gs_fonts.ps happens, allowing pdfwrite to know about substituted fonts. A detection of "pop defaultfontname" is textual, but there is no easy way to transfer the information to the font dictionary. It requires to change the op stack layout for many procedures in gs_fonts.ps . However We need to distinguish cases : 1. defaultfontname findfont (embed defaultfontname == key_name); 2. /x findfont where x substitutes to defaultfontname (embed x == key_name); 3. /y findfont where y aliases to z (embed y == key_name); 4. /f findfont dup length copy dup /FontName /h put /g exch definefont (proceed (1),(2),(3) with f, but .OrigFont points to a substitute, .OrigFont, font_name and key_name are unuseful). So it looks as we need .OrigName to point to the aliased font, rather than the original font. Such a change shouldn't make a harm to FontMatrix.
... and substituted/aliased fonts must have individual font dictionaries, rather than sharing them.
Patches http://www.ghostscript.com/pipermail/gs-cvs/2003-October/003733.html http://www.ghostscript.com/pipermail/gs-cvs/2003-October/003734.html http://www.ghostscript.com/pipermail/gs-cvs/2003-October/003735.html
*** Bug 687112 has been marked as a duplicate of this bug. ***
*** Bug 687111 has been marked as a duplicate of this bug. ***