Handling vertical advance; ascender / descender doesn't look correct for some fonts

opentypejs / opentype.js

Read and write OpenType fonts using JavaScript.

https://opentype.js.org/

MIT License

4.36k stars 466 forks source link

Handling vertical advance; ascender / descender doesn't look correct for some fonts #726

Open opengraphica opened 3 weeks ago

opengraphica commented 3 weeks ago

Expected Behavior

I'm looking for the correct way to draw a font vertically.

Current Behavior

If I use font.ascender and font.descender to determine vertical placement (unitsPerEm taken into account), I get unnaturally large gaps between characters with vertical spacing.

This is odd, since opening the font in FontForge doesn't show such abnormally large ascender/descenders as I'm getting from opentype.js.

Maybe it has something to do with you reading the glyph data instead of the actual font metrics?

Possible Solution

I noticed FontForge has a concept of a vertical advance, which I don't see in opentype.js.

Steps to Reproduce (for bugs)

Draw glyphs manually, using font.ascender and font.descender as metrics for spacing the glyphs vertically.

Your Environment

Version used: 1.3.4
Font used: Noto Sans JP

opengraphica commented 3 weeks ago

After inspecting the code, it seems the vmtx/vhea table is not parsed, and thus this feature is not supported. If it's easy enough I'll open a PR for it.

ILOVEPIE commented 3 weeks ago

Version 1.3.4 is outdated and has been for several years now, we're preparing a new release, please try the in development version 2.0.0 on the master branch.

opengraphica commented 3 weeks ago

Master branch works the same, like I said parsing vmtx/vhea will be the solution to this problem.

ILOVEPIE commented 3 weeks ago

Master branch works the same, like I said parsing vmtx/vhea will be the solution to this problem.

We'll look into it, probably for version 2.1.0 as we need to get 2.0.0 out quick.

ILOVEPIE commented 3 weeks ago

I'm actually going to close this as it seems to be a duplicate of #618. I will post a link to this issue in #618 so we can reference it.

opengraphica commented 3 weeks ago

We'll look into it, probably for version 2.1.0 as we need to get 2.0.0 out quick.

This is a very simple change; parse some tables, expose a few variables. Doubt you're going to see anything controversial in the PR because it's basically the existing hmtx / hhea code copied and renamed.