Generate Pairs only with multiples of 4

[Miyamoto]

Hi Tim, I am thinking of buying ikern; my question is if I can define a limited amount of kerning pairs in only multiples of 4 and have the program only to generate and expand these numbers without adding others. It helps me to control the grid and keep consistency in my process. I also wanted to ask you if this is not possible, if you offer this service or if you have thought about incorporating it. Regards, M.

[Tim Ahrens]

Can you explain what exactly “a limited amount of kerning pairs” would be? Also, what exactly are you trying to achieve? Not sure I understand.

[Miyamoto]

For example using only 4, 8, 12, 16, 20, 24, 28, 32, 36, 40 & 44 points as kerning pairs measures.

[Tim Ahrens]

There were similar requests before. My feeling is that the main motivation is to keep things “tidy under the hood”. This seems to be a strong (though irrational) desire among many designers, which I initially underestimated.

I will soon implement the quantisation of the autokerning values (multiples of 4 or something else) but for a different reason: It reduces the file size of woff and woff2 webfonts as it makes the data more “compressible”. At JAF, we have been applying that principle for many years.

There will be some tricky questions, though. Let’s assume there is a model for /n/v at –7. What’s the autokerning value for /h/v? It would not make sense to enforce multiples of 4 if the autokerning process clearly says it has to be exactly –7 because the shapes are identical. It will probably be some sort of soft snapping to the quantum.

[Manuel]

This is amazing to hear. I actually tested exactly that in the past week.

But compared to the 2–4% with your palettize script I was getting a much better improvement in file size. I think it is happening because it is applied before Kern On is build and not after resulting in less glyph-to-glyph pairs.

@ -7 units example
I don't think this is a difficult problem. I believe once the rounding/grid has been set by the user in Kern On it should on-the-fly round all values. (with a warning of course) Then a model of -7 units would right away turn into -8 units. (if the grid is e.g. 4, or 8)

I also attached two scripts I made for testing:
- Count Total Kerning Pairs.py
- Round All Kerning Fast.py
(the rounding script is much faster then all scripts I’ve found – instead of about 5min+ it has only 2 seconds execution time or less)


--------------------------------------------------------
Testing: Kerning Efficiency + File Size
--------------------------------------------------------
Testing if a rounding/threshold feature would have any positive effect and also if there is a better efficiency of kerning pairs (with kerning groups) vs the resulting total kerning pairs.
- Four Master
- Variable Font
- File size without Kerning: 133 KB

Workaround to test it
----------------------------------------
As a workaround I was using the scale feature via the UpM in Glyphs before running KernOn. But if you do this make sure to set a corresponding Subdivision in (> Info > Other) Having it directly in Kern On is surely more desirable. Any regular rounding before or after Kern On was run, had barely any effect. Though it might have been around 2%.

----------------------------------------
Results
----------------------------------------

My base setup (everything is compared to this)
----------------------------------------
2000 UpM, 32 kb, Keep Kerning Groups, woff2
--------------------
8789 Normal kerning pairs
--------------------
504023 Total kerning pairs
--------------------
57.35 Efficiency (the larger the better)
--------------------
193 KB (+60 KB, compared to no kerning)
--------------------


2000 (original) -> 100 UpM (10/1000 units kerning grid), 32 kb, Keep Kerning Groups, woff2
--------------------
(+/–) Kern On build was slightly faster
--------------------
(+/–) 7988 Normal kerning pairs
little less: expected
--------------------
(–) 393983 Total kerning pairs
less: a bit strange, not sure why this is happening
--------------------
(–) 49.32 Efficiency (the larger the better)
--------------------
–> Scaled back 100 -> 2000 UpM
(all nodes are back to original position, otherwise every node would be rounded on export! messing up your design)
--------------------
(++) 161 KB ! (-32 KB saved)
--------------------


2000 -> 200 UpM (5/1000 units kerning grid)*, 32 kb, Keep Kerning Groups, woff2
--------------------
(+/–) 8374 Normal kerning pairs
--------------------
(+/–) 459653 Total kerning pairs
--------------------
(+/–) 54.89 Efficiency (the larger the better)
--------------------
–> Scaled back 200 -> 2000 UpM
--------------------
(++) 169 KB ! (-24 KB saved)
--------------------

Normal vs Total kerning pairs
-------------------------------------------------------
Normal kerning pair count = each kerning group pair counts only as one entry, same as each glyph-to-glyph pair
-------------------------------------------------------
Total kerning pair count = counting also all possible pair combinations of each glyph within kerning groups



----------------------------------------
Kern On Kerning Groups (little off-topic)
----------------------------------------
There was also a significant negative effect in total kerning pairs when using Kern On Groups. Though this might be specific to my file setup. Will look into it more and do a different post on Kerning Groups.

2000 UpM, 32 kb, Kern On Kerning Groups, woff2
--------------------
(+/–) 9656 Normal kerning pairs
--------------------
(– –) 110845 Total kerning pairs
--------------------
(– –) 11.48 Efficiency (the larger the better)
--------------------
(+/–) 198 KB (+5 KB // +65 KB, compared to no kerning)



Overall I’m very much looking forward to have this build-in.
Maybe it could be also implemented with a custom parameter textfield alongside allowing access to a few other under the hood variables.

[Miyamoto]

Thank you for your reply Tim, and for the technical feedback of Manuel. I am working only with multiples of 4 and 8 since the last 3 years, it reduces my time for setting the values of contrast and spacing for my masters. It makes more sense to me since all my modules are measured and divided in the same proportions.

It would be very useful also, to see more plugins chained to a custom grid and guidelines in this regard, using color alignment zones, snap to grid "sounds" (nintendo game boy like) just to add some friendliness in a cold and repetitive routine!

Best Regards,
M.

[Tim Ahrens]

Thanks for your work, Manuel! There was lots of extensive Kern On feedback coming in today so I will need a few days to have a proper look at it and write the thorough answer it deserves.

Miyamoto, it seems you are working with 1000 UPM but then place everything, including contour points, spacing and kerning on a grid of 4? Then my advice is to simply switch to 250 UPM and work with a grid of 1. Problem solved, and Kern On will play along nicely. Working at a higher UPM than necessary and then keeping everything on a grid only makes things more complicated. Btw, I designed JAF Bernini Sans entirely at 250 UPM and this worked very well for me.

[Manuel]

Thank you Tim! Looking forward to your reply.

@Miyamoto – I would also recommend to work with 250 UPM. But if for whatever reason that doesn't work for you, you can just use the mentioned rounding script. You can execute it before generating the kerning and see if there are any issues with your models. And then run it another time after, to snap all your kernings to your grid. The only thing you wont get is the file size reduction.

[Miyamoto]

Thank you Tim and Manuel, I just bought Kern-On.
What if I use a grid of 8, what would be my UPM?
Best regards!

[Tim Ahrens]

If you currently use multiples of 8 at 1000 UPM, you can re-scale the font to 125 UPM as 1000 / 8 = 125.

[Tim Ahrens]

Thanks for the scripts, Manuel!

But compared to the 2–4% with your palettize script I was getting a much better improvement in file size.

This figure was just what I found back then, from a handful of files I was generating at the time. Comparing the saving to the overall file size is not a very sensible benchmark, one should measure the saving in relation to the amount of data used by the kerning.

@ -7 units example
I don't think this is a difficult problem. I believe once the rounding/grid has been set by the user in Kern On it should on-the-fly round all values. (with a warning of course) Then a model of -7 units would right away turn into -8 units. (if the grid is e.g. 4, or 8)

That is one way of handling this: Switching to a grid would be a one-off action, with a warning, and from that point the system would simply enforce that grid for all pairs, including models. However, this could lead to situations in which it is impossible to set a pair as a model because no grid-based value exists that doesn’t make it contradict another pair. This may be the case when the range of possible values is smaller than the grid.

Also, from a rational point of view, there is no benefit of restricting the models to a grid. I understand that some designers just like it that way and I have to accept this.

- File size without Kerning: 133 KB
193 KB (+60 KB, compared to no kerning)
(++) 161 KB ! (-32 KB saved)

Yes, that’s the right way of thinking, I believe. What exactly causes the reduction in file size is a very complex topic (as the woff2 compression algorithm is incredibly good). For example, I made some tests in which using purely glyph-glyph pairs, without any class kerning, led to almost the same woff2 file size as the corresponding class-kerning-based option. Without compression, the latter is much more efficient, of course.

During your rounding, some pairs are rounded to zero. This causes some pairs to disappear entirely, which is certainly responsible for a part of the size reduction. Another effect is that having more of the same value, possibly in a row, allows for stronger compression than having many different values. Ideally, one would untangle the two effects and measure them separately.

57.35 Efficiency (the larger the better)

What is the reasoning behind this definition of efficiency?

As I understand it, this efficiency is defined as:
(number of pairs after “expanding” the kerning) / (number of kerning pairs stored in the font editor)

The problems I see:

• After “expanding” the kerning, one gets many pairs that do not occur in the real world. In other words, we get “rewarded” for pairs that do not have any use.
• Why is this compared against the number of kerning pairs in the font editor? In order to calculate efficiency, I would expect a comparison against the space used by the kerning a font. Are you aware how kerning is written into a font? Each cell of the class kerning table uses 2 bytes, no matter whether it is zero or not. In other words, we’d have to take into account the implicit zero-cells, each of which uses just as much space (2 bytes) as the non-zero pairs that are stored and shown in the font editor. The number of pairs you can see in the Kerning Window (or which you can count via script) is irrelevant.