Sweet.
>One thought I have is that if we register the charhandler to always receive
>unicode I would like to short circuit the "special character" handler for
the
>symbol font and upshift it to unicode and then run it through the ordinary
>character handler when it is in unicode always mode, and to repeat this for
>the unicode character matchs in the wingdings font, and fall back to the
>spec char handler for the not matched cases. Though this might be overly
>complex, and it might be better to leave things as they are in the context
>of "special characters"
At first blush, the "short circuit" option sounds cleanest, but I haven't
given it much thought. We're crossing over into some of those nasty
font-lookup issues that so far we've managed to duck entirely.
No matter what, we'd need to decide how to represent those odd wingdings
which don't have any Unicode equivalent. Sigh.
I guess the first question is whether we have *any* shippable fonts which
can render all symbols and wingdings on each supported platform, and if so,
what codepages they use. If they're all the same, then avoiding draw-time
font mapping would be nice. However, if we're mapping anyhow, perhaps going
the full Unicode route makes sense.
And then there are the UI issues of what "should" happen if the user
"changes fonts" from Symbol or WingDings back to a "normal" font. If the
church secretary expects an Alpha to become an A instead of a slug, that's
the user experience we probably need to replicate.
In which case, maybe we do want to go the special character route after all.
Sigh.
Paul,
Mr. Wishy-Washy