Fredrick Brennan

It was intentional, however, it seems that I forgot the `cmap` entry that would make `_JpnPostalMark` resolve to both U+20B8 and U+3012…

Really? I believe you, but you can see that I added it: Maybe a fontmake issue, or perhaps MFEKstroke doesn't understand multiple `` values (MFEK/glyphparser.rlib issue). https://github.com/ctrlcctrlv/FRBAmericanCursive/blob/df5b0678c4c821584319e06ce7a9cf4ae9166742/FRBAmericanCursive-SOURCE.ufo/glyphs/_J_pnP_ostalM_ark.glif#L5 Please double check.

Thank you, reopened. I think the problem is in MFEK/glifparser.rlib. I'm not sure when that'll be fixed, but I'll make sure to triple-check this before 1.3. Thanks for your diligence.

Sure, will do - canonical forms of letters used in real hardware beat my made up ones any day of the week. :-)

Will complex strokes be allowed, like all the modes supported by [MFEK/stroke](https://github.com/MFEK/stroke)? It seems we only consider to support CWS mode (not VWS or PAP). I think all three are...

Oh, also @skef discussed NIB mode of MFEK/stroke which I get by linking to `libfontforge.so`, so you don't even _really_ need FontForge Python API for it. It might be possible...

My proposal was that this is a purely rasterization flag.

I like `PaintColrLayersZOrdered` idea, but it won't fix translucent glyphs crossing.

I was tagged so assumed this was about https://github.com/googlefonts/color-fonts/issues/93, and _hoped_ we'd want to fix both, but if it's good enough for you to fix the one and not the...

Oh yes, very good catch! The `MERG` table is almost exactly what I want. But @PeterConstable would know as he works at MS—is this for antialiasing only as is claimed...