Options

Diacritic marks crashing into descenders and baseline

I'm working on a monospace design and after creating the diacritic marks I'm running into the issue of diacritics overlapping other characters due to shallow line-space. I've attached a screengrab showing what it looks like in an application like InDesign (not as bad, only happens on descenders) and notepad/text edit (really bad, happens at baseline).

I believe the topic I should be researching to solve the issue is vertical metrics, however I'm deeply confused from what I've read on other threads here, and articles like this one on Glyphs or this one on best practices.

Some info about the design that may help to troubleshoot...
  • Design app = RoboFont
  • UPM = 1000
  • Fixed width = 700
  • Cap height = 700
  • Ascender = 750
  • Descender = -166

A couple things I think I could adjust to fix the issue are:
  1. potentially adjusting the ascender and descender values (not altering design of any glyphs)
  2. adjusting lineGap value, currently set to default of 200
  3. mess with the hhea and os/2 table (like in articles mentioned above)
Advice would be greatly appreciated.




Comments

  • Options
    jeremy tribbyjeremy tribby Posts: 220
    you can fix this with more generous vertical (hhea, typo, win) metrics. setting the line gap to 0 and relying on those metrics instead will get you more consistency across apps, google fonts has pretty good docs on this: https://googlefonts.github.io/gf-guide/metrics.html
    there is a table there with the relevant parameters you’ll need in UFO format, which should suit your needs in robofont 
  • Options
    The Glyphs tutorial you mentioned gives a pretty good overview of why there are so many ways to approach it; I don't think you have to understand them all. As for what to do, I think their "The Webfont strategy" is still a very good start. Not sure how that aligns with the Google fonts guide.
  • Options
    This article on type.today is also helpful for understanding how vertical metrics are handled by different software and browsers: Web design: vertical metrics puzzle
  • Options
    Nick ShinnNick Shinn Posts: 2,148
    Aring is not even the most problematic Latin character—be sure to set your parameters for Vietnamese. 
  • Options
    Thomas PhinneyThomas Phinney Posts: 2,756
    A with breve and acute is often the worst in Vietnamese.

    One recommendation for Latin fonts is to draw/test this one character prior to finalizing your vertical metrics, even if you do not otherwise need it, because you do not intend to support Vietnamese in your initial release version! That way if the font is later upgraded to such support, the metrics are already set correctly to handle it.
  • Options
    Josh NychukJosh Nychuk Posts: 28
    thank you for all these helpful suggestions. I will do some more research as it looks like these resources cover everything.

    @Thomas Phinney are you saying the vertical metrics cannot be changed at any time?

    I was under the impression you can update them after you have drawn all glyphs and accents and are happy with your design.
  • Options
    Craig EliasonCraig Eliason Posts: 1,404
    I think the idea is, while technically you can adjust vertical metrics at any time, if you've released the font into the world, such a change will throw off the documents made with the older version if their fonts are updated. Best to avoid that.
  • Options
    Thomas PhinneyThomas Phinney Posts: 2,756
    edited April 3

    @Thomas Phinney are you saying the vertical metrics cannot be changed at any time?

    I was under the impression you can update them after you have drawn all glyphs and accents and are happy with your design.
    Yes, absolutely, the vertical metrics can be changed at any time in development. My comment was about being prepared for the event one intends to ship an initial version to end users without such extensive language support, but might conceivably add it at some later date.

    You can, of course, change vertical metrics in an already-shipping font, but not without potential changes in user document/websites (or differences between different users of “the same” font on the same project), and reflow because of it. What exactly happens will vary depending on the change and the client app, and sometimes even on how the document was formatted (Word’s “single spacing” is more sensitive to metrics changes than if you specify points-based spacing). Thus foundries and type designers have reasons to avoid it when possible.
  • Options
    Josh NychukJosh Nychuk Posts: 28
    @Thomas Phinney Got it! Thanks for clarifying.
Sign In or Register to comment.