On 7/30/07, Arthur Reutenauer wrote:

...

I have patched 'pstoedit.dll' version 3.44 (0x6B674: 0x20 --> 0x25) and so it works with gs 8.57 for me!

(Yes, that 2-bit patch ;-)

Great! In the mean time I exchanged mail with the author of pstoedit (thanks to someone who forwarded my previous mail to him ;-) and it should be fixed in the next release of pstoedit (3.45). Actually the problem was (of course) a bit more complicated than what I first described and there was a reason why getorigfont should call itself recursively; and why it wouldn't work with newer versions of gs (I can explain it in case anyone is interested).

Anyway, glad I could help.

Well, you made 30, you can make 31 :) -- luigi ---------------------------------------------------------------- If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net

I'm interested, but it is good to post the explanation so it becomes part of the public record google can find.

Well, that wouldn't be the first time I report a bug indirectly; so here goes: When font dictionaries are altered (by changing FontMatrix, etc ...) in PostScript, it is customary to keep a copy of the original dictionary, which appears in the modified dictionary as a object associated with the key OrigFont. Now, if a programmer wants to access the original dictionary, he / she must of course expect to search the dictionary recursively; hence the original definition of getorigfont (which wasn't that bad actually): % Here the stack must contain a font dictionary /getorigfont { dup /OrigFont known { /OrigFont get getorigfont } if } def This definition could have worked in other languages ... but not in PostScript, because of the nature of dictionaries: they're so-called “composite objects”, meaning that if you copy this object on the stack you get eaxctly the same physical object (this is a bit like pointers in C); for further details see the PostScript Language Reference Manual, section 3.3.1 (http://www.adobe.com/products/postscript/pdfs/PLRM.pdf). Anyway, this means that a dictionary can contain itself, and this was the case with the font at stake (LMSans by the Latin Modern team, converted from cminch by Knuth). So retrieving OrigFont yielded the exact same dictionary at each iteration, and this created the endless loop. This (somewhat weird) definition of the font only started with Ghostscript 8.56; this is why the bug didn't happen with older versions of Ghostscript. The real bugfix Wolfgang Glunz (author of pstoedit) did was to check at each iteration if the retrieved OrigFont dictionary was actually different, thus avoiding the loop, but still looking for the “most original” font dictionary. As I said, the new code will be incorporated in pstoedit 3.45 and looks like: % font getorigfont font /getorigfont { 210 pscover % % retrieves the father font of the input font if possible % returns a font. % dup /OrigFont known % OrigFont is provided at least if Font was generated with makefont { 211 pscover dup % for comparison dup /OrigFont get ne % ne is a weak check against recursion % but is was needed from gs8.56 { /OrigFont get getorigfont } if } if } def For people wanting to experiment with pstoedit, you will certainly find the -pscover switch most useful: it writes to the file “pscover.txt” a unique number corresponding to a particular chunk of code in the PostScript prologue (the psinXXXXXX file); look for “xyz pscover”, where xyz is a integral number; this is how I found the bug in the first place. That's about all. Hope you had fun reading this, Arthur