Recent changes to 2194: wxt terminal messing around with any label (MacOSX)

#2194 wxt terminal messing around with any label (MacOSX)

2020-06-02T17:41:00.271000Z

So far as I can tell this is a slow-moving train wreck upstream. See discussion here:
https://github.com/harfbuzz/harfbuzz/issues/2394#issuecomment-626254448

I really don't know what is going to come out of this moving forward. It seems that the primary developers have decided that it is more important to support new fonts on extremely high-resolution displays than it is to support old fonts on what you and I would consider a "normal" display. Maybe upstream distros will fork and maintain an older (working) version of pango? Maybe they will at least provide a list of supported vs unsupported fonts? Maybe some backwards-compatibility setting will be added to the library?

My understanding of the detailed nature of this problem is limited. I gather it is largely due to harfbuzz not handling hinting. So perhaps disabling hinting would fix or improve things for you, a considerably less drastic change than degrading the resolution by 20-fold. Since I don't see the problem here I can't usefully experiment.

Meanwhile if I follow the trail of your earlier bug report to cairo->pango I see that other projects are reporting the same sort of errors from pango 1.44 on OSX:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/520#note_627033

So yes, it's an upstream problem. Possibly we could work around it be turning off hinting, but that would have to be explored by someone who is seeing the problem. Can you do the experiment? What happens if you replace hinting = 100 with hinting = 1 everywhere in .../term/cairo.trm and .../src/wxterminal/gp_cairo.c? Or may hinting=0 ?

#2194 wxt terminal messing around with any label (MacOSX)

2020-06-02T08:58:59.493000Z

@sfeam : a gentle bump on this: would the GP_CAIRO_SCALE fix above mean that it's not an upstream bug?

#2194 wxt terminal messing around with any label (MacOSX)

2020-04-06T12:52:59.691000Z

I could get rid of the artifact by changing line 84 of src/wxterminal/gp_cairo.h
setting GP_CAIRO_SCALE to 1 rather than 20

sed -i '' 's/define\ GP_CAIRO_SCALE\ 20/define\ GP_CAIRO_SCALE\ 1/g' ./src/wxterminal/gp_cairo.h

Could this help in pinning down the problem?

(I'm no more sure it's an upstream bug)

#2194 wxt terminal messing around with any label (MacOSX)

2019-12-17T06:34:14.877000Z

status: open --> open-upstream-bug

#2194 wxt terminal messing around with any label (MacOSX)

2019-09-28T19:48:37.224000Z

summary: wxt terminal messing around with any label --> wxt terminal messing around with any label (MacOSX)
Group: -->
Priority: -->

#2194 wxt terminal messing around with any label

2019-09-09T16:23:29.217000Z

I have lib64pango1.0_0-1.44.6-1.mga8 on Mageia (Cauldron) linux.
No evident problems with fonts for the wxt terminal here.

#2194 wxt terminal messing around with any label

2019-09-09T15:59:59.735000Z

[from pango gitlab issue report]

Can someone confirm this happens only on macos?

Could someone test wxt terminal on linux using latest pango v1.44.6 ?

#2194 wxt terminal messing around with any label

2019-09-09T12:58:07.023000Z

Followup: I posted an issue on the right pango gitlab: https://gitlab.gnome.org/GNOME/pango/issues/422

#2194 wxt terminal messing around with any label

2019-08-30T18:51:37.281000Z

I can confirm that the same problem occurs for the Cairo-based terminals. So your suspicion Pango is the reason seems correct.

(I also posted a question on Stackoverflow that brought me here: https://stackoverflow.com/questions/57698204)

#2194 wxt terminal messing around with any label

2019-08-30T16:08:03.494000Z

Do you see this same problem with the other cairo-based terminals? The wxt pngcairo and pdf terminals all share the same code for text layout.

If so, I wonder if it may be related to a deliberate change in pango to use harfbuzz rather than cairo to obtain font metrics:

https://github.com/harfbuzz/harfbuzz/issues/1892

The issue you see is not exactly the same as the one reported there, but they both result from incorrect reported font metrics.

On the other hand if you see this problem only with wxt and not with pngcairo or pdf, then something else must be involved.