Re: [ft-devel] GF's cmap fails

[Parth Wazurkar]

> 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