Simon McVittie <s...@debian.org> (2021-05-19): > It wasn't obvious to me where we'd keep track of this, or how correct > it would be to do that - cache invalidation is reputed to be one of the > hardest problems in computer science, and this would be one more thing > that needs to be invalidated on at least those occasions when the layout > has legitimately changed (but without invalidating it too often because > that would destroy the workaround). > > Having reproduced the English/rescue issue and got further with the > Sinhala/install issue with the GTK MR referenced below, I think it can > also happen that the layout flaps by an amount greater than 1 pixel > (I think the most I've seen is 4px), so a special case for n/n+1 isn't > going to be enough. > > One of the reasons this took me a while is that I got distracted by the > difference I was seeing being exactly 1px, which I thought might be to > do with GTK adding 1px of extra width to make sure there's space for a > cursor - but after tracing through it, it seemed like GTK is always > adding/removing that width correctly.
Looking at the traces I saved when installing in Swedish with just the GTK patch, I'm seeing a bunch of 1px to 4px differences, but it can even reach 8px! […] we asked Pango to wrap text for width 186px but it now wants 194px. Clamping result to 186px! > > > My next thing to get a try when I get a chance will be to make GTK > > > refuse to obey Pango when GTK asks Pango to stick to a width limit > > > and Pango goes outside that limit, with a g_warning(). > > This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2 > > The other thing I wanted to try was to make cdebconf create the > GtkTextView in an empty state, and then populate it with text a little > later (perhaps after layout but before drawing, or perhaps drawing one > frame without text and then adding the text in the next frame, I'm not > actually sure). And that also works: > https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6 > > Following the rule of thumb that bad interactions between two > components should often be fixed on *both* sides, I'd be tempted to > clone this bug, reassign to both gtk+2.0 and cdebconf, and apply both > changes. That looks good to me, I'll do so in a moment, and deal with (re)trying to understand everything going on with your patch before merging and uploading. > As for Pango, I'm afraid figuring out whether it is doing something > wrong here is beyond my expertise. If I can characterize the maybe-bug > in a clear enough way I can try asking upstream - but as I said > before, upstream will be very reluctant to touch this as soon as I > mention GTK 2, which has been on life-support for a decade and is now > officially dead. As mentioned before, GTK 2 has been working just fine for us… until it no longer did. It's *very*hugely*appreciated* that you've helped us that much this time around. We'll do the work next time, and I don't think it's important enough to try and dive into Pango some more at this stage, unless someone experiences similar issues with a hrm more recent and supported toolkit version… Thanks again, you're a lifesaver! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature