Fussiness under the baseline

PabloImpallariPabloImpallari Posts: 315
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

  • RalfRalf Posts: 170
    Nothing seems to make any difference.
    Well, that's because the Mac doesn't use the hinting settings.
  • 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.
  • @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.
  • PabloImpallariPabloImpallari Posts: 315
    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).

  • What did you do with the BlueValues? Before/after?
  • PabloImpallariPabloImpallari Posts: 315
    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.
  • I am curious about the formula but I couldn't find it in your website.
  • Georg SeifertGeorg Seifert Posts: 185
    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.
  • David BerlowDavid Berlow Posts: 491
    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 ;)


  • @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.



Sign In or Register to comment.