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. ========================================================================
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.
Created attachment 400460 [details] [diff] [review] 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 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.
(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
(In reply to comment #4) Wow, it's great. I confirmed. It works as expected. Thanks for your kindness. ^^
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).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
But, we've not implemented the support for non-unicode charmaps.
Right, forgot about that.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Created attachment 401764 [details] 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.
Assignee: nobody → mozilla
Status: REOPENED → ASSIGNED
Created attachment 401765 [details] [diff] [review] 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.
(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.
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?
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.
I'll probably not be able to work on any bugs in the near future.
Assignee: mozilla → nobody
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.
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.