Re: [openglean-devel]Font support.

[varol k. <var...@gm...>]

Dear Richard,

Sorry for the late reply. I had to go to a place (conference) with no
email access and stuff like that.

On 9/30/05, Richard Rauch <sf...@ol...> wrote:
> Varol:
>
> I've been looking at your code a little more this morning.  It
> looks like you only read characters in the range 0..255.
>
> Have you given much thought yet to supporting large character sets?

Well, one of the reasons that the current bdf subsystem is a hack is
because supporting unicode/etc the right way is difficult. If you want
to support unicode then you have to be much more careful.

> I'm inclined towards the idea of reading font glyphs more or less
> on-demand, rather than reading the entire font at once.  The
> difficulties are in finding where as-yet-unread glyphs begin and
> in rapidly finding glyphs in memory after loading.  (Allocating
> pointers to all possible glyphs in a big array and filling unloaded
> ones with NULL is probably not a very good solution; even for 16-bit
> Unicode, on a 32-bit system, that's a quarter of a MB of pointers
> for every font...)

I completely agree with the "not reading the whole font at once". Some
fonts out there are huge! As you noticed, the current bdf subsystem
design is not adequate at all (on purpose, to make things simple).
There are other things that are not working properly, like kerning or
calculations for proper string dimensions/extents which I plan to fix
when everything else is more settled down.

> I'm thinking of some kind of hash approach.  Take a sequence of
> primes, where the Nth prime is approximately 2^N.  Take the glyph
> number mod by the prime table size  That would be the primary
> location for already-loaded glyphs.  As the table fills, reallocate
> and re-hash.

hmm ... I am not sure about the hash thing. Unless carefully done, the
hash may turn out to be bad. We'll have to look at the occupation
characteristics of unicode planes ... there may be a better (easier)
approach. Special attention should be taken to make sure that the
common cases run fast.

> For unloaded font glyphs, some kind of sparse array could be
> used to locate known places in a font.  For example, after reading
> the font glyph for 'a', you would know the location of 'b'.  (Well,
> maybe not.  I am not sure if BDF files are necessarily presented
> in the order of the glyph encoding.  But in most, if not all, cases
> you will probably be better off to start searching for 'b' right
> after 'a', I suspect.  (^&)

I don't think that this is a good idea (too complicated). I would go
with something like this: make an API to let the library know which
parts do you want supported (latin1 + latin2 + latin5, or even a UTF-8
encoded string with all the characters that you will be using) and
then when you load a font, it will load only those characters. After
all, it will be the user who knows best. I can see, though, that your
approach is more transparent.

> Additionally, perhaps loading up to 8 or 16 glyphs at a time
> might be good.  If you need the Latin 'a', the chances are pretty
> good that you'll need 'b' before too long.

Incremental loading? I am not sure it is a good idea. The BDF format
is not designed for random access. You will have to scan through most
of the BDF each time to get to what you want. The BDF specification
does not seem to require that the characters are presented in order.
Not to mention that the encoding can be different too. While it is
true that 'b' follows 'a' is true for english, it is not necessarily
true for other languages (in turkish, 'c' is followed by '=E7' which is
nowhere near 'c' in the encoding, for example).

> (But for languages like Chinese, I don't think the odds are so favorable.=
)

I'll have to check with my chinese friends :-)

Varol