On 1 July 2018 at 10:30, Lawrence D'Oliveiro <ldo@xxxxxxxxxxxxxxxxxxx> wrote:
Then the page contains code points 0x300 through 0x33f (the first 64 code points on the page) because map[0] and map[1] both have all their bits set. It also contains code points 0x343 (0x300 + 32*2 + (4-1)) and 0x35e (0x300 + 32*2 + (31-1)) because map[2] has the 4th and 31st bits set. The code points represented by map[3] and later are left as an excercise for the reader ;).
On Sun, 1 Jul 2018 00:41:01 +0800, Elias Mårtenson wrote:
> Bug in Fontconfig?
Check your version of Fontconfig:
ldo@theon:python_fontconfig> python3 -ic "import fontconfig"
>>> fontconfig.get_version()
21300
I previously reported what I thought was a problem, only to discover
that it had already been fixed.
When I was younger I occasionally made fun of people that rush to blame their
tools rather than their own code. It's time for be to accept some of that ridicule
myself.
I had made an error in my code, causing it to escape the loop early and only ever
checking the first page returned from FcCharSet*Page(). After fixing that,
I now confirm that of course there is no bug in Fontconfig.
That said, I did find a bug in the documentation. The manual for FcCharSetFirstPage:
The documentation states:
""""""""
Builds an array of bits in map marking the first page of Unicode coverage of a. *next is set to contains the base code point for the next page in a. Returns the base code point for the page, or FC_CHARSET_DONE if a contains no pages. As an example, if FcCharSetFirstPage returns 0x300 and fills map with
0xffffffff 0xffffffff 0x01000008 0x44300002 0xffffd7f0 0xfffffffb 0xffff7fff 0xffff0003 |
""""""""
The highlighted quote: "because map[2] has the 4th and 31st bits set" is wrong. map[2] has the value 0x01000008 which doesn't have the 31'st bit set.
Regards,
Elias
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
