Re(10): Italic open-o in omega

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

there is no miracle: if ghostscript and acrobat reader can print documents
containing type 42 fonts on printers of level 1, then at some point 
conversion *is* done, and this means that your precious TrueType hints 
are replaced by something else.

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

yes, but the TrueType interpreter inside the PostScript printer cannot
necessarily handle all OpenType tables, as for example CFF

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

these type 42 fonts still have encodings, and hence you must break a type 42
font into smaller pieces if you need to use more than 256 glyphs.

this would mean that instead of what we suggest:

1) convert TTF/OTF into PFC
2) take glyphs from PFC and make small type 1 fonts

you suggest:

2) take glyphs from TTF and make small TTFs
3) put these small TTFs into small type 42 fonts

this is harder for odvips since it must look into the TTF file, grab the
glyf descriptions, build new TTF files [not that simple!] and convert
these ones into type 42.

Is the difference of quality between "re-hinted TTF converted into type 1"
and original TTF such important to justify the additional complexity?

If we discover that TTF fonts used by Omega print ugly and that the same
fonts embedded in type 42 print beautifully, then we will probably adopt
both approaches. But see also my remarks a few paragraphs lower, about
type 42 compatibility with PostScript operators

Not to mention that we still need the PFC approach for CFF fonts (which,
I hope, will be the most frequent good quality OpenType 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...
>
> 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.

are PostScript operators such as glyphshow working with type 42 fonts?

And how about charpath? That's the operator who adds the glyph's outline
to current path. I'm pretty sure this operator will break when it discovers
that the outline we ask him to add to the path is in fact a TrueType outline.

Mixing PostScript and TrueType is risky and fragile. I prefer doing it the
old way, with nice and clear type 1 outlines 

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

not if we establish a priority list

>if Omega will be bound only to
>Opentype tables to store metrics, then how one can use commercial
>opentype fonts which canot be changed?

produce PFC files out of them

>and how to use non-opentype
>fonts?

of course we will keep compatibility with OFM, OVF ad aeternam, so that
old PFB fonts can still be used the old way.

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

OpenType fonts have the concept of "mark": a mark is a location where you
can place an accent. Is that "metric" or "glyph"? Why keep that distinction?

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

not if we keep variation into bounds. Arabic needs curved connections between
glyphs. These connections can be done on-the-fly, it is certainly not
trivial but it doesn't either mean we necessarily get poor quality, 
on the contrary.

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

OK, you have proven your theorem by using the axiom of frozeness of TeX.
Omega is not frozen and it is in its growing youth. And Omega is hungry: 
it needs to eat data to do good typography, I don't see why you want to 
put it on a diet.

Don't forget that before Don, there was hot lead typography. And hot
lead typographers had indeed access to glyphs! They were not manipulating 
empty boxes. Don's approach was optimal for the late seventies where TeX
had to run with 64k of RAM, but maybe suboptimal today. 

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

because of upwards compatibility, Omega is morally bound to use OFM and
OVf files forever. But in the simultaneous presence of foo.otf/foo.pfc 
and foo.ovf/foo.ofm, omega will probably use the former.

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