• message, with automatic dismissal after a timeout
• message, with explicit dismiss button
• ask yes/no/cancel

This could perhaps be done with a layer popup in the selection info item.

In the viewed text, a glyph is currently either viewed or edited. There can only be a single glyph in "editing" state.

However, it may make sense to have a "selected" state, where we can play with the local axes.

There is always at most one glyph that is selected OR is in editing state.

• Click on a glyph: current "selected" or "editing" glyph (if any) goes back to "view" state, clicked glyph becomes "selected"
• Double click on a glyph: current "selected" or "editing" glyph (if any) goes back to "view" state, double clicked glyph becomes "editing"

The axis slider UI will only show global axes if no glyph is selected or is being edited, and it will additionally show the glyphs' local axes (if any) if it is selected or being edited.

If a selected/edited glyph has an axis with the same name as a global axis, then:

• moving the global slider should make the local one move the local one as well (apply range mapping)
• moving the local slider only affects the display of the selected glyph

Unlike the current situation, unselected glyphs should not be affected by local sliders, even if they have an axis with the same name.

• The axis UI starts to not be very responsive anymore

• Large URLs are probematic for the server, and for NGINX

• We should probably limit the maximum number of glyphs that can be displayed

• We should probably limit the URL length somehow (what info to drop? how to compress?)

As if it's adding a white stroke around the black strokes:

I had the same issue with the "T" icon, where I worked around it, may have to do something similar for the "i".

• Ideally, each occurrance of a glyph in the display string should have its own local axis settings
  • This is complicated when the string is edited in the text entry field: we effectively need editing of an attributed string
• All local axis settings in the display string should be encoded in the URL
  • This will change the URL format quite a bit

To be split into proper items and PRs.

• View and edit component parameters
• Need a simple "form" UI mechanism, to more easily implement UI for the things like the previous point
• Write changes back to backend: backend API needs to evolve methods for that #48
• Get/view/edit project-wide font info
• Get/view/edit font metrics: should have sources like glyphs, perhaps even layers #78
• Get/view/edit kerning: should have sources like glyphs, perhaps even layers

Looping over a string will yield surrogate pairs, which we'll need to hande separately. Eg. entering "𠂭" will not work, even if the code point exists in the font.

Likewise, non-BMP unicode values are (likely) incorrectly converted to string, as fromCharCode() only support 16-bit numbers.

This could be done as an alternate behavior for the space key. One idea is to use modifier keys. For example:

• Space key: super clean view (this is the current situation)
• Space + option key: clean view, but don't hide UI elements
• Space + shift key: clean view, but don't hide CJK design frame

Whether we also want to be able to write them is a somewhat separate question.

Tool items:

• pointer
• pen #30
• knife #190
• measure #45
• shape tool (rect/oval) #198

View items:

• scroll hand
• zoom plus and minus
• enter/exit full screen #189
• recenter around selection / selected glyph

Make sure to check the right modifier key on Windows

Position can be moving them left/right but also up/down creating a new line or inserting the glyphs in an existing line of glyphs

• The local axis settings should local to the selected glyph
• We can look at the same glyph multiple times with different local axis settings

Relates to #10

Some examples are mentioned here:

• fonttools/fonttools#2630 (comment)

We will have to implement discontinuous axes.

Often, the glyph search, axis box or selection info box collapse earlier than you'd like.

Perhaps they should only collapse if clicking in empty space but not on a glyph.

Perhaps they should grow an explicit close X button thing.

• Handles moving along with their neighbors around a "smooth" point (Done in #62)
• Tangent handles (Done in #62)
• Single quad off-curve (Done in #62)
• Refactoring, to allow the next items (Done in #66)
• Shift constraint (Done in #68)
• Alternative behavior (command-drag) (Done in #73)
• Alternative shift behavior (command-shift-drag)

Keep in mind: good quadratics behavior.

Using a default width, a placeholder preview char, or just the glyph name if no char is known.

Then, double-clicking such a glyph could create it (maybe after a confirmation dialog), so we can draw on it and add components.

• On iOS scrolling doesn't properly work
• On Android many things don't properly work

(But then we will also have to consider the UI design from a tablet-perspective.)

It is currently not possible to select or edit a glyph that has no outlines, such as space.

See for example FontGoggles: for empty glyphs it uses the advance width + ascender/descender box.

Most likely the main entry point for this will be a contextual menu. See #146

Maybe in the bottom left corner after a menu entry

Both for the global design space as wel as for local design spaces.

Tasks:

• UI to add/delete/edit global axes
• #716
• #409
• #399

It is useful to look at things really small

Relates to #63

May relate to #51

Even though the display of the glyphs is correct.

this would be a feature for collaboration where reviewers can leave their inputs

This currently works for for glyph changes in filesystem fonts (.designspace, .ufo and .rcjk), but only , but not for adding/deleting glyphs.

Things to do:

• Respond to glyph addition and deletion #153

• Similarly, respond to (reversed) cmap changes (May need #114)

• Respond to designspace changes #152

• Respond to RoboCJK MySQL DB changes (googlefonts/fontra-rcjk#27)

Currently, the rcjk file system back end leans on rcjktools, and the rcjk mysql backend does not (or hardly). The two implementations are quite distinct.

rcjktools was mostly written for viewing/reading/building, and not so much for editing.

My idea is to make a simple abstraction layer for getting the raw data, which will have two implementations (file system + mysql), and that all the conversion to Fontra objects can be shared.

https://automerge.org/

Thinking:

• A single glyph should probably a "document", in automerge terms

Question:

• There is no Python implementation, would our server need a JS component?

A good pilot case for this would be the CJK design frame.

• Define backend API for writing changes
• Implement for RCJK web API (googlefonts/fontra-rcjk#27)
• Implement for RCJK FS backend (googlefonts/fontra-rcjk#24)
• Implement for .designspace backend
• Implement for UFO backend

• https://peerjs.com
• understandable demo: https://github.com/jmcker/Peer-to-Peer-Cue-System
• signalling server: https://github.com/peers/peerjs-server

Possible scenario:

• We run a signalling server at fontra-collab.black-foundry.com (or something, maybe we should grab "fontra.xyz")
• User A runs a local (desktop) Fontra app
• User A offers to share a project, tells the signalling server, receives a URL to share that contains a temp token
• User A sends URL to User B
• User B goes to URL, receives all Fontra assets from our server, but makes a data connection to User A directly

(Hm, the assets could also come from User A, but I'm not yet sure how to do that over a data connection. The Fontra client app really likes regular HTTP for assets.)

When you type a character, the selected glyph should be replaced by that character.

Question: also if the glyph is being edited? Perhaps it will get in the way of (future) short cuts.

• Improve infrastructure so adding/deleting points/contours works #115
• Basic pen tool to draw an open polygon #115
• Close contour #137
• Attach to other open contour
• Drag BCP handles while adding new points #137
• DrawBCP handle from arbitrary point
• Insert point on segment #296
• Alt-click switches to pointer tool (maybe redundant, as we have 123 shortcuts for tool selection)
• Hover should highlight a node when something special happens when we click or drag on it

Relates to #9

Most likely GPL3.

When typing "delete", it should delete the selected glyph from the view.

(Perhaps not while in edit mode.)

should we consider disabling the behaviour of 'single selected glyph' when multiple glyphs are selected?

Adjacent to #19, here is the outline of a simple auto-locking scheme.

The idea is that we assume a glyph is unlocked/editabe, expecting this to be the common case by far, and simply go ahead with an edit (say, drag some points). But it will stop an edit-in-progress once the system finds out it is already being edited by someone else. I would like multiple clients to be able to have a glyph in "edit mode", so I don't want to tie glyph locking to the edit mode. I would like to lock only when actual editing takes place.

Prerequisites:

• The unit of locking is "variable glyph" (but could also be "kerning", "font info", etc.)
• A lockable object has a version token

Steps:

• Client: tells server it will edit, and the object version token it has, but does not wait for permission (we don't want lag)
• Server: if another client is editing this object: reject edit, send rejection notification to client
• Server: if the current version token doesn't match the version token the client sends: reject edit, send rejection notification to client
• Client: until the reject notification is received, just continue sending edit changes, which will be ignored by the server; then: rollback the edit locally, notify user why the edit was rejected
• Client: if the edit is done, send final edit message, then await the answer, as the edit can still be rejected at this point. If rejected: rollback edit, notify user. If not rejected, receive new version token.

(The server could let clients pro-actively know which glyphs are locked, which would be a little friendlier for the user in most cases. But the above is still necessary to avoid race conditions: what if two users start editing a glyph at roughly the same time, before either can be notified? The server will have to reject one of them while it is already editing.)

This is much simpler than a full CRDT, and has the following drawbacks:

• The client-server connection must exist: editing cannot continue if the connection gets dropped
• No concurrent edits possible on the same object: once locked, no other client can edit. Practically, this means that while one user is editing the Regular of a glyph, no one else can edit the Bold.

Compared to RoboCJK, this has the following advantage:

• Locking starts only when an actual edit is made, and ends immediately after the edit (say, a point drag)

This scheme can be made to work with RoboCJK's locking mechanism:

• Fontra client initiates edit, and goes ahead without waiting for permission
• Fontra server does the steps outlined above to see if any other Fontra client is editing
• Meanwhile, Fontra server asks robocjk for a locked glyph
• If this fails: reject edit
• If succeeded, compare received (locked) glyph data with previously received (not locked) glyph data; if different: reject edit (in this case, the version token could be a hash of the glyph data)
• After edit: unlock robocjk glyph

(This will cause quite some traffic between the Fontra server and the RoboCJK server, if edits come in quick succession, such as when dragging points. Perhaps it can be streamlined, eg. by delaying unlocking a little, so rapid successive edits can use the same lock.)

Ideally, every time when the server process is restarted, the browser should automatically reload all static content, so users don't have to do a manual deep reload.

Idea: a version cookie could be used, and compared to a previously read version cookie.