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

NEW
Unassigned

Status

()

Core
Graphics
--
enhancement
9 years ago
8 years ago

People

(Reporter: Peter Weilbacher, Unassigned)

Tracking

Trunk
x86
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
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.
========================================================================
(Reporter)

Updated

9 years ago
Severity: normal → enhancement

Comment 1

9 years ago
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

9 years ago
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 ?
(Reporter)

Comment 3

9 years ago
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

9 years ago
(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

9 years ago
(In reply to comment #4)

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

Thanks for your kindness. ^^
(Reporter)

Comment 6

9 years ago
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

Comment 7

9 years ago
But, we've not implemented the support for non-unicode charmaps.
(Reporter)

Comment 8

9 years ago
Right, forgot about that.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 9

9 years ago
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
(Reporter)

Comment 10

9 years ago
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.

Comment 11

9 years ago
(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.
(Reporter)

Comment 12

9 years ago
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

9 years ago
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.
(Reporter)

Comment 14

8 years ago
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.