Re: [ft-devel] Splitting up the GSoC project

[k kushal]

For creating artificial font like images, I am thinking of generating bitmap images from existing fonts. (Making a sample of images from glyphs which are visually different from one another ). After that editing these ( to make the faulty glyph renders ) will do. 

Then, retaining a copy of the originals, we using them for comparison. Any other way ? Any suggestions for the editing part ?

On Tue, May 9, 2017 at 9:54 AM, suzuki toshiya <address@hidden> wrote:

Hello Bathal!

>> The basic question is where the image differences shall be computed:
>> in the HTML backend (using, say, Java or _javascript_) or on the C side?

> It would certainly be possible to compute the image differences in the
> browser. The <canvas> element in HTML5 allows low-level image
> processing and JS libraries such as CamanJS (http://camanjs.com/) use
> canvas to provide all the pixel-level manipulations and image metrics
> we'll need to do the comparisons. That being said, I think there is
> definitely some merit in doing the comparisons in C.

The advantage to implement image comparison in _javascript_ is
dependent with the design of UI, I think.

If you focus the glyph set to US-ASCII or other small glyph set,
the advantage to compare the image in _javascript_ might be clear. But,
if you care the larger glyph sets, like CJK ideographs, the size
of images might become large.

If the design would be "compare whole glyph set and show selected
samples" style, the comparison in C space might be better. If the
design would be "select small set of glyphs for comparison, and
compare them only" style, the comparison in _javascript_ space might
be considerable option. Which direction is better for you?

--

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.

Regards,
mpsuzuki


Arvinder Bhathal wrote:
>>   Arvinder: HTML, CSS, and Java stuff
>>
>>             To begin with coding I suggest to create some artificial,
>>             font-like images as input, which are later on replaced
>>             with real-world data.
> Yes, I can get started on those right away. I think I should also
> create better mockups based on mine and Kushal's to get feedback on
> what we'd like from the UI.
>
>> The basic question is where the image differences shall be computed:
>> in the HTML backend (using, say, Java or _javascript_) or on the C side?
> It would certainly be possible to compute the image differences in the
> browser. The <canvas> element in HTML5 allows low-level image
> processing and JS libraries such as CamanJS (http://camanjs.com/) use
> canvas to provide all the pixel-level manipulations and image metrics
> we'll need to do the comparisons. That being said, I think there is
> definitely some merit in doing the comparisons in C. It would better
> modularize the project and allow the HTML component to be strictly for
> a neat visualization of existing data/images without any heavy
> computations. It would also allow the option to produce a text output
> of the comparison results without needing to first use a browser. I'm
> open to either.
>
>>   . Add very small input fonts together with a test suite that tries
>>     to cover as much as possible.  The code coverage could be checked
>>     with GNU `gcov' or LLVM's `SanitizerCoverage' feature.

> Sounds like a plan :)
>
> I'm also setting up my Savannah account and my GPG key right now and
> will update once it's done.
>
> - Arvinder
>