On Mon, 24 Sep 2018 18:28:16 +0200, Hadrien Lacour <hadrien.lac...@posteo.net>
wrote:
> Then you put your latin font first, since those usually don't contain CJK
> characters. The only case where it could gives problems is if you don't want
> fallback but really a merger of your fonts: e.g. using Terminus but wanting a
> different font for cyrilic.
>
> But yeah, I'm in favor of the range scheme, since it solves more problems and
> may make the implementation cleaner. If there are alphabet aliases or comments
> concerning common ranges in the config file, it should be pretty easy to use.
>
As usual, plan 9 has a good solution:
cpu% cat /lib/font/bit/dejavusans/unicode.16.font
20 16
<snip>
0x03a9 0x03a9 dejavusans.16.03a9
0x0101 0x0201 dejavusans.16.0101
0x0020 0x007e dejavusans.16.0020
0x0000 0x0000 dejavusans.16.0000
0xf400 0xf500 ../dejavu/dejavu.16.f400
0x2e18 0x2f18 ../dejavu/dejavu.16.2e18
0x2b00 0x2c00 ../dejavu/dejavu.16.2b00
0x28a2 0x29a2 ../dejavu/dejavu.16.28a2
0x27a1 0x28a1 ../dejavu/dejavu.16.27a1
0x0000 0x0100 ../dejavu/dejavu.16.0000
0x3000 0x30fe ../shinonome/k16.3000
0x4e00 0x4ffe ../shinonome/k16.4e00
0x5005 0x51fe ../shinonome/k16.5005
0x5200 0x53fa ../shinonome/k16.5200
Which has this meaning:
cpu% man 6 font
<snip>
...The format of the file is a header followed by any number
of subfont range specifications. The header contains two
numbers: the height and the ascent, both in pixels. The
height is the inter-line spacing and the ascent is the
distance from the top of the line to the base- line. These
numbers are chosen to display consistently all the subfonts
of the font. A subfont range specification contains two or
three numbers and a file name. The numbers are the
inclusive range of characters covered by the sub- font...
</snip>
There's little about this that is exclusive to Plan 9
fonts, or even to bitmap fonts, although if used with
truetype fonts, there may (or may not) need to be some
extra data stored.
A tool to generate this can be done with fontconfig, to get
the existing rendering, or can be implemented with a naive
ordered ranking of fonts, picking the first font that covers
a glyph.
For a slightly more sophisticated option, an ordered ranking
that attempts to minimize the number of "holes" in unicode
ranges could be written, ranking the scripts first in order
of script coverage, using the script table here:
https://www.unicode.org/Public/11.0.0/ucd/Scripts.txt
And then breaking ties by order of preference. That gives
you fewer jarring transitions, where one font happens to
implement a small number of glyphs but others cover the
range fully.
--
Ori Bernstein
