513295 - Support old DBCS fonts (embedded bitmaps, non-unicode charmaps)

Status: RESOLVED INVALID

(Core :: Graphics, enhancement)

Description

[Peter Weilbacher]

bug 509317 comment 7:
========================================================================
Maybe it's possible to support a embedded bit map font, so called sbit ?

In case of a DBCS glyph, it has a too many strokes. So a small point size glyph
is not readable. To avoid this, some DBCS fonts have embedded bit map glyphs.

If this is supported, we can lead to much more readability.
========================================================================

bug 509317 comment 10:
========================================================================
It's not a bitmap font but a early TTF whose face name is encoded by English
although it's encoded by Korean actually.
========================================================================

From bug 509317 comment 12:
========================================================================
http://www.ecomstation.co.kr/komh/fonts.zip contains three font files. The needed one is 'Sslxys.ttf'.
It doesn't have a unicode char map.
========================================================================

Comment 1

[KO Myung-Hun]

I've encountered a strange problem while making a testcase html.

If I specify Sslxys.ttf as a font face in html, it does not work. But any other fonts work fine. And in other programs, Sslxys.ttf works fine.

I've tested this SeaMonkey v1.1.16 because the higher version does not recognize a face name of Sslxys.ttf correctly.

So I'm afraid it's hard to provide a testcase html.

Finally, an embedded bitmap is not a feature of a old DBCS font only.

Comment 2

[KO Myung-Hun]

Attachment: Add a FC_EMBEDDED_BITMAP pattern support

Adds a FC_EMBEDDED_BITMAP pattern support to FontConfig. Now we are ready to use embedded bitmaps with Cairo.

Can anyone provide a Mozilla build to test to me ?

Comment 3

[Peter Weilbacher]

Comment on attachment 400460 [details] [diff] [review]
Add a FC_EMBEDDED_BITMAP pattern support

Cool, thanks, this looks great! Didn't know about this FC property.

I'll try to provide you with a build as soon as possible. Unfortunately, that could take a few days as I have to set up my OS/2 machine again.

Comment 4

[Dave Yeo]

(in reply to comment #2)
I've uploaded a test build of Firefox trunk built with mozfntcfg patched with attachment 40060 [details]. ftp://ftp.netlabs.org/incoming/mozilla/firefox_DBCS_20090914.zip

Comment 5

[KO Myung-Hun]

(In reply to comment #4)

Wow, it's great. I confirmed. It works as expected.

Thanks for your kindness. ^^

Comment 6

[Peter Weilbacher]

I pushed the patch to the Hg repo of mzfntcfgft, see
http://hg.mozilla.org/users/mozilla_weilbacher.org/mzfntcfgft/rev/9f19e9522c3a

Because the fix for this issue was in the external library, I resolve this bug as invalid (even though it was a good bug report).

Comment 7

[KO Myung-Hun]

But, we've not implemented the support for non-unicode charmaps.

Comment 8

[Peter Weilbacher]

Right, forgot about that.

Comment 9

[Peter Weilbacher]

Attachment: thebes.dll test

This is again a thebes.dll for testing that tries to handle non-unicode charmaps (use with the current SM nightly, 2009091823). But I'm not sure yet, if this makes sense at all. At least all the fonts that have such different charmaps still don't work with this change (SSLXYL.TTF included). But maybe it's just my system or my SeaMonkey setup.

Comment 10

[Peter Weilbacher]

Attachment: do it?

This would be the patch to do the change.

But note that the patch for the test DLL I just attached contains lots of extra debugging printf()s for diagnosis. It could be a bit slow for normal operation.

Comment 11

[KO Myung-Hun]

(In reply to comment #9)
That's too bad. It does not work on my system.

And I recommend to iterate charmaps from a last elements because some fonts have a 'Apple Roman' encoding at first.

Although I think it would be better to find a charmap based on the current 'LANG' before a brutal matching.

In addition, I think you should convert a code to a proper one to the encoding so that you get a valid glyph index.

Maybe, UTF-16 to the encoding.

Comment 12

[Peter Weilbacher]

How did you test that it doesn't work? It would be so much easier if I could just test myself! Which webpages would improve (how?) if it would work?

Comment 13

[KO Myung-Hun]

You can compare the glyph of 'Times New Roman MT 30' or 'Times New Roman WT K'.

If you uncheck 'Allow documents to use other fonts' and set 'Serif' or 'Sans-Serif' to 'SSLXYL.TTF'

And view 'http://www.naver.com'. Then change the fonts to 'Times New Roman MT 30' or 'Times New Roman WT K'. Nevertheless if you see the same glyph, we can determine it does not work.

Comment 14

[Peter Weilbacher]

I'll probably not be able to work on any bugs in the near future.

Comment 15

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 16

[Daniel Bodea [:danibodea]]

(In reply to Peter Weilbacher from comment #9)

This is again a thebes.dll for testing that tries to handle non-unicode
charmaps (use with the current SM nightly, 2009091823). But I'm not sure
yet, if this makes sense at all. At least all the fonts that have such
different charmaps still don't work with this change (SSLXYL.TTF included).
But maybe it's just my system or my SeaMonkey setup.

How do I confirm the bug with this file? How do I verify it in case it gets fixed?
Can you write a list of detailed steps to reproduce with actual and expected results, please?

Comment 17

[Peter Weilbacher]

This is an old bug from the time when some people still tried to support OS/2. Not sure, if someone still does that, but if so, it's not tracked in this Bugzilla any more. --> invalid