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.

Hello, apologies for the late reply. Thank you for pointing out that the "ghost" was likely a Mac feature. Whatever cache that was in has apparently cleared, as my ghost is now gone. I suppose it is a "feature" for when Mac senses an application has crashed? Sorry to be a bother. Didn't think it was something serious, but it had never happened before, so I was curious. I was going to upload my log to this, but I don't have the privileges necessary to do so. If you would still like it I'm happy to send in any manner convenient for you. Cheers Randy

hello @grahambradley, you can import and export preferences as .roboFontSettings files – see the options menu in the Preferences window there’s also the ThemeManager extension which allows you to bundle UI settings into themes, and quickly preview them good luck!

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. :)

Thanks, @frederik. I understand that, and I believe that it is not the best possible way to display this information, as evidenced by the screenshots in this thread. Specific options for selected background/foreground colors would be helpful, as I suggested above. I really appreciate the big advance you've given the app in the recent option updates! It makes a really big difference in the comfort of using RF in the evening. This is just one area that I believe still requires a little extra advancement to make the "dark mode" mode complete. Thank you!

Hi, could you elaborate 'no main window at all'? When RoboFont is launched on your computer only a menu bar appears. You should be able to open a new document or open existing ufos. Alternatively you start up RoboFont with shift down: no external scripts or extension will be installed. Is there anything in the log? see https://robofont.com/documentation/how-tos/submitting-bug-reports/#console-logs

Thanks a lot, I think it is going surprisingly welly well. Please, I just can't understand why is this not enough to rewrite the cell's content? It works but only when double clicking. Could you please link me, what causes this? I can see "testje" only after double clicking into the cell. https://github.com/jansindl3r/Metrics-dynamically/blob/master/metricsDynamically.py#L30