freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] comments on GF driver


From: Parth Wazurkar
Subject: Re: [ft-devel] comments on GF driver
Date: Sun, 12 Aug 2018 15:56:01 +0530

* 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?

Yes, it is needed as we have not defined a macro like
`T1_CONFIG_OPTION_NO_AFM' for the `tfm' module and the `ftview'
always try to attach a `tfm' file to the `gf' file and if the module is not found
it anyhow returns an error when it reaches the `TFM_READ_METRICS'
function. This can be fixed by defining a macro which can determine whether
to attach a `tfm' file or not. What do you suggest?

* 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.]

Yes! This can be changed later.

* 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.

Fixed.

* 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.

Fixed.
 
* 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.

Yes, I set that because initially I was allocating the metric values according
to the charcode from the font file and then setting up the encodings, so it
was needed to differentiate amongst the `set' and `unset' character_offsets.
Now its not necessary and fixed.

* 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.

Same reason for setting it as above. Now fixed!

Thank you

Parth


reply via email to

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