[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] GF's cmap fails
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] GF's cmap fails |
Date: |
Wed, 15 Aug 2018 23:36:12 +0200 (CEST) |
> After some debugging, I found out that, I was using binary search on
> the encodings array in the `char_index' function, although it wasn't
> sorted (so foolish of me :( ). Now, fixed! Thanks.
In the commit message, you write
Use `linear search' instead of `binary search' in the encoding table
as it will always be unsorted.
This really baffles me. I think you have an error in reasoning
somewhere, still not really understanding how a cmap works. I'll
retry.
GF provides a natural order of glyphs within the font file, we call
this `glyph indices'. Each glyph index is associated with a file
offset. For each glyph, GF assigns a character code to it. We thus
have immediately a mapping from glyph indices to character codes.
[For simplicity, I'm ignoring the still missing artificial glyphs that
must be inserted at glyph indices 0 and 1, as mentioned in a previous
e-mail.]
Taking `cmr10.600gf' as an example, this yields the following.
glyph index file offset character code
------------------------------------------
0 34 65 (A)
1 247 66 (B)
... ... ...
25 5813 90 (Z)
26 6004 97 (a)
... ... ...
51 10239 122 (z)
52 10368 0 (Γ)
53 10521 1 (Δ)
54 10736 2 (Θ)
... ... ...
What's needed for a cmap, however, is a mapping from character codes
to glyph indices. In other words, you simply have to reverse the
above mapping.
character code file offset glyph index
------------------------------------------
0 (Γ) 10368 52
1 (Δ) 10521 53
2 (Θ) 10736 54
... ... ...
65 (A) 34 0
66 (B) 247 1
... ... ...
90 (Z) 5813 25
... ... ...
97 (a) 6004 26
... ... ...
And this mapping is of course sorted!
You should thus have two arrays.
1. A table of file offsets, ordered by glyph index:
file_offsets[num_glyphs] = { 34, 247, ... };
This array goes into `GF_Face'.
2. A table of glyph indices, ordered by character code:
glyph_indices[num_chars] = { 52, 53, 54, ... };
This eventually leads to
typedef struct GF_CMapRec_
{
FT_CMapRec root;
FT_UShort num_chars;
FT_UShort* glyph_indices;
} GF_CMapRec, *GF_CMap;
(or something similar), and you do a binary search in `glyph_indices'.
> Although there is one more error, i.e even after displaying all the
> glyphs in the font file `ftview' is displaying extra `AAA...'s, any
> reason why this is happening?
This is expected. `FT_Get_Char_Index' returns value 0 for character
codes that don't have an associated glyph, and currently glyph `A' has
index 0.
Werner