Originally reported by: jackiem@users.sourceforge.net Customer #710. The attached file simple.ps causes a /rangechck in --.type1execchar-- error in Ghostscript. This only seems to happen is the code is surrounded by save/restore, and only with certain fonts (the example uses Optima. s/Optima/Times-Roman/ doesn't trigger the error).
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 The font Optima [Copyright (c) 1981 Allied Corporation, Copyright (c) 1985, 1987 Adobe % Systems Incorporated] contains Subrs array of 99 elements. Perhaps if it is loaded after 'save', the size of the array appears to be equal to 46. Probably something is wrong in memory management. See also bug #468389 - possibly the old fix for it was wrong.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 Oops, the previous followup is wrong. The font computes the output resolution and chooses different Subrs and CharStrings for low and high resolutions. Variants of Subrs array have lengths 99 and 46. Perhaps it is still not clear (1) why Subrs appears to be incompatible with CharStrings, and (2) why it depends on the 'save' context.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 The font is designed for loading into local VM. Perhaps GS sets the global allocation mode while loading the font. Due to this Subrs and CharStrings becomes inconsistent (the font builds them in different ways). This explais why the test fails. But this doesn't explain, why the effect depends on 'save' context.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 Here is my complete analyzis of the problem. 1. The font is designed to load into local VM. It uses save/restore while building Subrs and CharStrings, and supposes that the changes are being undone by 'restore'. 2. GS sets the global allocation mode when it loads the font. Therefore (1) cannot work correctly. 3. If the font loading is in 'save' context, the global VM doesn't unwind by the internal font's 'restore'. As the result Subrs and CharStrings become inconsistent. 4. If the font loading is not in 'save' context, the internal font's restore appears to be the outermost restore, and it unwinds the global memory (see PLRM). In this case the font doesn't fail. It works fine for small resolutions, but it uses the small resolution outlines with high resolutions (the last is a wrong behavior). 5. IMHO GS should execute 'true startjob' before running a document. PLRM3 specifies that startjob must execute 'save'. In this case the internal font's restore would be not the outermost one and must not unwind the global VM, so the font behavior would not depend on 'save' context. My conclusion is that 2 things to be fixed in GS : 1. Run startjob before interpreting a document. 2. Do not enforce the global allocation mode loading a font, at least for this font. Both changes may cause significant incompatibility to old GS versions. I think this should be a development project rather than a small bug fix, including an investigations of the possible incompatibility. Old GS developers should assist it at least in the design level.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 The patch http://www.ghostscript.com/pipermail/gs-code-review/2002- January/001762.html has been committed. It's only an additioin to Issues.htm, describing a development project to be fulfilled some later.
No sample file, so even if we wanted to work on this, we can't.