[bug-gs] composite font inconsistency

[Ray Johnston]

Kim,

Thanks for the thorough analysis.

Ghostscript doesn't really attempt to be 100% compatible with (some)
Adobe implementations. When we run the Genoa CET we see many instances
where we signal a different error than Adobe (mostly in cases where
the PLRM isn't specific). There may be Adobe implementations that
act the same as Ghostscript (but I doubt it). I think the HP printer
uses Xionics PostScript (another clone).

I also am not sure whether or not to interpret the test case as an
incomplete mapping or not. It is clear that a string ending with
\377 would be incomplete (missing the font number).

I hesitate to change Ghostscript to signal an error in this case
since the behaviour of stringwidth and/or show is not indeterminate
and we might have people that generate PostScript and rely on the
forgiving nature of Ghostscript (though I doubt it).

I also would like Raph to weigh in on this.

Obviously, if were up to us to make the change, we wouldn't (we
have plenty of other work), but if Raph thinks this is safe to
change, then we welcome your patch submitted to gs-code-review
@ghostscript.com.

Regards,
Ray
_______________________________________________________________

Kim Saunders wrote:

> Hi,
> 
> I've encountered an incosistency in the way that composite font escape
> codes are handled.
> 
> The situation regards the use of the `show' and `stringwidth' operators
> using operands that end in a composite font escape codes (e.g.,
> (\377\000hello\377\001)).
> 
> GhostScript handles this in a way that is, in my opinion, sensible -
> i.e., it is effectively a no-op, with the string being displayed in the
> same way it would be if the escape sequence weren't present.
> 
> However, certain PostScript implementations generate a rangecheck error
> when the `show' and 'stringwidth' operators are used on such strings -
> including Adobe Acrobat Distiller 5.0 (MacOs & Win32), and a Xerox
> DocuColor 2060. Other implementations, such as that on an HP LaserJet
> 5MP, behave in the same way as GhostScript (i.e., handling the string
> without an error).
> 
> My attempts to determine the correct behaviour from the PLRM (third
> edition, pages 359-360) have been inconclusive:
> 
> `The code length--the number of bytes extracted from the show string for
> each operation of the mapping algorithm--varies depending on the
> algorithm. Table 5.9 lists the mapping algorithms that the FMapType
> value can select. If the mapping of any string passed to a show operator
> is incomplete or if an attempt is made to index beyond the end of an
> Encoding or FDepVector array, a rangecheck error results.'
> 
> Is a string ending in a valid escape code an "incomplete mapping", or a
> degenerate form of a valid encoding?
> 
> `One byte is extracted from the show string. If it is equal to the value
> of the font's EscChar entry, the next byte is the font number, and
> subsequent bytes (until the next escape code) are character codes for
> that font. At the beginning of a show string, font 0 is selected. A font
> number equal to the escape code is treated specially; see Section
> 5.10.3, "Nested Composite Fonts."'
> 
> This refers to "subsequent bytes" _after_ the escape code, but does it
> neccesitate their presence, or merely describe what happens if the
> subsequent bytes happen to be there?
> 
> My personal views on this are that the gs interpretation/implementation
> is superior, but the mere fact that it is _different_ from the Adobe
> implementation caught me out - I expected my document to work under the
> Adoble implementation _because_ it worked under gs, and because I
> hadn't, to my knowledge, used any gs-specific features.
> 
> The solution would depend on any better interpretations of the `correct'
> thing to do, as well as whether correctness or Adobe compatability is
> the goal. To my mind, the latter approach would be the most useful in
> this situation. Even if is decided that gs implements these features
> `correctly', some kind of documentation of the difference, a warning, or
> an option adobe-compatability mode would be most convenient.
> 
> Please see attached example code, and log file from distiller.
> 
> Note that I would be interested in attempting to write a patch for this,
> should any modifications be deemed desirable.
> 
> Thanks

-- 
Ray Johnston
Director of Engineering
Artifex Software Inc.
______________________________________________________________________