I have an updated version of a font with shape and spacing changes to a large subset of glyphs (all changes made in FontLab 8), and an older Glyphs source with Kern On project. What is the easiest way to merge the Kern On project into the new version exported from FL8 to Glyphs? The subset of revised gyphs are not involved in KO models, so I want to be able to use the existing model set and not have to start KO from scratch.
I suppose one option is to open the old Glyphs file and replace the subset of revised glyphs. Is that the easiest way, or is there a method to copy a KO project one .glyphs file to another?
Copy kern on project?
Re: Copy kern on project?
You can copy the data that Kern On writes. The models are stored in each master's user data:
master.userData["KernOnModels"]
and so on. You can similarly find the other relevant dictionary keys. Don't forget to copy the kerning (exceptions) as well.
master.userData["KernOnModels"]
and so on. You can similarly find the other relevant dictionary keys. Don't forget to copy the kerning (exceptions) as well.
-
Tim Ahrens
- Site Admin
- Posts: 415
- Joined: 11 Jul 2019
Re: Copy kern on project?
Yes, the data is stored in the font (-file), using Glyphs’ support for user data, as Sebastian pointed out.
• Models, independents and user-set autopairs are stored in the master’s user data.
• The special spacing (or no kerning) information is stored in the individual glyph’s user data.
• Some other information such as version and recent user choices can be ignored when transferring a KO set-up. Same for the “KernOnName” entry in the glyph’s user data, which is only there to ensure correct identification of glyphs if the user re-names glyphs while KO is sleeping (fwiw, you shouldn’t do that while KO is running).
I personally like to inspect .glyphs files in a text editor occasionally. It’s probably not convenient enough – although possible – to use a text editor to transfer the data, though. Just tried with a .glyphspackage, which is somewhat more structured, but it’s probably not ideal.
It’s probably easier to use KO’s support for transferring data between fonts (or masters):
I hope this is self-explanatory. Make sure both fonts are open in Glyphs.
In the new font, you probably need to do the “Type at least 10 pairs” step first to make KO happy, then you can de-activate the models if necessary, then transfer the data. I realise this is not perfect, and we should ideally have a built-in function to transfer the whole set-up in one step. Will put that on my to-do list.
Keep in mind that showing the list of models/independent/user-set autopairs (by clicking on the arrows) gives you additional possibilities to juggle and shuffle things around with more fine-grained control. For example, you can copy and paste the list of pairs to a different font. There, you can select all and then switch all pairs to the desired type (creating models, for example). To transfer pairs between masters, you can simply show the list, activate a different master, select all and then do what is necessary. Or, just use this technique as a passive check whether things are like in the other font or master.
Similarly, for kerning types (normal/special spacing/no kerning) and special spacing groups, “Show overview” in combination with copy & paste and selecting multiple glyphs gives you some possibilities to compare or transfer data in a more fine-grained way.
In order to transfer kerning values (rather than pair types), you may want to copy and paste kerning from Glyphs’ kerning window while KO is sleeping. It only stores the pair types (not the values) so, when it wakes up, it will simply use the new kerning values without even realising what happened.
• Models, independents and user-set autopairs are stored in the master’s user data.
• The special spacing (or no kerning) information is stored in the individual glyph’s user data.
• Some other information such as version and recent user choices can be ignored when transferring a KO set-up. Same for the “KernOnName” entry in the glyph’s user data, which is only there to ensure correct identification of glyphs if the user re-names glyphs while KO is sleeping (fwiw, you shouldn’t do that while KO is running).
I personally like to inspect .glyphs files in a text editor occasionally. It’s probably not convenient enough – although possible – to use a text editor to transfer the data, though. Just tried with a .glyphspackage, which is somewhat more structured, but it’s probably not ideal.
It’s probably easier to use KO’s support for transferring data between fonts (or masters):
- Screenshot 2023-05-03 at 09.37.54.png (103.3 KiB) Viewed 2298 times
In the new font, you probably need to do the “Type at least 10 pairs” step first to make KO happy, then you can de-activate the models if necessary, then transfer the data. I realise this is not perfect, and we should ideally have a built-in function to transfer the whole set-up in one step. Will put that on my to-do list.
Keep in mind that showing the list of models/independent/user-set autopairs (by clicking on the arrows) gives you additional possibilities to juggle and shuffle things around with more fine-grained control. For example, you can copy and paste the list of pairs to a different font. There, you can select all and then switch all pairs to the desired type (creating models, for example). To transfer pairs between masters, you can simply show the list, activate a different master, select all and then do what is necessary. Or, just use this technique as a passive check whether things are like in the other font or master.
Similarly, for kerning types (normal/special spacing/no kerning) and special spacing groups, “Show overview” in combination with copy & paste and selecting multiple glyphs gives you some possibilities to compare or transfer data in a more fine-grained way.
In order to transfer kerning values (rather than pair types), you may want to copy and paste kerning from Glyphs’ kerning window while KO is sleeping. It only stores the pair types (not the values) so, when it wakes up, it will simply use the new kerning values without even realising what happened.