Hello all and a happy new year!
If I first set the kerning values for ‘a’ using aabacadaeafagahaiajakalanao etc, then set the left group of ‘a’ to: a, and then set the left of ‘ae’ to: a, then all the existing kerning pairs concerning ‘a’ unlock, meaning I have to relock all of them to get the correct kerning for ‘ae’.
Assuming there is some logic to this, and it’s not a bug, is there a way to close all locks for all glyphs?
Regards,
Jasper
I just saw that the same thing has been asked here: Lock icons keep popping open
But, I still don’t understand why such a feature has not been created. A simple ‘close all locks’ command in the kerning window would solve the problem. Obviously, such a command should not be used if there are intended kerning exceptions in the font, so a warning popup may be useful.
The Compress command does just that.
I don’t think so. Because say, va is kerned -20 with the lock open, and vä is not kerned at all with the lock closed, the compress command considers va a kerning exception, and leaves the lock open, which it isn’t supposed to be. I want to close the lock on va so that the kerning of vä also becomes -20.
Also, I’m not sure about the automatic opening of locks. Currently, it is set up in such a way that if I set up kerning values for ‘a’ first, and make the kerning class for ‘a’ after that, the lock gets opened by the app. I don’t get a warning about this, I just have to figure it out by chance. Furthermore, it forces me to set up my kerning classes BEFORE I start kerning, because otherwise I have to go through all the ‘grey’ kerning pairs and manually close the lock. This whole ‘auto opening of the lock’ doesn’t make much sense to me.
If there is no kerning for vä, the looks do not matter. (Or do you mean there is a zero in the kerning field?)
Assuming that the ä is in the same kerning group as the a the Compress command does exactly what you need. Sometimes you need to run it twice to get the full effect.
I find kerning troublesome in Glyphs for the same reason. I kern ‘a’ and then tell something else to be in the same kerning group, and ‘a’ suddenly becomes unlocked…it just creates needless extra work to have to go back and close everything.
What @Bendy said. And, is there a place where I can have an overview of all the kerning classes and what glyphs are in them?
Well almost. Because the Compress command will delete all exception-to-exception pairs and turn them into class-to-exception.
I confirm, I face the same problem with unexpected unlocking from time to time.
You can set the groups early on. When you kern later, it will be group kerning by default.
You’re can see them superimposed with View > Show Groups or you can sort by groups in the list mode.
Suggesting designers change their workflow instead of making the software more flexible? Type design is not a linear process, nor is there a single way all designers should work. This kind of reductive thinking really puts me off suggesting improvements and reporting bugs.
It is not about restricting. The problem is that there is no distinction between an exemption and a pair that got classes assigned later on. How does the compress function discern that?
It would need to have two different lock states but there is no way to store that in the current kerning data structure (that is used in Glyphs but also in ufos).
I’m open for suggestions.
I don’t mean to sound negative, but the effect of this is quite restrictive — setting all kerning classes before doing any kerning, or creating difficulties if not. I think all class kerning should be locked unless the user specifically unlocks pairs. Before using Glyphs, I found the kerning interface of FontLab unproblematic and more intuitive.
To explain the situation:
If you add a kern pair and the glyphs have no classes, then the pair is attached to the glyph directly. If there is a class, the it is attached to the class. You can see that in the kerning panel: some entries have an @, that means those are the class values…
So, if you start your kerning without classes, all kerning values are assigned to the glyphs (no @ in the kerning panel). For now all is fine. Lets say you have the following pairs: /T/o=-50 /T/odieresis=-10 /aogonek/j=+20 Now you add the classes and like to convert it to class kerning. The compress command goes through all glyph pairs and checks if the glyphs have a class assigned and if so, checks if that class has a value assigned already. If not, it move it to the class. So you get: @T@o=-50 @T/odieresis=-10 @a@j=+20. The first two are fine but the third is problematic. I don’t see a way of reliable detect what pairs to keep as exceptions.
I wouldn’t go as far as saying kerning in FL is unproblematic, but from my experience with Glyphs, the kerning interface definitely could use some improvements…
If I understand you correctly:
There is no possibility for a command that ‘closes all locks’ because whether a lock is open or closed is not actually stored in the kerning data. I’m no programmer, but it seems to me that it must be stored in Glyphs somewhere, and therefore such a command would make sense for within Glyphs, even if it only has an indirect effect on the kerning data. Furthermore, it wouldn’t have to differentiate between exceptions and ‘rules’, as it would just forcibly close all locks, and warn the user about any exceptions that might get lost.
The whole command probably wouldn’t be necessary, if the behavior of automatically unlocking locks would be altered. If AV is -20, and ÄV is not kerned, and then I add both A and Ä to the right kerning class/group ‘A’, that means I want both AV and ÄV to be -20. It would know that I want it to be -20, and not 0, since -20 is a manually included kern value, whereas 0 is just the consequence of not kerning. In the situation where AV is kerned -20 and ÄV is kerned -10, it would make sense for the lock to open, since there is no way for Glyphsapp to know which is the rule, and which the exception. In a situation where both are kerned -20, the locks could remain closed.
I hope this makes sense. think I understand the rationale behind unlocking the locks, but at the moment I think it’s doing more harm than good.
Glyphs does store the lock information, just not explicitly. The lock is open when the pair has classes but still kerning between glyphs.
1: The compress command does exactly do “Close all locks”.
2: It is not as easy. And what you describe is what the Compress command is doing. Just not automatic. So what should happen if you have a /aogonek/j=+20 pair. Should it be automatically converted to @a@j=+20. Probably not. So Glyphs can’t not know when to move kerning from glyphs to classes. There are some cases that seem obvious if a human looks at it but to build an algorithm that just works is not possible.
Running Compress Kerning twice does that — wherever possible. Obviously, if there is a conflict (e.g., AV -50 vs. ÄV -60), it will have to keep one of the exceptions. IOW there is no logical way to close all kerning locks in a situation like this.
No, that is a misunderstanding. Open = glyph (‘exception’), closed = group. That is the kerning data.
Two things:
If you do it, e.g., in this order:
… then Ä inherits all the group kerning created in step 3. Exchanging points 4 and 3 works as well, btw. Personally, I run the Set Kerning Groups script pretty early, so I usually start out with group kerning, and do the exceptions later.
Well… I know what you mean, and I understand your reservations behind rethinking a process that feels good and works for you. Though, what I suggested would mean running one script once. I don’t think it is a drastic change in workflow.
OTOH, if the user manually creates an exception (and that is what you do if you kern without groups), Glyphs should not assume the user would not know what he/she is doing.
It’s not so much that I’m attached to a particular workflow, but that type design is inherently a complex and often unpredictable process. That unpredictability means though one might try to set up all kerning classes before configuring any pairs, it’s often the case that kerning classes will need later additions. In a large glyph set, remembering which glyphs are locked, or which ones to check each time a glyph is added to a kern class isn’t very practical.
Thank you for taking the time to explain, @mekkablue and @GeorgSeifert! You make some fair points.
It seems that the ‘problems’ we are experiencing are more or less inherent to the way kerning groups are organized in Glyphs. The Glyphs method has its advantages, but I’m starting to think that the FL method, with a single glyph as the ‘group leader’, might eventually make more sense, as it would avoid the unexpected opening of locks.
Lastly, even if you don’t agree with my previous comments, a panel where one can comprehensibly view and edit which glyphs are in which kerning groups would be greatly appreciated.