> > * 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
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
