[bug-gs] composite font inconsistency

[Kim Saunders]

--=-zkagxctf9iU6QGyh2VDB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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
-- 
Kim Saunders <kims@contrail.com.au>

--=-zkagxctf9iU6QGyh2VDB
Content-Disposition: attachment; filename=comp.ps
Content-Type: application/postscript; name=comp.ps
Content-Transfer-Encoding: 7bit

%!PS-Adobe

% define a composite font (MyFont), scale it, setfont
/MyFont dup
<<
	/FontType	0
	/FontMatrix	[ 1 0 0 1 0 0 ]
	/FDepVector
	[
		/Helvetica findfont
		/Helvetica-Bold findfont
	]
	/Encoding	[ 0 1 ]
	/FMapType	3
>> definefont pop findfont 20 scalefont setfont

20 100 moveto
% works under everything
(\377\000Hello) show

20 80 moveto
% works under gs, HP LJ 5L - but not Acrobat Distiller 5.0 (MacOS + Win32),
% Xerox DocuColor 2060
(\377\000Hello\377\001) show

--=-zkagxctf9iU6QGyh2VDB
Content-Disposition: attachment; filename=comp.log
Content-Type: application/octet-stream; name=comp.log
Content-Transfer-Encoding: base64

JSVbIEVycm9yOiByYW5nZWNoZWNrOyBPZmZlbmRpbmdDb21tYW5kOiBzaG93OyBFcnJvckluZm86
IENoYXJPZmZzZXRzIAAAAAQAIAACAAAAAGUAAAAAAAAAAAAAAP////8AAVJcZm9udHMvSGVsdmV0
aWNhACBdJSUNDVN0YWNrOg0o/wBIZWxsb/8BKQ0NDSUlWyBGbHVzaGluZzogcmVzdCBvZiBqb2Ig
KHRvIGVuZC1vZi1maWxlKSB3aWxsIGJlIGlnbm9yZWQgXSUlDSUlWyBXYXJuaW5nOiBQb3N0U2Ny
aXB0IGVycm9yLiBObyBQREYgZmlsZSBwcm9kdWNlZC4gXSAlJQ0=

--=-zkagxctf9iU6QGyh2VDB--