hb-view: option to set a fixed line-height?

[danburzo]

Hi everyone,

I've been poking around hb-view to generate PNG previews for font files, and I was wondering if it's possible to add a CLI option that sets a fixed line-height (leading) for the text, as opposed to the configurable --line-space that gets added to the font's height:

harfbuzz/util/view-cairo.cc

Line 49 in b2a965d

double leading = font_height + view_options.line_space;

Such an option would allow the user to generate previews with aligned baselines (second row):

Not sure I'm underspecifying this and there are complexities that I'm missing, but I thought I'd ask.

Here's my hack job to test this out:
Edit: Removed throwaway code

[ebraminio]

Your patch looks good I believe and the feature is also a nice one, feel free to upload it as a PR, thanks :)

[danburzo]

Thanks for the reply! I'll bring it into a better shape and submit a PR.

[behdad]

So this is my objection to --line-height. The fonts won't line up if they have different ascent. So your example is wrong.

Please add --ascent and --descent instead.

[danburzo]

@behdad thank you for the feedback!

The fonts won't line up if they have different ascent.

If you mean in the patch from my original comment, that was just some throwaway code to demonstrate the intent; I should actually remove it from my comment. But with the code from the PR I submitted, the fonts seem to line up... here's a before/after comparison on a hundred randomly picked Google Fonts:

The Before image is from upstream/master with --font-size=48, the After image is from the PR, with --font-size=48 --line-height=66.

Please add --ascent and --descent instead.

I'll try to figure out how we can express the intent in terms of these two options.

[behdad]

The Before image is from upstream/master with --font-size=48, the After image is from the PR, with --font-size=48 --line-height=66.

Care to tell us how your --line-height works then? We need three numbers: ascent, descent, line-gap. How does providing line-height, which is the sum of those three, align the baseline? You can't.

[danburzo]

Well, I may be misunderstanding some basic concepts, but when you draw the glyphs in Cairo, their origin is at the baseline, right? so for each line i translate to (0, i * line_height):

The basic point of the PR is to replace the font-dependent ascender - descender + line_gap with a fixed, user-provided, line_height.

[alerque]

@danburzo I think you're just using the wrong term. What you are talking about and drawing there is generally known as "baseline skip" (to borrow from LaTeX lingo), not line height (which is kind of a nebulous thing defined differently in the HTML/CSS world than everywhere else. Well basically just everywhere.

The (very nice) thing you are accomplishing by forcing the baseline skip the way you seem to be is known as grid typesetting. You're setting consecutive baselines at an arbitrary fixed value apart from each-other and positioning the font ascender-decenders relative to that. It's a very useful little trick, line-height probably just isn't the best word for it.

[behdad]

Well, I may be misunderstanding some basic concepts, but when you draw the glyphs in Cairo, their origin is at the baseline, right? so for each line i translate to (0, i * line_height):

Right, that's not correct.

The position of baselines are, with zero-indexing:

  baseline[i] = ascent + i * (ascent + descent + line_gap)

and the height of the image of n lines is:

  height = n * (ascent + descent + line_gap) - line_gap

So you definitely need more control than just one. Here's a picture:

I just realized that we have an additional line_spacing that is added in the middle, separately from line_gap. So my formula and picture above are not complete. But the point is, those three numbers, ascent, descent, and line_gap currently come from the font. We need a way to fully remove dependence on the font to give you what you are asking for.

I'll take a look at CSS and see what I like to propose. My previous proposal of just adding --ascent and --descent was assuming that providing --line-spacing replaces line_gap, but I checked the code now and it doesn't. So is a bit more involved.

Alternatively we can add --font-extents=ascent:descent:line_gap. That matches hb_font_extent_t much better.

[danburzo]

I think you're just using the wrong term.

Yes, in retrospect, I have no idea why I went for the CSS term 😅.

And @behdad, thank you for taking the time for the additional explanations.

We need a way to fully remove dependence on the font to give you what you are asking for.

My proposal was altering the formulas (i.e. imposing a baseline position) when there's a --line-height argument present.

For the position of baselines, from:

baseline[i] = ascent + i * (ascent + descent + line_gap)
to:
baseline[i] = (i+1) * line_height

For the height of the image, from:

height = n * (ascent + descent + line_gap) - line_gap
to:
height = n * line_height + descent

It may not be the best name for an option, nor the ideal, most flexible, approach to only send the sum of font extent values (can I call it leading?). I had more modest requirements — images of fonts with their baselines aligned. For that, and nothing more, I believe(d) a single, fixed leading could suffice. That being said, I'm totally ready to not waste your time further, if it turns out I'm still none the wiser after your explanations.

Going back to your suggestion of specifying explicit font extents, it indeed provides a better mapping to existing concepts while also ensuring that:

• the resulting images have the same height;
• the desired ascent (which really controls the space on top of the image) is independently specified from the desired leading.