>> 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.
I am talking about the output that FreeType returns to the calling application. So, there can be a scenario where the external application first generates and save the output of the DF (distance field) to a file. And then later on some other external application loads that file and uses it. This scenario is common in games where a pre-generated DF is loaded and used, to reduce load times. > 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". No, I am not planning to save the output as a TrueType table. Initially I thought that FreeType supports saving glyph bitmaps to file. But Alexei clarified that. So now I think the saving part can be left to the external application to decide. >> 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. The output DF will be slightly larger than the original one (20-30% in dimension) to contain the spread. Also, I can see **Message not available* *after my emails in the freetype-devel archives. Am I doing something wrong? Anuj
