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