rafalbuchner / mastertools Goto Github PK

Is there a way to exit out of the master compatibility mode?

If so, I can't find it.

We've chatted about this in the past, but it makes sense to track as an issue.

In summary, table cells would be helpful as a "heat map," where rows with different values could use saturation of a color to quickly show relative values.

e.g. the highest value in the row gets a background of rgba(1,0,0,1), and the lowest value gets a background of rgba(1,0,0,0.25). Everything in between could interpolate the opacity based on its value. Potentially, the hue could also change, though this may be less helpful.

problem with updating the font/glyph– I'm assuming that masterprocessor is messing with glyph.changed updates, therefore it resets the table's cells highlightings

• remove /test_designSpace/mutatorSans-master
• add it back as a Git Submodule
• add a note to the README about how to clone the repo and pull in all submodules

Occasionally, the table seems to be getting "stuck," so that one set of numbers ends up overlapped on another, making it impossible to read.

Current version I'm using: 9a13a25

Challenge

It is possible to make a glyph that has the exact same number of contours between masters, but still fails in cu2qu, because segments are of mismatching types.

This is a very difficult error to find, because it requires manually going through all masters, and visually searching all segments for mismatching off-curve points.

Example

In the glyph /Q in Recursive Mono at 0d266f5d, this is the case for segments 2 & 5. In most masters, segment 2 has off-curve points, and segment 5 is flat. In the Recursive Mono Strict Italic A, however, these are flipped.

cu2qu gives the following error for this glyph:

ERROR:cu2qu.ufo:Glyphs named 'Q' have incompatible segment types:
  4: ('curve', 'curve', 'curve', 'curve', 'curve', 'curve', 'line', 'curve', 'curve', 'curve', 'curve', 'curve')
  7: ('line', 'line', 'line', 'line', 'line', 'line', 'curve', 'line', 'line', 'line', 'line', 'line')

Proposed solution

It would be really helpful for Master Tools to have a tool that could show segment type differences.

Not only would this help users to catch errors like the /Q shown above, but it also may help people to find where points are missing, more quickly.

Of course, the challenging part is knowing where it fits in the tool...

Option 1

A new table view (e.g. a separate window) could exist to show contour types for the current glyph. In the /Q example from above, that might look something like this:

FONT               | 0 1 2 3 4 5 6 7 8 9 
----------------------------------------
Strict B           | L C C C C C L C C C 
Strict A           | L C C C C C L C C C 
Strict B Italic    | L C C C C C L C C C 
Strict C Italic    | L C C C C C L C C C 
Strict A Italic    | L C C L C C C C C C 
Casual C           | L C C C C C L C C C 
Casual C Italic    | L C C C C C L C C C 
Casual B           | L C C C C C L C C C 
Casual B Italic    | L C C C C C L C C C 
Casual A           | L C C C C C L C C C 
Casual A Italic    | L C C C C C L C C C 
Strict C           | L C C C C C L C C C 

It becomes even more obvious where the issue is if these types are color-coded:

FONT               | 0️⃣ 1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 8️⃣ 9️⃣
------------------------------------------------------
Strict B           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Strict A           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Strict B Italic    | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Strict C Italic    | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Strict A Italic    | 📏 🥐 🥐 📏 🥐 🥐 🥐 🥐 🥐 🥐 
Casual C           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Casual C Italic    | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Casual B           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Casual B Italic    | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Casual A           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Casual A Italic    | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 
Strict C           | 📏 🥐 🥐 🥐 🥐 🥐 📏 🥐 🥐 🥐 

Of course, if this isn't in the typical view, you may also need to find a good way to alert users that they need to look at the table.

Option 2

Potentially, you could add secondary rows to the overall compatibility table.

This seems like it might be more complex to build. It would require a more complex table structure and would either mean many more rows, perhaps with the ability to expand/collapse a contour row to see its segment type. Even with the expand/collapse, I'm not sure whether it would be that much easier.

However, it might be nice, in a way, for the "compatibility table" to be a table to show all aspects of compatibility.

Option 3

There are probably more ways to do this, and you have a good sense about these things, @RafalBuchner. Of course, this is somewhat of an enhancement to the original scope, so you should only add it as time permits.

For now, I've got a croissant emoji script I can run to search for segment mismatches! :)

g = CurrentGlyph()

print("FONT".ljust(18), end=" ")
print("|", end=" ")

print("SEGMENTS")

for f in AllFonts():
    
    print(f.info.styleName.ljust(18), end=" ")
    print("|", end=" ")
    for c in f[g.name]:
        for s in c:
            # print(s.type[0].upper(), end =" ")
            
            # possible segment types: move, line, curve, qcurve
            
            if s.type == "line":
                print("📏", end =" ")
            elif s.type == "curve":
                print("🥐", end =" ")
            elif s.type == "move":
                print("🚚", end =" ")
            elif s.type == "qcurve":
                print("🥨", end =" ")
        print("|", end =" ")   
            
    print("")

Current icon is a placeholder

Go to https://github.com/RafalBuchner/masterTools/settings and enable the Github Pages from the /docs directory, then drop /docs/index.html (or, set up Jeykll in there :)

http://pages.gihub.com explains about how this works :)

Scenario:

I have changed the table width on a glyph window, to put numbers closer to one another:

However, when I go to the next glyph window (with EditThatNextMaster), the table width shifts, because it is back to the full-width default. This makes it hard to read the table when cycling between glyph windows in different masters.

A couple of potential solutions come to mind:

• The table opens in a floating window, and this updates to show the current glyph.
• When the table width is changed, this updates the width in all glyph windows.
  • If this causes performance issues with resizing the table, maybe this could have a short delay before updating?

Ideally, both of these things would be possible. I definitely like the table inside the glyph window, and I like how the width can be adjusted, but it's not very useable if I can't sync widths between windows.

Right now, the column titles are left-aligned.

This means that it's more difficult to read what numbers they connect to, at a glance.

It would be easier to use this (especially in complex families) if the titles were right-aligned, because this would put them in a straight visual line with the numbers they are associated with.

This is a view of a 12-master family:

Because I navigate between masters with EditThatNextMaster, it would be quite a bit nicer to have some kind of indication of which column the current glyph view is from. Maybe that column's header could be bold, or highlighted somehow. That way, I could very easily see where I'm at as I navigate through the space, with the table telling me what is ahead and behind.

I've noticed that in the current version of the compatibility table, it appears at seemingly-random x positions, within the glyph window. It's a lot easier to use while it's in the same place, and especially when that's in the corner. This might just be something that's getting current work, and if so, all good. Just wanted to report it in case it wasn't obvious on a different screen, etc.

I love that I can drag-and-drop a designspace file onto the tool's floating window to open it.

However, I should also be able to click the "designspace" icon to get a file explorer view, with .designspace filetypes allowed to open.

improve tracking whenever the glyph is incompatible

https://github.com/RafalBuchner/master-tools/blob/b6aebbbde25bddd38c818e1fdeb8ef5e3287fabe/todo_and_issues.md

Move each "to do" item to its own issue