Warning for conflicting kern groups

[davefojtik]

Hello again. As I am working with Glyphr quite often now, I have noticed a little problem with kerning groups. If you specify a same pair of symbols multiple times (can happen unintentionally when working with bigger groups or have too much of them), both groups cancel each other out completely and no kerning values from those groups are applied in the final SVG. And so you have to go manually through all of them and search for the duplicate.

This could be a nice little feature in the next releases. To warn a user if, and where he specifies a kern for symbol pairs more than once, so they don't conflict.

Regards

[mattlag]

Oh, this is a great point. I really like your idea of notifying the user that a pair already exists.

This check should also happen when the SVG Font is generated, to make sure we're not writing two of the same kern pairs to the file.

I'm surprised that nothing happens when two kern values for the same pair exist. I would expect, for example, that only the last one would take effect... I'll play around with this - create a SVG Font with duplicate kern pairs with different values, then convert to OTF, then see what if anything gets written to the OTF.

Thanks for pointing this out!

[davefojtik]

I believe the kerning is not present even when you convert it to OTF. I followed your suggested workflow - Export to SVG, import to FontForge, export to OTF. Then I use the font on the web in both .otf for PC and backup SVG for android devices and conflicting kerning groups were not present in both of them. It's an interesting behaviour. I would also expect at least one of the values to take effect.

Edit: But also when you have a group of let's say vwy-a and then you make v-a, the pairs w-a and y-a are not working either. That's even weirder.

[davefojtik]

Hi @mattlag

As I reached about 1366 individual kerning pairs in my font (please don't judge me lol) I kinda needed the help of a script to check them for me as it would be impossible to do it manually. So I decided I will take a short look at the feature I was talking about in this issue and tried to wrote and implement a simple function into the source code. I added a new button "test kern pairs" to the Kerning panel that runs this:

function testKernPairs() {
        var kp = _GP.kerning;
        var plist = [];

        for(var k in kp){ if (kp.hasOwnProperty(k)){
            for(var lg=0; lg<kp[k].leftgroup.length; lg++){
                for(var rg=0; rg<kp[k].rightgroup.length; rg++){
                    plist.push(String.fromCharCode(kp[k].leftgroup[lg]) + String.fromCharCode(kp[k].rightgroup[rg]));
                }
            }
        }}

        var alreadySeen = [];
        var error = false;

        plist.forEach(function(str){
            if (alreadySeen[str]) {
                alert("Warning! A value for kerning pair  " + str + "  is set more than once. Consider removing the duplicate to prevent conflict on export.");
                error = true;
            }
            else
                alreadySeen[str] = true;
            });
            if (error==false) alert("Test passed. No conflicting kern pairs found.");
    }

The part that splits inputs into individual kerning pairs is inspired by "ioSVG_makeAllKernPairs()" function but here it stores values in a variable. Then it runs through all of them and checks if it exists more than once - resulting in either in alert for each found duplicate OR "passed" message.

[mattlag]

This is why user feedback is so important... 1366 kern pairs was not part of my original scenario 😄 but, I think your suggestion is very good. Give warnings about overlapping kern pairs, and/or check for duplicate kern pairs on export.

Thank you very much for the code snippet. I will definitely be doing something around this the next time I get some cycles to do some bug fixes.

[thoka]

Hmm. I interpret having overlapping rules as a feature if rule precedence is defined, for example: later rule overwrites earlier rule. This allows fine-tuning a broad rule with a detailed one. Some popup would be annoying in this case. Fully fledged support for overlapping rules would need the ability to reorder rules and (optionally) some non-blocking indication of precedence. One simple implementation could add rule numbers and a column indicating overwritten rules.

[mattlag]

I'm investigating this. Interestingly, overlapping kern values all export to SVG... and when I open the SVG Font file in Font Forge, they are all read successfully

But when you try to round trip Export to OTF then read it back in, it looks like only the First entry is preserved.

So it looks like something is getting through. It may not be what the user expects, though.

[mattlag]

I'm going to close this - in 1.13.17 (just shipped!) I added the "Check for overlapping kern values" button. Also, on export, if there are multiple entries for a kern pair, only the first one is exported (so the entries should all be unique now). Oh, and if these are encountered during SVG Font export, warnings are sent to the console.