Add Nine Pointed White Star to Symbols2

[LaPingvino]

Fixes #64

[LaPingvino]

Abandon this version, will be picked up by @eliheuer

[LaPingvino]

@ctrlcctrlv suggests to reopen this PR

[LaPingvino]

Corrected to the new structure TODO: Add the correct metadata for this file around it

[LaPingvino]

Ehhhh, turns out that Glyphsapp's .glyph and UFO/fontforge .glif is NOT the same thing, so this merge isn't going to work anymore. I don't have a Mac so someone needs to do this for me...

@eliheuer do you have a Mac with Glyphsapp?

[LaPingvino]

okay @simoncozens, it looks like you are the culprit for changing from UFO to glyphsapp, I don't have a Mac and it looks like @ctrlcctrlv found more issues with the existing font than with my .glif file, so you might as well do the conversion and be done with it. My hands are tied here unless someone else has a Mac and can do that work.

[ctrlcctrlv]

So, now that it's reopened time for some technical discussion. This PR is a bit confusing as it's against b1380f6ef262d25a9e5405278726b8f0754b3332.

As of b1380f6ef262d25a9e5405278726b8f0754b3332, this repository was using UFO. But it seems like in the interim, it was converted into a laundered GlyphsApp font. So, when @LaPingvino asked “how are community contributions accepted” the answer was essentially “they aren't, unless you have GlyphsApp”.

And the entire “.glyphspackage” is totally…corrupt looking? I mean, none of these files are what they claim to be. The plist's aren't plist's, they are some quasi-JSON format (note the parenthesis—wtf?) apparently invented by Glyphs GmbH.

I can't edit this other than by hand and then fight with fontmake for hours, and then who knows if the files I hack together will work with Glyphs.

Don't close this PR though. UFO's should be restored, then the first version merged.

[simoncozens]

The plist's aren't plist's, they are some quasi-JSON format (note the parenthesis—wtf?) apparently invented by Glyphs GmbH.

These are plists. You're just a youngster. :-) NextSTEP plist files were invented before JSON even existed...

I can't edit this other than by hand and then fight with fontmake for hours, and then who knows if the files I hack together will work with Glyphs.

Nobody is asking you to do this.

[ctrlcctrlv]

Joop is :-)

[ctrlcctrlv]

For example, fontmake does have the ability to understand some GlyphsApp files (its level of support I can't say). But we could at least convert both masters, write a .designspace, and then use that to make a binary font. No way would it be accepted though.

It's anyone's guess what some of these key-value pairs mean:

instanceInterpolations = {
"6E6EE38D-3D27-4929-8DEE-9F0163F8D5EF" = 0.79;
"F394B0DB-5C84-43F6-ACB2-AE9DD557A8AE" = 0.21;
};

The order is furthermore bizarre, contents from order."plist" find themselves dumped verbatim into fontinfo."plist", it's unclear to me whether one of these files takes precedence, likely that's a matter on which fontmake and Glyphs will differ.

Kern pairs are stored haphazardly, just put basically anywhere, I see them in the glyphs and in the fontinfo, again another precedence issue.

The glyphs themselves totally ignore UFO .glif format and even have a boolean key for open/closed instead of simply differentiating on PostScript moveto, as would be the compatible way to do it.

God only knows what this means:

note = uni1F170;
production = u1F170;

If I had to guess—"on binary OTF write time this glyph is u1F170 but in the UI it's uni1F170 for consistency".

In sum I am sorry but if I have to contribute back in this format I can't and expecting a free software developer to do so is beyond wishful thinking.

It seems like this format is Glyphs GmbH's attempt to improve upon its previous even more bizarre flatfile .glyphs format: see https://forum.glyphsapp.com/t/documentation-on-the-glyphspackage-format/23435. Of course, that's the first result for ".glyphspackage documentation", meaning: there is no documentation.

It's unfair to ask Joop to buy a Mac+Glyphs license just to add this symbol, but unfortunately despite my greater experience I have no better immediate solution than he, for my solution would be to do away with the proprietary format as quickly as I could relying on fontmake's ability to extract whatever sense it can from its apparently (as I've just been helpfully informed) NeXTSTEP-inspired spaghetti.

But now that I know the origin of the sadness at least I can say with considerable certainty the GNUstep project probably has a parser. :joy:

[simoncozens]

Your views on the file format are well-known and noted.

[ctrlcctrlv]

(I told Joop I would do my best to do this privately so I am now writing here for he and others to know why this will not be getting done by anyone but probably Eli or another Glyphs user, as I did try a bit to see if I could roundtrip UFO to glyphspackage and no that won't work, so either a free format needs to be in use or someone willing to use Glyphs needs to use it. I'm not writing this for no reason, clearly he didn't know my position or he wouldn't have asked for my help, which I only gave as this PR was originally against a UFO and I didn't notice it had changed, I thought the problem was just FontForge's poor MM/GX support.)

[simoncozens]

If you want to make any changes and you don't have Glyphs on your machine and your editor doesn't open the Glyphs file format, run glyphs2ufo, do the edits, run ufo2glyphs.

[ctrlcctrlv]

Yeah that doesn't roundtrip cleanly, changes not made show up. And as I can't verify whether the final font still opens in Glyphs it seems dangerous for me to try to piece it together in Git. I certainly could try, what do you consider the final authority on the validity of a .glyphspackage and how it relates to its output binary font—Glyphs or fontmake?

[simoncozens]

what do you consider the final authority on the validity of a .glyphspackage and how it relates to its output binary font—Glyphs or fontmake?

In Noto we build .glyphspackage files using fontmake, so that's what has to work.

[ctrlcctrlv]

OK good, that's good at least, I'm somewhat confident I can do that as this edit is so simple, if I use Git to not pick up incidental changes but only the new glyphs, and test fontmake on every version. Thanks.

There also seems to be a GNUstep tool I can use to roundtrip the NeXTSTEP .plist files to XML .plist and back, so if I have to do manual editing I'm more confident now in that too.

[simoncozens]

Love it. Thank you so much.

[LaPingvino]

@simoncozens I didn't test it yet, and turns out this breaks the build. I added a fix to my copy.