Originally reported by: hansfn@users.sourceforge.net [This bug is also reported for gs 7.01 - see bug report 441566.] Running gsftopk on tmrm10ex.pfb (attached) fails. I have tried with version 5.50 and 6.51 and they both work fine. [gsftopk is a tex tool.] My system is Linux Suse 7.1 with gcc version 2.95.2. >gsftopk tmrm10ex 600 gsftopk(k) version 1.17/702 [13gs: Error: /undefined in k [cut] AFPL Ghostscript PRE-RELEASE 7.02: Unrecoverable error, exit code 1 Premature end of file
Comment originally by hansfn@users.sourceforge.net Logged In: YES user_id=21914 The failing command is >gsftopk tmrm10ex 600 [Unfortunate linebreak in first bug report.]
Comment originally by raph@users.sourceforge.net Logged In: YES user_id=379 I've poked around a bit, and find that this command line exhibits the problem: gsnd -c "(tmrm10ex.pfb) (r) file false /PFBDecode filter cvx exec" Splitting up the task into PFBDecode, followed by a separate exec, succeeds: gsnd -q -c "(tmrm10ex.pfb) (r) file false /PFBDecode filter 50000 string readstring pop print quit" > tmrm10ex.pfa gsnd -c "(tmrm10ex.pfa) (r) file cvx exec" Changing PFBDecode to do binary-to-hex conversion also succeeds: gsnd -c "(tmrm10ex.pfb) (r) file true /PFBDecode filter cvx exec" It looks like a fun stream bug of some kind. I traced through the code a bit, and it looks as though the eexec decode filter is being called well past the end of the actual data. There are several possible remedies: 1) Change render.ps in the TeX distribution to convert to hex in the PFBDecode. However, I wouldn't be surprised if there were other eexec bugs. 2) Find out why the eexec filter is being called more aggressively when the input is a filter than otherwise, and patch that. 3) Change eexec to recognize a string of '0' characters on input as an EOD.
Comment originally by hansfn@users.sourceforge.net Logged In: YES user_id=21914 I'm still waiting for a resolution to this bug. The bug is still present in version 7.05 (and 7.20) - I guess that's why it's still marked as open :-) Isn't it possible to use one of the solutions proposed by raph?
Comment originally by vojta@users.sourceforge.net Logged In: YES user_id=197485 I found the problem. The problem is not that the eexec decode filter is being called past the end of the actual data; quite the opposite (see below). Rather, the problem is that it is misidentifying the end of the actual data, and stopping early (in other words, returning EOD early). If that happens during a readstring command, then that string will be truncated and the remainder of the string will be read by the interpreter. This is what leads to the /undefined errors. I provide two alternative patches. The first one fixes the bug by correctly finding the end of the actual data. However, since the eexec operator specifies that one never reads more than 256 bytes ahead, and since the pad bytes are given in the text portion of a .PFB file, in hexadecimal, there is really no need to go to extra lengths to avoid reading (too far) past the end of the eexec data. Therefore I enclose a second set of diffs which removes this unnecessary code. This is the option that I prefer. Both fixes work properly on the 521 .PFB fonts supplied with the teTeX TeX distribution. --Paul Vojta
Comment originally by vojta@users.sourceforge.net Logged In: YES user_id=197485 Hmm... It seems that there's no way to attach a file to an existing bug report. So, I have put my patches on the web at the following URIs: http://math.berkeley.edu/~vojta/gsfix-short.pat http://math.berkeley.edu/~vojta/gsfix-preferred.pat (To avoid unfortunate line breaks, I have refrained from including the diffs in this message.) --Paul Vojta
Comment originally by hansfn@users.sourceforge.net Logged In: YES user_id=21914 In the hope that the patch will be added faster I have uploaded the patches from Paul Vojta. Thx, Paul. Hans
Comment originally by hansfn@users.sourceforge.net Logged In: YES user_id=21914 Is there any hope that the pacthes supplied by Paul Vojta will be added to coming releases of ghostscript? The bug is still open (yes, I know you know) and it's still a problem for me.
Comment originally by tillkamppeter@users.sourceforge.net Logged In: YES user_id=47862 I have applied Paul Vojta's "short patch" to the CVS of ESP GhostScript 7.05.x now. So this bug should be fixed there. Please test it. Go to http://www.cups.org/ghostscript.php to get it. Works also with spoolers other than CUPS.
In response to the earlier question: Yes, the bug is fixed in ESP ghostscript version 7.05.6. (It is still broken in AFPL gs 8.01, though.) I wasn't able to test the file tmrm10.pfb, but the bug can be checked by using any of the following fonts provided with teTeX: pcsl10 pcr5 cmcti9 rsfs7 rsfs10 wasy8 wasy9 wasyb10 A one-line way to do such a test is: gs -dNODISPLAY -q -c "(pcsl10.pfb) (r) file false /PFBDecode filter cvx exec quit" (excuse the unfortunate line break), or: gsftopk pcsl10 300
Closing for lack of activity.
This is still a bug (as of the released version 8.50, as well as the CVS version as of 01/19/05). And, it still has a patch waiting to be installed. The only reason that there has been no activity on this bug is that people have been waiting patiently for the patch to be installed. So, instead of annoying people by refusing to fix a known bug with a working patch, why don't you INSTALL THE DAMN PATCH!!!! and then mark it as resolved??? As a reminder, the URL for the patch (updated for 8.50) is: http://math.berkeley.edu/~vojta/gsfix-preferred.pat Sincerely, Paul Vojta
I didn't necessarily mean the lack of activity was on the reporter's side.
My concern with this patch is with the way PFB's are represented within PDF files (CUPS doesn't work with PDF input files). In PDF's there are three explicit "Length" values. Length2 indicates the eexec portion and Length3 is the final 512 bytes of 0's and the 'cleartomark' operator. Since Raph had looked at this, I'll hope that he takes a look at this, or if not, will let me know so I can look into it (and that he posts the relevant test files to allow me to duplicate it without having to fire up all kinds of linux utilities that I otherwise don't need to use).
this should get fixed with esp merge.
I have reproduced the bug post CUPS/ESP merge and the problem still exists. Here is the command line I used and the results: ./bin/gs -q -c "(tmrm10ex.pfb) (r) file false /PFBDecode filter cvx exec quit" Error: /undefined in --eexec-- Operand stack: --dict:8/11(L)-- --dict:8/11(L)-- Private --dict:18/18(L)-- --dict:8/11(L)-- CharStrings --dict:108/116(L)-- ffi (!F\322{35Jm\223\231\255\377\207\367\007\003\025\211\347\264\273\234bQ\r@\262\236\232NG\b\340\234\244\207\303@\371\327n\353\247\251\301-\035\312\273\271\207\222~y\330V\333\211\020\r?\305\234\246\340\256\366\372\365\375]\021i\213Q\256\230\326\315\330\375R\220~\305\222\\\354\363\277\207c\353\221t\3418M>\355\333\223\321-\267\321\334\332\022~\201 \350d\035\() 7025 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 1746 2 3 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:1142/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- --dict:1142/1684(ro)(G)-- --dict:18/18(L)-- --dict:108/116(L)-- Current allocation mode is local GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1
I have verified that the preferred patch at: http://math.berkeley.edu/~vojta/gsfix-preferred.pat does appear to fix the problem. Also I ran a local regression suite here and found that it caused no regressions. I recommend applying this patch.
Created attachment 4697 [details] 465936.patch This was tested on the cluster and caused no regression, and I tested the file for bug 689577 to make sure that it still works properly. Please review and approve for commit.
Created attachment 4698 [details] pcsl10.pfb Not "real" PostScript, but a PFB file used to test the fix. Thanks to Henry for digging this out of TeX
The patch from the comment #17 is adopted and committed as a rev. 9992. Regression testing shows no differences.