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: spepping@scaprea.hobby.nl