[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] [GSoC] Initial canvas results

From: Arvinder Bhathal
Subject: [ft-devel] [GSoC] Initial canvas results
Date: Wed, 21 Jun 2017 11:54:47 -0400

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.

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

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.

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.

For now, I will work on the two items I listed above. Please respond
with any comments or concerns.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]