Kern On

Jeremy Tribby wrote: ↑04 Apr 2024 Would it be helpful to have specific examples of this as OpenType feature code (and/or Glyphs specific format for VF), so that a suitable UI could be worked out from there?

Yes, that would be great!

I see. This brings up the same old question : “Find all composites in which the positioning of the components is affected by kerning.” This was surprisingly difficult to implement, as you remember, even with Georg’s help. To be honest, the current code never felt very robust to me, and now we are se...

Whether to autokern non-exporting glyphs is an interesting question. At first glance it makes sense to automatically exclude them but there can be non-exporting glyphs in a font that should be autokerned, e.g. for fractions. So, the approach is to generously generate autokerning pairs and then disab...

Thanks for the explanation and the workaround, Georg. I still don’t understand why you consider shouldAttach = False to be the correct return value in a case like this. The diacritic component is clearly attached (i.e. its position depends on the anchors). From a functional point of view, it does no...

Thanks for sending the file. Seems like we were not looking at the same file! Very similar but not identical, which made it easy to dig into it. As it turns out, the PUA values for the .case accents are causing this strange behaviour. What I tested: • Open your latest file (with PUA for the .case ac...

What happens if you run the script in Glyphs 3.2? I cannot run any Python scripts in Glyphs 3151 because Glyphs says it cannot not find a compatible Python version. One thing I noticed is that Hmacron seems to be completely unknown to my version of Glyphs. It doesn’t have a Unicode value and Glyphs ...

Btw this is a script that can be used to inspect what Glyphs returns for certain layer and component properties: for layer in Font.selectedLayers: print( layer.parent.name, 'hasAlignedWidth', layer.hasAlignedWidth() ) for c in layer.components: print( c, 'shouldAttach', c.shouldAttach() ) print() In...

This is strange. If I open the font with Glyphs 3249 and Kern On 1.31 then /H/macroncomb.case is not autokerned. Which version of Glyphs are you working with?

Thanks for your help, Sebastian. I definitely found the reason why the default groups were not set properly. They were set in the KO engine but not written to the userData in Glyphs. This discrepancy is the reason for the funny behaviour between the very first start with a font, and the next re-star...

Thanks for the explanation! I think I found the problem and fixed it.

Can you confirm: Setting the special spacing group only fails when starting with a fresh font, and before re-starting Kern On. Is that correct? Once you re-start Kern On, all behaviour is as expected, right?

Hello both of you, sorry about this. This is really frustrating for me as well because I really cannot reproduce the problem. Of course, I can see that it is happening in the video. Thanks for the detailed analysis, Alex. Seeing 1 vs 3 is very strange. Was the “Parenthesis” group one you created you...

As long as you don’t lose models or independents because of the crash, you can just finalize again. (Keep in mind that all kerning except models and independents is “lost” the moment you start Kern On).

Yes, we finally got it to work last week! I sat down with Georg to resolve this. It will be included in the next release.

Do you want me to send you my current in-house version if it’s urgent?

Some options are explained in the manual: https://kern-on.com/manual/#font-settings
Does that work for you?

You can just reply to your purchase confirmation e-mail, or use the one given in the footer at https://kern-on.com/

This is really difficult to answer without having the font file, I am afraid. Would you mind sending it to me?

This is really difficult to answer without having the font file, I am afraid. Would you mind sending it to me?

Hello everyone! I finally assembled a proper user manual:
https://kern-on.com/manual/

Some explanations are rather detailed – they might be interesting if you want more in-depth information than what’s shown in the videos.

Hi Brian, Thanks for your detailed feedback. Some of this is impossible to comment on without having the file or seeing more details, some of which I will try to answer here. Regardless of what font I’m working with in KO, I’m finding that with essentially any letters that have extremes amounts of n...

This does look a bit strange indeed. Would you mind sending me the file?

As a side note, one thing I noticed (although it does not explain the behaviour) is, why does the V have larger sidebearings than the W? I’d expect them to be the same or smaller.

It turned out to be a UI glitch. The list of special spacing groups simply did not get updated when we activate a different file (if KO is running for both files). Just fixed this. Btw, the old special spacing groups are still available in the drop-down menu after "Sync kerning types from"...

Hmmm... scratching my head.

This only happens if KO is running for both files. You could open both files, start KO for the target font and sync. Then close the other file.

It’s probably a bug, will have a closer look. Thanks for the notice.

One thing I noticed is that it does not import special spacing groups. No, this is a separate feature. It is called “Sync kerning types from”, also in the (•••) menu. “Kerning type” means special spacing, standard kerning or no kerning. If you want to transfer both then you should first transfer (s...

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 sen...

KernOn keeps telling me the right side bearing of my B is too tight so it kerns it away from the H by 7. Visually it’s now too loose to my eye, so I make a model pair and set it to zero. Yes, that’s the way to go! But now that affects my nn pair, which is also a model pair set to zero. That’s impos...

Manuel, sorry, here is the reply to what is left of your message:

What exactly was the problem? Did Kern On remove a model that contained the e? Which was the other model it was conflicting with?

It’s difficult to say what went wrong without seeing the file.

You should definitely not set the left side of the /n to “No kerning” as there are many combinations with /n as the second glyph that require kerning.

I’d strongly advise against using “No kerning” for any letters.

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

Hi mckc: overkern Let’s try to avoid this expression; it does not have any clearly defined meaning (and it is not commonly used afaik). In Rainer’s script it has a very specific meaning (see discussion here ), it seems you are using it with a different meaning (and, funnily, that spam bot with yet a...

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 an...

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...

Some spam filters are set to allow all posts from users that already have at least one approved post (I just saw that setting in my own filter but it is not active). That explains the strategy: first, one innocent post, followed by spam posts.

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.

Oh dear, I just found out that “DanielNiz” is in fact a spam account. Seems like LLMs are getting good enough to fool me (and the spam filter, which usually works quite well). In future, I’ll face the challenge of trying not to waste my time with stupid LLM-generated posts but also not to insult rea...

Daniel, what exactly does “overkern” mean as you use it? The term does not have a clear definition, and it is not widely used. The script referred to at the beginning of this discussion calls “overkerned” any pair that has a strongly negative kerning compared to the smaller advance width of the two ...

Yes, that’s exactly the problem.

Btw, the only perfect solution to handle the challenges described above is to use kerning triples. Implementing this in Kern On is fairly high on my to-do list, and Glyphs will also soon be more powerful at handling triples, I heard. ;-)

Update: It turned out that the script “New Tab with Overkerned Pairs” did not consider exceptions. I implemented that, and it is updated in the live version now. So, we should not get false positives from the script any more. I also slightly tweaked the algorithm in Kern On so as to avoid generating...

> I would love to, but KO keeps overkerning Thanks for pointing this out. I found out what is happening. This happens because Kern On usually has to omit exceptions in order not to exceed the given kB size. This means that, for rare pairs, we have to accept that the final kerning value deviates from...

Here is an example for reference. As you can see, the kerning value (-138) is exactly -50% of the advance width of quoteright (276). Even though, the script shows this pair if I set the threshold to 55%.

Just tried this script myself. One question is, where does the default 40% come from? What is the reasoning? Kern On limits the negative autokerning to 50% of the smaller advance width. If I set 50%, the script wrongly reports pairs. In other words, the output of the script is incorrect even accordi...

Class kerning (groups, as Glyphs calls it) is not necessarily better in this case: Three glyph-glyph pairs cost 3 * 4 bytes plus overhead for the first glyph. Writing these pairs into the class kerning table will add a row to the table, which costs 2 bytes per cell plus class definition overhead. Wr...

Maybe you omitted the .split() at the end of the first line?

This code should do practically the same but it is more complicated to set up. ;-)

You can also work with glyph names, with space in-between: characters_1st = 'f.calt g.calt t.calt f.liga t.low e.ss04'.split() characters_2nd = 'Aacute Abreve Acircumflex Adieresis Agrave Amacron Aogonek Aring Atilde AE Cacute Ccaron Ccedilla Ccircumflex Dcaron Dcroat Eth Eacute Ecaron Ecircumflex E...

This seems to be a unique use case. Right now, there is no elegant, built-in way of achieving what you want. Maybe I should add a feature that allows to specify user-set autopairs for groups of glyphs. For now, you can use this code: characters_1st = '◆■‣•' characters_2nd = 'ÁĂÂÄÀĀĄÅÃÆĆČÇĈĎĐÐÉĚÊËĖÈĒ...

I suppose you refer to the little lock symbol in Glyphs next to the kerning value? It’s just how Glyphs shows you whether a pair is a class-class pair (locked icon) or a glyph-glyph pair, a.k.a. exception (unlocked icon). It’s a strange visualisation as class-class pairs are not protected (“locked”)...

Sorry you are not getting the results you expect. It’s a bit difficult to tell what is going on without seeing it myself. Would you mind sending me the .glyphs file? Then I can have a closer look. It is not unthinkable that there is a small slip somewhere in the code that causes wrong output in your...

Sorry for not answering to your reply quicker. a user-specified filter into the step between where the deviations are calculated and when they are multiplied by the frequency of the pair. I don’t think being able to customize this value is necessary. It is not really a mater of taste and I believe a...

When Kern On determines the suggestions, the objective is to “fill the gaps” in the cloud of models. It should suggest pairs that have a shape combination which is not similar to any of the existing models, and therefore the engine (all models combined) currently has a “loose grip”, i.e. you will ty...

I can’t test the script in 3.1.2 as it complains about missing Python 3. I am certain that is worked at some point, as I tested it when I implemented it in February 2023. In any case, I think what Kern On needs to detect is clear: Composites in which kerning affects the positioning. It would be very...

Using this code: for layer in Font.selectedLayers: print( layer.parent.name, 'hasAlignedWidth?', layer.hasAlignedWidth() ) for c in layer.components: print( c, c.alignment, c.alignmentType() ) print() I am getting this output: onehalf hasAlignedWidth? True <GSComponent "one.numr" x=0.0 y=0...

Next attempt: for layer in Font.selectedLayers: if not layer.hasAlignedWidth(): continue pairs = [] prevComponent = None for c in layer.components: if c.alignment == 0 and prevComponent and prevComponent.alignment == 0: if c.alignmentType() == 3 or prevComponent.alignmentType() == 3: pairs.append(pr...

Btw, I am working in Objective C, of course. Georg, you can see the current code in the shared Github repo.

You mean something like this? for layer in Font.selectedLayers: if not layer.hasAlignedWidth(): continue kernedComponents = [] for c in layer.components: if c.alignment == 0: kernedComponents.append(c.name) if len(kernedComponents) >= 2: print( layer.parent.name, kernedComponents ) No, this also cat...

the fact that every launch is a new day means you have to proof *everything* after each correction, having no clue where to expect changes. This is exactly what the “Compare to” functionality is for. Just save the old version as a separate snapshot file, then start Kern On, make the changes, open t...

I need to identify composite glyphs in which the positioning of the components is affected by kerning.

Thanks for pointing this out. It’s not too difficult for me to implement the application of the font’s grid. I’ll add that to my to-do list.

Another possible work-around would be to work with a UPM of 20 (if your grid is currently 50 units at 1000 UPM). This is what I would do anyway, I guess.

Thanks for the file. This is a bug in Glyphs that was introduced at some point in 2023. I reported it to Georg in December. To demonstrate it you can use: for layer in Font.selectedLayers: print( layer.parent.name ) for c in layer.components: print( c, c.alignment, c.alignmentType() ) print() In som...

Hello, I seem to remember this was a feature introduced with some update a while back: glyph combinations that are used as components in other glyphs (such as /one.dnom /fraction in /onehalf) were kerned by Kern On, regardless of importance on the pair frequency list. Yes, this is how it should wor...

What exactly is it that is not working in the other masters?

Can you send me the file? Then I can have a closer look. Thanks!

Are the .italic glyphs accessible via any OT feature? In other words, is there any OT feature that has something like sub f by f.italic? If there isn’t then Kern On does not generate the auto-pairs for these glyphs. (The roboty answer would be that this means that in the exported font, these glyphs ...

As of today, is implemented in the latest version: Kern On now generates local models automatically when you un-autokern a master. You still get some warnings but Kern On is playing a trick: These warnings suppressed at first; they are only shown once you start modifying or setting new models, or if...

Good news! This problem should be solved. Get the latest update from https://kern-on.com/update/ and don’t forget to restart Glyphs!

Please let me know if you run into this problem again.

Update: I managed to reproduce this. Stay tuned.

This is tricky to answer without seeing the font. Kern On never thinks a pair is too tight as such, it only thinks it is it is too tight compared to another pair. For example, when it says “дл is too tight compared to vn” it might as well say, “vn is too loose compared to дл”, with the same meaning....

I will try to reproduce this problem. The challenge here is, this text field is an interaction between Kern On, Glyphs (because KO uses an Objective C class provided by Glyphs), and macOS, of course. Any change in any of the three can potentially trigger this wrong behaviour. Would you mind letting ...

Sorry, this video seems to be private. YouTube doesn’t allow me to see it.

Thanks for sending the file. So far, I could not find anything that does not work as it should. Maybe some clarifications help: Whenever I pick a group for a character, it’s not saved. This is strange. You mean, while Kern On is running the special spacing group shows on the dialog for the glyph but...

Sorry about this. Would you mind sending me the file? Then I can have a closer look, and I am sure we’ll find a fix!

Btw you can also try to juggle pairs and values by showing the models in the upright, then copy-pasting them (as text) into the italic, select all, make them models. In order to transfer the values you could shut down Kern On, open an autokerned backup of the Italic master, copy-paste all kerning to...

I would like to copy just the model pairs, but set the values resulting from the autokerning process. Agreed, this is simply what should happen if you deselect “Autokern from”. If you deselect “Interpolate master” this is how it already works (I believe) but I need to implement the same principle f...

I assume what is happening is what you also suspect: The pair is too infrequent in the list. This is why it does not end up with the ideal value (as it is generated on-the-fly while Kern On is running). See my explanation in the other thread for more details. As an experiment, you can increase the v...

What you describe is roughly how the class kerning algorithm works. Sticking to your example, let’s assume a certain pair against /adieresis has an ideal value of 50, and /amacron has 60. If 50 is the class kerning value then, if the exception with /amacron is omitted, the deviation is 10. Multiply ...

Thanks for the notice. I identified the bug that leads to the wrong slider behaviour, and I think this also fixes the wrong behaviour of the key-up and key-down in the text field (which was not as easy to reproduce). You can get the update from kern-on.com/update . Please let me know if any of the p...

Thanks for the notice. Yes, we do get a lot of spam and, although the spam filter is generally doing a good job, it sometimes lets things slip through.

Using class kerning for sparse rows or columns is inefficient in terms of data size: We need 2 bytes per table cell, no matter whether it is used (non-zero) or not. Glyph-glyph pairs need 4 bytes per pair (each option has a certain overhead). So, for rows or columns that contain fewer pairs than rou...

In principle, this would be possible to add as a feature but why would you want to do that?

Thanks for sending the file. This crash only occurs in very specific situations (one master autokerned from another master, from which all models are removed). I just fixed it in the code.

Thanks for the notice. Would you mind sending the file? Than I can investigate. Thanks!

Yes, I can confirm that Kern On crashes if all masters in the font have “Link Metrics With Master”. It seems to be independent of the OS (and, looking at the code, it should be). I am just fixing this crash. This set-up, however, is unreasonable: How can all masters in the font be linked to somethin...

Sorry, I cannot reproduce this crash here. Would you mind sending me the file? Thanks!

Thanks for the notification. I am installing Sonoma on one of my computers right now and will have a closer look at this problem.

This seems strange. Would you mind sending me the .glyphs file?

The quick answer is: Don’t worry about the number of kerning pairs. The somewhat longer answer is: Don’t try to make you font pretty under the hood. All that counts is the visible, final rendering. If that looks good then all is good. Try to be rational: What is the issue with a large number of pair...

What you describe clearly sounds like a wrong behaviour or Kern On. Would you mind sending me the .glyphs file so I can reproduce it? Thanks!

1. Sorry, there are still not bubbles yet. What you can do is: • keep a copy of the file with the manual Latin kerning • in Kern On, set the Latin letters to “No kerning” • after finalizing (generating the full autokerning), copy & paste the Latin kerning fro your backup file You need to do this...

Sorry, RTL is not implemented in Kern On yet. It is definitely on my to-do list, though. Stay tuned!

Further: When I generate the list of supported pairs (i.e. pair_frequencies.txt) I first crunch large amounts of text from various sources, combine them and then remove what appears to be junk data or does not make sense to me, and then synthesize pairs based on what I consider sensible pairs. “Synt...

The pipeline that generates the list of pairs has a list of to-be-kerned characters, which is the results of several whitelists and blacklists. I can confirm that all the mentioned characters are on the list: in principle, they are not excluded. Some more details on the occurrence in my corpus: ʔ U+...

To get a better overview: Latin Extended-B: Ɂ U+0241 LATIN CAPITAL LETTER GLOTTAL STOP (This is the uppercase of U+0242 and U+0294) ɂ U+0242 LATIN SMALL LETTER GLOTTAL STOP (This is the lowercase of U+0241 and U+0294) IPA Extensions: ɬ U+026C LATIN SMALL LETTER L WITH BELT ʔ U+0294 LATIN LETTER GLOT...

Are you using the 0k feature? This is always an interesting tool for analysis, to understand whether a pair is not kerned because it is simply not in the system, or whether it was lost because of its low frequency. You can also have a look at the file pair_frequencies.txt inside KernOnGlyphs3.glyph...

Okay, I just removed the default shortcut. This will be reflected in the next KO update. Let’s hope there are few or no users who want a shortcut, and at the same time cannot do so on their computer.

Good to know!

I guess I can’t “close this” thread, using a stone-age forum (oh, wait: bulletin board) software here.

Thanks for the notification, I will look into this.

Also, Eben’s idea is very good. If you specify 0kB you will get un-compressed raw glyph-glyph kerning. Could be a good hint when searching for the underlying problem.

Sorry to hear about these problems. Which version of Kern On are you using? In case you are using the latest version you will find an “About Kern On” entry in the (•••) menu. If you could send me the .glyphs file that would be great, then I can have a look and I’m sure we’ll solve the problem. Btw, ...

Kern On “links” all models to all autokerned pairs. It does not link any models to each other. Rather, it tries to assemble them all into an autokerning engine. Sometimes it doesn’t manage to “fit them all under one hat”, as we say in German, and it needs to remove one or several models. There is a ...

Another important thought: When we design typefaces, we do two things: Looking, and Thinking. Some decisions are based on Looking, such as “The w needs to be a little wider”. Other decisions are based purely on Thinking. While Thinking can be powerful and efficient, it can be (1) undeniably correct,...

If you slant a correctly spaced font then that means in practice, the spacing is usually still pretty much correct. If you look at it from a geometric perspective, though, you can’t say that nothing happens to the space between the shapes. One thing is, the distance between the shapes gets smaller i...

Kern On | Kern On forum

Search found 349 matches