Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#9810 closed bug (fixed)

Set font to wqy-microhei does not take effect

Reported by: mshlyn Owned by: pulkomandy
Priority: high Milestone: R1/beta1
Component: Applications/WebPositive Version: R1/Development
Keywords: WebPositive font display Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

After setting fonts to wqy-microhei, webpositive sitll can not display chinese properly. It seems that the font change does not take effect.

Attachments (5)

screenshot3.png (112.0 KB) - added by mshlyn 6 years ago.
wqy-microhei font does not take effect
Pe.png (156.4 KB) - added by mshlyn 6 years ago.
Pe can display wqy-microhei fine.
screenshot4.png (99.6 KB) - added by mshlyn 6 years ago.
Pe and Tracker can both correctly display chinese using font wqy-microhei
font-family.png (81.8 KB) - added by mshlyn 6 years ago.
Display of WebPositive for different font-family settings.
mutipaste.sh.html (2.9 KB) - added by mshlyn 6 years ago.
html file for font-family.png

Download all attachments as: .zip

Change History (13)

Changed 6 years ago by mshlyn

Attachment: screenshot3.png added

wqy-microhei font does not take effect

Changed 6 years ago by mshlyn

Attachment: Pe.png added

Pe can display wqy-microhei fine.

Changed 6 years ago by mshlyn

Attachment: screenshot4.png added

Pe and Tracker can both correctly display chinese using font wqy-microhei

comment:1 Changed 6 years ago by mshlyn

By the way, this can be reproduced both on r1alpha4.1 and latest nigthly build.

comment:2 Changed 6 years ago by axeld

The user guide specifically requests its font, so it's possible that Web+ finds and uses it instead of going with the default font. So that's probably not a bug. However, the base problem is the app_server that still does not support using a font (or several ones for different Unicode blocks) as base font to show missing characters in other fonts.

Changed 6 years ago by mshlyn

Attachment: font-family.png added

Display of WebPositive for different font-family settings.

comment:3 Changed 6 years ago by mshlyn

According to font-family.png, It seems that the app_server does using a font as base font. But the base font is not complete for Chinese characters. Is monospace the base font?

Changed 6 years ago by mshlyn

Attachment: mutipaste.sh.html added

html file for font-family.png

comment:4 Changed 6 years ago by pulkomandy

Milestone: R1/beta1
Owner: changed from leavengood to pulkomandy
Priority: lowhigh
Status: newin-progress
Version: R1/Development

comment:5 Changed 6 years ago by pulkomandy

The app_server has limited font overlay support. When the selected font lacks a glyph, it will look in the VL Gothic font. This was implemented as a proof of concept, and the Japanese asked first.

We should improve app_server to do the font overlay thing at a higher level, and find a single font it can use for drawing the complete string. This would make sure we get coherent results and use a single font for the whole string.

fontconfig has support for this and may be used for that purpose.

On WebKit side, I merged a patch to improve the font system. Selecting the font in the preferences dialog now works as expected (don't forget to click the Apply button!). It will work for most of your multipaste test, except the cases where the font is forced to "DejaVu Sans" or "DejaVu Serif". This means the user guide still fails rendering.

I hope this makes things much better for you. I think the remaining issues should be fixed on app_server side, if we want so, and in the User Guide CSS.

Last edited 6 years ago by pulkomandy (previous) (diff)

comment:6 Changed 5 years ago by pulkomandy

Resolution: fixed
Status: in-progressclosed

Seems to work now. You may have to restart the browser for the new font to be used. If CSS stylesheets still force another font, there isn't much we can do...

comment:7 in reply to:  5 Changed 4 years ago by roytam1

Replying to pulkomandy:

The app_server has limited font overlay support. When the selected font lacks a glyph, it will look in the VL Gothic font. This was implemented as a proof of concept, and the Japanese asked first.

We should improve app_server to do the font overlay thing at a higher level, and find a single font it can use for drawing the complete string. This would make sure we get coherent results and use a single font for the whole string.

fontconfig has support for this and may be used for that purpose.

On WebKit side, I merged a patch to improve the font system. Selecting the font in the preferences dialog now works as expected (don't forget to click the Apply button!). It will work for most of your multipaste test, except the cases where the font is forced to "DejaVu Sans" or "DejaVu Serif". This means the user guide still fails rendering.

I hope this makes things much better for you. I think the remaining issues should be fixed on app_server side, if we want so, and in the User Guide CSS.

I wonder if we can just replace VL Gothic font with for example Droid Sans Fallback so not just Japanese but whole CJK glyphs are all covered.

comment:8 Changed 4 years ago by pulkomandy

This would not be enough, because some glyphs have the same codepoint but should look different in different languages. So, there would be something on screen, but it wouldn't look right.

Also, is the license ok, and is the font not too big?

Note: See TracTickets for help on using tickets.