Re: [ft-devel] [GSoC] Initial canvas results

[suzuki toshiya]

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
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>