Fussiness under the baseline

PabloImpallari
PabloImpallari Posts: 806
edited July 2012 in Technique and Theory
I'm cant find a solution to this little problem:
image

If you look closely, will see that at 14 and 16pts there seems to be grayscale pixels under the /n serifs. How can I remove it, so it looks like the ones at 15, 17 and 18pts? (Firefox/Mac)

The blue lines are already in place, like this:
image
However, the problem remains.
I spend all day experimenting, hinting, un-hinting, tweaking blue values, looking at pixels, etc... and wasn't able to find a solution. Nothing seems to make any difference.

The greyscale pixels below the /o are OK, but not the ones below the /n, /i, /l, etc...


Comments

  • Ralf
    Ralf Posts: 170
    Nothing seems to make any difference.
    Well, that's because the Mac doesn't use the hinting settings.
  • Rainer Erich Scheichelbauer
    Rainer Erich Scheichelbauer Posts: 157
    Changing your hhea values may have an impact on it. I guess OS X does not gridsnap cubic curves. If you re-install the font in the system, make sure you empty caches and restart first, or rename the font every time.

    But seriously, why bother? This is only an issue if you scale a screenshot like this.
  • PabloImpallari
    PabloImpallari Posts: 806
    @Ralph: I have read somewhere (don't remember right now) that while the mac ignores the hinting, it does uses the blue values. But now, after testing, I'm not sure the blue values have any impact.

    @Mekka: Thanks, I will play around and report back if I found a solution.
    It's an issue for me, type looks much more crisp at 14px whiteout those pixels under the straight stems.
  • PabloImpallari
    PabloImpallari Posts: 806
    edited July 2012
    Two days, a lot of cigarettes and coffee later... finally found a solution!

    @Ralph:
    Mac may ignore the hinting, but renders quality can still be controlled!
    The fussiness/sharpness of the text, seems to be related to the Vertical Metrics, as Mekkablue suggested, and the vertical BBox.

    @Mekka: Playing around with the vertical metrics was the solution! Also, a little bit of blue values tweaking.

    This is how awesome it looks now (compare to the image in the first post):
    image

    It makes all the difference in text sizes.
    image
    Now it renders as good as the Webtype RE series, or the new H&FJ SmartScreen fonts.
    And maybe even better at 10 and 11px (Keep in mind that I only fixed the vertical metrics, there are still room to tweak the horizontal metrics and stem widths).

  • Rainer Erich Scheichelbauer
    Rainer Erich Scheichelbauer Posts: 157
    What did you do with the BlueValues? Before/after?
  • PabloImpallari
    PabloImpallari Posts: 806
    edited July 2012
    Tested hundreds of combinations :), until it worked out Ok.
    I will find a formula soon... I will also upload the source code for this font (as I do with all my other fonts) in my website projects section, so you will be able to see for yourself.

    As a side effect: It also improved the fussiness at the top of the x-height, not only at the baseline.
  • Ramiro Espinoza
    Ramiro Espinoza Posts: 839
    I am curious about the formula but I couldn't find it in your website.
  • Georg Seifert
    Georg Seifert Posts: 674
    edited July 2013
    I had a similar problem, once. In my case it seemed that macOS is generates alignment zones on the fly and I could "fix" it by increasing the overshot of the (lowercase) o.
  • Deleted Account
    Deleted Account Posts: 739
    If form holds, increasing the overshoot, (the actual glyph data), to fix a rendering issue at some sizes on the Mac, will reduce the rendering quality at some sizes on Windows or beyond. So, while there may still be room to tweak the horizontal metrics and stem widths...

    ...then, these little sizes on the Mac will become irrelevant, and you can slide the overshoots, stems and metrics back to where you the designer, wanted them in the first place. Then, it'll be like nothing ever happened, except you didn't have the time or money get that new bicycle seat.

    My advice is to design for size issues and let crude media screw up rendering without your help ;)


  • PabloImpallari
    PabloImpallari Posts: 806
    @David In my case, both before and after samples have the same overshoots and glyph data. They where not changed. The fussiness under the baseline was related to the hhea values.

    @Ramiro: There is no formula, but will try to explain what I've found:
    The hhea values will define the vertical grid for your font.
    If the baseline sits in a number that is divisible by the number of pixels used to render your font, there will be no fussiness. But if the baseline sits in a place that is not on the grid, it will be fussy.



Categories