Kevin Bracey wrote:
> Excuse my ignorance, but what system are we talking about that
> has "glyph codes" similar to Unicode, but not identical,
I'll be frank: I was talking about a rendering engine library whose source cose is mainly in my fantasy :-)
I don't know exactly what kind of system Mark had in mind, but I assume that we both were just speculating.
> and at what point are these codes visible to the
> I'm not familiar with the technology involved.
> If these codes are visible externally, and could be mistaken
> for Unicode code points, it strikes me as the top of a
> slippery slope.
Users and application programmers should never ever need to be aware of the internals of any rendering engine.
But font designers probably should: the set of glyph codes is precisely the interface between the font and the rendering software.
Of course the environment assumed behind such a design is poor old fonts (à la BDF). With newer technologies like OT or ATSUI all this (including the very idea of an independent Unicode rendering engine) don't make much sense, because it would mean duplicating or violating parts of the architecture.
> On our systems, the glyph ordering within fonts bears very
> little relation to any encoding -
This is OK. I was just stating that glyph indices *may* be inspired to Unicode values, not that they *must* be.
> indeed Unicode ordering would be hugely inefficient due to the
> huge gaps in the table.
It's hard to evaluate the generality of this statement. In my fantasy, my code is always infinitely fast :-) In a real implementation, there are many details that contribute in different way to efficiency.
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:02 EDT