Smaller bugs

I found some bugs:

  1. You can’t align single points with the alignment tools from the palette
  2. Deleting alignment zones in the font info doesn’t work
  3. The add component window could be a bit faster. Sometimes I enter a key into the searchfield and press enter immediately, but at that point it’s still on the old search result list. It also doesn’t update automatically when you add new glyphs that match the search pattern
  4. Glyphs loses members from groups.plist inside UFO files: When you open an UFO file with groups.plist populated, everything looks fine and the glyphs show the correct left/right kerning groups. Once you save as an UFO and reopen, some glyphs suddenly got dropped out of the groups (often the first ones)
  1. This is no bug. The align buttons only work on whole path. You have two other options. First, try cmd+shift+A or type in 0 for width or height in the info box when you have several nodes selected (open the lock first).

  2. I can’t reproduce this. Can you update to version 1.3.2 and try again?

  3. Yes. I this is sometimes very slow. I will have a look at it.

  4. You are right. I fixed that.

@2 I am on 1.3.2, 10.7, and it’s always reproducible (even on new fonts). The little auto generate icon works, but plus and minus don’t.


That language is your system set to?

I found one issue. Can you make the font info window as wide as possible and try again?

Yes, that fixes it!

Also, what is the custom parameter name for BlueScale?

Also the following:

If I add a zone from -15 to 0 by writing (-15, 15) it’s incorrectly added to OtherBlues, if I write it like (0, -15) it’s handled correctly

Also for some files it fails to export StemSnapH, while StemSnapV is fine. To reproduce, export the font at the link and run it through ttxn:

The alignment zones seem fine in your file:

/BlueValues [ -14 0 457 470 723 741 ] def
/OtherBlues [ -264 -264 ] def
/BlueScale 0.03700 def
/StdVW [54] def
/StemSnapV [54 55 58 ] def
/StdHW [54] def
/StemSnapH [54 53 ] def
/BlueShift 7 def

This is what gets written in the font file.

So if you define a zone from -15 to 0 this is actually a top zone for letters that are below it. Not sure if that is intended. usually the zone below the baseline has to be defined (0, -15).

Hm weird, I get this (just tried on another machine as well):

BlueValues {-14,0,457,470,723,741}
OtherBlues {-264,-264}
BlueScale 0.037
BlueFuzz 0
StdHW 54
StdVW 54
StemSnapV {54,55,58}

and it’s not a ttx bug, fl says the same

But that’s not that important (and doesn’t seem to happen on new fonts). More important I think would be the ability to add BlueScale, BlueShift and BlueFuzz into the custom parameters list

You can set the BlueScale and BlueShift in the Custom Properties of the Font use postscriptBlueScale and postscriptBlueShift as keys. Adobe recommends to always set the BlueFuzz to zero.

postscriptBlueScale doesn’t seem to work here, but I wrote a little post-build script to change these afterwards.

When do you think the update with the UFO group bug will be released?

Just uploaded and update that should fix the group bug.

Thanks now it works!
Here is some more stuff I found:

When you select the bold version in the font overview in an MM-Font (reg-bold), all characters are bold, once you double click on a character it also shows the bold cut, but the master selection button is stuck at regular. Changing to bold and back fixes it.

Commaaccent is renamed to commaaccentcomb on UFO-export, but glyphs referencing it are not changed (and need to be relinked manually).

When having multiple bottom anchors (eg. one for cecilla and one for commaaccent) the “accent cloud” shows both cecilla and commaaccent on both anchors, instead at only the correct one.

The tag cloud sometimes shows a cedilla instead of an commaaccent.

Also it seems that there’s a maximum of 5 levels of components. I reached that on the quote signs.
Here’s a font to reproduce it:

  1. This is a known bug.

  2. I will have a look at it.

  3. How you call both anchors?

And I thought that only three levels on nested components are possible. :wink:

I called them bottom and bottom_2.

The underscore + number suffix is used in ligatures to generate the liga mark feature for arabic fonts.

So it would be saver to call them differently.

But why would you need different anchors?