Dear Werner, Werner LEMBERG wrote: >> 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.
Ah, I think you mean 16bit "platform" are dropped. >>> 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. My understanding is that Anuj is planning to store the rasterized-then- blurred glyph images as the extra TrueType table, aslike sbix table. I slipped to think about the size of the memory buffer to store these data. I'm not in full understanding about "how to use that". > What 'image' dimensions are we talking about? > Usually, Freetype glyph bitmaps are very small, and compressing them > would be a complete waste of time. Ah, the (assumed/estimated) number of the pixels should be discussed for first... Anuj, please give us some informations. Regards, mpsuzuki