mattlag
commented
1 year ago These are all fantastic suggestions, thank you very much for writing your ideas down and sending them in! I have some quick responses below, but overall I'll keep these in mind as v2 progresses.
Mass drag / select
- in v1 this is available with
Ctrl+click either path points or shapes. But for path points especially, this can be physically difficult for points that are close together. Already implemented in Beta-1 (to be released soon) are two command buttons for "Select next/previous path point" to help cycle through adjacent path points. And, when holding downCtrl, it does multi-select! - I think dragging a rectangle for selection is a great idea for the canvas, this is a very common feature in all graphics editors and should be in Glyphr Studio as well
Glyph mass manipulation
Your suggestions encompass a few distinct scenarios:
- Export a subset of glyphs to a font. This should be easy enough. Possibly marking All or Some character ranges for export.
- Import many glyphs at once: SVG Font is kind of the only way this could work. Multiple file import is complicated. But, one thing I really want to do for v2 is "Merge" scenarios. So eventually I expect importing a font into an existing project will give you options for handling overlaps etc.
Improved imports
- Unfortunately, auto-width is a Glyphr Studio only concept. No font file format will save auto-width. All widths get calculated and saved as Advance Width when exporting. No imported fonts have a concept of auto-width, so we can't import it.
Grids and guides
- These should all be easy to implement. I've even thought about a "Reverse" color mode, where the canvas is black and the shapes are white... 🤔
Kerning and component exporting
- Sooooo in v1 (and in v2) the Project File saves everything. You can load and re-load components, custom guides, auto-width per glyph, class-based kerning... all these things will be lost every time you export to a OTF or SVG font. So, it is highly recommended to save your Glyphr Studio Project File as the primary working file, then export to a font when needed. In v1 the project file is a
.txtfile in JSON format. in v2 it is also a text file in JSON format, but the extension will be.gs2. These project files save a bunch of extra stuff I mentioned above that are useful for designing a typeface, but aren't included in the exported font file itself.
Again, thank you for your ideas, let me know if you have any more!
Zentheon
I've got a fair bit of experience with Glyphr 1 and am excited for 2, though it would be awesome to see some highly missed QoL features get added to really set it apart from 1:
Mass/drag select nodes
While ctrl+click selecting multiple nodes works well by itself in Glyphr 1, having the ability to drag select nodes as well would be great compliment to it.
Glyph mass manipulation
While glyph exporting and importing in Glyphr 1 is convenient, being able to do that with multiple glyphs at once would streamline workflows a lot better. An idea for how this could work is selecting multiple glyphs from the panel with a modifier key shows a mass export option that merges the symbols into an .svg font, and then importing can read from an .svg font either from Glyphr itself or another program.
Besides I/O, it could be further used to do basic mass manipulation (Deletion, resizing, repositioning, alignment ect.)
Improved glyph imports
The current Glyphr 1 implementation of .svg imports seems to omit auto width data, which is especially a problem if mass imports were a thing.
Grids and guide colors
The grid system in Glyphr 1 one of my favorite parts of the program, but it could definitely be further improved by having individual strength integers for snapping to both lines and intersections. Besides that, and this is just more of just a nicety, having a color system in 2 that allows changing default guide colors as well as custom ones would be nice for Dark Reader users.
Kerning and component exporting
Another export/import suggestion, and pretty self-explanatory. Since Glyphr 2 is going to introduce its own save format, kerning and components (and maybe even glyphs mass exports, if more viable) could use their own extension name to make it clear what they are.
That's about all I can think of for now, most of which has come to mind from needing to swap out and manipulate a lot of glyphs at a time from a project for different variations of a font. But yeah, I'd love some input on what's actually viable with all this!