mm2spacecenter's People
mm2spacecenter's Issues
Wider "# of words" input box
Sometimes the input number exceeds the width of the EditText box → unreadable.
Leaving this here for myself to potentially address when I have time.
How to handle non-prose glyphs, like figures
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?
[next-master] Question: can we improve the system of dealing with unencoded open/close punctuation?
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.
MM2SpaceCenter/MM2SpaceCenter.roboFontExt/lib/MM2SpaceCenter.py
Lines 508 to 522 in 3b04a29
I’m making a note of this as something to potentially look into after #26.
Add option to show related-shape control strings
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
toV 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.
Look to MM for contexts, when no text is available
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.
[next-master] spacing string broken by slash + suffixed O
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
.
Suggestion: Word length input
I think it would be good to add the original word-o-mat option back in
[next-master] glitches in mirrored pairs and open/close context
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:
- 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
orR e
- Incorrect: Doubled mirrored pairs, for pairs containing punctuation and uppercase, e.g.
bracketleft T
, or uppercase and figure, e.g.R 6
. - 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 ofH
and]
?" If the string isHH[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.
Suggestion: Remember last used setting
I think this would also be useful
When opening, open SpaceCenter and MM for current font, if neither is open.
Extension stops working when it hits a missing glyph?
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'."
Do we need the status message?
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).
Toggle for "show kerning" in 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)
/quotesingle vs. /quoteright in sample text (English)
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 '
When text sample unable to be found, search for pair within group.
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.
Draw attention to active pair in SC context somehow
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?
"Auto" context defaults to lowercase
Looks like the default spacing string is lowercase. I think it can react to the current pair a bit better.
Allow for custom spacing strings with variables
@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!
Suggestion: show all upfront text in its own line
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}
Suggestion: UI is a pop-over from a button in Space Center itself
Suggestion: Add lowercase-Uppercase words
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.