Re: Re(8): Italic open-o in omega

"YH" == Yannis Haralambous writes:

 >> 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.

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

as far as i know, there are some truetype fonts which rely heavily on
truetype instructions (hinting) which cannot be directly converted to
type1 hints, so converting truetype to type1 is generally bound to
worse quality than using directly truetype (or opentype) fonts.

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

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

i thought that most today's printers support level 2; and also the
level 2 postscript can be printed to any printer (even level 1 or
non-postscript) with ghostscript; also it may be possible to convert
the PS to PDF and then print it to any printer (again not necessarily
level 2) with acrobat reader.

 >> 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.

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

hm - i wonder why: type42 stores the binary image of the whole font,
with all it's tables, etc, so all tables of opentype fonts can be
stored too.

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

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

so it seems that a better approach might be to patch dvips to allow it
to partially download type42 fonts (than to generate type1 fonts out
of the opentype fonts on the fly).

 >> 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...

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

do we need any control? we just rely on rendering glyphs we asked it
to put at some place - nothing more is required.

 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).

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

sorry, ok.

 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:

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

but then Omega will be bound to handling only opentype fonts? or it
will be able to store metrics in OFM (and OVF) files, in addition to
the opentype tables? if so, this introduces comlications and conflicts
as to which font metrics to use. if Omega will be bound only to
Opentype tables to store metrics, then how one can use commercial
opentype fonts which canot be changed? and how to use non-opentype
fonts?

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

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

wow... i hardly can imagine how it is possible to automate such things
to make it work reliably for all cases. placing accents at custom
positions cannot be automated, and requires human intervention
(i.e. essentially the same as creating the virtual font which gives
the flexibility to specify positioning of any accents for any glyphs).

 YH> and if we want to do proper Arabic some day, then we need to be
 YH> able to produce glyphs on-the-fly,

again - are there any examples of programs which can generate glyphs
on the fly? i think that it requires major designer's work, and any
attempt to automate this will result in poor quality result.

 YH> and these glyphs will not necessarily have the same widths, so
 YH> once again, it is much better if Omega has access to glyphs.

maybe i don't understand the whole mechanisms which are supposed to be
implemented in omega...

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

i think that Don's decision was universal (like some theorem in math
which cannot be proven wrong once it was proven to be right): TeX
doesn't need any other info to put the letters than metrics, and the
actual glyph shapes are irrelevant (provided that they match the
metric, of course).

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

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

then it would be interesting to know what do you think of the
questions above (whether Omega will work with only
Opentype-table-based metrics, or with external metrics like OFM too)...

Best,
v.