[omega] Question about the paper published in EuroTeX 2005

[Yannis Haralambous]

> By the way, in what you explained, you use OTPs to translate a
> char-string into a glyph-string, which is perhaps not the right idea.
> Perhaps you should use OTPs to do translations only in the chars land,
> transforming "X" into "X at the end of word". And only then would 
> happen
> the transformation into a glyph, perhaps it looks like an OTP, but I
> think it should have another name.
>
> That would lead to 3 tools to do transformations:
> - OTPs to do those on chars;
> - XXXs to do those from char to glyph;
> - YYYs to do those on glyphs.
>
> I think the YYYs are already provided by the fonts (kern/lig program in
> TFM, other ones in OpenType). It might be interesting to provide some
> more explicits, like for the poorly defined fonts. But I think a
> different name would make things more clear.

Actually my idea was different:

1) OTPs can act both on chars, glyphs and properties. So for example 
you can match a texteme with glyph such and character such and such 
property, or only those which have a given property, or given char, or 
given glyph, etc etc. Once matched you can keep one of these values or 
replace it in the texteme(s) you produce. This is the most general 
case, and will be quite useful

2) there will be three operations which will be loaded as OTPs in the 
OCPlist: readLKP, readGSUB, readGPOS. Each one of these will do one 
operation: read the ligature and kerning program of a TFM file, read 
the GSUB table and apply, read the GPOS table and apply. If the font is 
TFM then only the first will actually do anything, if it is an OpenType 
only the two last ones, etc.

3) it is these three pseudo-OTPs which will chose glyphs for textemes, 
unless this has been done before by some other OTP or explicitly by the 
user. In that case the user or the OTP has to lock the glyph property 
so that the font does not overwrite it.

4) it will be possible to use regular OTPs before, between and after 
the three ones I mentioned, so that effects of font reading can be 
overwritten. The idea is to keep TOTAL CONTROL on what a font does to 
textemes. If I don't want to use ligature fi, I can lock the glyph of 
the f or the one of the i, and there will be no such ligature. or I can 
write an OTP which replaces the ligature glyph by the normal one.

Do you find my idea more reasonable now?

I don't like the idea of having different operations for chars, glyphs 
or going from chars to glyphs. All those operations can be mixed, and 
one can even imagine obtaining characters from glyphs, or any other 
combination [example: someone may say: whenever there is a fraktur 
glyph string Re then this is in fact the Unicode character for real 
part of complex numbers ---> this is going from glyphs to characters 
and obtaining correct characters in the output file...]

But I do retain your idea of "poorly defined fonts". Indeed there must 
be a way to obtain the same results as GSUB/GPOS for fonts which do not 
have these tables.

--
+--------------------------------------------------------------------+
| Yannis Haralambous, Ph.D.      yannis.haralambous at enst-bretagne.fr |
| Directeur d'Études                   http://omega.enstb.org/yannis |
|                                          Tel. +33 (0)2.29.00.14.27 |
|                                          Fax  +33 (0)2.29.00.12.82 |
| Département Informatique                                           |
| École Nationale Supérieure des Télécommunications de Bretagne      |
| Technopôle de Brest Iroise, CS 83818, 29238 Brest CEDEX 3, France  |
+--------------------------------------------------------------------+
                          ...pour distinguer l'extérieur d'un aquarium,
                                         mieux vaut n'être pas poisson

                         ...the ball I threw while playing in the park
                                        has not yet reached the ground