Set font to wqy-microhei does not take effect

[mshlyn]

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

[mshlyn]

wqy-microhei font does not take effect

[mshlyn]

Pe can display wqy-microhei fine.

[mshlyn]

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

[mshlyn]

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

[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.

[mshlyn]

Display of WebPositive for different font-family settings.

[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?

[mshlyn]

html file for font-family.png

[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.

[pulkomandy]

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...

[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.

[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?