Mac PPC Jan14 Seamonkey build PBook G3, System 8.5 1. Launch Seamonkey on PPC. 2. Go to: http://www.cnn.com and look at the small fonts, 9 point and smaller used ont he page, such as above or below photos, etc. • Small fonts are not rendering properly; Simon <sfraser> seems to think we are not selecting the right font size for display. The other problem seen is the jagged rendering of the characters at all sizes which is believed to be another bug, which I am filing. Win32 Jan 14 build displays properly. Linux build is too unstable to check against.

First off, the ATSUI font rendering does not look at all good, and in fact I'd like to turn it off for now (so that QA get accustomed to better rendering, and we bring ATSUI rendering up to these higher standards later). Turning it off is currently a build-time switch. There are some other problems: 1. Some fonts are not being found properly, so the system font is being used frequently. 2. Font size choice is not optimized for the Mac, so we end up rendering at ugly sizes (6, 11 etc).

Today's build should have some big improvements here: 1. I turned off ATSUI font rendering (temporarily, so you can see what it should look like) 2. No fonts are rendered at less than 9pt, to be more like 4.0x 3. I fixed a bug in the ATSUI font rendering which was causing it to fail to find fonts, to use the system font. I'm going to mark this resolved; if there are still problems, please reopen.

cc:ing those who voiced concernd about the 9pt min font size. FYI, peterl was not happy about this: [sfraser writes] 3. Added a condition that no font smaller than 9pt is used when drawing on screen. This condition existed in the old codebase, and fixes the issue with many sites having fonts that are unreadably small. [peterl writes] Please remove this. We should always render in the font size that the original author specified (modulo user prefs). We are not, should not, and cannot, be style police. No other platform has this condition. If you guys still have a problem with this, please reopen this bug.

glynn, what do you think against the 01/21 build? Better for ya? can you mark Verified.

Been trying to catch up on verifications...Jan 21 build - now while font displays in a readable format, and matches PC sizing, it is being rendered on pc and mac at larger size than what 4.0 renders at. Do folks want a new bug filed to cover the 4.0 vs 5.0 discrepency or do you want to use this one?

I'm not seeing the problem. The pages displayed in 4.5 and in Jan21 and are strictly identical.

I tried again and now it works...perhaps my eyes were a wee bit tired last night..will file new bugs as necessary for any other related items. Leaving verified.

Inserting Milestone info.

I add some code into Mac GFX which may affect this bug. It now switch to ATSUI in run time- it will use the non ATSUI in it if the text only have ASCII, it will use ATSUI if the string it draw have non ASCII in it. We need the ATSUI code so we can start test Japanese page.

Reopening the bug in order to reassign to ftang. When ATSUI is enabled (and it is not, as of today), small characters are not drawn using the right font. Beware: the flag NS_RENDERING_HINT_FAST_8BIT_TEXT has been set in the rendering context; it means that most of the text is rendered without ATSUI. A simple way to verify this after enabling ATSUI is to look at test0.html: the strings in the middle of the page that are supposed to be drawn with variable spacing are not displayed with the right font (note that the variable spacing doesn't work either under ATSUI but ftang told me that it wasn't implemented yet).

Clearing the resolution of fixed.

Reassigning to ftang

This is not a CSS bug (component set as 'Style System'). Reassigning qa contact to claudius@netscape.com. Component needs reassignment.

*** Bug 1909 has been marked as a duplicate of this bug. ***

changing the url to a test page borrowed from bug 1909. Changing componet to 'compositor'. I not 100% that's right either but it's not 'style system'.

It is fix for all the characters could be render w/ MacRoman by uinsg QickDraw

Mac - Font Size Test at 8px still fails....Test #1 PC and Linux - Rendering 9 point at 8px or smaller size Reopened

and that was using March 19 optimized apprunner builds.

Reassigned to myself because it's no longer a problem with ATSUI. We should removed the hack mentionned above that prevent rendering of fonts smaller than 9pt.

Changing my mind... Greg, you opened the bug because the small 8pt characters on CNN.com were illegible. We fixed it so that characters smaller than 8 are rendered as 9 (like in Communicator) and now you are reopening the bug because the 8pt characters on <http://style.verso.com/fontsize.html> are not illegible as they are supposed to be. We can't do both. Closing as Fixed again.

Actually not rendering fonts at size stipulated by the author, even if it is smaller than we think is legible is a problem. See peterl's comments from 1/15, which I agree with: [peterl writes] We should always render in the font size that the original author specified (modulo user prefs). We are not, should not, and cannot, be style police.

I saw what peterl wrote. I also know that users don't want illegible text on CNN.com and many many other sites. I can't decide on that matter. Reassigning to <rickg> to take a decision.

Updated platform field and summary to reflect latest developments awaiting decision regarding the forcing of rendering of sub 9 point to 9 point sizes cross platform. Was PP bug, Mac only, but not now. Target milestone should be updated as well by appropriate folks.

just housekeeping Summary and status fields

The URL referenced above has changed to http://style.verso.com/junk/fontsize.html There are two issues here: one is the Nav 4.x bug where fonts were rendered smaller than what the author specified. The other is that fonts specified in point units rasterize into fewer pixels on Mac than on Windows (see http://www.tidbits.com/tb-issues/TidBITS-467.html#lnk3 ). This is not a bug but an XP difference. I have proposed a UI whereby this XP difference can be obliterated, and argued that the XP default logical resolution should be 96ppi: http://style.verso.com/cssui/ . Implementing a 96ppi default logical resolution will mean that, e.g., 9pt fonts rasterize into 12 pixels on Macintosh, Unix, and Windows: parity. So I agree with Peter that fonts should be rendered as specified, but as they would render at the Windows default. Per CSS1&2, point units are inappropriate for the screen anyway, so this is in part to accommodate clueless autho

[ just updated the url ]

Ok -- the decision is made -- so this is your bug again. Enjoy.

Maybe you can close it as duplicate of #5000 now...

This is really a pixel/point conversion issue, now covered under bug 5000. *** This bug has been marked as a duplicate of 5000 ***

Verified Dup