[XeTeX] on GSUB

[Jonathan Kew]

On 2 Jul 2006, at 4:44 pm, Ralf Stubner wrote:

> Jonathan Kew <jonathan_kew at sil.org> writes:
>
>> I've double-checked the Adobe "Type 2 Charstring Format" spec, and
>> this doesn't even mention the 'seac' op-code (that's only found in
>> the "Type 1 Font Format" spec).
>>
>> It seems to me that the Type 2 spec is rather unclear, as it claims
>> (page 1) that "The Type 2 charstring operators are (with one
>> exception) a superset of the Type 1 operators." (It doesn't seem to
>> say explicitly what the "one exception" is supposed to be.) But then
>> it goes on to document the individual operators.... and omits
>> considerably more than one of those that were in Type 1, marking the
>> corresponding command codes as "reserved" in the tables in  
>> Appendix A.
>>
>> So not only 'seac' but several other opcodes from T1 are perhaps not
>> supported in T2, depending whether we believe the general "superset"
>> statement or the actual lists and descriptions in the T2 spec.
>
> I think the error message from (x)dvipdfmx is slightly missleading  
> here.
> I looked into cs_type2.c, and the seac op-code is not defined for  
> Type 2
> charstrings. The error message aabout seac being depricated is issued
> when the endchar opcode is processed and four or five entries are  
> found
> on the stack (cs_type2.c line 327--342). Using endchar with several
> arguments as a replacement for seac is documented and marked as
> deprecated in Appendix C of the Type 2 specs.

Yes, the message is not strictly accurate.

I was curious where you found this, as my copy of the Type 2 spec  
didn't mention it; but finally managed to get a newer copy (not from  
Adobe's site, where it is "currently unavailable"), and I see this  
has been added. However, note that Appendix C begins:

<quote>
The following constructs may appear in the CFF encoded font
programs in Portable Document Format (PDF) documents.
Since that usage predates OpenType fonts (OTF), the following
obsolete and deprecated operators should be supported in all
Type 2 charstring processors that may encounter such
programs.
</quote>

According to this, the use of endchar with 4 arguments to stand in  
for seac is permitted (although obsolete and deprecated) *only* when  
CFF is used to embed a font in a PDF document.  The spec only calls  
for it to be supported in that context; it is not documented as legal  
in a complete OTF font.

So while it might be nice if (x)dvipdfmx were extended to support  
this usage (especially if the same code is used to handle fonts from  
included PDFs -- I don't know if this applies), it falls outside of  
Adobe's spec for OTF fonts, and font editors should *not* be  
generating it.

JK