Hi, this applies to current HEAD. Older versions of dvips apparently do not pre-fill the Encoding array with .notdef This didn't cause problems with previous versions of ghostscript, but current HEAD complains $ gs ~/t.ps GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Font OmegaSerifGreek-Bold is being rendered with FAPI=FreeType Error: /typecheck in definefont Operand stack: false OmegaSerifGreek-Bold --dict:14/20(L)-- Font Adding "0 1 255 {1 index exch /.notdef put} for" to the Encoding array avoids this problem. Unfortunately we have a large number of Postscript files which were generated with older dvips. Is there a way to handle this gracefully without the need to update all old files? Thanks T.
Created attachment 6273 [details] simple tex produced ps file which gives error with current gs HEAD
(In reply to comment #0) > Is there a way to handle this gracefully > without the need to update all old files? It is up to Ken to fix this properly; before that you can use -dDisableFAPI to disable to freetype code and go back to the old behavior. Ken: we probably want to document the -dDisableFAPI switch?
The switch will go into the documentation, I did note it in the email we sent to gs-devel, as I thought that was the place most likely to be useful. I'll look into why this is an error, I didn't think we'd changed anything here, so its a surprise. Its perfectly legal not to pre-fill the Encoding array with /.notdef, if a little unusual.
Fixed in revision 11215, patch here: http://ghostscript.com/pipermail/gs-cvs/2010-May/010988.html Thanks for testing the new FreeType implementation and do please raise reports for any other issues you find.
I have added as r11228 the folllow paragraph in three places ("How to build Ghostscript with FreeType" in Make.htm, and "Debug Switches" and "Appendix: Running Ghostscript with third-party font renderers" in Use.htm): ------------------------ With switching to freetype 2 as the default font renderer in April 2010, we added a new switch: "-dDisableFAPI=true" to revert to the older behavior, just in case serious regression happens that cannot be resolved in a timely manner. ------------------------ BTW, there is some burbs about pdfwrite not using freetype in "Running Ghostscript with third-party font renderers" even when it is enabled. Is that still true? Some of the freetype related documentation needs to be updated.
(In reply to comment #5) > BTW, there is some burbs about pdfwrite not using freetype in "Running > Ghostscript with third-party font renderers" even when it is enabled. Is that > still true? I'm not at all sure why it was ever there, I suspect it may have not worked well at some point, but that was probably a long time ago. As you know the regression suite includes pdfwrite testing and there have been no reported problems. I had intended to remove the note when I added documentation for the -dDisableFAPI switch. I was also going to review the whole font/FAPI/rendering engine issue throughout the documentation at that time. But if you want to do it, please go ahead ;-)
(In reply to comment #6) > I had intended to remove the note when I added documentation for the > -dDisableFAPI switch. I was also going to review the whole font/FAPI/rendering > engine issue throughout the documentation at that time. But if you want to do > it, please go ahead ;-) I had filed a documentation bug for freetype/FAPI as bug 691294 , and put it to Chris; but we could all do a bit on the side on it...