Re(8): Italic open-o in omega

>i think that it is not a good approach to translate TrueType/OpenType
>fonts to Type1 (even on the fly), since it will reduce the quality of
>TrueType fonts. 

if you mean hinting, then (a) ttf2pt1 does autohinting, (b) for high
resolutions we don't need it in the first place, (c) it would be even
more interesting to convert TrueType hints into type 1 ones, or something
equivalent, instead of blindly relying on the TrueType interpreter

>it is much better to use Type42 fonts in (o)dvips.

type 42 is only understood by level 2 printers, that's not good enough

>Type42 fonts are directly produceable from TrueType/OpenType, and vise
>versa, without any loss of quality (hinting, etc) - Type42 preserves
>ALL features of TrueType fonts.

but not of OpenType, so once again it is not good enough

>currently, dvips is capable of handling Type42 fonts, but it cannot
>currently do partial font embedding of Type42 fonts.

which makes type 42 fonts completely unuseable for 9-12 Mb big CJK fonts...

>maybe, odvips can be changed in such a way that it's able to work
>directly with big type1 or type42 fonts, withour requiring to
>re-encode the font to several font encodings...

type 42 are *not* a good solution because they lack control: they are
TrueType fonts embedded in PostScript code. The PostScript interpreter
hands them to the TrueType interpreter, and over that one we have little
control.

> YH> Furthermore, for non-commercial fonts, we can include the PFC
> YH> data in the OpenType structure and obtain "enriched" fonts which
> YH> contain the same glyphs in both glyf or CFF, and charstring 1.
>
>but adding something to the commercial TrueType/OpenType fonts may
>again be considered as a violation of license. so it seems better to
>store all Omega-related additional info in separate files (like ofm,
>ovf, etc).

could you please read my text before answering? On the first line of
my text which you are yourself quoting, I explicitly say "non-commercial",
how come you read "commercial"? For commercial fonts we build external
PFC files.

> YH> Imagine that in OpenType fonts you can put italic, roman and
> YH> small-caps into the same font and distinguish them by
> YH> "properties". This means that you can have kerning between all of
> YH> them... no need for the \/ macro anymore since we stay in the
> YH> same font when we write "\emph{and})"...  And these OpenType
> YH> Computer Modern fonts will be useable by other software as well,
> YH> such as InDesign
>
>sounds promising, but in my opinion, all Omega-specific font metric is
>better kept in separate files... that will give more flexibility:

and more chaos! SFNT files are designed in such a way that you can
store many kinds of information in various tables, that's better than
having different files and loose track of them, mix up different versions,
etc. etc.

>Omega will deal only with font metric files, just as TeX does - it
>doesn't need to know glyph shapes.

Of course it does! Let us not be *that* dependent of Don's choices (which
were quite reasonable in the late seventies, but not necessarily anymore
today...)
If TeX deals only with metrics this is not necessarily
a good example to follow. there are so many things one can do in the
knowledge of actual glyphs. Imagine how easier it would be for TeX/Omega
to place, for example, an accent on a letter 'h' if it was able to identify 
the coordinates of its vertical stem. 

and if we want to do proper Arabic some day, then we need to be able to
produce glyphs on-the-fly, and these glyphs will not necessarily have the
same widths, so once again, it is much better if Omega has access to glyphs.

And why shouldn't Omega have access to *all* information necessary to create
an efficient electronic document? 

>Then, these metric files can be
>combined with virtual fonts to give arbitrarily complex font usage.

What virtual fonts can do, OpenType fonts can do, probably not always in
the same way, but the result can be the same. And if there are features
missing, we can add new tables to OpenType fonts to include them.

+--------------------------------------------------------------------+
| Yannis Haralambous, Ph.D.      yannis.haralambous@xxxxxxxxxxxxxxxx |
| Professor                                   Tel. +33 2.29.00.14.27 |
|                                             Fax  +33 2.29.00.12.82 |
| Computer Science Department                                        |
| École Nationale Supérieure des Télécommunications de Bretagne      |
| Technopôle de Brest Iroise, CS 83818, 29238 Brest CEDEX, 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