Thank you Taco and Gábor for your valuable comments-)
Based on both of your comments, it seems that the most practical approach in the short run is for Aleph (whose raison d`etre is more focused on the short run->) is to just treat otf's like cid/enriched type1 fonts (a la Latin Modern), which is what ConTeXt (and I guess LaTeX too) are already doing (with smart encodings, etc.) The main thing that aleph offers on this front is >256-glyph encodings. Simple otp's could provide switches to turn on needed features (small caps, superiors, swashes, etc) in a large font without clogging the system with multiple encodings (Occam's razor); only a single encoding vector for the entire raw font would be needed. I know that loading encodings in ConTeXt would certainly be a lot simpler-)
On Sat, 17 Dec 2005 06:13:21 -0700, <[EMAIL PROTECTED]> wrote:
3) OpenType fonts, as Taco has already mentioned, have a declarative nature: they tell you what to do but not how to do it.
In the short run, for Aleph's purposes, these declarations and much/most/all of the metainfo can be treated as "suggestions" for the otp designer to consider in implementing things. There is no need to treat them as something "holy".
Based on your comments and my other research, I will focus on enriched/CID type1 (which I guess is equivalent to cff-flavored opentype) font solution in my own work, and not worry about otf declarations for now.
In the long run, of course, it would be great if a rewrite of Omega could execute a complete implementation of otf functionality. I wish dear Yannis and Gábor the very best in this regard!
Best to all Idris -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
