112490 - want all fonts anti-alias bitmap scaled since they look better

Status: RESOLVED INCOMPLETE

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 11-27 linux trunk build on RH7.1-Ja

After bug 90813 (anti-alias bitmap scaled font), now the fonts in CJK pages
looks much nicer.
However, seems we need to do some more work to make it even better, because
right now with a lots of CJK pages, they have some scaled fonts and non-scaled
fonts mixed together which is not a very good looking - see following screen
shot, you will find unconsistent fonts in same page.  It might because we have
some condition for the fonts to be scaled.

I noticed, if I changed size to smaller, then I will get the whole
fonts that have been scaled, which looks more nice.

Comment 1

[Yuying Long]

Attachment: Image for yahoo-japan.

Notice the circled characters are not scaled which is not consistent with the
rest characters.

Comment 2

[Yuying Long]

Attachment: Image for after reduced size

View | Text Size, change it to 75%, then will get the whole characters scaled
which looks better.

Comment 3

[Yuying Long]

Reassign to Brian for now.

Comment 4

[kill this account]

The reason the Anti-Alias Scaled Bitmap (aasb) fonts look better is that
they are scaled down from a 2x bigger font which is better looking than
the non-scaled (regular size) font.

To support this we would need to add a per-language pref such as 

   pref("font.scale.aa_bitmap.always_aasb.ja", true);

and change nsFontMetricsGTK::PickASizeAndLoad to check for this.

Comment 5

[clkao]

i look forward to the always_aasb feature. currently most users in taiwan uses
ttf fonts, so even when set zoom size to 75% there is always fetchable size and
mozilla never does antialias for them. I'd really like to see this before we
have anything from bug 100570 working.

Comment 6

[Roland Mainz]

Current AASB implementation renders Mozilla unuseable (rendering performance)...
I doubt we can do this without hurting all users of remote X11 displays ...

Comment 7

[kill this account]

Roland: clearly some people are seeing adequate performance. Could you
be more specific about the conditions where aasb rendering is an issue?

Comment 8

[Roland Mainz]

> Could you be more specific about the conditions where aasb rendering
> is an issue?
It will be an issue if the latency is high - for example if there is a longer
distance between Xserver and client (different building, WAN etc.) or if you use
something which tries to do some optimisations via caching&compression of image
data (dxpc&co. comes in mind).

In all these cases the AASB code makes the Zilla slow&sluggish as molasses (full
refresh takes 2-3 secs... or more (use window manager "iconify" and then
"restore" the window) - compared to a "blink of an eye" if AASB code has been
turned-off) ...

Comment 9

[kill this account]

is there a person seeing this that I can talk to?

Comment 10

[kill this account]

Attachment: patch: add "always aasb scale" global and per-language option

This is off by default. Users will need to set a pref to enable this; eg:

  pref("font.scale.aa_bitmap.always", true); // global

or

  pref("font.scale.aa_bitmap.always.ja", true); // per-language

Comment 11

[clkao]

I tried the patch and turned out the settings. it works very well for japenese
pages. however for big5 (zh-tw) sites, it doesn't always do aa. a quick glances
of the ns_load_font debug output shows big5 fonts are aa'ed only when the
charset is recognized as jis.

for example:

http://www.clkao.org/ro/article-last.html does not do aa
http://www.clkao.org/ro/index.html does have aa for the big5 fonts.

i'll put together the deubg output log later.

Comment 12

[kill this account]

> big5 fonts are aa'ed only when the charset is recognized as jis.

A subtly of English is the difference between "ie:" and "eg:".
The term "ie:" means "in other words" whereas "eg:" means "for example".
http://www.agcom.purdue.edu/AgCom/library/ontarget/archive/ot2_97.html#anchor2

So the statement

  Users will need to set a pref to enable this; eg:
     pref("font.scale.aa_bitmap.always.ja", true); // per-language

is an example not the specific answer.

For traditional Chinese change the line with "zh-TW" and for simplified Chinese 
change the line with "zh-CN"; eg:

  pref("font.scale.aa_bitmap.always.zh-TW", true);

Comment 13

[clkao]

Hi Brian:

Thanks for the English lesson :-/ but I did understand, read the patch, and set
my pref.js correctly. what i meant by "big5 fonts are aa'ed only when the
charset is recognized as jis" is the ns_load_font_debug message is showing that
the (supposed to be zh-TW) fonts is recognized as jis- encoding. I also tried
turn on always-aa for zh-CN and the gb fonts were not antialiased either.

Comment 14

[clkao]

some more clues here:

zh-TW always-aasb doesn't work with truetype fonts, even if they are configured
with aliases for each size (this was introduced back in netscape 4 days, since
it doesn't not grab non-specific size fonts such as ttf).

The truetype font entry (that doesn't work with aa) from xlsfonts is
-default-ming-medium-r-normal--0-0-0-0-c-0-big5-0, displayed as
"default-ming-big5-0" in font preferences.

the all-size alias fonts mentioned above has entries like:
-aliasdefault-ming-medium-r-normal--10-100-0-0-c-100-big5-0
-aliasdefault-ming-medium-r-normal--11-110-0-0-c-110-big5-0
-aliasdefault-ming-medium-r-normal--12-120-0-0-c-120-big5-0
-aliasdefault-ming-medium-r-normal--14-140-0-0-c-140-big5-0
-aliasdefault-ming-medium-r-normal--16-160-0-0-c-160-big5-0

pcf big5 fonts works perfectly with always-aasb

Comment 15

[kill this account]

> zh-TW always-aasb doesn't work with truetype fonts, even if they are
> configured with aliases for each size (this was introduced back in netscape 
> 4 days, since it doesn't not grab non-specific size fonts such as ttf).

This is the design. The Anti Aliased Scaled Bitmap code does in fact scale 
*bitmap* fonts. This scaling is somewhat crude since the code has no 
information on what the font creator wanted. The code only has access to the 
pixels which (at anything less than enormous sizes) are a compromise since 
pixels come in relatively large chucks.

If the font is a outline scale type font then the anti-aliasing should
be done at the time the outline is rendered to pixels and definitely *not*
after that (ie: on the rendered pixels). Doing the scaling during the rendering
is faster (only scale once) and has the best possiblity of producing the
best glyph since the render has access to the font's theoretical design (not
just the rendered pixels).

See bug 100570 re: adding TrueType font support to mozilla.

Comment 16

[kill this account]

I'm planning to making builds with the code in bug 100570 available
in the mozilla experimental build area available soon. When that is
available we can look at how that work for you.

Comment 17

[kill this account]

-> 0.9.8

Comment 18

[kill this account]

Attachment: patch; nsFontMetrics.cpp and unix.js

Comment 19

[kill this account]

Attachment: patch; nsFontMetricsGTK.{h,cpp}, unix.js

Comment 20

[Frank Tang]

looks like check in this itself won't impact performance. Once it is in, we can
run cowtools against the setting turn on and off and find out performacne impact. 

Comment 21

[Christopher Blizzard (:blizzard)]

Comment on attachment 62434 [details] [diff] [review]
patch; nsFontMetricsGTK.{h,cpp}, unix.js

sr=blizzard

Comment 22

[Yuying Long]

nsbeta1

Comment 23

[kill this account]

checked in

Comment 24

[Yuying Long]

I wonder why I can not see the check-in made any change in 01-16 trunk build?

Comment 25

[kill this account]

Try setting one of these prefs in unix.js to true

 pref("font.scale.aa_bitmap.always", false);

or 

 pref("font.scale.aa_bitmap.always.ja", false);

Comment 26

[Yuying Long]

When I set:
pref("font.scale.aa_bitmap.always", true);
Seems the all latin characters get aab scaled, however, those un aabs CJK
characters still keep not aabs.

If I set by each language seperately, e.g. 
pref("font.scale.aa_bitmap.always.ja", false);
for Japanese, I will get Japanese get aabs, but other Chinese or Korean don't
make any difference.

I think we need some improvement:
1. User has to manual modify their unix.js.
2. Can we just let CJK(especially Japanese and Chinese) get aabs but keep latin
language not aabs?

I'm re-open this bug here try to get a better fix.

Comment 27

[kill this account]

There is a performance penality for AASB so I tended to try and limit its
use. For systems with a better selection of fonts I would prefer it use
the bitmap fonts and they are faster and can be better looking.

Should we consider a UI for setting this?

Comment 28

[Katsuhiko Momoi]

> Should we consider a UI for setting this?

I suggest that we do and hopefully only for Unix. Windows/Mac
users need not be exposed to this dialog. The question is how many
options there should be. Something like the following to begin
discussion with?

Anti-alias bitmap scaling applies to: 

[ ] None [ ] All [ ] CJK only [ ] Individual lang: Japanese
                                                   Trad Chinese
                                                   Simplidie Chinese
                                                   etc.

The last radio button choice is followed by a selection box.
This UI should be placed in the font dialog panel for Unix only.
How many options we should have is up to discussion. Should be a choice
to allow aabs only for Latin scripts? (That does not seem to make
sense.)
                                                   

Comment 29

[kill this account]

AASB is already set to "kick in" if the nearest font is more than +/-20% of
desired.

I suspect we could just have a single toggle and that would be
adequate for users.

 [ ] Always Anti-Alias Scale Bitmaps

Comment 30

[Yuying Long]

In fact, "always AABS" is not good for both CJK (not all fonts be scaled) and
western pages, for my point of view it's not a good idea to only has this one.  

Comment 31

[Sridhar Dhanapalan]

I have experienced this same oddity with CJK fonts, but also with italicised
Helvetica and Roman (ISO-8859-1) characters. Mandrakeforum.com shows quotes in
italicised Helvetica, which is automatically shown anti-aliased in Mozilla
without any manual scaling. In most cases, however, Helvetica needs to be scaled
down in size (to 95% or lower) for it to be anti-aliased. Note that it is only
anti-aliased when it is italicised, not normal, bold or underline (unless also
italicised).

Comment 32

[Sridhar Dhanapalan]

Attachment: Partial screenshot of Mandrakeforum.com

Partial screenshot of Mandrakeforum.com. Note the italicised Helvetica quotes
are anti-aliased, while everything else (also Helvetica) is not.

Comment 33

[Sridhar Dhanapalan]

Attachment: Font test page, no size scaling

Here's a page I made up to show the differences between Helvetica, Arial
(Monotype TTF from Windows), Times and Times new Roman (Monotype TTF from
Windows). With no font size scaling, everything is aliased.

Comment 34

[Sridhar Dhanapalan]

Attachment: Font test page, font size scaled to 90%

Here's the same font test page, but this time everything is scaled down to 90%.
Notice how the Helvetica italic fonts are anti-aliased, but the rest aren't.

Comment 35

[kill this account]

This is so interesting to me:

As an engineer I assume that a hand tuned bitmap will always be better
than an AASB but I continue to find people who want AASB over hand tuned
bitmaps.

Comment 36

[Sridhar Dhanapalan]

I think most people simply want anti-aliasing. The average user doesn't care if
it is done with AASB or a hand tuned bitmap, as long as it works well (of
course, performance is important as well). From my perspective, we already have
partial anti-aliasing for italicised Helvetica, so why not try to extend to to
all fonts and font styles? I'm not a developer (so I may just be talking
rubbish), but this appears to be the simplest way. Otherwise, we've got <a
href="http://slashdot.org/article.pl?sid=02/01/24/2028258">this</a>.

Comment 37

[kill this account]

> I think most people simply want anti-aliasing. 

Some do and some do not. Many users find anti-aliasing makes the text blurry 
(not smooth) and very strongly do not like it.

> The average user doesn't care if it is done with AASB or a hand tuned bitmap,

This is a confusing statement. A "hand tuned bitmap" is by its very nature
not anti-aliased. AASB is useful where there are limited sizes available.
Since Western languages have a small number of glyphs (~220) they tend to
be produced in many sizes. Because CJK languages can have a large number of
glyphs (~6000) they tend to only come in 1 or 2 sizes in which case AASB
really helps by making the few sizes available (if blurry) in many virtual
sizes.

The article you reference, 
"http://slashdot.org/article.pl?sid=02/01/24/2028258">, 
talks about Xft about which I have had interminal discussions. Xft is lacking
in a variety of areas the most important is in internalization support.
Keith and I do communicate about this and I look forward to including his work
in mozilla when it has the necessary features.

I do have TrueType support in the works and if I can ever get it super-reviewed
you can see it.

Comment 38

[kill this account]

this is probably requires a smallish amount of work

Comment 39

[Frank Tang]

nsbeta1- . let's do this after m1.0 
we need to release note this for m1.0 

Comment 40

[Andrei Purice]

Marking this as Resolved > Incomplete since the last real activity on this issue was 20 years ago and it might not be relevant anymore.
Feel free to re-open it if it's not the case and the issue is still relevant.