[Feature Idea] Link Glyphs to zones so that zone changes affect the glyphs

[Mark2Mark]

By Alex @slobzheninov

---

It would be sweet to attach accents to the zones, so that moving/stretching the zone would modify the accents accordingly. That would be a quick way to build the uppercase ones 🙃

[Mark2Mark]

That's an interesting idea. Something like mark a glyph (accent) as linked to a zone and then all changes to that zone change the height of it proportionally?
Would stretching be good enough? It will likely unshape them a bit.

✅

[slobzheninov]

That's an interesting idea. Something like mark a glyph (accent) as linked to a zone and then all changes to that zone change the height of it proportionally? Would stretching be good enough? It will likely unshape them a bit.

Exactly, that way you can either adjust the vertical position or height of all accents at once. Of course, stretching might need further adjustments, but the deformation is usually fairly small, and we do all that manually anyways :)

[Mark2Mark]

True.

What would happen if a glyph, let’s say the acute is outside of the current zone. For example way too low, 200 units below the zone.

Now you move that zone’s height. When calculating the relative scaling, it would be huge in that case, because the acute is out of the vertical bounds of the zone. I think in such a case the acute’s deformation will be drastic.

Of course this is kind of an exaggerated example, and the marks should be placed already inside the zone, I guess. But such cases need to be considered.

(I still like the feature idea, though!)

✅

[slobzheninov]

It would be strange to add it into that zone in the first place, wouldn’t it? I suppose when you link something like that to a zone, it could warn that it seems to be too far away and may not make sense.

When calculating the relative scaling

Relative? Wouldn’t the whole layer get the same scaling factor?

Apart from all that, it would also mess with overshoots, which is probably still ok in regular use cases:

[Mark2Mark]

It would be, but people do a lot of strange things :D
Also see below, when one CP has multiple zones, the acute from the example will eventually be outside one of the zones.

Relative? Wouldn’t the whole layer get the same scaling factor?

Relative: the layer paths in relation to the zone, right? Because a plausible case is the macron or dieresis, which usually don’t extend from top to bottom. (and also one would not want those to stretch with the zone height change) → Maybe mark those as position-change-able, but not height-change-able. ✅

I will build a little prototype just to see how this behaves and from there put more questions when I have some. Thanks for the input!

[Mark2Mark]

Another question would be: How to link a glyph to a zone?

• A custom parameter can have multiple zones (so that you can have top and bottom marks with the same overshoot, color, label, filter, etc).
• The name is not an identifier. (One could name all zones with the same name.)
• Should the linked glyphs be added to the Zone CP? That could make sense, but here we are also back to point 1, that this CP can have a high and low zone, rendering some of the paths being outside one of those zones. (There would be a UI to choose which Zone CP the glyphs should be added to. Or it is only allowed to touch paths that at least touch the adjusted zone (or are in it by a certain amount of area).

✅

[slobzheninov]

Since any glyph should only belong to one zone, wouldn’t another column Glyphs (after Position and Thickness) do it?

[Mark2Mark]

That would be the most definite. A little fiddly though if you want to add a lot of glyphs. I am thinking of Scripts like Thai or other SEA scripts, where you also have overlapping zones, different levels of tone marks etc.

And it would be nice if there would be a convenient way to add a glyph from the current layer > right click > add to zone. But selecting glyphs, copy as list, add to that new column might be sufficient for the beginning.

I think that could work. If I add another UI that lists all the glyphs and offers a glyph picker for adding.

✅

This reminds me in a new issue: #13

[Mark2Mark]

@slobzheninov , what do you think?

Current state:

Mark.Zones.-.Linked.Glyphs.mp4

Some notes:

• glyphs will be linked to a sub-zone (which is one of the multiple zones each custom parameter can have)
• the UI to add/edit linked glyphs is coming, once we think this is the proper way
• it needs some more tweaking on the math side of things, sometimes when grabbing a zone and move it both very fast, the transformed shapes can happen to be a little off.
• masters are not yet implemented. A zone CP is attached to the master, so other masters don’t know (yet) about the linked glyphs. What do you think about that part? The implementation for that might be quite more elaborate.
• the plugin doesn’t have an observer on the custom parameters (yet), which means that when you change a zone from the custom parameter, the linked glyphs will not change. Currently the transform is triggered by the mouse event only.

ℹ️ circumflex is deliberately not linked to that zone (for demo and testing)
ℹ️ dieresis has a flag set to "not stretch", so it will only be height-adjusted
ℹ️ it only transforms the paths. not anchors, not components

[Mark2Mark]

Update state:

Mark.Zones.-.Linked.Glyphs.2.mp4

@florianpircher: sorry for tagging you. Would you have an idea which UI element could be suitable inside that table? It (currently) is a cell based table view, as that did suffice for when it only held number values until now.

I basically added the "Linked Glyphs" property to what currently is each row in that CP UI table.

But with the additional "Linked Glyphs" column, I run into the problem:

• I could use a TokenFieldCell, if it would only hold glyph names, but it does hold a dictionary with glyph names plus a "stretch" property.
• So I thought of putting an NSButtonCell in there, and when clicking, I can open a popover with another list. But here is the issue: Interface Builder won’t allow me to set an NSButtonCell to the column. Also NS...Cell stuff seems to be on the deprecation track by Apple.

✅

[florianpircher]

Just the first thought that comes to my mind: Have a second table view to the right of the current one. When selecting a row in the left table view, you show the linked glyphs in the right table view. So, you no longer need the “Linked Glyphs” column. And you could add batch editing, where multiple rows are selected on the left and the user can change the linked glyphs for all of those at the same time in the right table view.

^{No need to worry for tagging me; I already watch this repository and get notifications for every activity.}

[Mark2Mark]

Oh, that’s a great idea! Thanks so much. I will try to do that.

^{(okay, no more tagging, thanks for letting me know 😁)}

✅

[Mark2Mark]

• Add linked glyphs mechanism
  • CP syntax that is backwards compatible
    • And potentially forwards compatible
  • Update CP parsing & updating
  • Update UI with linked glyphs
    • Add UI for adding glyphs (likely the default glyphs picker)
    • Consider adding a warning if an added glyph is (far?) outside the zone
    • Consider if multi-selection of zones to add linked glyphs to multiple zones makes sense: current thought = no
  • Add property for linked glyph item: stretch (defines if a glyph will be stretched or just repositioned relative to its zone
  • Move linked glyphs horizontally in italic angle when adjusting zone height
  • Preview linked glyphs’ transformations when in edit view (also inactive layers) and dim their original shapes
    • Preview zone in inactive layers, too
    • Same for adjusting non-stretch linked glyphs’ zone height
    • Should stretching be italicised, too?
• Update linked glyphs also when zone is changed in the CP UI (not only when zone is dragged)
• Tidy up the now messier UI, add naming which guides the user better:
  • Consider the main settings as "(Zones) Group" or such
  • Consider the "sub zones" as "Zones"
• Think about multiple masters (should zones be compatible? See linked issue)
  Think about a convenient way to add a glyph from the current layer > right click > add to zone. Or at least selecting glyphs, copy as list, add to zone in CP UI. the glyph picker allows multi selection and filtering/search, that suffices for now
• Make the list of linked glyphs copy-able, and paste-able into another zone (think of other masters mainly)
• Notify user somehow about the transformed glyphs
  • dragging: either preview all of them in edit view (or name them)
  • CP UI change: Message with OK/Cancel buttons

While on it:

• Show zone measurements when dragging: bottom y, thickness, top y

[Mark2Mark]

@schriftgestalt (sorry for tagging you)
Would you consider adding the possibility to present the GSSelectGlyphsDialogController in an NSPopover instead as a window?

It has a lot of useful functionalities (search, etc) that I think is not efficient to rebuild entirely. At the moment I cannot add it to the NSPopover, because its design as a windowController. Its contentViewController is always nil.

I can use its designated presentation method, but that opens the little window anywhere it has been closed before.

I need it in the Custom Parameter UI, which is already a sheet, so a Popover for adding glyphs seems the most plausible to me from a user perspective. What do you think?

[schriftgestalt]

You could do it with a modal dialog instead of a popover.
I’ll see what I can do.

[Mark2Mark]

Thank you! For now I use the kind-of-floating default window.

For the modal option: How would that be different from now UX-wise?

[florianpircher]

You could attach the picker window as a sheet, clearly signifying its association to the custom parameter editor window. (Even if sheets on sheets are discouraged.)

[Mark2Mark]

Yeah, because if the discouragement I was shying away from that option.

BTW: if there is a more flexible way to use the GSSelectGlyphsDialogController, it could also be used in other places. Maybe in the features window classes > right click > add glyphs. Visual feedback, like I prototyped in the OT-Peeper ages ago.