21.59 KB, image/png
6.89 KB, image/png
6.80 KB, text/html
11.28 KB, text/plain
78.85 KB, image/gif
3.62 KB, image/png
3.47 KB, image/png
152.15 KB, image/jpeg
Please put comments about the experimental Linux Moz TrueType build. See bug 100570 for more technical detail.
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
change: they will appear in the next build to: they will appear in the README.TrueType file in the next build
I am working on sharpening the glyphs. I will try using the technique I used to sharpen the AASB glyphs (bug 90813).
If you want to see the anti-alias effect in detail try running the "xmag &" command to see the pixels expanded up.
The experimental build is at: http://ftp.mozilla.org/pub/mozilla/nightly/experimental/truetype/
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.
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)
Created attachment 60910 [details] 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.
Created attachment 60911 [details] 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.
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.
Created attachment 60935 [details] 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?
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.
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.
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]?
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.
Preferences are so horked now they are unusable. Gotta wait till things settle. (bug 108939, bug 113482, bug 114299)
man, do some of the glyphs rendered via FreeType2 look poor
Created attachment 61061 [details] 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'.
Created attachment 61264 [details] same font with with hinting enabled This is the same font but with TrueType hinting enabled.
Created attachment 61266 [details] 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
Attachment #61264 - Attachment is obsolete: true
> - 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.
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..)
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
> 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.
> 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.
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..
>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.
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..
> 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?
> 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.
> Created an attachment (id=61545) > Gimp "Freetype"-plugin v0.2 font-sample showing Arial. This image has AA on and most likely TrueType hinting.
>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
David Turner <firstname.lastname@example.org> on the email@example.com 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..
this code is in so it is not longer experimental
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
this code is in so I'm closing out this "comments on experimental build" bug
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.