On Mon, Dec 09, 2002 at 12:26:16AM +0100, Hans Hagen wrote: > At 09:38 PM 12/8/2002 +0100, you wrote: > > For Context this might be worked out as follows: Each font family must > >be in a known encoding. When a font family is loaded, the encoding and > >the associated font family are added to a table of loaded > >encodings. When a unicode character is sought, the loaded encodings > >are scanned in the order in which they appear in the table, until an > >encoding is found that provides a glyph for that character. > > hm, must think this over, esp since tex has no way (except measuring) to > determine if a slot is really taken
My idea was that the encoding should indicate which slots are provided (if the font complies). > >The NFSS in LaTeX provides a default encoding for a character (not to > >be confused with Context's default encoding, which is a different > >thing). When the character is not found in the current encoding, it is > >taken from this default encoding. Such a strategy may be more > >efficient than going through the list of loaded encodings. > > eh ... context does have fall backs (nearly always something default, often > very plain); if something does not show up, it's probably not defined > (yet); so, maybe i misunderstand you I do not see this as a fallback but as an optimization. It is an effective means of knowing which encoding is on top for a certain character. > Indeed i think that we should have some reasonable defaults, and it seems > that there are no free complete unicode fonts, so we probably end up with > something There are apps, e.g. XMLSpy, that rely on a single font to provide all required characters. I find that a waste of resources; the user's fonts are used much better if they can combined into a set. Simon -- Simon Pepping email: [EMAIL PROTECTED] _______________________________________________ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
