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

[opengraphica]

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)

1. 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]

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]

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]

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

[ILOVEPIE]

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]

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]

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.