WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 250138
258962
[GTK] Fonts are not rendered metrically equivalent vs other browsers (Firefox / Chrome) at normal font scaling, leading to broken page layouts
https://bugs.webkit.org/show_bug.cgi?id=258962
Summary
[GTK] Fonts are not rendered metrically equivalent vs other browsers (Firefox...
Jeff Fortin
Reported
2023-07-06 21:59:44 PDT
Created
attachment 466965
[details]
Offline HTML page sample test case This may sound like
bug #250987
/
bug #250138
, but it's not the exact same thing, because of one key difference: it manifests at normal (1.00) font scaling. It's more subtle / a potentially more rare occurrence though, so it was harder to spot compared to the other two bug reports. The test case is the front page of
https://themes.tiki.org
That website demonstrates that Epiphany 44.3 / WebKitGTK 2.40.3 renders fonts in an incompatible way that breaks layouts compared to Firefox 115 and Chromium 114, with default font scaling at 1.00x. Since that website might change in the future, I'm attaching not only screenshots, but also an offline HTML version saved using Firefox; Epiphany seems able to open it. As you can see in the attached screenshots, Epiphany renders all the fonts consistently fatter/bigger than other browsers. Firefox and Chromium render the font metrically identically among themselves, WebKitGTK is the outlier, and a ton of website layouts break in various ways when browsed with Epiphany. I was unable to find out why it renders differently in Epiphany vs the rest, given that my font settings are at the defaults. Enlarging the window width or shrinking the zoom level does nothing to improve results with the test case above.
Attachments
Offline HTML page sample test case
(676.98 KB, application/x-xz)
2023-07-06 21:59 PDT
,
Jeff Fortin
no flags
Details
Screenshot comparing Epiphany, Firefox and Chromium's rendering at identical window widths
(652.22 KB, image/png)
2023-07-06 22:00 PDT
,
Jeff Fortin
no flags
Details
Screenshot comparing Firefox's equivalent width required to match WebKitGTK's rendering
(248.56 KB, image/png)
2023-07-06 22:02 PDT
,
Jeff Fortin
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jeff Fortin
Comment 1
2023-07-06 22:00:46 PDT
Created
attachment 466966
[details]
Screenshot comparing Epiphany, Firefox and Chromium's rendering at identical window widths
Jeff Fortin
Comment 2
2023-07-06 22:02:48 PDT
Created
attachment 466967
[details]
Screenshot comparing Firefox's equivalent width required to match WebKitGTK's rendering This screenshot shows the kind of window width shrinking you need to do in Firefox to approximate the broken layout/text wrapping that EpiphanY/WebKitGTK exhibits at 1.00 font scaling.
Jeff Fortin
Comment 3
2023-07-07 07:39:08 PDT
Actually _still_ a duplicate of
bug #250138
; it turns out that the app tricked me I was tricked into believing the font scaling changes were _entirely_ applied live, but they weren't, only _seemed_ like they were, but the changes were partial. After restarting the browser, at font scaling 1.00, the page renders correctly. So it's still a font scaling issue. Sorry for the noise! *** This bug has been marked as a duplicate of
bug 250138
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug