search

source-foundry / Hack

A typeface designed for source code
http://sourcefoundry.org/hack/
Other
16.38k stars 612 forks source link

"Wrong Metric" #480

Open rumpelsepp opened 5 years ago

rumpelsepp commented 5 years ago

Hi!

I use Hack in the kitty terminal emulator and the author of kitty mentioned that the font uses wrong "metrics" (I have no idea of the inner workings of fonts and what this means). The problem is that kitty truncates characters, since hack apparently has too large characters in the bold+itallic variant.

Hopefully you can shed some light on this: https://github.com/kovidgoyal/kitty/issues/1470

Stefan

chrissimpkins commented 5 years ago

Responded in the kitty repository thread that you linked. Let's see what Kovid has to say about the issue. This is the first that I've heard about problematic horizontal metrics. Not sure what he means.

chrissimpkins commented 5 years ago

Based on Kovid's comments, I will need to investigate the horizontal metrics b/w the regular and italic sets. Thanks for pointing this issue out. Will take a look.

aron-bordin commented 4 years ago

hi! any update on this?

balbassam commented 4 years ago

Friendly ping asking if there's any update on this :)

chrissimpkins commented 4 years ago

Here was @kovidgoyal's comment:

The important part as far as this issue is concerned is that the size of the cell used to render characters is font-independent. It is calculated based on the metrics of the "regular" font. Bold and italic variants of the regular font are rendered in the same sized cell. This means that if a variant's characters dont fit within the same cell, they will be truncated.

I reviewed the lower case p that is described in the kitty thread. Here is where we are with metrics across regular, bold, and bold italic styles (italic has the same 1233 font unit bounding box in a 2048 UPM)

2020-02-04_11-07-10 2020-02-04_10-59-39 2020-02-04_10-59-14

In this monospaced font, there is a consistent set of bounding box metrics across the entire design space (i.e., all styles). You can see the advance width values of 1233 that are circled in green. I think that this issue may be due to the fact that the render does not account for the additional right side width required for the italic angle that is added when conversions between regular and italic are made? The "box" becomes slanted for oblique/italic forms. If that is the case, then clipping would happen along the pink line in the last image relative to the lower right bounds of the box. I don't know that there is a way to fix that in the font without breaking other environments. @kovidgoyal can you weigh in with additional details on how the H metrics are approached in kitty? I'd be interested to see the implementation so that I understand this problem.

kovidgoyal commented 4 years ago

cell width is calculated based on the metrics from the base font. No alternate faces are consulted at all. It is expected that italic and bold faces will fit within the metrics i.e. advance width of the base face. If that is not true you will get either cutoff or resized glyphs depending on the extent of the misfit.

So to summarize it is expected that the bounding boxes of all glyphs from any variant fit within the advance of the base face.

chrissimpkins commented 4 years ago

Thanks Kovid!

For those following and interested here, this seems like an analogous issue: https://www.codeproject.com/articles/14915/width-of-text-in-italic-font

If you disregard the added width in the slanted forms by taking sum(advance widths of all characters in upright), the last character is trimmed or must be scaled in some fashion to fit within the upright bounds. The "overhang" at the last character on a given line is clipped at the spot where the right margin on the baseline of the upright form is defined as shown in the pink line in my image in https://github.com/source-foundry/Hack/issues/480#issuecomment-581988069

I don't see that there is a horizontal metrics issue in the fonts as released here, nor that there is a possible workaround that we can support to make this work on kitty. If anyone has ideas, please do weigh in.

chrissimpkins commented 4 years ago

I'll add that typefaces that do work in that environment must have different sidebearings (spaces to right and left of the outline) so that the entire form in italics is shifted to the left of the vertical line that I've shown above. Those will be the metrics that you want to play well with kitty.

chrissimpkins commented 4 years ago

e.g.,

2020-02-04_13-21-33
chrissimpkins commented 4 years ago

This move in Hack would track out the letter spacing across the entire typeface which is not desirable.

kovidgoyal commented 4 years ago

No not quite. In kitty text is not laid out in lines but cells, per character.. And for italic characters, empty columns on either side of the character are trimmed if the resulting bitmap is wider than the cell width (see line 417 in kitty/freetype.c) So if italic characters are getting cut-off it means the actual non-empty width of the italic characters is wider than the wadvance for the regular face.