Dear Arvinder, I've checked and built your sources, the results were visible for me. Good. Could I write a suggestion?
- main.c could be unified? At present, main.c & main-2.c are given, although their difference is quite small (main-2.c gives extra "-2" suffix to the glyph index for output filename). I suggest to extend main.c can take a suffix via commandline option and remove main-2.c, because you can reduce the cost to keep both files consistent. Or, do you have any plan to differentiate these 2 main files? (e.g. main.c would be modified for very very legacy FreeType?). If you dislike the commandline option, it would be also possible to specify it by compiler flag. Taking a glance on main.c, there are many hardwired values, so I guess you would work more on it. My suggestion could be in too early to give :-) Regards, mpsuzuki suzuki toshiya wrote: > Dear Arvinder, > > On 2017/06/22 0:54, Arvinder Bhathal wrote: >> First, Suzuki-san had mentioned the following regarding canvas: >> >>> And, although I've not checked the latest implementation of Canvas >>> in modern browsers, I remember some experts complained that the >>> color or grayscale levels might be changed during the loading of >>> the pixel data onto canvas element. For bi-level monochrome images, >>> it would not be harmful, but, if you would consider the subpixel >>> or anti-alias rendering, please prepare some code to check the >>> hi-fideliy of canvas implementations. >> >> >> Canvas does report incorrect pixel data in the case when individual >> pixels are set using putImageData() with the alpha channel anything >> other than 255 or 0, then read using getImageData(). This is because >> pixels are set using straight alpha channel and canvas converts it to >> pre-multiplied. This would be a problem if we want to change pixel >> data in the browser. But, I believe we'll only be reading pixel data. >> My tests confirm canvas reports the correct pixel data for grayscale >> anti-aliased images. Iirc, FT uses pre-multiplied alpha values for >> subpixel rendering and canvas should also report the correct pixel >> data. I am testing this next. > > That's good to hear, thank you for confirmation. > >> Next, what I've done with canvas so far: >> >> - Generate grayscale bitmaps for characters A - Z using FT 2.5.1 and 2.8* >> - Manually populate an HTML table with a few glyphs from both versions** >> - Use JS to go through an array of all images in the current pages and >> put them into a canvas element, zoomed in without smoothing >> >> * I chose such an old version of FT to guarantee rendering differences >> ** Something to note is canvas requires a URL to the image or an HTML >> element with the image. So, the HTML generation code needs to create >> <img> elements of all the glyphs with the appropriate filename/type, >> which are then stored in canvas elements when the .html file is >> opened. >> >> For the browser, I see the following as next steps: >> - Confirm pixel data for subpixel rendering >> - Test direct HTML generation using C or with an HTML templating >> library to ensure no surprises later on >> These two I will report back on tonight. > > It should be interesting. > >> Regarding the glyph comparison, almost every pair of glyphs from 2.5.1 >> and 2.8 differ in their dimensions. As Hin-Tak has mentioned before, >> 1-to-1 pixel comparisons are pretty much out. I've yet to try using >> the surrounding 4 or 8 pixels. >> >> My code is in the arv-test branch and I put the files inside the >> glyphtest folder. The bitmap generation code is a small snippet I >> wrote using the QDBMP library. Of course, Kushal's code will be used >> later on. > > So now your code is ready to build & execute? I will take a look... > >> For now, I will work on the two items I listed above. Please respond >> with any comments or concerns. > > If I have something in the execution of your code, I will ask > something, but I don't have at present. Please proceed. > > Regards, > mpsuzuki > >> _______________________________________________ >> Freetype-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/freetype-devel >> _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
