Re: ftdump can show the CID registry, ordering, and supplement?

[suzuki toshiya]

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 GID-CIDs are already sorted, it's easy to dump the
available CIDs in a compressed syntax. Although I have no sample
font including unsorted CIDs, I'm unsure whether it is required
in some specifications.

Anyway, I'm very happy to hear the negative comment on 64kBit array.
I would submit my MR based on 64kByte array, and commit it. I think
freetype-demos has no CI mechanism yet... Right?

Regards,
mpsuzuki


P.S.
Yet I have not checked in detail, Apple's TrueType spec has a "gcid"
table which is a simple array of CID (to be retrieved by a gid). I'm
interested in whether it can be included in a conventional TrueType
using glyf table (instead of OpenType/CFF). Currently, most fonts
supporting CID are PostScript-based fonts (t1cid or cff or OpenType/CFF),
so the glyphs are already sorted by their CIDs. If it is possible to
have a TrueType font including both of glyf and gcid, the glyphs would
be ordered not by CID but by Unicode.

On 2023/04/19 11:26, Alexei Podtelezhnikov wrote:
> 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 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).
>
> Thanks,
> Alexei