Bug 14743 - FE characters draw as white box (Tofu) after MLang's HFONT cache is full
Summary: FE characters draw as white box (Tofu) after MLang's HFONT cache is full
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 523.x (Safari 3)
Hardware: PC Windows XP
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar, PlatformOnly
Depends on:
Blocks:
 
Reported: 2007-07-24 02:33 PDT by 808caaa4.8ce9.9cd6c799e9f6
Modified: 2007-09-17 17:44 PDT (History)
3 users (show)

See Also:


Attachments
Issue reproduction html, filling mlang's cache at one go (1.64 KB, text/html; charset=Shift_JIS)
2007-07-24 02:36 PDT, 808caaa4.8ce9.9cd6c799e9f6
no flags Details
Resulting screenshot. (15.52 KB, image/png)
2007-07-24 02:37 PDT, 808caaa4.8ce9.9cd6c799e9f6
no flags Details
Reference, screenshots, with 'hacked' mlang.dll, see comments (14.44 KB, image/png)
2007-07-24 02:42 PDT, 808caaa4.8ce9.9cd6c799e9f6
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description 808caaa4.8ce9.9cd6c799e9f6 2007-07-24 02:33:36 PDT
related: bug#14601

After using Safari/WebKit for a while, white boxes appeared at the position of
FE chars. This time, is not encoding problem, since some part of FE strings
are drawed correctly.

At that time, langFontLink->MapFont() returns E_INVALID, and 
FE font mapping does not succeeded. It's not for invalid argument.
Even arguments intact, this error may occure.

Today some pages depends on MapFont(), and cousumes mlang's internal cache.
With IDE disassembly pane, MapFont() seems have very small font cache entries,
probably only 16, << if we call MapFont with 2nd argument nonzero. >>
If all of entries occupied once, they seems simply return with error
for every new custom fonts creation after that.
// Applies for mlang.dll, v6.0.2900.2180, deployed with XPSP2.
// By MS DLLDB online, WindowsServer2003 SP's mlang is newer, but not tested.
// Cache entry have internal refcount for each, and
// with ReleaseFont(), cache entry is reused (as documented in MSDN.)

See attached example again, some middle of body is rendered.
It's explicit-specified to 'Lucida Grande' part, 
it's cached previously at the time of drawing UI.

I don't know what to do about this concisely,
or whether we should use MapFont() with specify 0 in argument#2,
or whether we should cache by the MapFont's param rather than MapFont's result,
once suspected at bug#14601.
Comment 1 808caaa4.8ce9.9cd6c799e9f6 2007-07-24 02:36:51 PDT
Created attachment 15657 [details]
Issue reproduction html, filling mlang's cache at one go
Comment 2 808caaa4.8ce9.9cd6c799e9f6 2007-07-24 02:37:56 PDT
Created attachment 15658 [details]
Resulting screenshot.
Comment 3 808caaa4.8ce9.9cd6c799e9f6 2007-07-24 02:42:43 PDT
Created attachment 15659 [details]
Reference, screenshots, with 'hacked' mlang.dll, see comments

Experimental/reference only.
With mlang.dll, 'hacked' as internal cache slots 16 to 128,
resulting is without Tofus (white cubes).
Comment 4 808caaa4.8ce9.9cd6c799e9f6 2007-07-24 02:59:30 PDT
Online reproduction.

1. With google searchbox, search 'アップル' 
2. Find and open http://ja.wikipedia.org/wiki/アップルコンピュータ . 
3. White boxed starts appeared at left, but main contents drawed collectly.
4. Restart safari process.
5. Reopen http://ja.wikipedia.org/wiki/アップルコンピュータ .
6. This time whole texts drawed collectly.

With #3 hacks (to mlang) experimentally, whole drawed OK at Step3.

'アップル': Apple, in Japanese Katakana form.
'アップルコンピュータ': Apple Computer, in Japanese Katakana form.
Comment 5 Alexey Proskuryakov 2007-07-24 06:45:54 PDT
With both beta 3.0.2 and nightly r24441, I'm getting similar, but somewhat different results when opening the attached test case: all characters are displayed as white boxes. Same on ja.wikipedia.org (Roman and Cyrillic characters are displayed correctly).

Maybe that's because I'm using an English version of Windows XP.
Comment 6 David Kilzer (:ddkilzer) 2007-07-24 07:28:10 PDT
<rdar://problem/5356812>
Comment 7 David Kilzer (:ddkilzer) 2007-07-24 07:30:32 PDT
Comment on attachment 15657 [details]
Issue reproduction html, filling mlang's cache at one go

><meta http-equiv="content-type" content="Shift_JIS">

For future reference, this should be:

<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">

However, this only affects loading the file locally (from disk).
Comment 8 Dave Hyatt 2007-09-17 17:44:52 PDT
Fixed in r25611.  Long term we may want to remove MLang completely.