Subject: Re: commit: List labels are UT_UCSChar's now.
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Mon Feb 26 2001 - 12:20:32 CST
tf> Two comments: (1) the only unicode fonts I have been able to get
tf> working are ttf. First of all, unicode pfa fonts are not easy to
tf> come by, and second, the X server does not seem to be able to
tf> handle them correctly (it sees only the first 256 chars). Now, I
tf> personally am happy to use ttf fonts, but not everyone running AW
tf> under Unix will have a ttf font server, so someone will first need
tf> to find out how to get pfa unicode fonts to work under X.
Back when I was working on remapGlyphs, and just before I realized I
was out of my depth on Unicode (and fonts in general), I found out
that the GTK approach is to use "fontsets". Fontsets are, I think,
virtual fonts composed of actual fonts mapped into various parts of
the 16-bit character space. My guess is that this wasn't particularly
intended to solve the general Unicode font situation, but was intended
to let you have a common base font which could be combined with a
locale-specific font.
So, I think GTK probably has a mechanism for displaying glyphs of
common interest without needing a complete Unicode font. I don't know
what this means for PS printing, though.
ms> If this doesn't work out I suggest we implement a remapping table
ms> to map the correct unicode glyphs to our Symbol and Dingbat
ms> fonts. I think its the only way we can maintain XP compatibility
ms> of various interesting bullet type symbols.
This would be feasible, but I'm sure exactly how much work it would
be. Since Martin was working on this whole bullets thing and asking
for comments about it while I was working on remapGlyphs, I did ponder
a little bit how to accomplish it. It was more than I could bite off
at the time, so I only designed and implemented the simpler form of
remapGlyphs that we have today.
remapGlyphs works by noticing missing glpyhs from the font in which a
text run is being rendered. It does a table-driven substitution of a
different glyph from the same font, with a fallback to the
(arbitrarily chosen) degree symbol if there is no applicable table
entry.
To implement a more grandiose scheme, I think you would need:
* Change the table mechanism so that, instead of just having a source
and replacement character value, it also has source and replacement
fonts. For the bullets problem, we would most often be mapping from
some normal font into the symbol font, I reckon.
* I don't know if it's useful, but while you're at it, you could also
have parameters for size, bold/italic, etc. My intuition is that
some of these additional attributes would prove practically useful,
and most would not (by which I mean "would hardly ever, but not
never, be used in practice"). It would depend on the luck of the
implementation if the useless ones came along for free. (I will not
admit how much time I have spent over the years adjusting the font
sizes of bullets so that they look right to various parties with
different fonts installed.)
* Probably run-splitting. The current remapGlyphs is algorithmically
pretty simple, so it remaps on the fly, and the text run in which
the replaced character lives doesn't know anything about it. If
you're going to potentially do a secret font change and maybe
attribute change, then you're really juggling a lot. You might as
well split the text run to isolate remapped character(s) so that the
rest of the layout engine can just work the way it always has.
* If you split the runs, then you have a design choice of really
replacing the font and attributes or virtually changing them at
render time. If it's a virtual change, then you want to preserve
the original font and attributes for when the document is exported.
In other words, a text run could now have two sets of font and
attribute descriptions, which has these implications:
-- Text run coalescing code has to be aware of that and not coalesce
unless both sets are the same.
-- Layout/rendering code has to use the virtual set.
-- Export code (does that include clipboard) has to use the real
set. Coalescing on export needs only consider the real set.
This is a bit of work, I guess, but not overwhelming. It could be
easily phased by doing the run-splitting stuff first, then doing the
change to the remapGlyphs table to handle other information.
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Mon Feb 26 2001 - 12:19:07 CST