Re: [ft-devel] GSoC status update.

[Parth Wazurkar]

>> I wonder whether it makes sense to add an artificial space glyph to
>> the GF + TFM combo – most font formats have a space glyph for
>> simple string support...  What do you think?
>>
>> The width of such a space glyph could be derived from TFM's
>> `param[2]' value.
>
> I don't really know how to work that out.  Can you suggest any
> format which does this?

FreeType already does that for some formats: The glyph with index 0
must be the equivalent to the `.notdef' glyph (also known as the
`undefined glyph' or `default glyph') – cf. the WINFNT or BDF driver.

Oh, I always wondered what was this `notdef' glyph in the WINFNT driver.
I thought this was something format specific. I get that now. Thanks :-)

BTW, it seems this feature is still missing in the GF driver, so
please add it.  The actual shape of the glyph with index zero doesn't
matter; for example, you could construct it on the fly (i.e., while
loading the GF file), say, a bitmap that contains a hollow box as with
most TrueType fonts, scaled to the proper font size.

   XXXXX
   X   X
   X   X
   X   X
   XXXXX

Similarly to the above you should construct a second artificial
character to hold the space glyph (i.e., an empty bitmap which only
has an advance width); for convenience, I suggest this glyph gets
index 1.  As a consequence, you would have to shift all (native) glyph
indices by two; a GF font with 128 glyphs becomes a font with 130
glyphs, etc., etc.

In case no TFM file is attached to the GF file, please use the font
size to derive a heuristic width for both the `.notdef' and the
`space' glyphs.

Ok. I will do it.

Thank you

Parth