freetype-devel
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]