Open Mark2Mark opened 5 months ago
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.
â
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 :)
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!)
â
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:
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!
Another question would be: How to link a glyph to a zone?
â
Since any glyph should only belong to one zone, wouldnât another column Glyphs (after Position and Thickness) do it?
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
@slobzheninov , what do you think?
Current state:
https://github.com/Mark2Mark/mark-zones-plugin/assets/5824595/ce49116d-27bd-4d8f-b8b2-eb7e374aa4b7
Some notes:
âšď¸ 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
Update state:
https://github.com/Mark2Mark/mark-zones-plugin/assets/5824595/0df63727-34a4-434d-810f-1899a2a18f15
@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:
â
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.
Oh, thatâs a great idea! Thanks so much. I will try to do that.
(okay, no more tagging, thanks for letting me know đ)
â
While on it:
@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?
You could do it with a modal dialog instead of a popover. Iâll see what I can do.
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?
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.)
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.
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 đ