[gs-bugs] [Bug 691316] { /ISOLatin2Encoding findencoding } fails

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Fri May 21 15:24:56 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691316

--- Comment #25 from Christopher Yeleighton <giecrilj at stegny.2a.pl> 2010-05-21 15:24:54 UTC ---
(In reply to comment #23)
> (In reply to comment #21)
> > The notion of named resources (LanguageLevel 2) supports *the second method*. A
> > resource is a collection of named objects that either reside in VM or can be
> > located and *brought into VM on demand*. 
> 
> "*Either* reside in VM *or* can be located and brought into VM on demand". The
> text does not say that resources must not be loaded into VM until demanded.
> While it supports loading on demand it does not preclude pre-loading. Many
> other PostScript interpreters also preload resources. In fact I'm only aware of
> one which doesn't.
> 
> 
> > Forced preloading of all existing Encoding resources at startup time is
> > incompatible with this text.  
> 
> No it is not, the resource may exist in VM after startup and so need not be
> loaded when demanded. The text does not require that resources *not* be present
> unless requested.
> 

You gave perfect reasons why only standard encoding resources should be loaded
into VM for a generic job.  I (obviously) agree with it; accordingly, custom
(user-specific or site-specific) resources should not be preloaded.

> 
> > startup is insane, especially when a failure to do so causes the VM to
> > completely fail.
> 
> Loading a broken resource fails, true. Loading any broken PostScript program
> fails, it does not crash and while the failure may seem inexplicable to you, it
> is meaningful to others. Many PostScript errors fall into this category.

I can see no justification for autoloading code from a file relative to the
*current directory* during startup, without the user requesting anything to be
loaded, and failing because of that.

Besides, it turns out that while my code 

{ (gs_il2_e.ps) runlibfile } 

fails, 
the supposedly equivalent code 

{ (/usr/share/ghostscript/8.64/lib/gs_il2_e.ps) run }

runs happily and does what it should to do.

It looks like a problem in the implementation of /runlibfile.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list