114130 - Comments re: experimental Linux Moz TrueType build (bug 100570)

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[kill this account]

Please put comments about the experimental Linux Moz TrueType build.
See bug 100570 for more technical detail.

Comment 1

[kill this account]

Here are the steps required to enable TrueType fonts in the experimental
builds (they will appear in the next build):

1) Tell moz where the fonts are.
   In mozilla/defaults/pref/unix.js edit/add/remove the font dirs:

      pref("TrueType.font.dir.1", "/usr/local/share/fonts/ttfonts");
      pref("TrueType.font.dir.2", "/usr/share/enlightment/E-docs");
      pref("TrueType.font.dir.3", "/home/bstell/tt_font");
      ...

2) Run moz. The very first time moz is run it will scan the
fonts to get the list of valid chars/glyphs in each font.
THIS WILL TAKE SEVERAL MINUTES.

3) Set the font preferences to use TrueType fonts.  
TrueType fonts will start with an upper case letter. 

   How to set font preferences
   -------------------------------------------------
   Open the menu "Edit->Preferences". 
   Select "Fonts".
   Set "Fonts for:" to the language group of your page
     (eg: "Western"). 
   Set "Proportional:" to "Serif" (if needed) 
   Set "Serif:" to a font with starting with an upper
     case letter. 
   Click "OK".

Try: http://www.mozilla.org/start/

4) Add comments as appropiate to:
http://bugzilla.mozilla.org/show_bug.cgi?id=114130

Comment 2

[kill this account]

change:

  they will appear in the next build

to:

  they will appear in the README.TrueType file in the next build

Comment 3

[kill this account]

I am working on sharpening the glyphs. I will try using the technique I used
to sharpen the AASB glyphs (bug 90813).

Comment 4

[kill this account]

If you want to see the anti-alias effect in detail try running the "xmag &"
command to see the pixels expanded up.

Comment 5

[kill this account]

The experimental build is at:

http://ftp.mozilla.org/pub/mozilla/nightly/experimental/truetype/

Comment 6

[R.K.Aa.]

assuming it's the unix.js found in mozilla/defaults/pref/unix.js that takes the
editing, the pref for min size doesn't seem to have any effect?

Edited it to read pref("font.antialias.min",        15); 
but smaller fonts still antialias.

Comment 7

[Dawn Endico]

http://salon.com/books/int/2001/12/08/palestine/index.html

This page looks pretty funky with this build although it looks normal 
with today's nightly build.

- Normal paragraph text looks bold although the picture's caption looks ok.
- There is too much space between lines of text.
- The top row of pixels on the capital S seems to be missing. (and others?)
- The lower case 'e' looks a lot like a 'c' because there is no space between
  the horizontal bar and the top curve of the e.

I think there is also a leading problem with the article headlines at
http://slashdot.org/. It looks like the headlines there are antialiased,
but not the rest of the lettering.

this is on amok, Red Hat Linux release 6.2 (Zoot)

Comment 8

[Dawn Endico]

Attachment: chunky fonts from salon.com article

http://salon.com/books/int/2001/12/08/palestine/index.html
Screen shot shows the 'S' and 'e' characters I mentioned in my earlier comment.

Also, all of these characters seem bold.

Comment 9

[Dawn Endico]

Attachment: screen shot from slashdot showing extra leading

this shows extra vertical space on the antialiased font used in the headline.
The other fonts are normal. The same is also true of the salon screen shot.

Comment 10

[kill this account]

when a run of text begins with a negative lbearing (think italic 'p') the 
right side is tuncated.

I need to add debug code to display the bounding boxes. Then I can make the
positioning exact.

Comment 11

[kill this account]

Attachment: html with sizes 1 - 69

Use this html to see where the anti-aliasing minimum is.

Note that the size numbers (eg: 9pt) are fixed at 10 so be sure to check the 
text "abcde..." for anti-aliasing (not the size).

Also note that the pref("font.antialias.min", 10) is in pixels not points.
Should this be changed to points?

Comment 12

[kill this account]

Thanks for the feedback. I see a couple issues here.

GLYPH SHAPES
------------
> - Normal paragraph text looks bold although the picture's caption looks ok.
> - The lower case 'e' looks a lot like a 'c' because there is no space between
>   the horizontal bar and the top curve of the e.
> - chunky fonts from salon.com article
> - Also, all of these characters seem bold.

What font and size was being used?

(Clearly, I need to add a NS_FONT_DEBUG printf for this.)

For a given font my goal is to see similar glyphs on Linux as on Mac/Win.
I have noted that the FreeType2 render seems to produce different glyphs
than I see on Mac/Windows. In the next experimental build I will add the 
FreeType2 demo font viewer. Using this people can see what the font looks 
like in a reference FreeType2 viewer and we should be able to identify if 
the difference is in the code in moz or in the code in FreeType2.

GLYPH METRICS
-------------
> - The top row of pixels on the capital S seems to be missing. (and others?)
> - a leading problem with the article headlines at http://slashdot.org/.

I also see a pixels cut off at the right end of italic runs if the first 
char (left end) has a descender (negative lbearing). I will be addding the 
debug code that draws the bounding boxes so I can see exactly where the 
glyphs are relative to the bounding box. None of the math is complex but
there are a lot of small details to get right (as I learned when I did this
in the AASB fonts, bug 90813).

For the next experimental build I will:

1) add some diagnostic output so people can tell which font(s) they are using 
   so they can view it in a FreeType reference viewer.

2) work on the glyph metrics isses

My goal is to have a new experimental build a few days after the 0.9.7 freeze.

Comment 13

[R.K.Aa.]

the pref should remain in px as long as the preferences UI uses px.
But again: Changing the pref for when font antialiasing triggers size-wise, does
not work. Is mozilla/default/pref/unix.js the right file? Or is the pref
hardcoded in some other file, packed in a jar?

As I understand the preference, it's meant to set the "smallest" fontsize you
want to antialias? Meaning everything smaller should NOT be antialiased.

I set it to 15 but moz keeps showing fonts down to 10 px antialiased.

Comment 14

[kill this account]

yes, it is the line pref("font.antialias.min", 10) in 
mozilla/default/pref/unix.js

I'll add a debug printf for the next build

For now, would you kinldy attach your unix.js file and screen shot of 
attachment 60935 [details]?

Comment 15

[R.K.Aa.]

Attachment: unix.js

Comment 16

[R.K.Aa.]

Attachment: snippet of screenshot, zoomed to 300%

Comment 17

[kill this account]

humm..., wonder why it works for me but not you.

If you set it to say 5 does the threshold move?

I will put in a debug statement in the next experimental build.

Comment 18

[R.K.Aa.]

Preferences are so horked now they are unusable.
Gotta wait till things settle. (bug 108939, bug 113482, bug 114299)

Comment 19

[kill this account]

man, do some of the glyphs rendered via FreeType2 look poor

Comment 20

[kill this account]

Attachment: Agfa Monotype-century schoolbook 16 points

This is displayed by the FreeType2 reference display program, ftstring,

This was NOT displayed by moz (of course it looks the same (bad) of moz.)

Compare the '7' and the '8'.

Comment 21

[kill this account]

Attachment: same font with with hinting enabled

This is the same font but with TrueType hinting enabled.

Comment 22

[kill this account]

Attachment: 61264: same font with with hinting enabled (previous was not bold)

previous was not the bold font

both of these look much better than when the hinting is off

Comment 23

[kill this account]

> - The top row of pixels on the capital S seems to be missing. (and others?)
> - The lower case 'e' looks a lot like a 'c' because there is no space between
>   the horizontal bar and the top curve of the e.

This could be because hinting is disabled.

Comment 24

[R.K.Aa.]

if i set the pref in unix.js to 55 then fonts at 40px are NOT aa'ed, but fonts
at 41px and larger *are* aa'ed.

So something is funny with that pref.

What's far worse: Even when not aa'ed TT-fonts in chrome are affected and do not
look good. Same with TT fonts on pages. Attaching two screenshots with that
build, where TT fonts are used but the minimum size to aa them at is set to 55
(which again for some reason is read as 40..)

Comment 25

[R.K.Aa.]

Current CVS build without AA
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=61523

TT enabled build:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=61524

Comment 26

[kill this account]

> something is funny with that pref

I have reworked this part of the code so we should re look at this using
the next experimental build.

Comment 27

[kill this account]

> TT enabled build:
> http://bugzilla.mozilla.org/showattachment.cgi?attach_id=61524

The FreeType2 library included in the 1st experimental build has
TrueType hinting disable (standard build setting because of patent
issues).

Correct me if I'm wrong but it looks like AA has also been disabled in 
this image.

The poor looking glyphs clearly point out that hand tuned bitmaps are 
typically better looking than outline scaled fonts which are rendered 
without anti aliasing and without TrueType hinting (which is the 
case for this experimental build).

Even with TrueType hinting enabled it is my impression that the glyphs
produced by FreeType2 for a given font look quite different that those
produced on Mac and Windows.

In the next experimental build I will include a FreeType2 reference viewer
so we can indentify if a glyph issue is a FreeType2 issue or a moz issue.

Because the quality of the glyphs produced by FreeType2 might be an issue
I have opened bug 114885 to address the quality of the glyphs from FreeType2 .
In general, FreeType2 glyph quality issues should be addressed there.

Comment 28

[R.K.Aa.]

xfs with xfsft as used in XFree86 4* and also RH's older XFree86 3.3.6 (prolly
more) also lean on the Freetype library.

RH7.1 comes with freetype-2.0.1-4 i believe. Fonts render by default without AA,
and all TT fonts look good.

Personally I'd like to see TT fonts at larger scales antialiased, while I'd like
to keep fonts from around 14pt downwards un-aliased, for the sake of crispness
and speed. And when un-aliased, i'd like them to render like they do per today
in common nightlies. 

The "freetype" truetype plugin/filter in the Gimp http://freetype.gimp.org/ also
leans on the Freetype2 library. I'll make a screenshot..

Comment 29

[R.K.Aa.]

Attachment: Gimp "Freetype"-plugin v0.2 font-sample showing Arial.

Comment 30

[R.K.Aa.]

>Correct me if I'm wrong but it looks like AA has also been disabled in 
>this image.

No, that's the vital part: That is the build WITH TT rendering, but with 
pref("font.antialias.min", 55); 

So I'm telling moz NOT to aa fonts smaller than... (some size) 
In other words: The build isn't actually rendering the fonts anti-aliased, but
it sure messes them up - just compare to the other image where i use exactly the
same fonts.

My expectation would have been that hose two images should have looked
identical, since the fonts aren't AA'ed in any of them. But they don't look
identical. The AA enabled build renders unaliased TT fonts rather poorly,
compared to how the same TT fonts look in a nightly.

Comment 31

[R.K.Aa.]

me expert at making myself unclear..

What i mean is: When an AA build of Moz is told NOT to trigger antialiasing
"before the fontsize is some-specific-size" - then i expect the AA stuff to be
utterly *bypassed* - and in other words that X serve the smaller fonts just like
before, all up to the point where fonts of larger sizes than set in prefs are
found. Does that make sense at all..

Comment 32

[kill this account]

> attachment 61545 [details] Gimp "Freetype"-plugin v0.2 font-sample showing Arial.

This looks like TrueType hinting is enabled. 

Can you show the same font in the FreeType2 reference viewer: ftstring?

Comment 33

[kill this account]

> RH7.1 comes with freetype-2.0.1-4 i believe. Fonts render by default 
> without AA, and all TT fonts look good.

There are bug reports already where people complain that the outline scaled 
fonts look bad; bug 95280, bug 87738, bug 92590. Because of this I 
specifically added code to avoid outline scaled fonts when there is a bitmap 
size of about the desired size (within 90-110%).

> I'd like to see TT fonts at larger scales antialiased, 

At larger sizes the difference between outline scaled with and without
AA seems minor to me. Partly because at big sizes the percent of the
pixels on the edges is much smaller. Partly because large glyphs are
not very common.

> while I'd like to keep fonts from around 14pt downwards un-aliased, 
> ... i'd like them to render like they do per today in common nightlies. 

This is a statement that for sizes below 14 you find the hand tuned 
bitmap fonts better looking than unhinted outline scaled fonts. I agree
with this feeling. (Of course embedded bitmaps in TrueType fonts also look 
very good.) When the TrueType hinter is enabled I find that the results tend 
to be much better but enabling the TrueType hinter problematic because of 
patent issues.

Right now the code architected by Erik is not well suited to selecting
between different foundries/encoding based on size. So at this time I do not 
think it likely that moz can choose a different foundry (read: TrueType vs X 
bitmap) based on pixel size.

In the long run if we can address the hinting issues (the patent issues may 
not be solvable) I would prefer to move toward the Mac/Windows font model 
since that is where new work is being done.

Comment 34

[kill this account]

> Created an attachment (id=61545)
> Gimp "Freetype"-plugin v0.2 font-sample showing Arial.

This image has AA on and most likely TrueType hinting.

Comment 35

[R.K.Aa.]

>At larger sizes the difference between outline scaled with and without
>AA seems minor to me. 

For me it's opposite. It's *particluarly* in larger fonts i'm fascinated by the
"photographic" look made possible through antialiasing.
Without AA the page below looks like a 2nd generation carbon-copy, even if TT
fonts are used all the time. (Needs MS webfont collection installed)

http://www.microsoft.com/typography/css/gallery/slide6.htm

Comment 36

[kill this account]

David Turner <[e-mail]> on the [e-mail] mailing list on 
Fri, 14 Dec 2001 
----------------------------------------------------------------
This image definitely looks like the bytecode interpreter wasn't
used. I also think that the current auto-hinter (post 2.0.5)
produces a better job anyway so maybe hinting was completely
turned off..

By the way, I just looked at the results of monochrome TrueType
rendering in FT2 with the bytecode interpreter compiled in, and
it seems we have at least two problems:

  - composites are not corectly generated, most accents are
    not legible or have invalid shapes, as if they were not
    translated with good values..

  - compared to FreeType 1, glyphs have lower quality. It seems
    we have another problem here..

Comment 37

[kill this account]

this code is in so it is not longer experimental

Comment 38

[kill this account]

this code is in so I'm closing out this "comments on experimental build" bug