I'm using Debian Linux (sid/unstable). Currently, Debian provides epiphany-webkit version 2.27.1-2 in sid, which uses webkitGTK+1.1.7. The problem I encountered is that epiphany-webkit has not inconsistent font selection behavior compared with other GTK2 apps when epiphany-webkit is rendering web pages containing Chinese characters.
To be specific, we consider a freshly setup Debian Linux with packages ttf-arphic-uming and ttf-arphic-ukai installed. These two packages provide Chinese fonts: AR PL UMing and AR PL UKai. These packages also installed fontconfig configuration files which contain the instructions to prefer to AR PL UMing when Chinese characters are rendered through fontconfig. That is, when a typical GTK2 app needs display some Chinese characters (not covered by the system's default font DeJaVu Sans), AR PL UMing font will be selected. Such a behavior is consistent in both GTK2 and QT4 apps.
But in epiphany-webkit, a GTK2 app using webkit, this behavior is no longer consistent. For example, when we open a web page, like www.google.com.hk, AR PL UKai will be used instead to render the Chinese characters. As another example, when www.xinhuanet.com is accessed, AR PL UKai is also selected instead of AR PL UMing.
So, I wonder if there is a bug in webkitGTK+ so that epiphany-webkit does not fully respect fontconfig's configurations.
Created attachment 32682 [details]
Patch to fix QuickTime/X11 namespace conflict
(In reply to comment #1)
> Created an attachment (id=32682) [details]
> Patch to fix QuickTime/X11 namespace conflict
Also, epiphany guys cc'ed
ps: patch looks unrelated and is in so bad shape (lack of commit message and explaination, lack of context, etc).
Is this still an issue? A lot has changed with font selection. If you notice some inconsistency between Chromium/Firefox and WebKitGTK+, I'd be very interested to fix it.
I see Chromium and Firefox selecting the same font that WebKitGTK+ does in the situation listed above. If this is not truly the case or there is some further issue, feel free to reopen this bug. I think it may be fixed now though.