Re: Bug#956612: libpango-1.0-0: broken kerning since 1.44

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2020-06-26 at 00:16 +0200, Cyril Brulebois wrote:
> I thought severity was higher than that. Reasoning for serious is that
> rendering looks ***bad*** plus this breaking d-i's automated testing.
> 
> I'm told desktop users also suffer from that (cc-ing Corsac for a
> possible confirmation).

Yes indeed. If it's not possible to investigate this in Debian, at least
pushing it upstream would be nice.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl71p8IACgkQ3rYcyPpX
RFuB6Af/SYmXSjTqDnU48+e1v5E3Egk//1V+B5M93gn/4dvT1pZZS8klwQxc6obP
jcRYYHfyocyo78XMCdUPy5msTlxBawUrrk4y36JkkJxtPRtQg3QdIQLWvTAnyWyR
DHGGQqrqKbwhHoROom17wem8m5GxABG0BjFgET8YzfydMj+RsYVEgLCku/M7HiHB
d00jC3ReLR/2n019TW3YKVdpPmwmqcmY/EG9iZ/ZeJybD5M44cgonzSqpD3JbfOc
IxWkz3OWKhjeEUroIeCOPTF4ice5dMqI8niFFXuMflNW4XBfESVoJ3SuFKIXt5FV
p8ewCTGoMmgdLKNWMtYs1gabishdkA==
=O2NX
-END PGP SIGNATURE-

Re: Bug#956612: libpango-1.0-0: broken kerning since 1.44

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/pango/-/issues/404

On Fri, 26 Jun 2020 at 09:46:10 +0200, Yves-Alexis Perez wrote:
> On Fri, 2020-06-26 at 00:16 +0200, Cyril Brulebois wrote:
> > I thought severity was higher than that. Reasoning for serious is that
> > rendering looks ***bad*** plus this breaking d-i's automated testing.
> > 
> > I'm told desktop users also suffer from that (cc-ing Corsac for a
> > possible confirmation).
> 
> Yes indeed. If it's not possible to investigate this in Debian, at least
> pushing it upstream would be nice.

There are several upstream bugs open about font rendering being different
in 1.44.x. It probably doesn't help that many of them can be summarized
as "fonts look bad now" rather than something more specific, leading to
it being difficult to tell what the problem is or when/whether it has
been fixed.

The extent to which font rendering differs between pango 1.42 and
1.44 depends on the font, hinting settings and probably other factors,
leading to the impact of this bug varying between "not noticeable" and
"difficult to read" depending on those various factors. I haven't noticed
this being a problem in GNOME, which might mean that fonts-cantarell is
one of the unaffected fonts, or might be to do with my font settings.

https://gitlab.gnome.org/GNOME/pango/-/issues/404 is probably the closest
match among upstream issues. Comments from an upstream developer indicate
that there is a behaviour change in pango involving harfbuzz and cairo:

> The underlying change here is that we are now getting glyph extents
> via harfbuzz, instead of via cairo.
>
> For glyph 78 in that output above, cairo returns 3072 and harfbuzz 3652,
> which we then round to 4096, so we end up wiht a one-pixel difference.

This is presumably measuring in some internal unit that is a small
fraction of a pixel, with actual sizes having to be rounded to the
nearest whole pixel if subpixel positioning is not used.

https://github.com/harfbuzz/harfbuzz/issues/1892 appears to be related. A
comment on that issue suggests that the way forward for pango involves
getting an upstream cairo release out, possibly so that pango and
cairo agree on the way they use harfbuzz (same hinting settings, etc.),
or so that text can be rendered with subpixel positioning so the rounding
becomes unnecessary? (This is really not my area of expertise, so I might
be entirely wrong about this, and I am not the right person to be
developing a patch.)

smcv

Re: Bug#956612: libpango-1.0-0: broken kerning since 1.44

[Tomas Janousek]

Hi,

On Fri, Jun 26, 2020 at 10:53:09AM +0100, Simon McVittie wrote:
> https://github.com/harfbuzz/harfbuzz/issues/1892 appears to be related. A
> comment on that issue suggests that the way forward for pango involves
> getting an upstream cairo release out, possibly so that pango and
> cairo agree on the way they use harfbuzz (same hinting settings, etc.),
> or so that text can be rendered with subpixel positioning so the rounding
> becomes unnecessary? (This is really not my area of expertise, so I might
> be entirely wrong about this, and I am not the right person to be
> developing a patch.)

I'd gotten the same impression when I read these comments a few weeks/months
ago, but it turns out the situation isn't as optimistic as that. The only
thing that a new release of cairo brings is the possibility to enable subpixel
positioning in pango, but that's just a possibility, nothing more, no change
in behaviour, no fix, nothing.

The core of the issue with pango is that in 1.44 they dropped support for full
horizontal hinting, presumably because pango (and cairo) is largely
unmaintained:
https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/#:~:text=Unhinted%20rendering

Chromium and Firefox (via the Skia library) and Qt still support full hinting,
but gtk (via pango/cairo) no longer does, and probably never will as there
aren't any developers willing to maintain that support.

The point of full hinting is to both align the glyphs to the pixel grid and
change the glyph shape to align individual stems to the pixel grid as well, in
order to obtain sharp rendering with minimal need for antialiasing. The
downsides of this approach are described in detail in this document:
https://docs.google.com/document/d/14IQEWrVS0wydzpTAMbvJep7HnX9t-ljuxFwTToSbOVk/edit
From my personal experience as a user, the primary downside is that kerning is
often suboptimal (rn sometimes looks like m, that sort of stuff) but the
sharpness of text is so good that the suboptimal kerning seemed to be a minor
issue for me for many years. It's also worth noting that to obtain really
sharp text, one also needs to set 
FREETYPE_PROPERTIES="truetype:interpreter-version=35".
For interested readers, there's a lot more (possibly outdated) info at
https://pandasauce.org/post/linux-fonts/.

Anyway, in pango 1.44 full hinting is no longer supported (results in abysmal
kerning/glyph placement, as the glyphs are positioned without applying hinting
to adjust the stem positions and thus glyph width, but then rendered using the
hinted glyphs). The only officially supported way forward is to disable full
hinting and retrain your eyes and brain to the new rendering of fonts. The
good news is that by disabling full (horizontal) hinting, kerning is improved
significantly.

Or… to be more precisue, kerning _would_be_ improved significantly, if
subpixel positioning was enabled as well. This is a good idea now as neither
the glyphs themselves nor the stems in them are aligned to the pixel grid, and
the rendering relies on (subpixel) antialiasing and LCD filtering (to make it
look sharp enough yet without color artifacts), so it doesn't really matter
which of the three color subpixels a glyph is positioned to, it will always
look almost the same (more blurry than full hinted, but also more like the
font designer intended, more like a larger size version of itself, etc.).

The bad news is that subpixel positioning is only supported in cairo git, and
there's no knob to enable it in pango/gtk. The good news is that Chromium,
Firefox and Qt do not have this problem and will use subpixel positioning as
soon as full hinting is disabled. There may some bugs here and there, so
there are knobs in e.g. about:config that make it possible to force this, but
the functionaly is there, as opposed to pango/gtk. The wiring of subpixel
positioning in pango/gtk is "tracked" here:
https://gitlab.gnome.org/GNOME/gtk/-/issues/7#note_795665

I really wanted to have subpixel positioning everywhere, so I built a cairo
package from a git snapshot (https://salsa.debian.org/liskin/cairo) and
created a shared library hack to force-enable subpixel positioning in cairo:
https://github.com/liskin/dotfiles/tree/e64efabf6db10a7e57f49b844f66a0d8331a0e5c/src/pango-force-subpixel-positioning
https://github.com/liskin/dotfiles/blob/e64efabf6db10a7e57f49b844f66a0d8331a0e5c/.bashrc.d/10_env.sh#L15
It's ugly and doesn't work with apparmor-protected apps like evince. Patching
and rebuilding pango might be a better option, actually. But I've been using
it for the last 2 months and it's nice that gtk apps like liferea render fonts
as good as the browser does.

More importantly, this is only relevant once you accept that full hinting is
gone, freetype interpreter v35 is gone, fonts will be more blurry than they
were your entire life, and you just want to make the most out of "kerning
might be a bit better now". Now that I think about it, switching away from gtk
apps might have been a better id

Bug#963755: installation-report: fails to boot with Gnome DE

[Ambroise Grau]

Package: installation-reports
Version: 2.71
Severity: grave
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
Booting the debian after installation, hangs at loading Gnome DE.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? 
Launched rescue mode, verified partition table and launched
interractive shell to verify logs.
   * What was the outcome of this action?
Partition table is as expected, shell works as expected, logs
indicate no obvious error.
   * What outcome did you expect instead?
Expected Debian to boot directly.



-- Package-specific info:

Boot method: USB floppy disc
Image version: 64-bit PC netinst iso, downloaded 2020/06/23, 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
Date: 

Machine: GameMax desktop
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[E]

Comments/Problems:
The boot loader installed properly, detected the other OS present
(Windows 10) but failed to write the boot table correctly so that
only debian appears there.
Launching debian hangs after loading the Gnome DE in normal mode, recovery mode 
works fine.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u4"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux GM-Debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0100] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V 
Gigabit Network Connection [8086:1503] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series 
Chipset Family High Definition Audio Controller [8086:1c20] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation H61 Express Chipset 
Family LPC Controller [8086:1c5c] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 
Series Chipset Family SATA AHCI Controller [8086:1c02] (rev 05)
lspci -knn: Subsystem: Intel Corporation Device [8086:2017]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series 
Chipset Family SMBus Controller [8086:1c22] (rev 05)
lspci -knn: Subsystem: 

Bug#963755: Fix that worked for me

[Ambroise Grau]

Hi, 

I realised the problem could come from the graphical interface loaded by Gnome, 
since Debian was able to start in recovery mode. For a strange reason I could 
not
configure my ethernet connection properly in that mode and had therefore not 
the possibility to download install drivers using apt (sideloading it was 
working but
the drivers I needed where too complicated to get that way).

In order to install all the firmware for my graphic card (nvidia GTX 1650) I 
entered
the rescue mode and followed all the steps of the setup leading to the selection
of the partition of the root file system to repair. Taking advantage of the 
hardware 
detection and settings run by the installer to have a working ethernet 
connection, 
I launched a shell in the target debian root file system and I was then able to 
set 
`apt` to get the firmware needed and install them. I was then able to reboot 
into
Debian with the full Gnome desktop environment.

Regarding Grub that noticed the Windows partition at installation, but did not 
write
it on the boot table, a simple `update-grub` from the recovery mode fixed it, 
and I
did not have to configure the menu.lst file as suggested in the FaQ 
(https://wiki.debian.org/DebianInstaller/FAQ#Q:_What_do_I_do_if_I_can_no_longer_boot_Windows_after_installing_Debian.3F
 

 ).

This therefore raises two questions from my part:
1/ Is Grub not updated after writing the new boot loader to the MBR?
2/ Would it be possible at the final step of the installation, just before the 
reboot,
to allow the use of a shell running in the newly created debian file system in 
order to install additional firmware that could not be loaded in another way 
and 
that are needed for some DE for example? 
(In my questions I am referring to the graphical installer in standard mode, as
I don’t feel confident enough to use the expert mode, and thus don’t know if 
this
is already accessible in that mode).


Apart from this, many thanks it worked great!

Ambroise