Make you own copy paste: copy: import AppKit import json # get the pasteboard pasteBoard = AppKit.NSPasteboard.generalPasteboard() # get the font (maybe check if there is a font) font = CurrentFont() # create your pasteboard type bahmanPasteBoardType = "Bahman.special.copy.paste" # collect data data = [] for glyphName in font.selectedGlyphNames: glyph = font[glyphName] anchorData = [dict(glyphName=glyph.name, x=anchor.x, y=anchor.y, name=anchor.name) for anchor in glyph.anchors] data.append(anchorData) # write it to the pastboard pasteBoard.setString_forType_(json.dumps(data), bahmanPasteBoardType) paste: import AppKit import json # get the pasteboard pasteBoard = AppKit.NSPasteboard.generalPasteboard() # print out all the availabe types print(pasteBoard.types()) # create your pasteboard type bahmanPasteBoardType = "Bahman.special.copy.paste" # get the paste board string for type data = pasteBoard.stringForType_(bahmanPasteBoardType) # its None when there no such paste board type if data: data = json.loads(data) # do something with this data good luck!!

should be fixed here: https://github.com/typemytype/GlyphConstruction/commit/01c7c9362561822a68073305c69c9fbc054ddf13 Getting kerning is advised to use font.kerning.get(pair) where it does not fail. This is similar to a normal dict. Or you can also check first if pair in font.kerning: ... thanks!

fixed! see https://github.com/typemytype/GlyphConstruction/commit/56e6d49533d3124ee28b887846c06cae5abbd35b

@frederik said in how to add custom button to the SpaceCenter's display menu ?: for now this is not possible... Space center menus are on the restructuring table. To split up into a menu for display options and a menu for typographic options. I can imagine adding a similar notification like in a glyph window or font overview So I imagine that it is also not possible for the right-click menu in SpaceCenter? this button, on top of the SC, for now, should be enough. Thanks!

Thanks, Frederik! I think this update on mouseDragged will also make the extension I’m working on much easier.

Hi! Thanks a lot! Looking forward :)

I've found some tips about making things run faster in RF and I want to share them here. I hope they're useful for others too: 1. Python objects are faster than RF font objects I realized if my script is run once, it's better if I convert RF objects to python objects. This way in many cases there is a huge performance boost. This could also be dangerous if you keep the data after user made changes to the font. So if you want to do something once and you're done after, this might help. Here is a very small public gist, but it's a start: https://gist.github.com/typoman/38a41811ad5dd8eb16a9d8acb6519a7f 2. Representation factories If you're making a user interface and are calculating something every time user makes a change, the representation factory is the way to cut some time. This is how you can cache data in font. Representaions can be anything, it doesn't have to be a visual data. RoboFont already has many. Like Glyph.area which gives you the surface area of the glyph. You can find how to make representation factories here: https://github.com/robotools/defcon/blob/master/documentation/source/concepts/representations.rst An example: https://github.com/typesupply/glyph-nanny/blob/2d41cc0e200726b2ddc5ffda3f85caeee7a7235b/Glyph Nanny.roboFontExt/lib/glyphNanny.py#L627

the current implementation has either editable guideline or all guidelines locked. You will have to make a custom Editing Tool to have this feature.

@frederik Thanks!!

its been described here https://docs.microsoft.com/en-us/typography/opentype/spec/features_ko#lfbd You can use pos in an feature to position a character or a pair (like kerning) or even contextual move characters around.

maybe you have to explain what you want to achieve... A space center object has getRaw which returns the input text as seen in the control and get which returns a list of glyph names, those are parsed from the input controls.

Also the same happens in the cut method. It seems BaseEventTool is not overriding the keys meant for this methods because I get them in the keyDown, but for paste I don't see the event in keyDown, so it's working there.

hi @bahman, you can provide your own style.css file inside the same folder as the markdown or html sources, and it will override the default stylesheet. we can also try to improve the default stylesheet so that large images are scaled to fix into the window width. cheers

Ok the problem was on my end. I had a script that was running on fontWillSave, and it was raising an error. Apparently that also halted the fontWillSave notification overall... So if one script fails, others may not be called? Would it be possible to post the fontWillSave notification even if a script attaching to that event fails? Thanks!

Ive made an issue here https://github.com/roboDocs/ScaleFast/issues/8

@frederik Oh interesting! After some thought, I wouldn't lock the vertical line to 90 degrees because after you've set the baseline, I'm not sure you'd want your horizontal movement of the x-height point to unexpectedly change the decided baseline setting. Having the angle of the x-height line only react to the baseline points makes sense to me. In terms of UI interaction, the only thing I'd change from the public release is to not draw the vertical line (or maybe draw a lineDash if anything), as it doesn't seem to correspond to any UI in Glyph View. Otherwise, I think it's less about the UI than the unexpected resulting transformation.

similar as to vanilla SplitViews an AccordionView will get: anAccordionView.isPaneVisible(label) anAccordionView.showPane(label, animate=True) anAccordionView.togglePane(label, animate=True)

Cool Ryan! I will have a look after Christmas. Maybe I will come up with some ideas how to make it work 100% nicely :D

In many cases I find a lag in RF interface. It feels RF is not responsive as before or is slow in way that is blocking me from doing a task. I forget to document or report them. So here is a start: BaseEventTool shift key release To reproduce the issue perform the following: Open a glyph which contains an anchor. Select the anchor using mouse and the basic editing tool. Drag the anchor in a fast reptitive motion. While dragging, hold the shift key and release it, but don't release the mouse while doing so. Now the anchor that was being dragged is lagging behind the cursor. Same thing happens with contour nodes. Is there any reason this is happening?

For maximum flexibility each glyph has his own undo manager. You dont want to use a single undo manager for everything. I understand in this case a single cmd-Z should perform actions in multiple glyphs. A while ago Ive made dirty hack... let me see if I can clean it up.