Truncating on right for wide glyphs

[drj11]

I can barely believe this is possible as i am typing this, it seems much more likely that some simple but obscure config has been flipped.

It seems that hb-view version 6.0.0 is truncating wide-glyphs on the right, at the right-hand end of lines. They are truncated at essentially one UPEM box from the final glyph's origin point (or as close to that as i can tell without digging into any code).

Lifting from my typo.social post: https://typo.social/@drj/109722147274855966

This is ‰ displayed using overpass-regular.otf from https://overpassfont.org/

[behdad]

Humm. Doesn't reproduce for me.

[behdad]

Does the same happen if you skip the "| kitty icat"? What if you redirect the output to a PNG file?

[khaledhosny]

No repro here either

[khaledhosny]

OK, I can reproduce with 6.0.0 (at least homebrew binaries).

[drj11]

so it's a homebrew and/or 6.0.0 problem?

FWIW, the SVG is wrong too, there is a clipPath:

; hb-view --output-format=svg --unicodes=2030,2030 overpass-regular.otf
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="675.0625pt" height="288pt" viewBox="0 0 675.0625 288" version="1.1">
<defs>
<g>
<symbol overflow="visible" id="glyph0-0">
<path style="stroke:none;" d="M 54.527344 -91.136719 C 85.246094 -91.136719 95.488281 -116.992188 95.488281 -136.703125 C 95.488281 -158.464844 84.480469 -182.273438 54.527344 -182.273438 C 24.0625 -182.273438 13.3125 -156.414062 13.3125 -136.703125 C 13.3125 -115.199219 24.320312 -91.136719 54.527344 -91.136719 Z M 60.929688 3.070312 L 183.296875 -182.273438 L 161.792969 -182.273438 L 39.425781 3.070312 Z M 54.527344 -108.800781 C 39.425781 -108.800781 32.511719 -120.574219 32.511719 -136.703125 C 32.511719 -152.0625 39.167969 -164.609375 54.527344 -164.609375 C 69.121094 -164.609375 76.542969 -153.089844 76.542969 -136.703125 C 76.542969 -121.855469 69.375 -108.800781 54.527344 -108.800781 Z M 168.191406 3.070312 C 199.167969 3.070312 209.40625 -22.785156 209.40625 -42.496094 C 209.40625 -64.257812 198.398438 -88.0625 168.191406 -88.0625 C 137.984375 -88.0625 127.230469 -62.207031 127.230469 -42.496094 C 127.230469 -20.992188 138.238281 3.070312 168.191406 3.070312 Z M 267.007812 3.070312 C 297.984375 3.070312 308.222656 -22.785156 308.222656 -42.496094 C 308.222656 -64.257812 297.214844 -88.0625 267.007812 -88.0625 C 236.800781 -88.0625 226.046875 -62.207031 226.046875 -42.496094 C 226.046875 -20.992188 237.054688 3.070312 267.007812 3.070312 Z M 168.191406 -14.59375 C 153.34375 -14.59375 146.175781 -26.367188 146.175781 -42.496094 C 146.175781 -57.855469 153.089844 -70.398438 168.191406 -70.398438 C 183.039062 -70.398438 190.207031 -58.878906 190.207031 -42.496094 C 190.207031 -27.648438 183.296875 -14.59375 168.191406 -14.59375 Z M 267.007812 -14.59375 C 252.160156 -14.59375 244.992188 -26.367188 244.992188 -42.496094 C 244.992188 -57.855469 251.902344 -70.398438 267.007812 -70.398438 C 281.855469 -70.398438 289.023438 -58.878906 289.023438 -42.496094 C 289.023438 -27.648438 282.113281 -14.59375 267.007812 -14.59375 Z M 267.007812 -14.59375 "/>
</symbol>
</g>
<clipPath id="clip1">
  <path d="M 29 25 L 594 25 L 594 212 L 29 212 Z M 29 25 "/>
</clipPath>
</defs>
<g id="surface1">
<rect x="0" y="0" width="675.0625" height="288" style="fill:rgb(100%,100%,100%);fill-opacity:1;stroke:none;"/>
<g clip-path="url(#clip1)" clip-rule="nonzero">
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
  <use xlink:href="#glyph0-0" x="16" y="208"/>
  <use xlink:href="#glyph0-0" x="337.53125" y="208"/>
</g>
</g>
</g>
</svg>

Thanks for the extremely quick investigation!

[khaledhosny]

But I can’t reproduce with self-built 6.0.0, perhaps Cairo issue?

Yup, HB_DRAW=0 fixes it with homebrew binaries.

[behdad]

More possible that it's a cairo problem. With 6.0.0 on Linux still no repro.

[behdad]

Ah yeah, cairo user-font clipping issue.

[behdad]

What cairo version is that?

We need a cairo release... @matthiasclasen

[khaledhosny]

$ brew info cairo
==> cairo: stable 1.16.0 (bottled), HEAD

[khaledhosny]

Wow, that is 4 years old. Is Cairo still following even releases are stabled, odd releases are unstable numbering scheme? If not people might have missed the memo.

[drj11]

Right, so thanks for HB_DRAW=0; setting that environment variable fixes it. Approximately what does it do?

[behdad]

Wow, that is 4 years old. Is Cairo still following even releases are stabled, odd releases are unstable numbering scheme?

Not really. These days we advise using whatever micro release we can get @ebassi or someone to make.

[behdad]

Right, so thanks for HB_DRAW=0; setting that environment variable fixes it. Approximately what does it do?

Previously we were using cairo-ft, the Cairo FreeType font backend to render things. HB_DRAW=0 enables that old code path.

More recently, we switched to using the Cairo user-font backend in combination with the hb-draw API for rendering, sidestepping FreeType. This uses HarfBuzz for fetching the glyph outlines instead, but exposes bugs in the Cairo user-font backend, which is something I wrote back in 2008 but was not heavily used by anyone until now.

[khaledhosny]

Wow, that is 4 years old. Is Cairo still following even releases are stabled, odd releases are unstable numbering scheme?

Not really. These days we advise using whatever micro release we can get @ebassi or someone to make.

Apparently, 1.16.0 is the latest release uploaded to https://cairographics.org/releases/

[behdad]

Wow, that is 4 years old. Is Cairo still following even releases are stabled, odd releases are unstable numbering scheme?

Not really. These days we advise using whatever micro release we can get @ebassi or someone to make.

Apparently, 1.16.0 is the latest release uploaded to https://cairographics.org/releases/

For a while no one had access there apparently! Distros use git tags I think. Or alternatively you can for now point Brew people to:
https://download.gnome.org/sources/cairo/1.17/

[behdad]

@khaledhosny I had forgotten about this bug. Maybe we should set the default draw back to cairo-ft again based on cairo version.

[khaledhosny]

Wow, that is 4 years old. Is Cairo still following even releases are stabled, odd releases are unstable numbering scheme?

Not really. These days we advise using whatever micro release we can get @ebassi or someone to make.

Apparently, 1.16.0 is the latest release uploaded to https://cairographics.org/releases/

For a while no one had access there apparently! Distros use git tags I think. Or alternatively you can for now point Brew people to: https://download.gnome.org/sources/cairo/1.17/

https://gitlab.freedesktop.org/cairo/cairo/-/issues/622#note_1732239

[khaledhosny]

@khaledhosny I had forgotten about this bug. Maybe we should set the default draw back to cairo-ft again based on cairo version.

I think so, given that Cairo made no stable release in the past 4 years...

[drj11]

Adding export HB_DRAW=0 to my .profile lol

[behdad]

@khaledhosny I had forgotten about this bug. Maybe we should set the default draw back to cairo-ft again based on cairo version.

I think so, given that Cairo made no stable release in the past 4 years...

Now onto which version to require...

[matthiasclasen]

We'll hopefully get a cairo 1.17.7 any day now, and 1.18 soon thereafter.