Strange squish (unsure how to describe in words)

I’m new to Gyphs Mini, and to bug reporting in general, but here goes:

As a first attempt at making Udierisis, I pasted my colon onto my Uaccent. I then rotated it the colon 90° and started nudging it upwards. When I realized this wasn’t going to achieve what I wanted, I used undo to try getting back to the state in the image above, but suddenly this happened:

This has happened before, as has a version where all or some of the points in a character are relocated into a single overlapping point, usually in the bottom left corner. It happens like this one, from hitting undo, or from editing number fields (I think mostly sidebearings, but I can’t remember). In the latter scenario, hitting undo does not fix the issue, and indeed sometimes all the work I’ve put into the character is lost. Oddly, I can redo (i.e. Command+Shift+Z) the one I’ve captured in the images above, and the error is fixed, though of course my progress in the edit is out of reach because the timeline of changes is interrupted by this issue.

ETA: It happened again with a different character, and I was able to reproduce it many times (which I haven’t before):

  1. Copy and paste J to create J.001
  2. Create two points, then select all points to the left of these and delete. (I’m creating a long skinny variation.)
  3. Type new number in left sidebearing field to make symmetrical.
  4. All points except the two I just created are relocated to a single position at -244,0.

Any clues? Anything I need to do to help find a solution? And thanks!

What version of Glyphs Mini do you have?
Would it be possible to make a screencast of what you are doing (the QuickTime app can do that)? That way I know exactly what you are doing.

Glyphs Mini 2.1.4 (113), and I’ll investigate a screencast. Thank you!

Screencast: https://downtowndurham.com/cms/wp-content/uploads/2022/04/strange-squish.mov

Can you please update to the latest cutting edge version. You can activate it in Preferences > Updates.

1 Like

Could you send me that file?

Updated to 2.1.6 (117)! File on the way.

Does it still happen in the latest version?

I can’t reproduce this.

Just tried it again (the J steps) with the update, and it happened again exactly the same way, but I’m not super surprised you couldn’t reproduce it because it happens very unpredictably.
Is there anything else I can do or watch for to give you more clues?

New info:

  • The same thing happens when I update the sidebearings field whether I’m in the character interface or in the font view.
  • Hitting undo changes the affected shape from this…

…to this (note that the original width was 524, not the 776 it is here, and that the overlapped points are now located on 0,0)…

…to this, So it’s undoing everything that I selected and deleted, but everything else is still squished!

If nothing else I feel good about calling it “strange” :slight_smile:

What version if macOS do you have? And what mouse?

Monterey 12.2.1 and Logitech 355

More data on this issue based on these steps:

  1. Copy and paste to create an alternate of an existing letter (in this case, O)
  2. While still in font view, change the left sidebearing of the new letter. New sidebearing does NOT reflect what I just typed in that field (more info below).
  3. Letterform merges into a single coordinate on the baseline and at what would have been the left-most point of the letterform before the sidebearing changed.

(For context, I just updated to Cutting Edge 2.1.6 (117), and I’m doing this with my trackpad rather than my mouse)

I’ve repeated this multiple times this morning to make sure I’m not just making a typing error. Regarding the sidebearing weirdness of step number 2, it seems to be subtracting the original value from the new one, as you can see below:

Original | typed value | end value
30 | 5 | -25
30 | 15 | -15
30 | 25 | -5
30 | 35 | 5
30 | 45 | 15
30 | 55 | 25
30 | 65 | 35
30 | 75 | 45
30 | 12 | -18
30 | 100 | 70
30 | 72 | 42

…and so on. Note however that all of these changes are in the left sidebearing. At the same moment the right sidebearing - without typing anything into that field - automatically changes to the width of the original letter, regardless of what value is entered (or outputted) in the examples above.

More:

  • This does not happen when following the same steps on the original letter.
  • This does not happen when changing the right sidebearing value on a copied letter.
  • It does still happen when changing the left sidebearing value after changing the right sidebearing value.
  • It also happens when changing the left sidebearing value from the view of the individual glyph.
  • It happened to the handful of other copied characters I tried (letters, number, punctuation)
  • It happens regardless of what iteration of alternate it is (e.g. zero.001 or zero.009 etc.)
  • It does not happen when I move the character within the glyph view and then adjust the sidebearing value, even if I move it back to the same place (e.g. selecting all points, then hitting the left key and the right key.)
  • It does happens if I move it and then undo that move, and in that scenario I don’t even have to change the sidebearing value - I just select all points, hit a direction key, hit Command+Z or select Undo from the Edit menu, and it happens. In this situation the coordinates that all the points merge to are 0,0 - presumably because [original sidebearing value] minus [original sidebearing value] = 0, to connect with the calculations above.
  • As a variation on the previous point, if I select only some of the points in the letter form and follow the move-then-undo steps, only those points I selected are affected. If I then select some of the remaining (unaffected) points and move-then-undo, they too are merged onto 0,0. I think this is the connection with the way I initially described the issue as in the image at the top and the video of the J.

Sorry, that was a lot!

I’m looking into it.

1 Like