John Hudson wrote:
> At 01:38 PM 29-11-99 -0800, Erik van der Poel wrote:
> >Well, the semantics of the character entities are clear. If Mozilla
> >detects fonts on the system that include the various math glyphs and
> >glyph parts, then it will map the document's characters and character
> >entities to font glyphs, not necessarily one-to-one. Mozilla needs to be
> >careful not to let any of the PUA codes "escape" out of the app, e.g.
> >cut/copy/paste, which will probably be done in terms of MathML "source",
> >including character entities, markup and all.
> How will Mozilla detect these fonts?
It will look at the font name. For example, I currently have the
following math fonts on my NT4 box: Symbol, Math1, Math2, Math3, Math4
and Math5. Many of these are "symbol" fonts, but the same mechanism can
be used for Unicode fonts. The font name tells us which glyphs are in
there, and what their code points are. We will have a table for each
> We're one of the companies currently reviewing the Scientific and Technical
> Information Publishers group's font requirements for the STIX project, and
> I'm beginning to wonder if someone isn't putting the cart before the horse.
> I can only see one way in which all this is going to work seamlessly: the
> characters specified by STIPUB need to be assigned standard Unicode values
> before the STIX fonts are developed and before anyone tries to implement
> MathML font support.
But it is quite likely that the Unicode committee will reject at least
some of the symbols that we have been talking about. For example, the
LEFT CURLY BRACKET TOP in Symbol is not currently in Unicode, nor are
they likely to accept it, right?
As I write this, I notice that Shyjan has already given a good reply.
I believe the math people want to use glyphs at various sizes (Shyjan
calls them extensions) and glyph parts because they cannot rely on the
font scaler to give beautiful results. Presumably they will embed tuned
bitmaps for those glyphs into TrueType fonts.
> Even if the PUA encoding approach can be made to work
> without major font problems, someone will have to do the work all over
> again when the characters are properly encoded.
Even if some of the math symbols are accepted by Unicode, they can be
given duplicate character codes in the cmap. So they wouldn't have to do
the work all over again. They would just have to add some character
codes to the cmap (given that the glyph codes and the glyphs themselves
don't need to change).
Anyway, we want to make the fonts work on other platforms like the Mac
as well, and we're not sure that Windows won't do strange things to our
PUA codes, so I think we've decided to stick with "symbol" fonts, each
with 223 glyphs plus SPACE, so STIX will have multiple fonts, similar to
Another possible hack with Unicode fonts would be to use, say, the Han
area for math glyphs and glyph parts. Then Windows probably wouldn't do
any strange things to those Han codes, and would simply give us the
measurements and drawing that we want. Of course, we'd have to make sure
that we use those fonts only for math and not for CJK (Han). This is
yucky, but I just thought I'd mention it as a way of reducing the number
of STIX fonts on Windows. Not sure whether this would work on the Mac.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT