Dear Anuj, Anuj Verma wrote: > Hello Suzuki, > >> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed >> (16Dot16, 32bit). > > I think using FT_F2Dot14 will be a good option because the signed distance > field will have a range [-1.0, 1.0]. > But for now I'll stick with *float* as you suggested.
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). >> BTW, the most biggest trade-off in your mind is the size >> of extra table (in TrueType font file) to store Distance >> Fields info? Or, the speed to calculate the Distance Fields >> info? > > Usually distance fields are stored as an image (e.g. > https://i.imgur.com/ruWAhT3.png<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D&reserved=0>). > And since each pixel in the distance field is the distance to the nearest > edge/outline there > can be more than 255 values. So, in this case the trade-off can be the > accuracy of the distance. > But, on the other hand, I think 255 values might be enough because they are > interpolated if a > point lies between two. I see. > 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. There is a possibility that JPEG makes better compression ratio. But I think using PNG is better choice for FreeType2, because recent ready-made binaries of FreeType2 on many GNU/Linux platforms (and on maOS and Windows?) have a dependency to libPNG already (to support bitmap emoji fonts). Adding new dependency to libJPEG is not the best. Regards, mpsuzuki Anuj Verma wrote: > Hello Suzuki, > >> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed >> (16Dot16, 32bit). > > I think using FT_F2Dot14 will be a good option because the signed distance > field will have a range [-1.0, 1.0]. > But for now I'll stick with *float* as you suggested. > >> BTW, the most biggest trade-off in your mind is the size >> of extra table (in TrueType font file) to store Distance >> Fields info? Or, the speed to calculate the Distance Fields >> info? > > Usually distance fields are stored as an image (e.g. > https://i.imgur.com/ruWAhT3.png<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D&reserved=0>). > And since each pixel in the distance field is the distance to the nearest > edge/outline there > can be more than 255 values. So, in this case the trade-off can be the > accuracy of the distance. > But, on the other hand, I think 255 values might be enough because they are > interpolated if a > point lies between two. > >> *This is just my idea without deep thinking*, XML or JSON >> (or, compressed version of them) would be considerable option >> to store the data, during the development of the initial >> draft, because it is easy for them to change the data >> format, insert or remove some extra data. Also it would be >> easy for external programs to extract or manipulate. > > This is interesting, I haven't thought about storing them as XML or JSON. > This option can be good if the parsing time is less than the generation time, > otherwise the external application can directly generate the distance field. > We can also store them in some format which support floating point (e.g. hdr) > > 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? > > Thanks, > > Anuj > > On Wed, May 13, 2020 at 9:03 AM suzuki toshiya > <mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>> wrote: > Dear Anuj, > > I think you can use *float* directly in the initial draft. > > When we merge the implementation using the float type into > the official public release, we should discuss the design. > > There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) > and FT_Fixed (16Dot16, 32bit). But yet we don't know which > is the most appropriate for your Distance Fields project, > or we need another type, thus starting with direct usage > of float would be safer to keep the all possibilities. > > BTW, the most biggest trade-off in your mind is the size > of extra table (in TrueType font file) to store Distance > Fields info? Or, the speed to calculate the Distance Fields > info? > > *This is just my idea without deep thinking*, XML or JSON > (or, compressed version of them) would be considerable option > to store the data, during the development of the initial > draft, because it is easy for them to change the data > format, insert or remove some extra data. Also it would be > easy for external programs to extract or manipulate. > > Regards, > mpsuzuki > > Anuj Verma wrote: >> Thank you all for the comments. >> >> I too agree with Werner. >> I think comparing both the types seems to be a good option, So, I'm gonna do >> as Suzuki suggested >> and use floats for my initial draft and later without floats. >> And I'm not gonna focus on the saving part because the user can always do a >> conversion. >> >> Also, can I directly use *float* or use FT_Fixed? >> >> Thanks, >> >> Anuj >> >> >> On Wed, May 13, 2020 at 5:47 AM suzuki toshiya >> <mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp><mailto:mpsuz...@hiroshima-u.ac.jp<mailto:mpsuz...@hiroshima-u.ac.jp>>> >> wrote: >> Dear Anuj, >> >> I agree with Werner's comment. >> >> It might be uncomfortable for you to leave an untested question, something >> like "if I use a floating point calculation, the result could be better?". >> >> Please use a floating point in your initial draft (if you want), >> and let's discuss about the trade-off with the implementation >> with no floating point, in later. >> >> Regards, >> mpsuzuki >> >> On 2020/05/13 6:14, Alexei Podtelezhnikov wrote: >>> I'll just add references below. >>> >>> On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG >>> <w...@gnu.org<mailto:w...@gnu.org><mailto:w...@gnu.org<mailto:w...@gnu.org>>> >>> wrote: >>>>> I can't decide which format to use for storing the SDF(signed >>>>> distance fields). I think using floating-point values (fixed-point >>>>> in this case) for generation will be more accurate than using >>>>> integer, but then saving the SDF to a file will require a >>>>> conversion. >>> The basic types are described here: >>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871&sdata=%2FVbt%2BfNz6x24eJNK9ag1PDhZXz49rS4b64fcmMJ2G9A%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=07QmgnoPBg1WWncTqqpfEYh9wc4ZsWqhF8BRImE09sk%3D&reserved=0><https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249313838205364&s data=QZPY8mNjaJMiznsZrP%2F%2Fx%2FspNjSR7NVrA5Mro4kslrA%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274590640&sdata=WT034BhLYg0cZID5xqwZJSTiMh7a%2FfqOt84KNhIxloo%3D&reserved=0>> >>> The computations are described here: >>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871&sdata=T%2BQR9KKVWo%2BEI4Lqr5vFkgguWHV8xm8BB3USWcaQ8iY%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274600639&sdata=AzFDuf95tA%2BJUUEL8eob9cZCwIkt6aU8kpqu4KiYX%2BY%3D&reserved=0><https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C6372493138382 15316&sdata=RB7tz2dCaDs2XpjYZP6tu%2Bt7j%2Fqqn%2B1d7yDYz6dRnb4%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274600639&sdata=AzFDuf95tA%2BJUUEL8eob9cZCwIkt6aU8kpqu4KiYX%2BY%3D&reserved=0>> >>> Saving files is not of FreeType's business. We just return data. >>> >>>> The basic question is whether the accuracy is really needed. >>>> Currently, FreeType doesn't use floating-point arithmetics. >>>> Personally, I would favour a solution without floats, but maybe there >>>> are good reasons for using them. >> >