cjdunn / mm2spacecenter Goto Github PK

Sometimes the input number exceeds the width of the EditText box → unreadable.

Leaving this here for myself to potentially address when I have time.

Figures, for instance, aren't getting much useful output. Is something better than nothing? Should we just add strings of figures into the sample text from which the extension pulls?

Currently, the script seems to check for unencoded open/close punctuation, but only if it specifically has a name using the .uc suffix. However, there are plenty of potential names that could fall outside of that. For one, .case might be another logical suffix for case-specific punctuation, but then there also might be any other potential reasonable suffixes on punctuation alts.

I’m making a note of this as something to potentially look into after #26.

When I kern, I wish I could see the decisions I have made in other, related shapes, in order to be more confident in the decision I am making and that things are staying consistent. E.g. when I kern the Ve, I also wish I could easily see Wo Yo Xo To . I’ll call this a “related-shape group” for now, though I doubt that is really the best name.

During the Occupant Fonts TypeLab presentation on their WIP machine-learning kerning tool, they showed that in Glyphs, they always kern in context, with related glyphs above/below, and this was something I realized would be a really helpful view.

So, in Space Center, that might look something like this:

(Actually, just making that, I see that my oVe, oWe, and oYe all have somewhat different levels of kerning...)

To make this work, I think we would need a few things:

• A list of related-shape groups. This would include things like
  • V W Y X T
  • K X A R Z
  • Z L
  • v w y
  • x k.
• I imagine these related-shape groups would be in a list view, with controls for “add, delete, import, export,” similar to Ramsey Street. That way, a user could add things like W.alt to V W Y X T, create related-shape groups for more characters, etc.
• A checkbox to show related-shape control strings. And maaaybe a checkbox to always show a control string?

I have wondered whether this would be such a different use case that it might call for a separate extension. However, I think that it’s really closer to the “open+close context” we have just added: it only applies to certain characters, and I would often still want to see the real-word contexts below these control strings. So, I think that a checkbox in mm2sc is probably the best option, but of course open to other opinions.

This might step a bit on #6 but I wonder if there's a way to latch onto the user's already-set MM "contexts" (contextual spacing strings) for the default instead of hard-coding into MM2SC.

Separating this edge case issue from #26.

The pair slash O.RECT breaks the space center string:

I can literally only trigger the last case with slash O.RECT. The font I’m trying this on has other similar suffixes, like R.RECT and Q.RECT, but those don’t cause the issue. It’s weird.

I suspect this might be due to slash O matching a phrase, BID/slash/O FFER SPREAD, and that must somehow be conflicting with our handling of the slash and our handling of suffixes. For instance, if I change the language away from English (e.g. to Finnish), the glitch goes away – so it’s not some inherent problem with O.RECT.

I think it would be good to add the original word-o-mat option back in

This is an issue I’m filing to track some debugging in a logical place. This issue is basically copying in the conversation from #18.

The issue

#22 was made to correct the problem of a mirrored pair not showing up if "show open+close context" was active. It helps, but also has issues.

Now, in the next-master branch, there are unexpected interactions of "show mirrored pair" and "show open+close context".

As of (#22), I can get at least three states:

1. Correct: One mirrored pair, for pairs containing lowercase or figures, e.g. e a, slash six.hiviz, bracketleft a, or for pairs not containing punctuation, e.g. A T or R e
2. Incorrect: Doubled mirrored pairs, for pairs containing punctuation and uppercase, e.g. bracketleft T, or uppercase and figure, e.g. R 6.
3. Confusing edge case: A strange case in which slash O.RECT breaks the space center string entirely.

I can literally only trigger the last case with slash O.RECT. The font I’m trying this on has other similar suffixes, like R.RECT and Q.RECT, but those don’t cause the issue. It’s weird.

My hypothesis/hope is: we might be able to solve all three problems with a bit of refactoring.

Probably, the script can be slightly refactored to eliminate a few if/else blocks that might be causing some of the issues.

We could potentially do something like:

# set mirrored pair if option is check, else set as empty string
mirroredPair = self.pairMirrored(self.pair) if self.w.mirroredPair.get() else ""

# set open close context if option is check, else set as empty string
openCloseContext =  openCloseContextReturn(self.pair) if self.w.openCloseContext.get() else ""

# form the text, with options in front if they are set
text = f"{mirroredPair} {openCloseContext} {self.getSpacingString(pairstring)}"

...were we set partial strings based on settings, then make the text string only once, putting together the pieces. The actual code is more complex to handle different contexts, so maybe my hope is overly idealistic, but I’ll explore this route.

Where is the best place show open+close context?

At one point, the open+close context was placed in front of the string, but since then, it was moved inside of the string.

Example: if the pair is T bracketright, there are two main options for how it can be shown:

• in front: [T] HHT]HOT]OO
• inside: HH[T]HO[T]OO

Advantages for having it in front:

• When I look at it, I sometimes want to check: "is T in the middle of H and ]?" If the string is HH[T]H, I can’t see that.
• Having it in front of the spacing string also makes it more obvious to users what effect the option has.

Advantages for having it inside:

• For things like quotes, it is quite advantageous to see the context of a string like nn‘s’no‘s’oo, to show how the quotes are kerned against control characters.
• It is more compact.

I’m split. I suppose for quotes, the advantage of having it inside is extremely helpful, and that might be important enough to leave it inside. I won’t change it for now, but I’m open to opinions!

What is the best way to show the mirrored pair?

I could go either way. It feels a little simpler to understand as just LRL, but I can imagine that it might be helpful to have LRLR, to see not only how R fits between L, but how L sits between R. Maybe that is redundant / unnecessary?

I’m unsure. I often just flip the pair (command F) to check the opposite mirroring. However, this could potentially disrupt one’s place in the pair list. So, I will also leave this as LRLR for now, but I’m somewhat uncertain that this is the best option.

I think this would also be useful

Got the following traceback with no capital Germandbls in the font. Advancing to the next pair then didn't change the SC text, so the app needed to be restarted to work again.

Traceback (most recent call last):
  File "lib/eventTools/eventManager.pyc", line 165, in callObserver_withMethod_forEvent_withInfo_
  File "MM2SpaceCenter.py", line 307, in MMPairChangedObserver
  File "MM2SpaceCenter.py", line 647, in wordsForMMPair
  File "MM2SpaceCenter.py", line 366, in getPairstring
  File "MM2SpaceCenter.py", line 355, in checkForUnencodedGname
  File "lib/fontObjects/fontPartsWrappers.pyc", line 1845, in __getitem__
KeyError: "No glyph named 'Germandbls'."

After working a bit on the UI, I'm wondering if we need the status message text in the window at all. It already shows the message in the space center, and this window seems to be about settings rather than dynamic output (space center).

This toggle in Space Center sometimes isn't on, which makes this extension useless. First idea I had was to always force this setting to be on, but maybe MM2SC just gets another checkbox. That way "Always show kerning" could be a user decision to force that toggle on.

This code would set the "Show Kerning" to True. (with help on the side from Jackson and Connor)

from mojo.UI import CurrentSpaceCenter

choice = True

lv = CurrentSpaceCenter().glyphLineView

# set whether kerning is shown in space center
lv.setApplyKerning(choice)

# make sure the "Show Kerning" checkbox in the space center pref contextual menu gets updated
states = lv.getDisplayStates()
states['Show Kerning'] = choice
lv.setDisplayStates(states)

Often the wrong apostrophe pops up. Will look into sample text when I have time. Would be good to have both of these situations represented, as apostrophes are often mistyped as '

Love this extension! Would be great if there could be a text sample as often as possible. When there's none, for a weird pair, maybe it could look into other glyphs/pairs within the current glyph pairing.

Sometimes the output text is long enough that it can be disorienting / slow to find the pair in question. So here's a blue-sky idea. What if the pairs were underlined or somehow highlighted in-context, in Space Center, so you knew immediately where to look? Obviously this could be another CheckBox preference toggle in the window UI.

Possible?

Looks like the default spacing string is lowercase. I think it can react to the current pair a bit better.

@arrowtype (moved from question here: #5)

A slightly more abstract question, possibly better for an issue ... how else might we add in more context? E.g. probably, for a pair like V., users will want to also see W., Y., and maybe others as well. Is this something we could guess at (like open+close context), something that people are already able to just do with default MM features, or something that might require some kind of Ramsey-Street style user settings?

This is an excellent question, and something I’ve been thinking about. I'll move this to a new issue.

I‘ve been thinking about a way to add context strings in a simple way, without trying to make too many assumptions. I‘m thinking we could do something like the way Space Center uses /n for new line, perhaps using the existing MM variables of /$LEFT and /$RIGHT for left glyph and right glyph, eg:
[given current pair is A V, aka left= A right = V]
text field could take input like:
HH/$LEFT/$RIGHTH/$LEFTWH/$LEFTYHOHO/$LEFT/$RIGHTO/$LEFTWO/$LEFTYO
output:
HHAVHAWHAYHOHOAVOAWOAYO

I've already been doing some things like this on my own fork of the extension where I hard code in custom spacing strings like this, but without the /$LEFT and /$RIGHT variables. Would make sense to also use the MM variables /$LEFTCLOSE /$LEFTOPEN /$RIGHTCLOSE /$RIGHTOPEN as well.

Though thinking about this more, I would love to shorted to /$L and /$R as well as /$LC /$LO /$RC /$RO to save space, if there are no issues with this. Might even need a popup window, or something similar, to define this context since it will likely be longer than the main window size, and I like keeping the main window size small. If you want to take a crack at this I‘d love to see it. Thanks for asking!

Small idea: could each output from the checkboxed options live together on one line before all the text starts?

With "open and closed" and "mirrored pair activated"...
Instead of

{R} R}R HHR}HOHOR}OO
{WINDOW} {WATER} {COUNTER}

(Text shown above wouldn't generate, but could, ideally)

...could it instead be the following, to be a tiny bit more glance-able?

{R} R}R 
HHR}HOHOR}OO
{WINDOW} {WATER} {COUNTER}

... rather than taking up a whole new window.

Something like this:

Thoughts?

I usually kern lc-UC and often find myself making up CamelCase words but we could easily let MM2SpaceCenter come up with them. I'm happy to try implement this and add a pull request.