Hey there,
I was hoping to make a new font in the language Khmer, but it seems like the type is not available on glyphs yet, any ideas of how to generate the font?
There is no default set in the sidebar, but that does not mean that you cannot add Khmer letters. Try Window > Glyph Info and search for khmer. Do you know Khmer well? Perhaps you want to help creating categories for the sidebar.
I made my own a couple years ago, but since I don’t ever use the sidebar for anything I never bothered to do anything more with it. I could send it over, but @RobPratley didn’t you make Khmer categories for the sidebar?
Also, if you want to see a Glyphs file for Khmer (or tons of other scripts) all the source files for the Google Noto project are at https://github.com/googlei18n/noto-source/tree/master/src
2 Likes
I started to yes, but didn’t get it finished as other things came up. I will finish putting it together, then put a link to it in here.
1 Like
Great! Would be much appreciated
Highjacking this thread for a related question:
Is the missing implementation of Khmer the cause for why my marks don’t attach according to their anchors in Khmer? Languagesystem is set and my test document work shows working mark attachment in other Khmer fonts, so it cannot be due to the test document. The Marks-Cloud in GlyphsApp is displaying the marks in the correct position as well. Any ideas?
Have you had a look at the mark and mkmk features in the temp features.fea?
Yes, now I did 
There is some stuff like
feature blwm {
script khmr;
pos base [ka-khmer] <anchor 492 0> mark @mark_bottom;
pos base [kha-khmer] <anchor 434 0> mark @mark_bottom;
# and
... lookup abvm_mkmkkhmer_top {
pos mark [e-khmer] <anchor 161 520> mark @mark_top;
} abvm_mkmkkhmer_top;
etc. So I assume it is working until some point where the cause is to be seeked somewhere else?
I see the Microsoft spec from 2002 lists abvm and blwm rather than mark for Khmer, but why? I’d managed to get a prototype Khmer font rendering perfectly well in all tested environments with mark and mkmk only (since it’s so similar to Thai with regard to marks, I didn’t see a reason to change the system).
Is there some useful distinction between the different kinds of mark features? They’d all be GPOS LookupType 4 or 5, right?
Side note: if including script tags in these auto-generated features, as in @Mark’s compiled feature code, the fonts won’t put marks in the right place unless the script is declared in the HTML test doc, or by the app? Shouldn’t it also work for script dflt in situations where the script is not explicitly declared?
Hi Zachary
In the Noto Sans Khmer, you might want to consider including subjoined forms of all the independent vowels, not just the handful that are there already. My Khmer colleague (he works with Danh Hong) tells me these are ‘somehow important for linguists and archaeologists’, and they’re included in some fonts (e.g. KhmerOSsiemreap), though they’re terribly squished. I’m still digging around on these — will try to do a Wikipedia Khmer dump and search for all coeng-independent vowel sequences — but if they do turn out to be useful perhaps they should also go into the Glyphs XML.
I ran into something years ago where mark and mkmk wasn’t always working correctly, but blwm and abvm were fine. I can’t remember exactly what it was, but because the MS spec says abvm and blwm there could very well be implementations that only expect that. There’s no logical reason to require abvm or blwm over mark and mkmk, but I wouldn’t be surprised if some software treats them differently.
They usage of abvm and blwm can tell the layout engine something about the layout. I don’t really remember what it what and if it is relevant for Khmer. I’m happy to use mark/mkmk, because it is much easier to do and more stable.
Can someone send me some relevant sample texts with a font that renders it correctly and a .glyphs file. Then I can have a look.
OpenType selects the script based on the Unicode code points in the text, not based on any declaration. For the language, it does depend on declarations, such as the HTML lang attribute.
It’s odd. I’ve run into cases where mark and mkmk (and even kern) not having script tags meant they did not get applied when text is marked with a script. I’ll try to find that font, but my approach would be to duplicate the lookups for dflt and the script, to be most reliable in most circumstances.
@Mark does the feature work any better if you manually remove the script declaration?
I’m moving the code that the lookups don’t have any script/language but then are called again with it. That way both cases (where you need the declaration and where not) will work. I’ll have a look how Khmer is doing in that regard.
@Bendy You mean the one in the Languagesystems? That’s the only one I got. And there is an auto-generated feature
script khmr; lookup Abvs1_khmer { ... } Abvs1_khmer; (just shortened here)
@GeorgSeifert would a simple HTML with some random text in a couple of working fonts suffice?
Yes.
I meant here:
See what happens if you remove the script tag in the .fea file and re-export the fonts.