Re: [ft-devel] GSoC - Image comparison in test framework

[Werner LEMBERG]

> Do we want to detect and highlight the location of the
> error/difference in a particular glyph?  For example, a pixel is
> missing at the bottom of a character so we identify that area as
> containing the difference, and somehow show this in the report.  If
> a stem were shifted, I imagine the entire glyph might be identified
> as being different.  Or, we just display the baseline and the
> erroneous glyph without trying to identify where within the glyph
> the error was.  The measure of the difference between baseline and
> test would be the same in either case.

I'm a big fan of blinking comparisons.

  https://en.wikipedia.org/wiki/Blink_comparator

On my laptop running KDE I use virtual screens, and I have assigned
navigation keys to switch from one virtual screen to another.  If I
position two identical views of, say, `ftview' into different virtual
screens (together with a magnification tool to enlarge the pixels),
it's very easy to see the differences by switching forth and back.

What I would like to have if I run `make glyphtest' (or whatever) is
something like the following.

  1. Report whether there are differences.

  2. If yes, generate an HTML page that shows all glyphs of the
     problematic font, with the changed glyphs highlighted (e.g.,
     framed by a box, and coloured differences).

  3. If I click on the glyph, I get a new page that shows me the old
     and new rendering of that glyph side by side, probably for a
     larger bunch of different ppem values.

  4. If I click again on one of the two images, I get a zoomed version
     (without smoothing) so that I can further examine the pixel
     differences.

  5. Another nice feature would be to create images of the outlines
     used for rendering (something similar to the output of `ftgrid').

To avoid zillions of small glyph images I can imagine that the
baseline glyphs are created on demand only while MD5 checksums (or
whatever is appropriate) for item 1 is stored in advance.

> Also, are we targeting a specific version of HTML for the output
> report?  HTML 4.01 should be compatible enough, although nowadays
> HTML 5 might also be okay.

This is completely up to you.  I have no preference.


    Werner