> Oh, I see the value to be stored is in a range [-1.0, 1.0].
> I want to hear the comments from other developers :-),
> whether the initial implementation should be FT_F2Dot14 (16bit)
> or float (32bit, at least).
Well, we have dropped 16bit support already, so it's only a question
about storage size.
>> But, for now I think the storing part can be postponed until we
>> have compared the accuracy. If there isn't a much difference in
>> the accuracy of floats vs integers, then we can simply use 8 bits
>> per pixel and store them as something like PNG. What do you think
>> about this?
>
> If the Distance Fields should be stored as an image (PNG, or
> something like that), I want to withdraw my shallow idea. XML and
> JSON are not the best options to store the image (using dataURL and
> base64 bitstream? what a stupid idea!), please ignore that.
What exactly do you mean with 'stored as something like PNG'? Is this
the output that FreeType returns to the calling application? Or is
this a temporary storage within FreeType? In both cases I'm not sure
that this is the best solution, since compression and decompression
costs a lot of time. What 'image' dimensions are we talking about?
Usually, Freetype glyph bitmaps are very small, and compressing them
would be a complete waste of time.
Another use case might be that the calling application provides a
pre-allocated buffer. In such a situation compression is wrong, too,
since FreeType will simply fill the buffer with data.
Please elaborate.
Werner
