[ft-devel] comments on GF driver

[Werner LEMBERG]

[git commit 743b415ca95ad25722a2fb260920cfab21220479]

Parth,


while debugging your code I've observed some issues.

* A missing TFM module is not a reason to abort loading of the GF
  file, cf. line 222 in `gfdrivr.c'.  Or is it?  Does loading a plain
  GF file (without a TFM file) needs code from the TFM module?

* The proper way in FreeType to parse a contiguous block of data is to
  define a `frame' using `FT_FRAME_ENTER' and `FT_FRAME_EXIT'.  This
  allows to access the data sequentially without doing error checking.
  In other words, you should use this technique for GF, PK, and TFM
  data after you've located the various file offsets and backwards
  file seek operations are no longer necessary.  There are plenty of
  examples in `winfnt.c' how to do that.

  [Of course, this is future work to be done after GSoC.]

* In `gflib.c', line 564, you are allocating the `bm_table' array with
  256 elements.  However, not all GF fonts have this much glyphs.
  IMHO, you should thus reallocate the array to the final size as soon
  as you know how many elements are really in the font.

* It's not necessary to assign NULL in a loop to `bitmap' (file
  `gflib.c', lines 569f) since a call to `FT_ALLOC_MULT' already
  initializes all elements to zero.

* It's not necessary to assign `-1' in a loop to `char_offset' (file
  `gflib.c', lines 587f), since `char_offset' can never be zero in a
  GF file.

* Serious: In `gf_set_encodings' you are always using 256 iterations
  in loops to handle `tosort' and friends.  However, those arrays only
  have `nencoding' elements!  Please think of such issues from the
  very beginning since they are potential security risks.

I have to leave the train now.  Will continue later this day
hopefully...


    Werner