[XeTeX] on GSUB

[Jonathan Kew]

On 28 Jun 2006, at 12:39 pm, Jonathan Kew wrote:

> On 28 Jun 2006, at 12:18 pm, Pablo Rodríguez wrote:
>
>> Jonathan Kew wrote:
>>> On 27 Jun 2006, at 3:16 pm, Pablo Rodríguez wrote:
>>>> I'm using the lastest version, but generated with FontForge to
>>>> avoid the
>>>> seac operator on other documents.
>>>
>>> I know you've mentioned this, but I have not yet seen an example --
>>> in particular, GFS Didot (current OT release) seems to work fine for
>>> me. Are there specific characters that cause it to fail?
>>
>> GFS Didot OT works fine for me with small texts, but not with my
>> dissertation. And I have found a glyph that uses the seac character.
>>
>> \emph{é}
>
> Aha! Yes, that does it.
>
> OK, I'll see if I can find time to look into this.

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.

Anyhow, I'm afraid this isn't something I can work on at the moment.  
Actually implementing 'seac' will take some detailed and careful  
work, and I can't commit the time to it. If someone wants it badly  
enough to write and test a patch, feel free!

Meanwhile, I would suggest asking the GFS people to rebuild their  
OpenType fonts without this operator; and if tools like Fontforge or  
FontLab generate it in Type 2 charstrings, then suggest to the tool  
authors that they should be using subroutines instead. (Expecting the  
font designer to decompose composites within the design tool is  a  
poor workaround.)

JK