Closed Bug 509317 Opened 15 years ago Closed 15 years ago

DBCS fonts are not supported well: enable emboldening of fonts without bold counterpart

Categories

(Core :: Graphics, defect)

x86
OS/2
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
status1.9.1 --- .4-fixed

People

(Reporter: komh, Assigned: mozilla)

References

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.21) Gecko/20090410 SeaMonkey/1.1.16 Mnenhy/0.7.6.0
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.21) Gecko/20090410 SeaMonkey/1.1.16 Mnenhy/0.7.6.0

Hi/2.

DBCS fonts have two face names at least. One is a NLS name, the other is a default name, maybe English.

But, Firefox shows only a default name regardless of LANG or a codepage.

And the name of some old DBCS fonts consists of a NLS name not a UCS one.

In this case, the name is replaced with spaces.

Finally, most of all DBCS fonts does not have a separate bold face unlike SBCS fonts because they are very large. So bold face is simulated by a font driver. But current Firefox does not use OS/2's font system, instead it has introduced its own font system. Unfortunately, Firefox's font system does not simulate bold face correctly. it seems just to widen the width not to thicken the stroke.

Reproducible: Always
Thanks for filing the bug. I have known about this for quite some time but I have not given this bug enough priority. I think I know how to fix the boldness problem, but I do not yet know how to attack the font name issue (for me, even in the old Firefox 2.0.0.x packages, DBCS names appear as question marks).
Blocks: 371503
Status: UNCONFIRMED → NEW
Component: General → GFX: Thebes
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
Hi/2.

In my case, the showstopper is a boldness simulation. But it's very fortunate if you know how to fix.

In case of DBCS names, if you provide some code snippets to test to me, I willing to help you.

Here, I have a question. Firefox for Windows does not have this problem at all. It simulates a bold face and show a name for a DBCS font.

Why cannot Firefox for OS/2 do this ?

Windows version and OS/2 version do not use the same font engine ?

(In reply to comment #1)
> Thanks for filing the bug. I have known about this for quite some time but I
> have not given this bug enough priority. I think I know how to fix the boldness
> problem, but I do not yet know how to attack the font name issue (for me, even
> in the old Firefox 2.0.0.x packages, DBCS names appear as question marks).
(In reply to comment #2)

> Here, I have a question. Firefox for Windows does not have this problem at all.
> It simulates a bold face and show a name for a DBCS font.
> 
> Why cannot Firefox for OS/2 do this ?

Because I didn't know how important that is for Asian users and I have too many things to do already, so I forgot.

> Windows version and OS/2 version do not use the same font engine ?

No, Windows uses the Windows font engine, the OS/2 version uses FreeType (v2.3.x).
OK, switching on embolden for all fonts where required is easy. I now updated the Mozilla font library to use FreeType 2.3.9 and there even emboldening Workplace Sans (v0.4) gives good results without forcing antialias. So I guess we can remove that forceful antialias for emboldened text.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
This was my testcase. If one doesn't have "Times New Roman WT K" installed one can edit the HTML source to replace it with one of the other TNR variants (I know of TNR MT 30, TNR WT J, TNR WT SC, or TNR WT TC).
Attached file thebes.dll for testing
thebes.dll for testing with the SeaMonkey nightly from
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/2009/08/2009-08-09-03-comm-1.9.1/

This adds a bit of debug output, like this:

int w = FC_WEIGHT_REGULAR;
FcPatternGetInteger(fcMatch, FC_WEIGHT, 0, &w);
printf("%s: wantbold=%d, havebold=%d\n",
       NS_LossyConvertUTF16toASCII(GetName()).get(), fcW, w);
if (fcW >= FC_WEIGHT_DEMIBOLD && w < FC_WEIGHT_DEMIBOLD) {
    printf(" --> embolden!\n");
    // if we want a bold font, but the selected font doesn't have a
    // bold counterpart, artificially embolden it
    FcPatternAddBool(fcMatch, FC_EMBOLDEN, FcTrue);
}

If this doesn't give good results, please redirect the output of a SeaMonkey session to a file, send it to me or attach here, and give the URLs in question.
Thanks, it's much better.

And I have a another request.

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.

(In reply to comment #6)
> Created an attachment (id=394326) [details]
> thebes.dll for testing
> 
> thebes.dll for testing with the SeaMonkey nightly from
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/2009/08/2009-08-09-03-comm-1.9.1/
> 
> This adds a bit of debug output, like this:
> 
> int w = FC_WEIGHT_REGULAR;
> FcPatternGetInteger(fcMatch, FC_WEIGHT, 0, &w);
> printf("%s: wantbold=%d, havebold=%d\n",
>        NS_LossyConvertUTF16toASCII(GetName()).get(), fcW, w);
> if (fcW >= FC_WEIGHT_DEMIBOLD && w < FC_WEIGHT_DEMIBOLD) {
>     printf(" --> embolden!\n");
>     // if we want a bold font, but the selected font doesn't have a
>     // bold counterpart, artificially embolden it
>     FcPatternAddBool(fcMatch, FC_EMBOLDEN, FcTrue);
> }
> 
> If this doesn't give good results, please redirect the output of a SeaMonkey
> session to a file, send it to me or attach here, and give the URLs in question.
OK, great that this fix was so easy. I will mark this bug fixed and (hopefully) address the issue with the font names in bug 511361.

No, bitmap fonts are not supported. Unless I misunderstand what you. I would need an font example to look at and a (HTML) testcase. And that should go into a new bug.

P.S.: In general you don't need to cite what I wrote when answering in
      Bugzilla, especially not if you bottom-quote.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Summary: DBCS fonts are not supported well → DBCS fonts are not supported well: enable emboldening of fonts without bold counterpart
Fixed for FF 3.6 and (as code freeze for 3.5.3 was apparently Aug 12th) in 3.5.4:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/40ebb670a347
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/660f1f8a1e22
Keywords: fixed1.9.2
Hi/2.

(In reply to comment #8)
> OK, great that this fix was so easy. I will mark this bug fixed and (hopefully)
> address the issue with the font names in bug 511361.
> 

Ok.

> No, bitmap fonts are not supported. Unless I misunderstand what you. I would
> need an font example to look at and a (HTML) testcase. And that should go into
> a new bug.

It's not a bitmap font but a early TTF whose face name is encoded by English although it's encoded by Korean actually.

And I'm sorry I don't understand what you meant by 'an font example'. Do you want a real font file ?
Yes, a real font file would be very useful (if I don't have it already, my collection of foreign fonts is quite big by now). Basically, all TTF files should be supported by the FreeType that is used in Mozilla on OS/2, but some really old fonts don't have a unicode character map, and those are problematic.
You can get it here,

    http://www.ecomstation.co.kr/komh/fonts.zip

It contains three font files. The needed one is 'Sslxys.ttf'.

It doesn't have a unicode char map.

BTW, do you have no plan to an old font without a unicode char map ?
OK, now I just need a testcase (an URL or a HTML file) where this font (or glyphs from it) should be used but isn't. Please use bug 513295 for that which I just opened. (All-in-one bugs like this one don't work well in Bugzilla.)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: