Perform visual regression test

[sladen]

Ideally this could be more automated (make visual-test or something), but this can be done with something like ftview from the freetype2-demos suite:

$ ftview -w 1000 -h 1000 16 old/Ubuntu-Regular.ttf release/Ubuntu-Regular.ttf

Then switching forward/backward with n and p keyboard inputs.

Where 16 is the point size, and the following arguments are the TTFs to test render. The resolution can either be specified with -w/-h for width/height, or -r for resolution.

*(A more mechanical way would be to output overlaid renderings to PDF, render these with various PDF engines (mupdf/Popper/…) and look for colour fringing where there is not a perfect overlap.

[madig]

Damn, the ftview method fails due to different glyph order...

[sladen]

madig: custom strings can be passed with -m "…". However, that is then only probably displaying mapped characters, and not glyphs.

. o 0 {What would it take to make the glyph order match?}

[anthrotype]

{What would it take to make the glyph order match?}

changing public.glyphOrder, then updating the composite glyphs' OFFSET instructions in VTT sources so that they point to the correct glyph index. The latter can be done with vttLib, using that tools/update-vtt.py script of yours.

[madig]

It would mean to kill the empty alignment glyphs though, which I have no problem with :)

Edit: or better, make them misalign stuff.

[anthrotype]

no, because those don't get compiled in the TTFs, are simply placeholders. The public.glyphOrder can contain more glyphs than the UFO contents.plist. It's the order of the ones that are actually present that you are interested in.

[madig]

Yes -- but modifying the glyph order means moving glyphs around inside the list, messing with the manual alignment of the placeholder glyphs.

[anthrotype]

Oh I see. Well, if it were for me you could get rid of them. Ask Denis

[madig]

The following script:

#!/usr/bin/env python3

import glob
import defcon
import os
import extractor

for ufo in glob.glob("source/*ufo"):
    font = defcon.Font(ufo)

    u2=defcon.Font()
    ttfpath = "/tmp/font1/" + os.path.basename(os.path.splitext(ufo)[0]) + ".ttf"
    extractor.extractUFO(ttfpath, u2)
    font.lib["public.glyphOrder"] = u2.lib["public.glyphOrder"]

    font.save()

reduces the GlyphOrder diff to zero. (font1 houses the GF fonts renamed to source filenames)

Using ftview and setting the hinting engine to 35 reveals some 1-pixel-off spacing differences in BI florin and backslash, while the overall layout remains the same.; LI has the ubuntu disc thing hinted; Mono-B has a 1-pixel-off spacing issue in "<" and something layout wrecking going on in uni1F98 or uni1F99; M has the caron on uni01EE misaligned and the ubuntu disc thing slightly higher.

[sladen]

So how about a target make get-old-release that wgets the present release from fonts.google.com, and unpacks it in old-release/*.

With that it is then possible to refer to old-release/$ttf in a reliable way, and so add the script above as make fix-glyphorder (relying on old-release), then the script will work indefinitely.

[moyogo]

I’d rather have a github release for the previous release. Going forward we should compare with the previous release that is made here.

[sladen]

Yeah, it's mainly for this first baseline release where there only some previous black-box binaries available. Going forward what will matter is the tagged/released source.

[moyogo]

We can tag the first commit (or a branch from there) as a release with the baseline fonts.

[madig]

Inspecting Ubuntu-BI with ftgrid and the interpreter set to 35, I see no difference in florin and backslash. I also can't see the offness in Mono-B "<" and uni1F98 or uni1F99. Not sure where those are coming from in ftview. When I leave the glyph order alone, I can't even see the layout wrecking in Mono-B...

for M uni01EE, the caron is off to the right in the UFO build (v35 interpreter). Strangely enough, the points are the same according to ttdebug.

[madig]

The commands to inspect the glyphs are:

# In ftview, press H twice to switch to v35 hinting engine.

# uni1F98
ftgrid -f 1124 16 build/UbuntuMono-B.ttf &
ftgrid -f 1123 16 current-gf-release/UbuntuMono-Bold.ttf

# florin
ftgrid -f 100 16 build/Ubuntu-BI.ttf current-gf-release/Ubuntu-BoldItalic.ttf

# backslash
ftgrid -f 475 16 build/Ubuntu-BI.ttf &
ftgrid -f 473 16 current-gf-release/Ubuntu-BoldItalic.ttf

# <
ftgrid -f 31 16 build/UbuntuMono-B.ttf current-gf-release/UbuntuMono-Bold.ttf

I've written Werner Lemberg about the offset caron in uni01EE.

[madig]

I made a mistake in instrumenting ttdebug in that the amount of "c" I have to echo depends on how many glyf programs are running on a glyph. The displaced caron in uni01EE wan't picked up because I didn't execute far enough! Looking at ttdebug to make it execute to the end and then accept commands.

[madig]

The new debug glyphs that I constructed out of .sups and .sinfs have broken hinting... gotta debug before we can put them in a release. (or construct them differently)

[madig]

Doh. I forgot to delete the hinting of the composite glyph. Let's see if I can just get rid of all references to EFFD in the hinting code. That would save us from dealing with "expected different component offset" errors.