Dear Alex,
I agree that bitshift is too complicated. If the glyphs are sorted by
CID, you might not need the temporary storage if you keep track of the
previous CID and some format string tricks. I can work on that later
by adopting the lines 676-707 (if the CIDs are sorted indeed).
Indeed. If
Dear Suzuki
> BTW, if the 64kByte array to check CID availability can be
> reduced to a 64kBit (= 8kByte for most architecture) array
> by a bitshift calculation, is it the way to go?
I agree that bitshift is too complicated. If the glyphs are sorted by
CID, you might not need the temporary stora
Dear Werner, Alex,
Thank you for positive comment. I fixed my broken comment by Werner's advice.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...2bf378a1
BTW, if the 64kByte array to check CID availability can be
reduced to a 64kBit (= 8kByte for most architecture
>> The execution "ftdump -c" for OpenType/CFF fonts with "holes" in the
>> implemented CIDs, like Hiragino fonts on macOS, generates the output
>> ending with:
>>
>> --
>> (...Charmap printout...),2f9de,2f9df,2f9f4
>>
>> /CIDSystemInfo dictionary
> The execution "ftdump -c" for OpenType/CFF fonts with "holes" in the
> implemented CIDs, like Hiragino fonts on macOS, generates the output
> ending with:
>
> --
> (...Charmap printout...),2f9de,2f9df,2f9f4
>
> /CIDSystemInfo dictionary
>Regis
Here is the 3rd revision.
https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...228f50f0
The execution "ftdump -c" for OpenType/CFF fonts with "holes" in
the implemented CIDs, like Hiragino fonts on macOS, generates
the output ending with:
---
