Closed Bug 162152 Opened 22 years ago Closed 21 years ago

Font too narrow with "system setting" dpi

Categories

(Core :: Layout: Text and Fonts, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pivert, Unassigned)

References

()

Details

Attachments

(5 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
BuildID:    20020722

The font is too small in the left frame when you bowse the site. Strange because
it well displayed with konqueror.

Reproducible: Always
Steps to Reproduce:
1.Go to the Snogard page at www.snogard.de
2.Press the link to redirect (JS redirection does not work, bug is already reported)
3.Try to read what's in the left frame (menu) :-))

Actual Results:  Very small font in the left frame. (menu)

Expected Results:  Easy to read font (such as in Konqueror or IE)
The font looks fine over here (Mozilla linux build 2002-08-09-04).  Could you
attach a screenshot of what you see?
I'm using a previous version of Mozilla (Build 20020530) and everything looked
fine. Are your font sizes in appearance preferences big enough?
Can you clean your cache and reload the web-site (clean it manually, if
possible, to make sure you deleted all files)? It is possible to be a stylesheet
problem (maybe using another stylesheet instead of the one used by that frame).
If this solves your problem should be considered as as cache update bug.
Attached image Screenshot (1280x1024)
As requested, here is the attachment.
crappy code...
stylesheet as .txt and text/plain (but we still "eat" it)
tons of unclosed <font size="1">, but they get overwritten.
The stylesheet says font-size:8px (and is invalid because of SGML comments
around it)
they really do everything to get their styles not allied, but fail - and so we
have 8px.

do we really read such CSS files?
WFM, 2002-08-10-04 trunk Linux.
kai: the extention of the css file doesn't mean anything as long as it says
text/css. also, css doesn't (afaik) use sgml comments, so except for the crap
with <-- which it should ignore, the css should be fairly ok.

anyway, attaching html testcase w/o the cruft.
Attached file testcase (obsolete) —
reporter: are the fonts just as small with this one?
Attached file testcase #2
alge: that has to be "text/css" not "txt/css".
Attachment #94857 - Attachment is obsolete: true
QA Contact: petersen → amar
Hi !!

I'm adding two screenshots of www.utopolis.lu, as the problem seems the same.
On screenshot is with Konqueror (It's small, but we can read), the other one is
with mozilla (absolutely unreadable).
Here... a good display through konqueror ...
it does appear to be the same problem...

does the testcase (#2) also exhibit this problem?

do you see this with a clean profile?  what dpi setting do you have in Mozilla?
Hi !! Here a snapshot of my font settings. I never changed that.
ok, page say 8px, page gets 8px - where's the bug in this?
> ok, page say 8px, page gets 8px - where's the bug in this?

the bug is that he's getting fonts that appear to be ~8x high, but are very
narrow and scrunched together.

thanks pivert!  could you try setting the dpi to 96, or one of the other
settings (anything but System).  One possibility is that X is telling Mozilla
that the dpi is very asymmetric.  Beyond that, it's choosing a bad font (Intl)
and / or placing the characters too close together (layout)
You seem to be right Andrew.

When setting the display resolution to 72, well it's a bit small, but it's
really better, and readable. When setting to 96 dpi, it's simply perfect. (I'm
using a 19inch Vision Master Pro 452 monitor in 1280x1024).

Thanks !!
....so we can close as wfm?
the problem is probably with XServer telling Mozilla the dpi is some ridiculous
value.

pivert: could you do one more test:

prompt>  xdpyinfo | grep resolution
[root@pivert root]# xdpyinfo | grep resolution
  resolution:    85x89 dots per inch
[root@pivert root]#
ok, those are reasonable values.  could you switch back to "System Setting" and
see if the bug comes back?
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Hello !!

Yes, when back to "System" settings, the www.snogard.de and www.utopolis.lu are
again unreadable.
ok.  reopening.  Mozilla should behave here assuming it is getting the correct
dpi settings.

This might also be X's fault instead of Mozilla.  Looking at the source, it
looks like it ignores the vertical dpi and should use the horizontal (85 for
you) for both (which should be fine).  However, I don't know how to get at the
dpi Mozilla actually uses without adding printf's to the source.  :(
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Font too small. → Font too narrow with "system setting" dpi
quotation fron the CSS2.1 Draft:
"It is recommended that the reference pixel be the visual angle of one pixel on
a device with a pixel density of 96dpi [..]"
http://www.w3.org/TR/2002/WD-CSS21-20020802/syndata.html#length-units

(CSS2.0 said 90dpi), so maybe we should remove this option and _always_ asume 96dpi?
pivert, are you using Xinerama by chance?
Hi !!

I'm not using Xinerama...
 
More infos on my config :
Mandrake 8.2 with KDE 3.0.2 update
Video   : Asus V7100 (GF 2MX)
XP 1700+ on a K7VZA Elitegroup MB - 1x 512MB SDRAM 133
Storage : IBM DTLA 45GB/7200 + CDRom
Network : RTL8139 + Skystar1 DVB
Imaging : HP4100 USB scanner + Olympus C40-Z Digital Camera + Creative WebCam5
Sound   : Creative SB-Live

I'll probably update to MDK9.0B4 this WE... So 'll pay attention of what's
installed and see if the bug is still there.
Related to bug 64504?
.
Assignee: attinasi → font
Component: Layout → Layout: Fonts and Text
QA Contact: amar → ian
Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.
I tryed with Mozilla 1.3 Final under Mandrake 9.1 and it works OK. 
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
reopening.  FIXED is reserved for bugs fixed by patches.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
this bug is WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: