Home› Technique and Theory

1000 em units?

Charles Borges de OliveiraCharles Borges de Oliveira Posts: 71
in Technique and Theory
Is it possible to have a font that is postscript that can have flourishes that go past the cap height. My caps are set at 700 but the largest flourish peaks at 1073. The same flourish also peaks out at -735 below the baseline. Do I have to scale the whole font down so everything fits in the 1000 em unit. I was hoping not too because I am afraid I will get minor distortions from scaling down. The font works fine in adobe products but the flourishes get cut off in word 2007. I am not very familiar with word but when testing it the alternates that have flourishes were all cut off. I am afraid that some customers will complain if they are using word or the basic word program on a mac. Thanks for any info you suggest.

Comments

  • John HudsonJohn Hudson Posts: 2,815
    You need to set your OS/2 WinAscent and WinDescent values to exceed the tallest and deepest glyphs to avoid clipping in GDI apps on Windows. Note that this will also increase the default linespacing in such apps.
  • PabloImpallariPabloImpallari Posts: 773
    edited October 2013
    Font Info → Metrics → TrueType Specific Metrics:

    1) Select "Set Custom Values"
    2) TypoLineGap and LineGap, both set to 0 (zero)
    3) Os2 TypoAscender and TypoDescender: Use your normal metric values
    4) hhea Ascender and Descender: Use your normal metric values
    5) WinAscent and WinDescent: use 1073 and -735

    Or, option 2, use the bbox values for all the 3 groups:
    3) Os2 TypoAscender and TypoDescender: 1073 and -735
    4) hhea Ascender and Descender: 1073 and -735
    5) WinAscent and WinDescent: 1073 and -735

    In webfonts we usually go for option 2, to minimize line-height rendering differences between all the different browsers and operative systems and apps.

    Also, we usually try to fit the font in bbox values no larger than 25% bigger than the UPM.
    So, maybe I will suggest just a little bit of scaling down, so that the sum of WinAscent + WinDescent does not exceeds 1250 units.
  • Charles Borges de OliveiraCharles Borges de Oliveira Posts: 71
    Thank you so much for the help friends!!! Much appreciated.
  • John HudsonJohn Hudson Posts: 2,815
    This is the model we use to obtain compatible metrics. Pablo's option 2 works, but I figure the linegap data fields are there, so why not use them. This is how Mike Duggan at Microsoft requested we set values for deliveries to them, and we've been doing it ever since.

    1. Set OS/2 WinAscent and WinDescent values to bounding box height and depth.
    2. Set TypoAscender and TypeDescender relative to actual ascender and descender measurements, but rounded so that together they sum to the UPM value (both values taken as positive for this calculation).
    3. Set TypoLineGap to be the difference between the sum of the TypoAscender and TypoDescender values and the sum of the WinAscent and WinDescent.
    4. Copy Typo- values to corresponding hhea metrics.

    As Pablo suggests, if you want the linespacing produced by use of the OS/2 Win- values in GDI apps to be no larger than typical default leading (120-124% of body height), then you might need to scale the outlines so that the bounding box is smaller. But scaling will produce outline rounding errors, so I would be wary of doing this if you have substantially completed your design. The relationship of outlines to vertical metrics is, ideally, something you work out at the beginning of the design process.
  • Matthew ButterickMatthew Butterick Posts: 143
    Another good resource: Karsten Lücke’s advice on font metrics, which I’ve always followed, and never had a problem.
  • PabloImpallariPabloImpallari Posts: 773
    edited October 2013
    Agree, setting the metrics as early in the process as possible is always good.
    the linegap data fields are there, so why not use them
    Because different browsers/os/apps use then in inconsistent ways. And you never know if they will be used or ignored by any particular application in any particular OS, now or in the future.

    By setting all the 3 metrics groups to the same values and the linegap to zero, you minimize the chance of inconsistent line-height rendering across devices.

    Google have done intensive/obsessive testing on this (in particular to prevent text reflow issues in Google Docs, where the same document can be open/printed by any device under any OS, including phones and tablets) and this is the method they recommended us.
  • John HudsonJohn Hudson Posts: 2,815
    Yes, browser proliferation has altered the compatibility picture somewhat. Back when we were testing metrics results with MS and Adobe, the OS was the main determinant of linespacing behaviour. App variation was mostly limited to, on the Mac, first line depth from top of text block.
  • John HudsonJohn Hudson Posts: 2,815
    If all modern apps respected the OS/2 fsSelection bit 7 setting, we'd not only have reliable layout compatibility but would also be able to decouple linespacing from bounding box!
  • Kent LewKent Lew Posts: 905
    the linegap data fields are there, so why not use them
    Because different browsers/os/apps use then in inconsistent ways. And you never know if they will be used or ignored by any particular application in any particular OS, now or in the future.
    Sounds like yet another case of moral hazard for the browser/os/app makers.
  • Deleted AccountDeleted Account Posts: 739
    Get two problems for the price of three!

    Differing languages and Scripts also want use of different metrics pesented to the app from the same font, if these metrics have not been so compromised, e.g. to have kabonged the Aring to the rest of the accent heights...

    So if the app is misbehaving for some other reason, that's one thing forever, and then you have the script language issue, and then there is the ever present forgotten issue of size, where vertical metrics are not best restricted to one size fits all.

    Eternal design compromise, via voodoo numbers, or a better font format... Hmmm.
  • John HudsonJohn Hudson Posts: 2,815
    Differing languages and Scripts also want use of different metrics pesented to the app from the same font

    Amen.

    Every time I visit Microsoft, I tell them we should add script and language specific vertical metrics to fonts. The OTL tag system provides everything they'd need in terms of script and language identification: they'd just need a place to add the metrics data associated with the tags. VMTR table anyone?
  • Deleted AccountDeleted Account Posts: 739
    "VMTR table anyone?"

    Voodoo Metrics Type Restrictions?

    SIZE matters. This age of NMAE no one nkosw the eanmgni of is getting old., I think. The public is on it's way to the tables.;)
  • Dave CrosslandDave Crossland Posts: 1,319
    > scaling will produce outline rounding errors

    Not with Fontforge :)http://fontforge.org/faq.html#non-integral
  • John HudsonJohn Hudson Posts: 2,815
    Not with Fontforge... if you are making PS fonts, don't mind larger font sizes, and are confident that all PS scalers out there are equally comfortable dealing with non-integer coordinates. I've never been that confident, but would love to see data confirming one way or another.
  • Denis Moyogo JacqueryeDenis Moyogo Jacquerye Posts: 162
    The BASE table allows for script/lang specific yMax and yMin. Why not use those?
  • John HudsonJohn Hudson Posts: 2,815
    Do you know anywhere that the BASE table yMax and yMin are implemented?

    There is also a big question about what the relationship of max and min extent settings should be to linespacing. We already have a massive legacy problem with GDI treating WinAscent and WinDescent extent values as a basis for linespacing, instead of Typo values. One thing we should have learned is that non-clipping bounding box zones should not necessarily correspond to desired default linespacing.
  • Denis Moyogo JacqueryeDenis Moyogo Jacquerye Posts: 162
    Yes, the definition of the MaxMin extent sounds like max bounding box which is redundant with WinAscent/WinDescent.

    The BASE table could be extended with a format that contains script/lang specific lineheight information then. The cost of implementing a new BASE table format or a brand new VMTR table is practically the same. Whatever it is in the end, I’m all for it, we seriously need this to be implemented.
  • Jan Willem WennekesJan Willem Wennekes Posts: 148
    Useful post, thanks guys!

    One extra question: I've seen a number of typefaces where accented characters (e.g. /Egrave) do go above the ascender height. Will something like that result in problems (e.g. in Word)?
  • John HudsonJohn Hudson Posts: 2,815
    Only if they extend beyond the OS/2 WinAscent height. If so, they will be clipped on screen.
  • Jan Willem WennekesJan Willem Wennekes Posts: 148
    Thanks for your reply John. I just looked up Karsten Lücke's font metrics document, that helped a lot. (it's right here for those interested). Test file works ok now!
Sign In or Register to comment.