I found the part about randomisation interesting.
It inspired me to do a bit of coding. I’ve never coded before, never needed to until the last couple of weeks, learning font making. I’d love to hear what you think of my first effort in code!
I thought it would be nice to have a font with really common letters in 11 different versions/variants; and the rest in 6 versions. So I have done a test with numbers (from already existing fonts). There are 11 versions of 1,2,3. There are 6 versions of 4,5
I did this to test if I could make it seem random under the tightest possible constraints. Here are the results of my code>
Using only 4 and 5:
In each picture I will include the non-repeating text plus one line of repeat, i.e. the first line again, as it naturally reoccurs.
I had never heard about randomisation in fonts before a few days ago but it sounded like a good idea. How does this seem? I think it should appear genuinely random with any normal text. Do I have the right approach?
Impressive. Technically there is also a rndm feature, but it still has little app support.
Best in terms of randomization inside contextual feature code only that I can offer are independent glyph cycles. There’s sample code for two cycles (vowels and consonants) in the Advanced Contextual Alternates tutorial. I have had good results with up to six cycles. Beyond that, the contextual chains became overly long and complicated and you didn’t see much of a difference anymore. If I had to do it again, I would probably do three cycles.
Yes, I was inspired by that tutorial, so I created this script in the calt feature… Took me a long time! But the code is fairly short Seems just with these two cycles it is pretty random, don’t you think?
It worked impressively with just those 5 numbers. However I have had trouble with my actual proper font.
My font has the same principle - really common letters in 11 different versions/variants; and the rest in 6 versions. I copied the code I made for the numbers test and pasted it into this font. It works great on Glyphs!
However it doesn’t work when exported, in Pages. Nor in TextEdit.
What it does is only show the glyphs that are not ligatures. None of the ligatures are working. And by the way it’s only the ligatures that are randomised in the above process. And the glyphs that are not ligatures that are in the randomisation process (only a few), while they do appear, they only appear in one version. N.B. on Glyphs they cycles through 6 versions.
Since it worked in Glyphs fine (randomised ligatures displayed perfectly), but not when exporting, I ran some trouble shooting:
Disabled the calt function and exported again:
All the ligatures worked. Obviously the randomisation did not take effect.
I considered whether it was because I only had regular versions of the components for the ligatures. So I added all components in all alt version. Result: Glyphs - no change (still working). Pages and TextEdit - no change (still not working).
I also tried going back to the number test font I made above, and replacing 4 into f_o_u_r.liga. That font also has the alphabet, so there are versions of all the components already, but, only in the regular version, no alt versions. But, it still works when exported in Pages! No problem. Ligature worked fine, and also came in the proper randomised sequence. So it doesn’t seem to be simply because it has a ligature.
And as I said, the code is identical.
And yet, since the full font works in Glyphs fine, and works in Pages when exported with calt disabled, it stops the ligatures from working in these other apps after being exported.
Any ideas? Here’s my code: [Edit: it says I can only mention 10 users - maybe it’s the @ marks in my code? Anyway can’t post the code apparently but happy to PM it to you!]
If you have your ligature feature before the contextual cycling, the ligatures must be part of the cycle somehow, e.g. like in the @etc class in the sample code of the tutorial.
If you have ligatures after the contextual cycle, you cannot use the original a, b, c for a_b_c anymore, because this sequence of glyphs will not exist anymore after contextual cycling, because instead of a b c, it may have become a.alt2 b.alt1 c.alt1 or something similar. You would need to substitute not sequences of individual glyphs, but sequences of glyph classes, approximately like this:
sub [a a.alt1 a.alt2 a.alt3] [b b.alt1 b.alt2 b.alt3] [c c.alt1 c.alt2] by a_b_c;
Yes, the classes that are cycling has mostly ligature glyphs. Also my ligature glyphs have nothing to do with the components - I just used ligatures to make an easy input system. Since it’s a non-English writing system.
In both the number test font and the full font, ligatures are above calt.
Thanks! Here it is:
sub [@common_ALT8 @rare_ALT1] [@common_ALT10 @rare_ALT5] [@common_ALT9 @rare_ALT4] [@common_DEFAULT @rare_DEFAULT] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT1 @rare_ALT1];
sub [@common_ALT10 @rare_ALT3] [@common_ALT5 @rare_ALT5] [@common_ALT4 @rare_ALT4] [@common_ALT3 @rare_DEFAULT] @rare_DEFAULT' by @rare_ALT3;
sub [@common_ALT10 @rare_ALT3] [@common_ALT5 @rare_ALT5] [@common_ALT4 @rare_ALT4] [@common_ALT3 @rare_DEFAULT] @common_DEFAULT' by @common_ALT2;
sub [@common_ALT5 @rare_ALT5] [@rare_DEFAULT @common_ALT6] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT7 @rare_ALT2];
sub [@common_DEFAULT @rare_DEFAULT] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT1 @rare_ALT1];
sub [@common_DEFAULT @rare_DEFAULT] [@common_ALT1 @rare_ALT1] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT2 @rare_ALT2];
sub [@common_DEFAULT @rare_DEFAULT] [@common_ALT1 @rare_ALT1] [@common_ALT2 @rare_ALT2] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT3 @rare_ALT3];
sub [@common_ALT2 @rare_ALT2] [@common_ALT3 @rare_ALT3] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT4 @rare_ALT4];
sub [@common_ALT3 @rare_ALT3] [@common_ALT4 @rare_ALT4] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT5 @rare_ALT5];
sub [@common_ALT4 @rare_ALT4] [@common_ALT5 @rare_ALT5] @common_DEFAULT' by @common_ALT6;
sub [@common_ALT6 @rare_DEFAULT] [@common_ALT7 @rare_ALT2] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT8 @rare_ALT4];
sub [@common_ALT6 @rare_DEFAULT] [@common_ALT7 @rare_ALT2] [@common_ALT8 @rare_ALT4] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT9 @rare_ALT1];
sub [@common_ALT8 @rare_ALT4] [@common_ALT9 @rare_ALT1] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT10 @rare_ALT3];
sub [@common_ALT8 @rare_ALT4] [@common_ALT9 @rare_ALT1] [@common_ALT10 @rare_ALT3] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT5 @rare_ALT5];
sub [@common_ALT10 @rare_ALT3] [@common_ALT5 @rare_ALT5] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT4 @rare_ALT4];
sub [@common_ALT10 @rare_ALT3] [@common_ALT5 @rare_ALT5] [@common_ALT4 @rare_ALT4] @common_DEFAULT' by @common_ALT3;
sub [@common_ALT3 @rare_DEFAULT] [@common_ALT2 @rare_ALT3] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT1 @rare_ALT2];
sub [@common_ALT2 @rare_ALT3] [@common_ALT1 @rare_ALT2] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT8 @rare_ALT1];
sub [@common_ALT1 @rare_ALT2] [@common_ALT8 @rare_ALT1] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT10 @rare_ALT5];
sub [@common_ALT8 @rare_ALT1] [@common_ALT10 @rare_ALT5] [@common_DEFAULT @rare_DEFAULT]' by [@common_ALT9 @rare_ALT4];
[Edit: I’m not sure why only every other line have bits in red. Could that be a part of the problem? I copied and pasted it straight from Glyphs calt feature into this comment.]
I was just doing something and thought it might be connected? When editing a glyph, I wanted to use a part of it to make a new glyph, but unrelated to the first. I selected the part I wanted, and chose ‘component from selection’. I found it a nice way to make a new glyph. However, I don’t fully know what ‘component’ means. And in one ligature, it warned me it was going to affect all master layers or something? Could doing this procedure have caused the issue?
Bare in mind it works fine in Glyphs, so, still curious as to what is wrong. Apparently not wrong enough to stop it working in Glyphs.
Also if my code looks weird, I can explain why - it gives a 13 step sequence. I made two overlaying 13 step sequences to give more randomness than merely giving 6 (and 11) glyphs in ordinary sequence.
That is just because it defaults to Python syntax. You can add text after the first triple backtick. (I did that for you now.)
If it works in Glyphs, consider: making sure there is no cache problem, and make sure the right features are active, and your aalt is up to date. Otherwise it is hard to tell remotely. I still suspect a mixup with the ligatures not being part of the right groups, and the groups you are substituting are not the ones that are there at that moment.
Components: please read the Handbook chapter ‘Reusing Shapes’, and this tutorial:
It’s not.each time I always export with a new font name.
The calt function was working automatically with the other one. The font only worked (without alternates) when exported with calt disabled. Turning it on before export made the problem.
From this I assume the apps don’t need me to turn anything on manually for this. But that something in connected with calt is making the font not work. Even though it’s the identical calt script that did work with the number test font. Both work in Glyphs. Any ideas? Or can you limit the issue to what variables could be causing it?
I cannot see there what the effect is that was described by the automated message on Glyphs as doing something to ‘masters’.
Anyway just to be sure, I selected all glyphs, and then selected ‘decompose components’, hoping that would solve any potential problems with components.
For some reason now when I click on ‘update’ in Features, it says:
MakeOTF error
An unknown problem occurred. MakeOTF could not write the font file.
Struggling to find why, and not sure if that is what caused it, or something else I did before!
Anyway, I still have the old version… so back to that and why it’s not working. I now discovered a feature in ‘features’ that must have automatically been added, called ccmp. It has 3 of my ligatures in it, like this:
lookup ccmp_latn_1 {
lookupflag 0;
sub h a r u by h_a_r_u.liga;
sub m e r u by m_e_r_u.liga;
sub s u r u by s_u_r_u.liga;
} ccmp_latn_1;
script latn;
lookup ccmp_latn_1;
I notice that having the calt funtion switched on when exporting, makes the resultant font in Pages makes any of my normal ligatures not happen. However, these ones still do. I do not know if this is an important function, since there is the liga function somewhere above in the list. And those 3 are also already in that list, automatically, along with all the other ligatures. That seemed to be doing this function just fine with the others. But, could this be part of the issue?
Also I do not know why only those 3 are in there. Perhaps I used a different way to generate new glyphs for those one…?
I now see what difference there is in those 3 glyphs. They’re nonspacing marks. They’re the only marks. I guess that’s what made them get automatically put in the ccmp feature. I am guessing that’s a good thing somehow? But curious they are the only ones working when exported. Hopefully this will help diagnose the situation!
Summary:
Turning the calt funtion on makes no difference in Glyphs but stops the non-mark ligature glyphs from appearing once exported into Pages and TextEdit.
The number test did not have any marks. I wonder if that is causing the problem. I will test and report back.
One other thing I notice, probably irrelevant but just in case - I have some alt ligatures that have more than one version, such as one ligature which in addition to .ss04 ending, also has a version .ss04.002. Could that be a problem? They’re just spares that won’t appear in the font, unless manually chosen I guess. But they do not feature in the calt code. Just the regular .ss04 in proper place.
Hmm, ok that was quicker than I expected. So I selected those 3 glyphs and pasted them into the number test font. N.B. I have already added the whole alphabet to that font so they should work right? Ligatures such as h_a_r_u.liga, since this font has the h and a and r and u - even though their glyphs are not actually used in the ligature glyph.
So I pasted these nonspacing marks from my main font into the number font:
/h_a_r_u.liga/m_e_r_u.liga/s_u_r_u.liga
Though they do not in the main font, here pasted, they appear with a warning sign, yellow triangle with !, in the top right corner. When I click on them to get into edit view, I no longer see any warning sign. So I do not know what it is warning me about. Perhaps this is part of the problem?
Sorry! I now realise why - was references to other glyphs in the main font for left and right spacing. Fixed that - the number font DOES work fine. It generated the same ccmp feature code. It all worked fine on export. So, seems it was not that. …
By the way, now I cut the glyph name down one hyphen at a time off the end. It was finally working when there were only three left on the right. That’s 60 characters long. Is there a 60 character limit perhaps? (I tried searching on the ‘naming’ tutorial but could not find the info.
If it’s the length that’s causing the problem, it could maybe be worth adding an error message that can identify why the whole font is not working? I guess maybe it’s not a common problem to run into, but would be useful for those like me!
Marks are usually ignored in ligature features. That is what the lookupflag IgnoreMarks directive is all about. You can either take out that line or rewrite the substitution context.
Could you explain a little more? Does it mean that you can make a ligature, and it will be automatically added to the liga feature, but will not work as a ligature when exported?
And so we need it also to be in that ccmp feature (also automatically generated)?
Which is ‘that line’ - the one in liga, or in ccmp feature? Also is there any problem with just leaving them as they were automatically generated?
And… could you say anything about the big issue I was happening that stopped all ligatures working except those in the ccmp feature? specifically the long ligature I explained above? I finally stopped troubleshooting as Glyphs kept crashing with my full font, but I have a version working which is the same - copied all the glyphs and code to a new project and it works fine, without that glyph.
But I’d like to know what caused the problem and how to avoid it, since it took me multiple full days of work to identify what was causing the whole font to not work. I did read the naming tutorial and could not find the answer, so. I’d love to know. Maybe there’s a character limit for glyph names? Or a limit to how many hyphens can be in a ligature? Or…
Seems just with these two cycles it is pretty random, don’t you think? 