[FreeType2] Sometime hard to distinguish bold and normal fonts

ASSIGNED
Assigned to

Status

()

Core
Internationalization
ASSIGNED
16 years ago
9 years ago

People

(Reporter: tenthumbs, Assigned: kill this account)

Tracking

({intl})

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Reporter)

Description

16 years ago
Now that bug 130661 has been fixed, I can see that the default combination of
anti-aliasing and no hinting produces similar renderings for normal and bold
fonts. Hinting helps but that's not always available.

Screenshots upcoming.
(Reporter)

Comment 1

16 years ago
Created attachment 75971 [details]
anti-aliasing, no hinting

If I didn't know what was supposed to happen, I wouldn't know that there are
normal and bold fonts here.
(Reporter)

Comment 2

16 years ago
Created attachment 75972 [details]
anti-aliasing+hinting, but not auto-hinting

Hinting helps a lot but normal weight fonts still appear dark. Compare the
document with the menu bar. Yes I know the fonts are different but most users
don't
(Reporter)

Comment 3

16 years ago
Created attachment 75973 [details]
no anti-aliasing, hinting, no auto-hinting

The difference between normal and bold is more noticeable.

The weird pointy things on Courier New seem to be a freetype2 artifact.
(Reporter)

Comment 4

16 years ago
Created attachment 75974 [details]
xfs/freetype1 realizations

For comparison, this is a xfs/freetype1 server realizing the same fonts.
(Assignee)

Comment 5

16 years ago
Should this be handled separatel from bug 114885 "FreeType2 glyph rendering 
issues"?

Have you had a chance to try FreeType 2.0.9 which is supposed to have better
rendering?

Could you try changing this pref to 0.0 in unix.js:

  pref("font.scale.tt_bitmap.dark_text.gain", "0.0");

Status: NEW → ASSIGNED
Target Milestone: --- → Future

Updated

16 years ago
Keywords: intl
QA Contact: ruixu → ylong
(Reporter)

Comment 6

16 years ago
> Should this be handled separatel from bug 114885 "FreeType2 glyph rendering 
> issues"?

I tend to think of anti-aliasing as something independent but it's up to you.


> Have you had a chance to try FreeType 2.0.9 which is supposed to have better
> rendering?

That is 2.0.9. :-(


> Could you try changing this pref to 0.0 in unix.js:

I'll attach a tarball with some tests. Setting the gain = 0.0 makes it light but
quite fuzzy. There's not much difference for anything >= 0.3. I also have a
larger set of tests that make small changes in both gain and min. There are
differences but they're not particularly exciting. Do you want to see them?
(Reporter)

Comment 7

16 years ago
Created attachment 76038 [details]
dark-tests.tar.gz
(Assignee)

Comment 8

16 years ago
> > Should this be handled separatel from bug 114885 "FreeType2 glyph rendering 
> > issues"?
> 
> I tend to think of anti-aliasing as something independent but it's up to you.

To me the anti-aliasing is an integral part of glyph rendering.

> > Have you had a chance to try FreeType 2.0.9 which is supposed to have better
> > rendering?
> That is 2.0.9. :-(

too bad. :(

> > Could you try changing this pref to 0.0 in unix.js:
> I'll attach a tarball with some tests. Setting the gain = 0.0 makes it light 
but
> quite fuzzy. 

You see the effect exactly. The code 'hardens' the edge by boosting the
pixels.

> There are differences but they're not particularly exciting. Do you want 
> to see them?

I was really just looking for you opinion.

> Created an attachment (id=76038)
> dark-tests.tar.gz

Would it be possible to just attach the images directly so people could
just click on the link and see them?

thanks for looking at this

(Reporter)

Comment 9

16 years ago
>> There are differences but they're not particularly exciting. Do you
>> want to see them?

> I was really just looking for you opinion.

I'm not a fan of anti-aliasing. There never seems to be general
agreement on what looks good so someone is always tinkering, trying to
make it "look better." From what I've seen that usually involves an
equivalent of gamma correction.

Right now you're doing exactly that and you're using a simple two
parameter piecewise linear function. That helps but that also suggests
that a more complexfunction might work even better. It also suggests
that it might be worthwhile to enable mozilla to read an external
weighting function.

I must ask why the truetype weighting initialization is different from
the scaled bitmap one. The two parameter have similar names but
they're not used the same way. You can certainly use the same
procedure for both, just with different numbers.

> Would it be possible to just attach the images directly so people
> could just click on the link and see them?

Two things:
1) I'm too impatient. If bugzilla is slow, as it often is these days,
then I don't want to spend the time feeding it attachments.
2) Bugzilla forms basically use point-and-click gestures. I can't move
a mouse all that well so it's harder for me than for most.
(Reporter)

Comment 10

16 years ago
Created attachment 76436 [details]
weighting function plot w/ default values

Forget some of what I said about the two weighting functions being 
similar. They're obviously not. However, the aa bitmap one seems more 
appropriate. Look at the attached plot and it's clear that the aa 
function has slope = 1 for small values which is where much of the 
glyph data is. The tt function, however, has slope = 0 so much of the 
glyph data is compressed into one value. That's probably why the tt 
fonts look so chunky.
(Assignee)

Comment 11

16 years ago
You are right that the tt pref name should be corrected.

For outline generated AA glyphs the "correction" really should occur in the
code that renders from the outline. Doing it after the fact is a hack.

For the AA scaled bitmaps (AASB) there is no "outline rendering" phase so it 
can only be "corrected" to be after the fact (ie: only a hack is available).

I'm pretty sure I tried the AASB correction on the tt fonts before settling
on the simpler form . I certianly welcome other experimenters. I think that
the real fix needs to occur in the rendering engine.

(Assignee)

Comment 12

16 years ago
you might consider discussing this on the freetype mailing list:
http://www.freetype.org/mailman/listinfo/freetype
(Reporter)

Comment 13

16 years ago
> You are right that the tt pref name should be corrected.

Actually, I really think the function should change. :-)

> I'm pretty sure I tried the AASB correction on the tt fonts before
> settling on the simpler form . I certainly welcome other
> experimenters. I think that the real fix needs to occur in the
> rendering engine.

There is some experimental code in the freetype library. I can't say 
it does anything startling but it is better than mozilla's. That may 
just be due to the fact that mozilla's correction is more aggressive.

Not that aa by itself is all that great. Hinting is much more 
effective; at least I think so.
(Assignee)

Comment 14

16 years ago
> Actually, I really think the function should change. :-)

Would you kindly elaborate?

> There is some experimental code in the freetype library. 

Hows about a pointer to this code?
(Reporter)

Comment 15

16 years ago
> Would you kindly elaborate?

As I said above, the current function make the glyphs very contrasty
so they appear dark and chunky. It becomes more obvious if you compare
it with freetype's correction function. I also think that the AASB
function is superior to the tt one.

Obviously this needs some investigation so it's not going to change
for 1.0. Afterwards, I would think that it would be better to use a
piecewise linear function that passes through the two end points and
two interior points. You could use the same code for the tt and sb
cases and reproduce the current curves and more. If this happens the
the pref names have to change too. :-)

> Hows about a pointer to this code?

Search for GAMMA in freetype/src/smooth/ftgrays.c. It uses just three
points for the transfer function.
(Assignee)

Comment 16

16 years ago
As is often true: the devil is in the details.

I tried a variety of methods. This is the one that seemed to work best.
If you find one you think works better would you let me know?
(Reporter)

Comment 17

16 years ago
> If you find one you think works better would you let me know?

Sure, but don't hold your breath. It will be a while.
(Assignee)

Comment 18

16 years ago
I don't have any thoughts on how to implement a better solution so patience
is a necessity.
(Reporter)

Comment 19

16 years ago
Created attachment 91978 [details] [diff] [review]
testing only patch

I've got some time for this now. the first thing is this patch which allows
mozilla to load the FT weighting table from a binary file. It's a log faster
than recompiling mozilla all the time. :-)

Right now I'm experimenting with power law curves. Pictures soon.
(Assignee)

Comment 20

15 years ago
any update?
(Reporter)

Comment 21

15 years ago
I upgraded the machine that compiles mozilla so I'm way behind on this. 
Once I get the machine working more to my satisfaction I'll come back to 
this.

Sorry about the delay.
QA Contact: amyy → i18n
You need to log in before you can comment on or make changes to this bug.