>
> > 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.
>
Really sorry for the late reply, I have been involved int some personal
issues.
My changes to `cmap' were done to load glyphs in the order they
appear in the font file, as the `gf driver' uses the offsets taken from the
`char_loc' commands in the `gf' file to get the metrics, now when the
driver
goes in the loop to get all the `char_loc' values ( the chardx and chardy
values ), it loads the glyphs in the order they appear in the `char_loc'
command, which is different from the order they appear in the font file.
It loads glyphs in the increasing order of their character code.
Now, what I did is, I took the offsets and sorted them and then in the same
order loaded the `glyph indices' thus fulfilling the goal. And as the
`indices table'
is formed in such a way, it will remain unsorted, i.e. the
enoding[0] maps to char code 65 and glyph `A'
enoding[1] maps to char code 66 and glyph `B'
enoding[2] maps to char code 67 and glyph `C'
... ... ...
enoding[57] maps to char code 0 and glyph `Γ'
enoding[58] maps to char code 1 and glyph `Δ'
enoding[59] maps to char code 2 and glyph `Θ'
[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.]
>
This is in the pipeline and will be added soon :-)
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'.
>
This will load the glyphs in the same order as they would do previously
in the order of their charcodes because of the `char_loc' commands, I think
I will have to change the `gf_load_font' function according to the cmap
scheme above.
Thank you
Parth
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
