Closed
Bug 2411
Opened 26 years ago
Closed 26 years ago
Font size not properly selected for layout of page(sub 9pt forced to 9pt)
Categories
(Core Graveyard :: GFX, defect, P2)
Tracking
(Not tracked)
M6
People
(Reporter: glynn, Assigned: peterl-retired)
References
()
Details
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.
Comment 1•26 years ago
|
||
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).
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 2•26 years ago
|
||
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.
Comment 3•26 years ago
|
||
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?
Comment 6•26 years ago
|
||
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.
Comment 9•26 years ago
|
||
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.
Updated•26 years ago
|
Status: VERIFIED → REOPENED
Updated•26 years ago
|
Resolution: FIXED → ---
Comment 10•26 years ago
|
||
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).
Comment 11•26 years ago
|
||
Clearing the resolution of fixed.
Updated•26 years ago
|
Assignee: sfraser → ftang
Status: REOPENED → NEW
Comment 12•26 years ago
|
||
Reassigning to ftang
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
QA Contact: 4110 → 4130
Comment 13•26 years ago
|
||
This is not a CSS bug (component set as 'Style System'). Reassigning qa contact
to claudius@netscape.com. Component needs reassignment.
Comment 14•26 years ago
|
||
*** Bug 1909 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Component: Style System → Compositor
Comment 15•26 years ago
|
||
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'.
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Comment 16•26 years ago
|
||
It is fix for all the characters could be render w/ MacRoman by uinsg QickDraw
Reporter | ||
Comment 17•26 years ago
|
||
Mac - Font Size Test at 8px still fails....Test #1
PC and Linux - Rendering 9 point at 8px or smaller size
Reopened
Reporter | ||
Comment 18•26 years ago
|
||
and that was using March 19 optimized apprunner builds.
Updated•26 years ago
|
Assignee: ftang → pierre
Status: REOPENED → NEW
Comment 19•26 years ago
|
||
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.
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Comment 20•26 years ago
|
||
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.
Reporter | ||
Comment 21•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: pierre → rickg
Status: REOPENED → NEW
Comment 22•26 years ago
|
||
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.
Hardware: Macintosh → All
Summary: [PP] Mac - Font size not properly selected for layout of page → Font size not properly selected for layout of page
Reporter | ||
Comment 23•26 years ago
|
||
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.
Updated•26 years ago
|
Summary: Font size not properly selected for layout of page → Font size not properly selected for layout of page(sub 9pt forced to 9pt)
Whiteboard: awaiting stylistic decision
Comment 24•26 years ago
|
||
just housekeeping Summary and status fields
Comment 25•26 years ago
|
||
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
Comment 26•26 years ago
|
||
[ just updated the url ]
Comment 27•26 years ago
|
||
Ok -- the decision is made -- so this is your bug again. Enjoy.
Comment 28•26 years ago
|
||
Maybe you can close it as duplicate of #5000 now...
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: FIXED → DUPLICATE
Whiteboard: awaiting stylistic decision
Assignee | ||
Comment 29•26 years ago
|
||
Comment 30•25 years ago
|
||
Verified Dup
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•