Subject: Re: POW 19.12
From: Paul Rohr (paul@abisource.com)
Date: Mon Jan 24 2000 - 16:34:10 CST
At 08:27 AM 1/25/00 +1100, Martin Sevior wrote:
>On Sun, 23 Jan 2000, Michael Vogt wrote:
>>
>> The Tabs and Spaces are drawn as special Latin1 Charackters. Can I savely
>> assume that every font has a Latin1 mapping (I think, the "Dingbats"
hasn't) ?
>
>Hi Michael,
> You should not assume this. Besides Dingbats, Symbol does not
>use Latin 1 encoding - plus there are numerous new unicode languages that
>abi is the process of learning that do not use Latin 1. I was wondering
>how to do this too and I think you will have to insert your own font for
>every one of your funky code characters. This should not make too much of
>performance hit provided all the code characters come from the same font.
>
>It will mean remembering the current font, inserting your code with its
>font, then restoring the current font again.
Here's an even more general solution. Instead of using specific ASCII
characters, reference the equivalent UNICODE characters instead (via the
appropriate UCS_ #defined constant in ut_types.h). In many cases, this
should Just Work.
More importantly, when it doesn't, the fallback logic becomes a *lot*
clearer and easier to code. For example, we already know that for some
non-Latin-1 languages, we'll occasionally need an extra layer of code at
drawing time to map between UNICODE and the charset of the font being used.
Presumably, if the character is available in the current font (either
directly from UNICODE or after mapping back into the font's charset), that's
the glyph we want to use.
We probably only want to fall back to a *different* font if both of those
lookups fail. (Even so, we'll need a flag on the drawChars() methods to
tell whether to invoke this character-level font substitution logic or just
draw slugs.)
If we do things right here and optimize for the common case, then we should
only take a performance hit (to invoke this font fallback logic) in the
following rarer cases:
- using fonts with the "wrong" codepage
- using fonts which don't have these special characters at all
In both cases, users can control how often they encounter these problems by
choosing which fonts they use in their documents. Sheer evolutionary
pressure will favor the creation of fonts which include the needed
characters.
Does that make sense?
Paul
This archive was generated by hypermail 2b25 : Mon Jan 24 2000 - 16:28:49 CST