@jack received and discount code send

what font1.defaultLayer[glyph.name] = glyph does: check if the glyph already exists: if it exist it will be removed from that layer: so that the reason why the glyph is at the end of the glyph order in the font overview. (as that glyph is also removed from the glyph order) create a new glyph draw the given glyph in the newly created glyph I cannot reproduce the error, based on your instructions. I will flag this to investigate.

see Franks comments here https://github.com/adobe-type-tools/afdko/issues/1205

FYI: this will be tested when RoboFont 4 is going to be tested for release on different macOSs.

Fairly randomly, if I make adjustments to the list of glyphs in a set, or make a new set, the changes aren't saved and either the whole set gets deleted or reverts back to previous versions. No output data available. Rockin Version 3.4 (build 2004281315) on Catalina 10.15.7

If public.default is the name of a layer, but it is not set as the default layer, the UFO will not save, and pops up with "The document [file-name] could not be saved. The file isn’t in the correct format." Output window: Traceback (most recent call last): File "lib/doodleDocument.pyc", line 186, in writeSafelyToURL_ofType_forSaveOperation_error_ File "lib/fontObjects/doodleFont.pyc", line 224, in save File "/Applications/RoboFont_3-5b2.app/Contents/Resources/lib/python3.7/defcon/objects/font.py", line 823, in save AssertionError Weird edge case, but took me a while to figure out when I ran into it. The UFO was a generated instance, and I had manually returned it to the foreground (default), background layer naming scheme, so it could work with some of my inelegant scripts.

ehum, if the data is incorrect its hard to find a solution for this issue. MM is build as such this doesn't happen :) I dont know what should happen in this case: MM should not create empty kern groups MM should not return empty list for not existing groups as fallback MM should not remove that pair with the missing group. Maybe MM should report, so it gets fixed first. (but there are many edge cases to report...) (Maybe this is a case for ufonormalizer?)

continue here https://github.com/typemytype/GlyphConstruction/issues/52

Noted down and added to the MetricsMachine todo list. The skippeing-glyphs lib key and Metrics Machine originated years apart of each other :)

@frederik I dream of the day someone would convert fontTools feature ast objects to json and we won't use fea file anymore.

looks promising, will check it out

@tallpauley Thanks for the update to run the command! This gives me something to play around with. To take it a step further, is there a lib API I can use to also pull in space center and glyph view shortcuts, like whatever they use to populate their "Hot Keys" tabs? (Btw, I won't filter out commands that don't have shortcut keys, this is part of the allure of having a command palette, you can access commands that don't have shortcuts keys defined yet). I saw mojo.UI.setGlyphViewDisplaySettings, but this isn't all the available commands for glyph view. For space center I didn't see any API in mojo.UI I would dig around myself, but I think you guys compile to .pyc and I don't want to violate the EULA by reverse engineering (hence me actually clicking on the EULA lol). Once I have all the commands available, I think I should have what I need.

Hi @frederik It just never ends, no tracebacks. If I don’t manage to solve it with @gferreira tip I will try to prepare a dummy ufo and post it here. Thank you both!

Okay, that's all for now. Apologies for the long posts! ;)

Thank you. That's great to hear Frederik. Please wait a little with pushing an update. I encountered a bunch of small errors that you might want to have a look at too. Will post them shortly.

hello @ArrowType, the Application Menu page shows only the modifier keys needed to toggle some menu items (such as Preferences Editor, Select All, etc). the keyboard shortcuts for the main menu (for example ⌘+N, ⌘+O, etc) are collected in the Keyboard Shortcuts page. hope this is clear!

@jansindl3r That is possible... there were some bug fixed related to trial and student versions of extensions. Will send @erik new student licenses for MM and PP. @erik will need to compile a fresh version of Skateboard for students ( @tal )

@gferreira Thanks. What I did was the opposite. Just tell me if it's OK to do > I was looking for <string>foreground</string> in the lib.plist file, and changed the name to a different name. saved. and the new name replaced the duplicated foreground layer inside the layers in RB. then, I just deleted the layer with the new name. Is it good enough? Thank you.

that was a new feature in RoboFont 1.1... https://robofont.com/version-history/#robofont-11 will review it :)

Current Issue I’ve made a script to toggle between light & dark mode in RoboFont: https://gist.github.com/arrowtype/ce0cee426f47c2fe7e82aa07d1e0a450 However, there is an unfortunate bump in dark mode: markColors that are high-opacity can greatly disrupt the dark palette. That is, I have set up existing UFOs with marks that are opacity=1. However, these colors were selected with a light UI in mind, so they work well when surrounding glyph cell backgrounds are white, but not very well when they are dark. Here's my typical gray for glyphs made from Glyph Construction, disrupting an otherwise dark theme: Glyph marks are much more effective when changed to a lower opacity, about 0.25–0.5. Here are the same marks but at 0.5: Unfortunately, in my darkmode toggle script, the best I can do to get working mark colors for darkmode is to offer to change the opacity of marks if they are above a threshold. However, this requires me to change data in the actual UFO, and doesn’t work automatically for new UFOs I open. Because I have existing marks in many UFOs and don’t want to make meaningless commits, this is unappealing. Worse, for some users, they may have processes or scripts connected to specific glyph mark colors (e.g. a collaborative workflow that relies on different hues or opacities to show what is "done" vs "in progress," perhaps also connected to automatic proofing, etc). Possible Solution If the RoboFont preferences had a setting like glyphCellDisplayedMarkOpacity with a 0–1 value, this problem could be very easily solved. E.g. a glyphCellMaxMarkOpacity of 0.5 would multiply all rendered mark opacities in the glyph view by 0.5. This would enable Font View preferences to be freely adjusted without requiring users to edit the actual mark color information in glyphs. This isn't the only possible solution, but it seems like it might allow the flexibility needed here, with a minimum of additional required preferences for users. Thanks for adding the glyph view preferences! This is a big bonus to an app I use daily. :)