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

"YH" == Yannis Haralambous writes:

 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.

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

yes - e.g. by glyph outlines. the point is that such a task is rather
complex and really belongs to rendering programs, rather than to
typesetting programs. typesetting programs like TeX or Omega, in my
opinion, should concentrate on abstract glyphs (described only by
metric), and leave the task of glyph rendering and handling particular
low-level font formats to other applications. that's the strength of
design of TeX: being developed in 1970's, it's free of any
dependencies on font formats, and happily adapts to work with any
fonts which even did not exist at the time TeX appeared.

 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.

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

does level 2 postscript support CFF? and, as R C van Dalen noted,
"relying on the TrueType interpreter seems to be quite correct if the
user has picked this TrueType font." - it's up to user to decide which
fonts to use, and it's not a good idea to translate these fonts to
something else if such translation is bound to quality loss (which is
the case with TTF to PFB conversion).

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

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

 YH> this would mean that instead of what we suggest:

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

 YH> you suggest:

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

no, i do not suggest to break the big TTF font to small TTFs, but to
use reencoded fonts: when dvips reencodes the same big font to smaller
fonts, it preloads all glyphs of the big font in a single PFB font,
without breaking it into smaller PFB files.

e.g., install the cm-super fonts, then run "tex testfont", and draw
the table of ecrm1000, tcrm1000, larm1000, lbrm1000, lcrm1000.  then
run "dvips testfont.dvi -o testfont.ps"; you'll find that the font
sfrm1000.pfb is preloaded only once, and it contains all glyphs of
these fonts.

the same is possible with big truetype or opentype fonts: when storing
them in PS file, it is not necessary to break them into small
sub-fonts.

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

but that's the Right Thing (TM) compared to converting TTF to small
type1 subfonts. :-)

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

in some cases, it is very non-trivial to create correct type1 font
from the TTF font (when the font heavily relies on truetype
instructions).

 YH> Not to mention that we still need the PFC approach for CFF fonts
 YH> (which, I hope, will be the most frequent good quality OpenType
 YH> fonts).

imho these things are outside of the area where a typesetting program
like TeX or Omega should deal with - it's the problem of handling
specific font formats, and it has almost nothing to do with the task
TeX or Omega has: to place the glyphs properly.

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

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

sorry, i cannot reply to these questions right now, as i didn't
investigate in this area.

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

 YH> produce PFC files out of them

sorry, could you give a quick description of what will be these PFC
files, i.e. which info will be kept in them? (or a link to a message
or article where it was explained)

 >> 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> OpenType fonts have the concept of "mark": a mark is a location
 YH> where you can place an accent. Is that "metric" or "glyph"? Why
 YH> keep that distinction?

to me, it is obvious that "mark" is a "metric" thing, rather than the
"glyph" thing: such a notion makes sense universally - i.e. it doesn't
depend on how glyphs are described, so it is the metric property. you
can just extend OPL syntax to allow specifying such a parameter.

 YH> not if we keep variation into bounds. Arabic needs curved
 YH> connections between glyphs.

can the font contain all pre-built combinations of connected glyphs?
(made by a font designer)

 YH> These connections can be done on-the-fly, it is certainly not
 YH> trivial but it doesn't either mean we necessarily get poor
 YH> quality, on the contrary.

i just think that things which require "art work" like designing
glyphs are not the ones which can be automated.

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

 YH> OK, you have proven your theorem by using the axiom of frozeness
 YH> of TeX.

no, i did not use any axioms :-) that was just an example - an analogy
- to express my point of view, that there are things which can be true
ages and thousands of years after they were discovered:

you said "Let us not be *that* dependent of Don's choices (which were
quite reasonable in the late seventies, but not necessarily anymore
today...)" - but i think that the fact that the typesetting program
needs only metric, but not glyph shapes, is an example of such
universally valid approach.

 YH> Omega is not frozen and it is in its growing youth. And Omega is
 YH> hungry: it needs to eat data to do good typography, I don't see
 YH> why you want to put it on a diet.

i'm not saying that TeX's metric is perfect and should not be extended
by e.g. adding the notion of "mark" or other extensions (which can be
implemented in Omega - and some of them are already implemented).
what i'm saying is that typesetting program should not deal with glyph
shapes and font formats, but leave this to document rendering
applications (printers, previewers, etc), and should use just font
metrics.

Best,
v.