Suppressing overshoot


#1

Hello,

I’m remastering some fonts that were originally build in FontLab and hinted with the Adobe FDK autohinter, but I can’t seem to suppress the overshoot. The image is an enlargement of the old font on the left side and a new otf exported from Glyphs with autohinting enabled on the right side, set in 12 pt in InDesign. Screen capture made on 100%.

Alignment zones, vertical and horizontal stems seem to be set correctly. I’m using default blueScale.

Do I have to use a custom blueScale?


#2

can you post an image that is less blurry?


#3

Here’s a 100% view from InDesign.


#4

Can you send me the .glyphs file?


#5

The image is still bury. The Forum rescales the images. Can you send a .zip of the image?

What might causing this: incompatible or missing zones, or stems. Any of the other hint settings (blueScale…).


#6

I’ve sent Rainer the.glyphs file. Here’s a zip with the image.

Screen Shot 2019-03-09 at 22.39.48.zip (69.8 KB)


#7

You can click the download link at the bottom after magnifying the screenshot, and you will get the original file.


#8

There is something wrong with the zones.


#9

I think the zones were not the problem, but the blueScale value. Is that correct @mekkablue?


#10

Yes, I double checked outlines (zero handles, path direction) and added a blueScale parameter.

To be fair, the zone sizes are on the diverse end of the spectrum (similar or same sizes in all zones do make it easier), and that may have caused the difference between the renderings at x-height and baseline. But the blueScale knocked everything down anyway. :slight_smile:


#11

So that would mean that if most of my zones are 12 units, but my x-height zone is 20 units, it’s best to try to set that to 12 units too?


#12

To be precise, it’s best if:

  1. your actual overshoots (in the outlines) are the same size everywhere,
  2. and they are all inside zones.

Well, ‘best’: they can all toggle at the same PPMs more easily then.


#13

Well my actual overshoots differ within the lowercase, some characters have a larger overshoot then others, but they all fall inside the zone.

Still haven’t been able to replicate your results with the blueScale value…


#14

Are you sure that the zones are compatible? Have a look at the expired file (with OTMaster or ttx).


#15

I didn’t know it was possible to check zones in OTMaster. In what table are zones stored?


#16

It is in the CFF table. Or check the .ps file in the temp folder. You can open it in a text editor like Textmate or Sublime.


#17

I checked the .ps file, the BlueValues match the ones that I set in the Glyphs file.


#18

1
Actually different shapes need different amounts of overshoot, so by making all overshoots identical, the design might suffer. This error already happened in the analog drawing rooms of big type foundries, where rooms full of drawing ladies were instructed to snap everything to guidelines, destroying many optical subtleties that for instance Frutiger had applied to his drawings.
2
When a few glyphs need a bit more overshoot than most, you can set BlueFuzz to 1 or 2, keep in mind this increases the minimal distance between two zones. Value 0: min. dist. = 1, value 1: min. dist. = 3, value 2: min. dist. = 5. BlueFuzz catches those bigger overshoots without overshoot taking place at a smaller size. Something Adobe had forgotten it seems.


#19

I just added a zone of 40 units and oddly it appears to work ?
Which I’m happy about . . . but crazy


#20

yes, but in sizes where overshoot is suppressed, the “round side” of a zone is used for rounding to the grid, so when the x-height zone is 40, the x-height will be rendered bigger in many small sizes. Which can be good or look grotesque.
Keeping zones that belong together (baseline, cap height, x-height) at the same thickness makes sure they start to overshoot at the same size, but zones for superiors or ascender/descender can definitely be narrower.