On Thu, 08 Dec 2011 13:00:15 +0100,
<[email protected]> wrote:
> Is the font chosen just the first one RUfl encounters
> (alphabetically?) that has a match?
Pretty much, yes. See:
http://source.netsurf-browser.org/trunk/rufl/src/rufl_init.c?revision=9792&view=markup#l1061
Just to explain the motivation behind this design: the substitution
table is 65K, and there are 18 weight-slant combinations. I wanted
RUfl to have small memory usage, so adding a table for each weight-
slant would have taken too much space. Perhaps a different data
structure or approach would be possible.
It wouldn't be difficult to construct the table in a different order
from alphabetical though.
James
Thanks for the additional background information, James. Certainly 18 x
65k would be a bit heavy!
I couple of thoughts occur:
- RUfl could pick the most "neutral"-styled font (no slant, medium weight)
it can find when there are multiple options for a point in the
substitution table. Ideally, it would be a bit intelligent about it, and
favour choosing fonts it had already used in the table, to avoid a
mish-mash of fonts creeping in.
- Although 18 tables would probably be overkill, three (65,536 * 3 =~ 197k
) might be a compromise between memory footprint and aesthetics: One for
"no-style", one for "average italics" and one for "average bold"?
- In my case, I have a font family with about 7 different weights (no
slants) all defining the same glyphs, one of which RUfl is using for the
majority of points in the substitution table. If RUfl could be aware of
"equal" fonts - fonts in the same family that define exactly the same
subset of glyphs, just in varying styles - it could match the weight/slant
as a second step after looking up the codepoint in the (still 65k)
substitution table. Of course, that would only be of help when the user
has families of fonts defining the same glyphs, as described, but that's
probably not all that infrequent.
- Is the substitution table statically linked to each binary that uses
RUfl? I guess it must be. If the substitution table were to grow much in
size, and as more and more software starts to use RUfl (as I hope will be
the case), there's perhaps an argument for moving it into a module and
only maintaining a single set of tables for all apps? In fact, the best
thing would be if it could hook into the Font Manager and provide its
functionality to all apps "for free". Unfortunately, as I've recently
discovered, FontV isn't actually implemented in any version of RISC OS.
But the Font Manager itself could be modified. I'm not sure what the deal
is with modules that take 10 minutes or so to start up, though (as could
be the case when RUfl indexes fonts)!
To be clear - I'm certainly not expecting anyone to do anything about this
(i.e. coding); I'm just interested in discussing options here. If a
suitable consensus of opinion emerges, I'd be happy to look at making a
patch/patches when I have a bit more time.
Thanks,
WPB
