Add the ability to open individual .glif files

[eliheuer]

This I something that came up in this issue: #248 (comment)

If icons are stored in the resources directory in the future, it might be nice to store them as individual .glif files instead of a full ufo. @ctrlcctrlv has set up MFEK to do this, so I'll look into how it is done there at some point.

[eliheuer]

It would also be nice if there could be icons that are specific to themes, so one theme might have a completely different icon set loaded from .glif files. Maybe some themes could even have bitmap graphics for icons? For example, 3d rendered png icons or low-color palleted pixel art icons with animations and that kind of thing.

[ctrlcctrlv]

Well, how it's done in MFEK is like, a deep issue of philosophy and how software is built. Runebender is a monolith; you can't just "run the glyph editor" detached from the font view. The only way to get to the glyph editor is to run Runebender itself on the whole font, and then click the right glyph.

Meanwhile, in MFEK there's two ways to get the glyph editor. You could use MFEKufo, which I'm still working on. That's my name for the font viewer program, which just uses std::process to open MFEKglif on whatever glyph you double click. Or, you could just run MFEKglif itself on an arbitrary glif file.

Because MFEKglif knows it can be run this way, it assumes it's being run this way until proven otherwise, and care was taken to never fail if not in a UFO, just degrade features. So, there's no descender/ascender line, images won't work, any components won't load, and so on.

So, it's really an infrastructure thing Eli. I wanted a modular font editor so I had to make sure that this would work. Every part of MFEK is going to work this way. MFEKdesignspace won't fail if the sources don't exist, it'll just degrade whatever feature set it eventually ends up having.

I really don't know how you can make this work in a sane way in a monolith. I can think of a hack: if an unparented glif is opened, copy it to a system temp dir and create a barebones UFO around it, then open that, then immeiately pop the glyph editor window.

[eliheuer]

Just keeping the icons in a UFO would probably be way easier for designers, so I'm happy to do that if this is too difficult. It might be a better choice for making a user-friendly application anyway.

[ctrlcctrlv]

That's not correct because of the nature of the UFO format. Monoliths are less user friendly in this case I feel.

UFO "files" are actually represented as directories. So, almost every file browser is going to just open it and confuse the user. I don't think that MS Windows explorer.exe recognizes directories as possibly having extensions? Definitely most GNU/Linux file browsers don't.

So, users are always confused by browsing around and seeing UFO's. Associating each constitutant UFO subfile with a program is the best way in my opinion to fix such an issue. When MFEKufo is done, I can even add a feature in MFEKglif, if the .glif has a parent UFO, "browse parent font".

Soon, what was once an issue can become an asset. User learns about the parts of the UFO file naturally. Click a glyph, get a glyph editor. Click the fontinfo.plist, get a metadata editor. Click the designspace, time to manage axes. And so on.

Achieving this in a monolithic editor is impractical, but perhaps possible if there was very strict separation of concerns. I can't say, since I'm not trying to make a monolithic font editor.

[ctrlcctrlv]

I'm thinking about this issue based on its title, not based on the specific case of how to manage your icons. I also do that in a font, have done since very first time I added icons to MFEKglif.

[cmyr]

The main issue with opening individual glif files, (as I see it) is that it really does matter whether a glif is part of a font or not, for the purposes of things like components or layers. The glif format was not really designed as a standalone.

That said, I don’t think it would be that hard to let runebender open individual glif files, skipping the main font window, and the idea of an option to “show containing font” could make a lot of sense.

[ctrlcctrlv]

The format isn't at all designed for it, I agree, but also think users are going to want to do it—because I want to do it and make fonts :-)

How important you think it is is entirely up to you. I find it very important as glyphs are always being copied and moved around I find when working on variable fonts, or often I'll run a script on the points of an unattached glyph and then want to just see what it looks like, not really edit it. I see MFEKglif as both a viewer and an editor, both jobs being equally important. So if there's something to view I try very hard to show something.

[ctrlcctrlv]

(The something you get being much uglier than what you'd get if the glyph were attached, but still often extremely useful for developing and debugging fonts.) MFEKglif flashes warnings at you currently if you open an unattached glif, I should probably put one in the title bar too. "MFEKglif (UNATTACHED) — /home/user/Workspace/glif.glif"

[ctrlcctrlv]

Oh, also, one final thought. You should know that FontForge has used .glif as an available interchange format since it got its UFO support. "Glif" is one of the export options. So, unattached files exist, in large numbers.

[cmyr]

cool, that's all very helpful, thanks @ctrlcctrlv! I definitely think this would be a nice addition, so I'll see what I can do. 😁