# [XeTeX] on GSUB

Jonathan Kew jonathan_kew at sil.org
Wed Jun 28 14:52:55 CEST 2006

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