WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
286420
[GTK] Japanese/Simplified Chinese characters should be rendered differently, but are rendered equal
https://bugs.webkit.org/show_bug.cgi?id=286420
Summary
[GTK] Japanese/Simplified Chinese characters should be rendered differently, ...
Deleted User
Reported
2025-01-23 04:30:01 PST
Created
attachment 473983
[details]
Example rendering characters with `lang="ja"` and `lang="zh-CH"` STR: open the attached example. Expected: the characters for `lang="ja"` are rendered differently from the one corresponding to `lang="zh-CH"`. I'm unfamiliar with Japanese/Chinese and base that assumption on
https://searchfox.org/wubkat/rev/cbb8b220c0f1f1ceaf9bac84eafc71dc87f2fc46/LayoutTests/imported/w3c/web-platform-tests/svg/text/reftests/lang-attribute.svg#9
. Actual: the characters are rendered the same. Chrome and Firefox both render them differently. An example where the language attribute correctly affects the rendering in WebKit would be helpful for fixing bug
https://bugs.webkit.org/show_bug.cgi?id=285993
.
Attachments
Example rendering characters with `lang="ja"` and `lang="zh-CH"`
(263 bytes, text/html)
2025-01-23 04:30 PST
,
Deleted User
no flags
Details
rendering in safari, firefox, chrome
(1.13 MB, image/png)
2025-01-23 18:51 PST
,
Karl Dubost
no flags
Details
Rendering with WebKitGTK's MiniBrowser on Ubuntu 24.04.
(43.60 KB, image/png)
2025-01-27 00:43 PST
,
Deleted User
no flags
Details
Rendering with Epiphany on Ubuntu 24.04.
(44.00 KB, image/png)
2025-01-27 00:45 PST
,
Deleted User
no flags
Details
Example with Noto Sans font-family
(303 bytes, text/html)
2025-01-27 00:53 PST
,
Deleted User
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Karl Dubost
Comment 1
2025-01-23 18:51:07 PST
Created
attachment 473994
[details]
rendering in safari, firefox, chrome Mirko, the characters are rendered as expected in all browsers.
Alexey Proskuryakov
Comment 2
2025-01-24 12:51:15 PST
The rendering is indeed different on the attached Safari screenshot.
Deleted User
Comment 3
2025-01-27 00:42:17 PST
They differ with WebKitGtk's MiniBrowser on Ubuntu 24.04.
Deleted User
Comment 4
2025-01-27 00:43:22 PST
Created
attachment 474018
[details]
Rendering with WebKitGTK's MiniBrowser on Ubuntu 24.04.
Deleted User
Comment 5
2025-01-27 00:45:21 PST
Created
attachment 474019
[details]
Rendering with Epiphany on Ubuntu 24.04.
Deleted User
Comment 6
2025-01-27 00:48:24 PST
The screenshot showing different results for Safari indicates the font used by Safari differs from the font used by Firefox and Chrome, shown on the same screenshot.
Deleted User
Comment 7
2025-01-27 00:53:48 PST
Created
attachment 474020
[details]
Example with Noto Sans font-family
Deleted User
Comment 8
2025-01-27 00:54:22 PST
Karl: can you please check with the attached Noto Sans example?
Karl Dubost
Comment 9
2025-01-27 01:25:07 PST
Do you mean locally installed Noto Sans? This will not work because it protects against finger printing. Then after there is the notion of which Noto Sans you are linking to with @font-face
https://fonts.google.com/noto/specimen/Noto+Sans
Noto Sans has different versions according to the language. There is a special Noto CJK (aka Chinese Japanese Korean)
https://github.com/notofonts/noto-cjk
Are you using this one?
Deleted User
Comment 10
2025-01-27 02:01:32 PST
(In reply to Karl Dubost from
comment #9
)
> Do you mean locally installed Noto Sans? > This will not work because it protects against finger printing.
I wasn't aware of the finger-printing issue.
> Then after there is the notion of which Noto Sans you are linking to with > @font-face > >
https://fonts.google.com/noto/specimen/Noto+Sans
> > Noto Sans has different versions according to the language. > > There is a special Noto CJK (aka Chinese Japanese Korean) >
https://github.com/notofonts/noto-cjk
> Are you using this one?
The test uses `font-family: Noto Sans` (see
view-source:https://bug-286420-attachments.webkit.org/attachment.cgi?id=474020
). However, I understand that example may not be applicable to Safari. Still, the issue exists with WebKitGTK, see
https://bugs.webkit.org/attachment.cgi?id=474018
. It also occurs with a local WebKitGTK build with last week's WebKit source.
Alexey Proskuryakov
Comment 11
2025-01-27 09:13:08 PST
Let's track this as a WebKitGTK issue then.
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