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

[Werner LEMBERG]

>> Currently, FreeType already emits MD5 checksums for rendered glyphs
>> if asked for, i.e., using the `bitmap' group and debug tracing
>> level 3 or higher in the `FT2_DEBUG' environment variable, for
>> example
>>
>>   FT2_DEBUG=bitmap:3 ftview ...
>
> The MD5 checksum will be good for checking for any errors up until
> and including rendering the glyph.  However, what about when
> adjusting the kerning for successive glyphs when printing a string
> of text?  If a bug results in improper kerning for a given pair of
> gylphs, is it true the MD5 checksum will report no differences and
> an additional check for differences would be required?  Does this
> hold for all operations concerning the placement of successive
> glyphs?

You can completely ignore kerning issues.  The primitive kerning data
derived from the `kern' table is not worth for further investigation
IMHO (besides probably monitoring the values itself), and the more
complicated kerning from the `GPOS' table isn't handled by FreeType at
all but by higher-level libraries like HarfBuzz or ICU.

And yes, the MD5 checksum is not affected by kerning.

>>   . In a string of glyphs, the gap between glyphs changes.
>
> For example, would an additional check besides the MD5 sums be
> required for the above differences?

If you ignore kerning, the only reason for different gaps are changed
left and right side bearing values, and this is covered by the advance
width.  So it is necessary to monitor both the scaled and linear
advance width values (the latter can be changed by variation font
instances).

>>   . A glyph isn't rendered at all due to an internal problem of
>>     handling the glyph's data.
>>
>>   . A stem gets positioned higher or lower; this affects a series
>>     of consecutive horizontal or vertical pixels.  This is the
>>     most frequent – and most important case.
>>
>>   . In B/W mode, a rendered structure has one pixel more or less.
>
> If I'm correct, I believe the MD5 sums should detect these.

Yes, but what's needed is a solution to nicely visualize the
differences.

> Concerning the image comparison,
>
>> Neither `fast' nor `simple' is important IMHO.
>
> I think I was going about the image comparisons the wrong way with
> my initial thoughts on them. I'm going to research better ways of
> doing the comparison and displaying the results.

:-)

> Unrelated to the project but I've had to fiddle with freetype in the
> past when trying to improve my font rendering and it's interesting
> (and humbling) to see just how much is involved in rendering
> text :-p

Indeed.  There are far too many devilish details to take care of.


    Werner