Closed
Bug 5236
Opened 25 years ago
Closed 24 years ago
Unix: default UI font very small
Categories
(SeaMonkey :: General, defect, P2)
Tracking
(Not tracked)
VERIFIED
WONTFIX
M17
People
(Reporter: thully, Assigned: alecf)
References
Details
(Keywords: platform-parity, Whiteboard: [nsbeta3-][RTM NEED INFO])
Attachments
(9 files)
(deleted),
image/gif
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/xul
|
Details | |
(deleted),
text/css
|
Details |
I am running Mozilla M4 on Linux, and the default font is tiny! I do not have
many fonts installed, but that should not affect anything. I am running RedHat 5.2 with gtk 1.0.6 and 1.1.2 hanging around (should this work?) and kernel
2.0.36. On the first loading of Mozilla on this configuration, it gave me an error about gtk. I think this is related to the default font Mozilla picks.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M5
Comment 1•25 years ago
|
||
What is the error message about GTK that you get on first loading?
Also, we are currently working on the default font size. In the meantime, could
you try the following before starting Mozilla:
setenv GECKO_FONT_SIZE_FACTOR 1.75
You can change the number to 2.5 if you want it even bigger.
I do not know, but I have already un-installed that release of Linux because it
was crashing a lot. It happened especially if I went to the Mail window or
tried to Add a bookmark.
Updated•25 years ago
|
Target Milestone: M5 → M6
Comment 3•25 years ago
|
||
I have checked in a change to make the default DPI on Unix (GTK) be 96 (per
peterl@netscape.com). This may improve your situation. Also, in the future
there will be a UI for changing the pixel density. Marking M6 to get it off the
M5 radar.
Updated•25 years ago
|
Summary: On Linux, default font very small. → Unix: default font very small
Comment 4•25 years ago
|
||
Thully, have you tried a more recent build?
No, I have not tried a more recent build. I cannot download 8MB that often with
my speed of connection.
Summary: Unix: default font very small → [PP]Unix: default font very small
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 6•25 years ago
|
||
Date: Tue, 27 Apr 1999 21:45:04 -0700
From: Erik van der Poel <erik@netscape.com>
Newsgroups: netscape.public.mozilla.gtk, netscape.public.mozilla.unix
I just checked some code into the GTK version of Mozilla to read the
"browser.screen_resolution" preference. This preference can be set in
your prefs file (~/.mozilla/prefs50.js) as follows:
user_pref("browser.screen_resolution", 120);
The above will set the dpi to 120. If you set the pref to zero (0),
Mozilla will use the X server's dpi value. Note that "viewer" does not
read the prefs file yet, due to an unrelated bug. Use "apprunner" to try
this.
If the pref is not set, it uses the default value of 96.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 7•25 years ago
|
||
In the 5/17 Linux Build, the default font size appears correctly.
Comment 8•25 years ago
|
||
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Comment 9•25 years ago
|
||
This bug is not fixed, despite the bug report. See the attached screenshot.
The line of menu items above the URL field is especially tiny; hard to read &
hard to hit.
Comment 10•25 years ago
|
||
Ooops! A few further notes. I have observed this in M12; it must have
regressed. My X server uses about 100 dpi and is AFAIK properly configured.
The attached GIF, for the problem to be seen, must be viewed at 100 dpi.
Updated•25 years ago
|
Component: Layout → UE/UI
Comment 11•25 years ago
|
||
randolph, the screenshot show no problem about this origional bug. Basicailly,
your comment reflect your psonal opinion about the usage of a small size font
for the toolbar menu. This is by-design instead of a software bug. (Although I
totally w/ you that the size is too small- in particular for CJK text).
I reassign this to our UI person to encourage they use bigger font size for ALL
their UI design. Again, this is not a software implementation bug, but a UI
design problem. The origional problem is fixed by erik.
Updated•25 years ago
|
Assignee: erik → shuang
Status: REOPENED → NEW
Comment 12•25 years ago
|
||
reassign to shung- Is that possible you can use font size > 9 for all the UI design in the futre.Font size <=9 is unreadable for Chinese/Japanese/Korean. Making is adjustable throuth CSS is not a solution since it dramatically increase L10N and QA work and cost.
Comment 13•25 years ago
|
||
Clearing WorksForMe Resolution. Moving from M6 to M14 for Beta since reopened.
shuang, please reset milestone if this is incorrect.
Updated•25 years ago
|
Assignee: shuang → german
Comment 14•25 years ago
|
||
reassign to german. german, please make final decision about default font use
for UI before M14. cc other ui folks for consistence considerations they may
have.
Comment 15•25 years ago
|
||
I think we can close this bug now that we have exposed this pref direc tly in the
prefs UI, which should remedy the problems described by the original poster.
We'll probably move this pref to the 'Advanced' section.
Comment 16•25 years ago
|
||
Having a pref is a workaround for now, but if the default size is unusable
on some platforms, we should consider increasing the default size, IMHO.
Comment 17•25 years ago
|
||
moving out to way after beta, because the pref is what we are going to have for
beta. Awaiting end user feedback after beta has been seeded, and see whether we
need to correct anything
Status: NEW → ASSIGNED
Target Milestone: M14 → M20
Updated•25 years ago
|
Summary: [PP]Unix: default font very small → Unix: default font very small
Comment 18•25 years ago
|
||
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Comment 19•25 years ago
|
||
Is this bug related to 18135
The descriptions are very very close.
Comment 20•24 years ago
|
||
I've seen a LOT of complaints from PR1 about the small font which is the default
on Unix. I also think we should set the default font larger or figure out why
some users have small fonts and others don't. Maybe the installer (if/when we
have one?) could set an appropriate default?
We should definitely release note this.
Keywords: relnote
Comment 21•24 years ago
|
||
*** Bug 30285 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
I suspect that the problem is that Unix users are accustomed to having a large
font in the UI (e.g. menubar). We currently have a very small font in the UI,
possibly because that is the norm on Windows. Perhaps one possible solution to
this problem is to use CSS "system" fonts in Mozilla's skin(s). On Unix, the
system fonts could be implemented in such a way that they are larger than those
on Windows. There are separate bug reports for the CSS system fonts on the
various platforms.
Comment 24•24 years ago
|
||
CC:ing akkana at her request.
Comment 25•24 years ago
|
||
Joining bug since 30285 was just marked as dup.
There are two issues with fonts on linux:
1. The fonts in the UI are far too small for any normal human to read. This is
what bug 30285 (fonts in chrome and dialogs) was about. There is no pref for
this font; the app is just unusable unless the user wants to play a
guessing-game about which button is what or what's in the urlbar.
2. Some Unix users, depending on their installed fonts, resolution, and prefs,
find the default font too small. The prefs should normally take care of
changing this, though it might be reasonable to worry about whether the default
is right.
If this bug tracks issue 1, then perhaps the summary should be changed to
indicate this. If it covers issue 2, then bug 30285 isn't really a dup.
Comment 26•24 years ago
|
||
It is quite clear that this bug is about the UI font. I'm updating the Summary
accordingly.
Summary: Unix: default font very small → Unix: default UI font very small
Comment 27•24 years ago
|
||
I'm not running Linux, but if "the fonts in the UI are far too small for any
normal human to read", then this should not be M20 and should be nominated for
nsbeta2.
Comment 28•24 years ago
|
||
bob, you should take a look at it in Allan's machine. Font is quite ugly and
text overlaps in chrome.I agree, it is nsbeta2
Comment 29•24 years ago
|
||
Cleared TM M20 since it conflicts with the "nsbeta2" nomination.
Comment 31•24 years ago
|
||
*** Bug 39431 has been marked as a duplicate of this bug. ***
Comment 32•24 years ago
|
||
Hi German, this bug has been nominated for nsbeta2 and approved by PDT as
[nsbeta2+], but the target milestone still says "---". I'm wondering whether
this is because you are swamped with other work. Do you need help? Or would you
prefer to make the decisions yourself and then do the work?
Updated•24 years ago
|
Severity: normal → major
Comment 33•24 years ago
|
||
This has gotten much worse with the recent skin landing. At 1600x1200 on a
vanilla Redhat 6.2 system, I can't read fonts in dialogs or in the activation
panel at all -- the letters write on top of each other. I've had to make a
user.css for myself in order to be able to use the app.
Comment 34•24 years ago
|
||
Here's what we need to can to fix it for beta2 (I assume this bug is true and
verified for both the classic and moderfn skins) We need to hardcode the an
appropriate Linux/Unix font into the window{} style rule (global.css I believe).
Since I have no clue what fonts are commonly shipped with linux and other Unixes
(I understand they are not similar to Mac/Win32), I will pass this on to Don to
assign to the appropriate X-head to make the change. Pick a sans-serif font that
is legible under the conditions described.
The tricky part is for the mdoern skin that we have *one* Theme, not three
variants for the three platforms. The challenge is to pick a set of font-families
(default, fallback 1, fallback 2) such that they look right on Win32 and Mac and
use a fallback font that ships with Linux, like:
font-family: Arial, Helvetica, LinuxFontName, sans-serif;
so Windows will trigger on the first, mac on the second and Linux on the third
font, and all others will fall back to sans-serif.
cc'd Ben, Hyatt
Assignee: german → don
Status: ASSIGNED → NEW
Comment 35•24 years ago
|
||
When I put the following in my user.css, dialogs, the mail thread window, and
mail headers become much more usable and better looking, both in Modern and Classic:
window {
font-family: helvetica !important;
font-size: 3.5mm !important;
}
This is at 1600x1200.
Comment 36•24 years ago
|
||
German,
I'm sorry, but my team can't fix this bug at the eleventh hour. (If you would
have asked for help last week then I might have been able to do something about
it. :-) As per our conversation on the phone I'm re-assigning this to you.
Neither Ben nor I like the hardcoding idea. Ben's not even sure how to fix it
the right way. My advice: ask hyatt and pavlov for help. Sorry.
BTW, I certainly sympathize with the other X-heads about the problem. :-)
Assignee: don → german
Comment 37•24 years ago
|
||
Thanks Akkana!
This will not be a problem I believe in Linux classic, we just need to set the
font on window to said 3.5mm Helvetica
As for Linux modern it seems to me the safest strategy is right now to set the
font of Window (which is not currently set at all) to Arial, Helvetica, sans-
serif 3.5mm. This should work, I'll try it out tomorrow. Taking the bug back from
Don. Setting ETA to 7/21. Akkana can you try this out by editing your global.css
under /skins/modern/ and adding the following rules under window {}:
font-familiy: Arial, Helvetica, sans-serif;
font-size: 3.5mm;
and let me know whether this does it for you. I will do the same on macOS, win32
and ask Hyatt whether the style rule would be OK overall.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 7/21
Comment 38•24 years ago
|
||
The size worked, but the font family list didn't. Apparently redhat 6.2 has an
Arial installed which is awful, very difficult to read (I can attach a screen
shot on request). If I reverse the order of the font families, i.e.
font-family : Helvetica, Arial, sans-serif;
font-size : 3.5mm;
then everything looks beautiful and readable. I tried this on a Mac, and it
looked nice there, too. Wouldn't this order work just as well on Windows (and
pick up Arial if Helvetica isn't installed)?
Comment 39•24 years ago
|
||
yep this would work for modern windows as well IMO. Hyatt, any objections?
Comment 40•24 years ago
|
||
What about
font-family : Geneva, Tahoma, Helvetica, Arial, sans-serif;
Given that Geneva is (I would think) hardly ever found on either Windows or
Unix systems, and Tahoma hardly ever on Unix, this would make all three
platforms look better, would it not?
Comment 41•24 years ago
|
||
BTW:
Tahoma does not come with every win32 system, only with the ones with Office
installed (at least on Win95, but that would be OK as Arial is likel on those
machines.
Comment 42•24 years ago
|
||
Matthew's suggestion of "Geneva, Tahoma, Helvetica, Arial, sans-serif;" with
3.5mm font-size looks fine on my RH 6.2 system.
Comment 43•24 years ago
|
||
While testing on MacOS and Win32 some more I found that the large font-size
3.5mm does not work well with certain dialogs, it's simply too large. Certain
Panels like SmartBrowsing would get cropped if we chose 3.5mm. I will
investigate.
Comment 44•24 years ago
|
||
Akkana, can you try 3mm on your RH6.2 system?
Comment 46•24 years ago
|
||
Checked in partial fix (reviewed and suggested by akkana and german) which
changes the font-fmaily but not the font-size. This oughta be something better,
at least, for beta 2.
Removing nsbeta2+, nominating for nsbeta3, and assigning to mcafee so he can
help german do this the right way.
Comment 47•24 years ago
|
||
Additional notes: 3mm is still too small on my 1600x1200 system. We all agreed
that 3.5mm looked better both on my system and on Don's 1200x1024 (?) system.
Apparently, though, 3.5mm looks too big on Mac and Windows. It's bothersome
that it would be different for Linux than for Mac and Windows; this may point to
a problem in the Linux font handling (i.e. someone may have re-broken the code
that Erik fixed quite a while ago; alas, Erik is on sabbatical right now, but
maybe we can get together and try to chase this down and get platform parity for
beta3).
Whiteboard: (PDT: this WAS nsbeta2+ earlier so don't freak out) → (PDT: this WAS nsbeta two plus earlier so don't freak out)
Comment 49•24 years ago
|
||
I also find the default settings unreadable. I've had to go to 12pt to get
something usable. That's for 1024x768 on a 17" monitor. That comes out to
about 80dpi so I've set Mozilla's screen resolution to 75dpi.
I don't think there's an easy fix because:
1) Mozilla thinks in terms of pixels while X thinks in points. Because of
this there are some round-off errors in the pixel size fields of some of the
standard unscaled (.pcf) fonts. Using pixels to select font sizes is
non-linear.
2) Mozilla tries to use the unscaled fonts to avoid "ugly looking"
rendering. Nice idea but Mozilla seems to round down which isn't good.
Add in some round-off error in Mozilla's calculations plus the usual Unix
goofiness and Mozilla often chooses unwisely. From a bash shell, you can say
NS_FONT_DEBUG=3 ./mozilla
and you can watch what happens
There are bugs filed on all of this but it's going to take some work.
I also would not assume that an X system is missing a particular font. It
didn't take me long to find the Tahoma truetype fonts. Not surprisingly,
they look worse that the standard Helvetica ones. I'm sure I could find
Geneva if I wanted to but there's no guarantee it would be the Windows one.
Comment 50•24 years ago
|
||
I don't understand this bug. The defaults are fine on my system, and I run at
2000x1500 pixels on a 125 dpi screen. It seems like the problem is that people
aren't informing their X server of the physical size of their display. For
example, by launching X with start -- -dpi 130, or setting the parameter in the
XFree config file (assuming XFree). If your X server can't properly translate
points to pixels, you can't really expect the fonts to look right.
P.S. use xdpyinfo | grep resolution to determine what X thinks your dpi is, and
refer to your owners' manual to determine the actual size of the screen. If I'm
way off base here, somebody clue me in. It just seems to me that we might be
screwing up Mozilla's defaults to make them better on poorly configured
machines.
Comment 51•24 years ago
|
||
Nav triage team: [nsbeta3+]
Whiteboard: (PDT: this WAS nsbeta two plus earlier so don't freak out) → [nsbeta3+]
Comment 52•24 years ago
|
||
> I don't understand this bug. The defaults are fine on my system, and I
> run at 2000x1500 pixels on a 125 dpi screen. It seems like the problem
> is that people aren't informing their X server of the physical size of
> their display. For example, by launching X with start -- -dpi 130, or
> setting the parameter in the XFree config file (assuming XFree).
Sure, a misconfiguration can cause all sorts of problems but your 125dpi is
outside the common 75dpi - 100dpi range. You may be using just scalable
fonts.
> If your X server can't properly translate points to pixels, you can't
> really expect the fonts to look right.
The unscaled (.pcf) fonts hardcode the pixel size and the point size fields
and the X server just accepts them so only the unscaled fonts have a
round-off problem. If you never use them, you never see this.
> P.S. use xdpyinfo | grep resolution to determine what X thinks your dpi
> is, and refer to your owners' manual to determine the actual size of the
> screen. If I'm way off base here, somebody clue me in. It just seems
> to me that we might be screwing up Mozilla's defaults to make them
> better on poorly configured machines.
I agree somewhat. I've always thought that Mozilla tries to hard to be
clever and tries to work around too many problems. I think that Mozilla
should just accept the system defaults. If they're wrong, that's the user's
problem, although a some recommendations on how to fix problems would be
nice.
However, Mozilla still has troubles on a properly configured system. On my
75 dpi machine with the standard X fonts, 3mm is ~8.8px. There is just no
available font at either 8px or 9px that I can read. Yes, the cause is X's
poor font support, but that's the way it is. If Mozilla wants to support X
server based systems, it has to deal with this.
Now 4.x uses 12pt by default for its chrome so I think Mozilla must do the
same thing. If that means a loss of cross-platform purity, tough.
Comment 53•24 years ago
|
||
larger 3.5mm size requires 12 pref panels to be relaid-out/squished:
fonts, Navigator, Smart Browsing, Mail and Newsgroups, Viewing Messages,
Composing Messages, Disk Space, Composer, Cookies/Images, Forms and Passwords,
Desktop Integration, Debug. Possibly other panels on commercial build.
Comment 54•24 years ago
|
||
*** Bug 40888 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
pref panels have been fixed, 3.5mm font looks Ok on Linux, Win32,
but NOT on Mac (too big?). Need help on Mac.
Updated•24 years ago
|
Priority: P2 → P1
Comment 56•24 years ago
|
||
3.5mm = 9.96pt so why not just use 10pt; it would make more sense.
Comment 57•24 years ago
|
||
Sure, that would be okay too.
Comment 58•24 years ago
|
||
Bah, nothing is ever easy. If I set browser.display.screen_resolution 75
to match my system, use the standard X fonts, and set the default chrome
to 10pt then Mozilla should look for a 10pt font.
I know Mozilla thinks in pixels but 10pt is 10.4px@75dpi so it should
have rounded to 10 and found something like
-adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 which is a
standard X font. Instead it seems to have settled on 11px and chose
-adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso8859-1. Too bad
that's 8pt at the wrong resolution. It should be no surprise that the
75dpi and 100dpi bitmap fonts do not have exactly the same metrics so
the result is a rendering that's too small.
I have no idea why it thinks 10 is 11 but that's certainly a problem.
There's also bug 40373 on why Mozilla should use points when talking to
an X server.
Comment 59•24 years ago
|
||
Investigating platform-specific style rule for this.
Linux & Win32 look ok, Mac looks huge with this change.
Comment 60•24 years ago
|
||
The geneva font _is_ huge. I installed it on my Linux system and it renders
significantly larger that Tahoma or Helvetica.
Comment 61•24 years ago
|
||
Aha! Do we need to use Geneva? Could we drop that and just use Helvetica,
Arial, Sans Serif, so Unix and Mac would both pick up Helvetica?
Comment 62•24 years ago
|
||
We still have a problem with font size, Mac wants to specify
fonts in pixes and Win32/Linux want to use points/mm.
Comment 63•24 years ago
|
||
Erm, the idea behind using Geneva on Mac is that using *anything* besides Geneva
10 (or 9, at a pinch) on Mac, Helvetica included, looks pretty crappy to your
average Mac user.
But Mac Classic is using Geneva 10 already, and I would guess that the number of
Mozilla users on Mac who will use the Modern skin will be in the single figures,
so you may not care about this. :-)
Comment 64•24 years ago
|
||
Now now Matt, I sense some negative vibes here :-) you will see lots of people
use modern, as they do today with Netscape 6, yes even on a Mac.
I hate to bring this up but does Arial solve the problem? Arial looks better
on-screen on a Mac and would render similar on Win32. Only philosphical problem
is that Arial on Mac comes bundled with any newer Mac due to the fact that IE
that comes with MacOS also throws the MS fonts onto the Macs. Helvetica and
sans-serif could then still be the back up fonts in case Arial was not on the
machine.
Comment 65•24 years ago
|
||
pref layout work is done, we should find a reasonable
fallback font list and hope the larger font works on Mac.
I think my part of this bug is done, I really need help
with the Mac issue, over to german for a look.
Assignee: mcafee → german
Comment 66•24 years ago
|
||
There are still some font mysteries. See bug 47582 for an example. It may be
very hard to find a set of font names that will work even halfway well on all
platforms, not to mention the fact that you can do all sorts of tricks with
fonts.* files on an X server
Comment 67•24 years ago
|
||
German: using Arial won't solve the problem (at least in XP chrome) because
listing Arial first will bring back the Linux problem with Arial that we just
fixed for M17.
Comment 68•24 years ago
|
||
Comment 69•24 years ago
|
||
a mac side note, see attachment above - the standard helvetica bitmap should
never be an option for a mac display font, it is of very poor quality. that's
one vote to place helvetica further towards the end of the list. possibily remove
it entirely if, there are no other cross platfrom system dependencies.
Comment 70•24 years ago
|
||
That's too bad, since on Linux it's the opposite (at least with our app; I think
we may be doing something evil when it looks for arial, though, since it's not
obvious to me that my system actually has arial installed at all).
Will attach a screenshot of arial vs. helvetica on my redhat 6.2 machine.
Comment 71•24 years ago
|
||
Comment 72•24 years ago
|
||
I talked with hyatt, if we cannot get the fallback hack to work
(and it *is* really a hack), we should go with platform-specific
style sheets and throw the font family and size stuff in there.
Yeah "it sucks" but I can think of lots of other things that "really
suck" so I'll need a better arguement than that.
german, give this back to me if we decide to go with platform-specific
style sheets.
Comment 73•24 years ago
|
||
Not that my opinion matters much, but I think a platform.css with the right
precedence would solve the problem with a minimum of effort; there certainly
are more important things to deal with. Place outside of any skin it could help
enforce standards on all skins.
Comment 74•24 years ago
|
||
This looks pretty good with the new modern skin. Not critical to stop ship.
Low profile polish. Moving to P3. Adding [PDTP3]
Priority: P1 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
Comment 75•24 years ago
|
||
I think it looks good on Mac and Win32 now. Barring any major objections I'd
like to take the "+" of this bug. Linux? Mac?
(Also I am worried about Theme Designers wanting to create just one theme and
get that to work across platforms.)
Comment 76•24 years ago
|
||
Well, someone just checked in a 9px font in the new modern theme, which of
course is non-device-independent and practically unreadable on a high-resolution
device. Personally, I would leave the + until it can be shown that theme people
are paying attention to font size issues.
Comment 77•24 years ago
|
||
Has anyone looked at directory or ftp listings recently? They are impossibly
small and they don't seem to want to change size. This isn't over, yet.
Comment 78•24 years ago
|
||
For me, the worst of it is the personal toolbar, where the glyphs are miniscule,
and actually missing some strokes. Status bar text is too small to read too.
Comment 79•24 years ago
|
||
Tooltips are just as small. It's because the modern skin specifies absolute
sizes more than once. I've filed bug 51515 on this. Should this bug depend on
that?
Comment 80•24 years ago
|
||
Actually, for me, the fonts on the Classic skin are much smaller than the fonts
on the Modern skin (though they're both too small). This isn't a gtk setting;
when I bring up gnome apps (though I use kde on this machine), their menu font
is significantly bigger than the font used by either Classic or Modern.
Comment 81•24 years ago
|
||
akkana, trudelle: is Mozilla's dpi set to the right setting in your prefs? If
your pref dpi is set lower than your actual dpi, the chrome fonts are all too
small.
On all my machines most of the chrome fonts are the right size if and only if my
display, X, and mozilla all agree on the dpi. This is true on displays of 75,
100, and 125 dpi.
Comment 82•24 years ago
|
||
My true dpi is approximately 100. Mozilla's setting is 96 (and I think it
rounds, so setting it to 100 would probably gain me nothing). The X server
thinks I'm at 75: it's XFree86, set up via Redhat 6.2's normal setup for this
resolution and this monitor; I know I can change that, but I've avoided doing so
because most users won't and I persist in thinking that we should work with
configurations generated by installation programs, not just expert users who
know how to hand-configure their X servers.
Comment 83•24 years ago
|
||
That's fine, but if we break fonts for those of us with properly configured
displays, that will not be very cool. Since RH 6 is the only Unix that is an
official 1st-tier platform, why don't we evangelize them to fix their XFree
install procedure?
Actually, if Moz thinks you have a 100 dpi display, and you do have a 100 dpi
display, and Moz is requesting fonts based on their pixel size, I can't imagine
why that doesn't work. Perhaps your 75 dpi fonts are listed before your 10 dpi
fonts? I have no other good ideas.
Comment 84•24 years ago
|
||
Well, I guess I'm not sure what my actual DPI is, how can I tell? I think it is
around 100 dpi though, and changing it from 96 -> 100 -> 125 doesn't seem to
have any effect on the problem fonts. Wouldn't changing it to 75 make all fonts
even smaller? The fonts in the content are okay, I don't want to change them.
Comment 85•24 years ago
|
||
For whatever reason, the content area does not respect the prefs dpi setting, so
you are not in danger of messing up the content fonts.
If you want to know your display's resolution, determine the pixel resolution
(e.g. 1024x768), and the physical size (e.g. 15.9" diagonal), and use math.
The dpi is h/(4*sqrt(d^2/25)), where h is the horizontal resolution in pixels
and d is the diagonal size in inches. For example, a 15.9" diagonal monitor
running at 1600x1200 has a resolution of 125 dpi.
Comment 86•24 years ago
|
||
but math is hard! ;-) Thanks, that puts me at 102, so I guess my setting was
correct.
Comment 87•24 years ago
|
||
> For whatever reason, the content area does not respect the prefs dpi setting,
> so you are not in danger of messing up the content fonts.
That depends on the content. If the content uses "pt" units, the dpi pref *will*
have an effect. Ditto for in, mm, etc, but not px.
Comment 88•24 years ago
|
||
In the 2000-09-07-08 nightly, the personal toolbar font is specified at an
unreadable 11px. See bug 51748 which I posted on this issue.
Comment 89•24 years ago
|
||
So, am I missing something or is this P3 bug -- destined to automatically
become nsbeta3- tomorrow anyways -- not going to get fixed for beta3,
especially considering it's not assigned to an engineer? Removing nsbeta3+ for
reevaluation.
Whiteboard: [nsbeta3+][PDTP3]
Comment 90•24 years ago
|
||
I love how bugs get marked + for every beta, then just ignored month after
month. Oh, well, we obviously don't really care whether Linux users can read
the UI in our app.
Comment 91•24 years ago
|
||
you can also blame CSS for this because it assumes that font families and font
lists, should be independent of a particular size. The spec would be more
typographically sound if each font name parameter had it's size counterpart,
since typefaces have widely varying proportions and characteristics. Some are
bitmaped well at 12 but not at 11 or 10 for example, so you cant expect a entire
list of fonts, to work well at the same exact screen size.
The only solution I can see is that we use platform specificness in this
situtation. otherwise we are sacrificing quality for consistency
Comment 92•24 years ago
|
||
Actually, CSS makes allowances for that. We just don't implement the code that
would solve that particular problem. ('font-size-adjust')
Comment 93•24 years ago
|
||
Actually, Mozilla will have to implement read-only @font-face support before it
can use font-size-adjust properly. @font-face is a good idea anyway because we
need a way to combine various physical fonts into one family with appropriate
rules.
BTW, the CSS docs use the Verdana font to illustrate the use of dont-size-adjust.
Mozilla seems to have fallen into a known trap.
Comment 94•24 years ago
|
||
Marking nsbeta3- until this bug can be assigned to an engineer.
Whiteboard: nsbeta3-
Comment 95•24 years ago
|
||
If you guys are really serious about pushing a Linux Mozilla out the door, all
you really have to do is:
1) fix bug 51515 so that there is exactly one place where the font size is set.
The classic skin does this, the modern skin does not.
2) ship a Linux userChrome.css or, at the very least, a userChrome.css.sample.
3) Mention in the release notes how to deal with umreadable fonts.
I don't see what the big problem is.
Updated•24 years ago
|
Assignee: german → don
Whiteboard: nsbeta3-
Comment 96•24 years ago
|
||
Handing German's bugs to Don.
Comment 98•24 years ago
|
||
Changing relnote keyword to relnote3.
Comment 99•24 years ago
|
||
Taking off the beta 3 radar and nominating for RTM.
Keywords: rtm
Whiteboard: [need info] → [nsbeta3-][need info]
Comment 100•24 years ago
|
||
I really need to get to the bottom of this one ...
Priority: P3 → P2
Whiteboard: [nsbeta3-][need info] → [nsbeta3-][RTM NEED INFO]
Comment 101•24 years ago
|
||
Adding alecf to "cc" list so he can save my ass.
Comment 102•24 years ago
|
||
If we just used the system font in the modern skin, like we do in the classic
skin, it would solve the problem. That would really be the best solution since
it respects the user's preferences and eyesight.
Comment 103•24 years ago
|
||
I don't think the answer is that simple. New Modern seems to have literally
been drawn in photoshop and then hacked into XUL/CSS pixel-for-pixel. For
example, the buttons in new modern will not scale vertically. You can change
your chrome font size if you want, but tall fonts will simply flow out through
the bottom of the fixed-pixel-sized buttons.
It's depressing, yes, but the solution requires a major re-thinking of the New
Modern implementation. I'm using Classic :)
Comment 104•24 years ago
|
||
there's a change going in very soon for RTM which will give us scalable buttons
and widgets. it's already been plussed, we're just waiting to check them in.
Comment 105•24 years ago
|
||
Marlon, to which bug are you referring?
Comment 106•24 years ago
|
||
A quick remark:
Lets set up some reasonable criteria by which we call the theme font selection
successful on Linux (here is an example):
should be large legible enough for the following resolutions on those monitors:
- 800 * 600 on 15"
- 1024 * 768 on 17"
- 1280 * 1024 on 19"
etc.
I have seen people use (especially on Linux) 1600 * 1200 on 17" and 19" screens
and I would not call this a typical or even healthy resolution. lets avoid
optimizing for fringe cases, at least not at the cost of the 95% user case.
Comment 107•24 years ago
|
||
Xwindows is inherently a variable dpi system so Mozilla's inability to
deal with this exposes a fundamental flaw in its design. Obviously, it's
too late right now to address this.
Xwindows also has a relative scarcity of usable fonts and those are
available only in a few sizes. Since it can't anti-alias, it's attempts
at scaling are usually laughable. You might wish it weren't so but it's
a fact of life. To me, this means that you have to simplify the skins
which, in turn, means you can't make fancy font choices which, in turn,
means a skin should use precisely one font size. Yep, it's ugly. Yep, it
an affront to everyone's sensibilities but it *is* necessary.
Finally, note that 800x600/15" and 1024x768/17" are closer to 75dpi than
100dpi and also that XFree86 defaults to 75dpi. A fresh Mozilla will
ignore the OS value and *assume* 96dpi. In theory, this works; in
practice, it often doesn't. Mozilla is in the difficult position of
justifying why it ignores the OS values, particularly when they may well
be correct. This, in turn, makes it difficult for you to justify any errors.
Comment 108•24 years ago
|
||
don - bug #54105
Comment 109•24 years ago
|
||
If the buttons in New Modern are going to be rescalable, I'll reiterate my plea
for using the CSS system font.
Assignee | ||
Comment 110•24 years ago
|
||
it seems wrong that we default to 96DPI right off the bat.. .it seems like we
need to add this line to unix.js:
user_pref("browser.display.screen_resolution", 0);
this will cause mozilla to take on the OS default screen resolution.
If the user's machine is screwed and has the wrong DPI, then they should
override it the prefs....
Does this sound good enough to take us through Netscape's RTM?
Comment 111•24 years ago
|
||
It sounds SO good, that I'm re-assigning this to you. :-)
Hell, go ahead and work up the change! When you have a reviewed patch, let me
know and I'll mark this "rtm+".
Assignee: don → alecf
Comment 112•24 years ago
|
||
1. Note that the DPI stuff only affects font sizes that are given in "real"
units, e.g. pt (points), in (inches), mm (millimeters), etc. So if the font(s)
targetted by this bug report use other units like px, then fixing the DPI stuff
won't affect the UI font sizes.
2. It might be a good idea to clearly define the boundaries of this bug report.
I.e. do we want to fix the font size in all of the themes, or just the default
theme?
Assignee | ||
Comment 113•24 years ago
|
||
Comment 114•24 years ago
|
||
r=erik for the patch attached 10/03/00 13:58
What about the other questions that have been asked? E.g. the default theme, or
all themes? Using CSS "system" fonts in one or more of the themes?
Comment 115•24 years ago
|
||
I think this bug just applies to the 'Modern' theme as this is the only one with
a cross-platform font CSS setting. (like many subsequent themes will have where
designers will not want to go through the effort of creating 3 platform specific
versions).
Assignee | ||
Comment 116•24 years ago
|
||
ok, adding that pref on my system, which is 1280x1024 on a 21" monitor makes
everything look really bad.
Then I discovered that I'm running at 75dpi. I actually measured the screen
with a ruler: it's 12x16", which would make it about 85.3dpi. I entered this as
my screen resolution, and the menus are exactly 8 pixels high, and an "e" is 4
pixels wide.
On windows, the menus are 9 pixels high, and an "e" is 5 pixels wide. This means
that in pixels, the menus are about 13% taller and 25% wider, which would
explain why menus look a bit bigger there.
When I increase my preference to 100dpi, I get 9 pixel high menus, and a 5
pixel-wide "e" Seems to me like we have some kind of rounding or calculation
error such that a correct DPI of 85 does not give us a 9-pixel font. I'm going
to try to see what the threshold is
This is all with the modern skin on both platforms.
So here is what I think we need to do:
- add this pref, which will make things look bad
- in the release notes, explain how to change the DPI on XFree86. The only way I
can find is "startx -- -dpi 100" or edit your Xservers file. We should suggest a
few defaults like 85, 96, and 100.
- fix this rounding error. Anyone know where we should look?
Comment 117•24 years ago
|
||
With XFree86 4, you can specify the physical screen size in millimeters with the
DisplaySize directive in the XF86Config file. The syntax is:
DisplaySize width height
Example:
DisplaySize 327 243
The physical screen size is normally found in the display's owner's manual.
Comment 118•24 years ago
|
||
The rounding is performed in mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp, in
nsFontMetricsGTK::Init(), where it is setting mPixelSize.
Assignee | ||
Comment 119•24 years ago
|
||
Ok, after a binary search with some font resolutions, I found that on my screen
(1280x1024 on a 21" screen, true resolution of 85dpi) there is a threshhold
between 99 and 100dpi that gets me 9 pixel menus:
at 99dpi I get 8 pixel menus
at 100dpi I get 9 pixel menus
I don't know if this is signifigant, but what this means is that there is no
difference between entering my real resolution (85dpi) and the suggested DPI in
the prefs (96dpi)
There is a similar threshold between 82dpi and 83dpi, for 7 pixel and 8 pixel
fonts.
Assignee | ||
Comment 120•24 years ago
|
||
ok, more interesting stuff. it seems that in nsDeviceContextGTK::SetDPI(), we're
hardcoding a variable pt2t, which I think is points-to-twips, to 72. When I
lower this number (it's the numerator in the calculation of mPixelsToTwips, and
the divisor in mTwipsToPixels) I get some decent fonts.
When I set this number to 60 instead of 72, I get 9 pixel menus at 85dpi! (I
also tried setting it to 50 and I got giant 12 pixel menus, doh!)
This is basically what _I've_ been shooting for. Does anyone object to this as a
goal - 9 pixel menus at the correct resolution for your machine? If so, I'd like
to consider changing pt2t to a reasonable number lower than 72.
Erik: where did the original 72 come from? Is it reasonable to lower this to 60?
Everyone else who wants to help: Can people with other resolutions try this:
- Determine your TRUE dpi: Measure the width of the display area of your
monitor, in inches. Divide your horizontal resolution (i.e. 1280, 1600, etc) by
this number.
- edit gfx/src/gtk/nsDeviceContextGTK.cpp and change line 514 so that pt2t is
60.
- start mozilla. Use XV or a similar tool to zoom in on the menu and count the
height of the capital "F" in the File menu.
- if you have time, experiment with values of pt2t.
Now answer the following questions:
----
Monitor/pixel dimensions: (i.e. 16"x12" at 1280x1024)
DPI used: (e.g. 85dpi - as set by your X server, or as overridden by mozilla)
Font size with pt2t=60: (e.g. capital letters are 9 pixels high)
Font is too big/too small/perfect for my tastes:
---
and post results here (make sure someone else has not already entered your
screen resolution)
Comment 121•24 years ago
|
||
That isn't the solution at all. There are 20 twips to a point, regardless of
the output device resolution.
Assignee | ||
Comment 122•24 years ago
|
||
well, pt2t is currently 72, so I guess that means that it's not points-to-twips.
You got me.
Here's the relevant calculation:
mPixelsToTwips = float(NSToIntRound(float(NSIntPointsToTwips(pt2t)) /
float(aDpi)));
mTwipsToPixels = 1.0f / mPixelsToTwips;
Comment 123•24 years ago
|
||
No, please do not change the 72. I don't know who wrote that code, but "pt2t" is
a terrible name for that variable. 72 is the number of points (pt) per inch, and
it is fixed (not a variable). The calculations in SetDPI() are basically
correct, although it is performing some rounding that may require further
investigation.
Assignee | ||
Comment 124•24 years ago
|
||
ok, experimenting with the rounding to see what I can find.
Status: NEW → ASSIGNED
Comment 125•24 years ago
|
||
>Does anyone object to this as a
>goal - 9 pixel menus at the correct resolution for your machine?
I object rather strongly to this goal. Remember that this DPI code is used for
*all* fonts using physical sizes (pt, in, mm, etc) in Mozilla -- both in the UI
and in the content. I think we should take a closer look at the theme (themes?)
to see exactly what they are requesting, and check whether Mozilla is doing the
right calculations for those requests, including the DPI value.
If the theme is asking for N points, then the number of pixels should *vary*
from resolution to resolution. (It shouldn't be a constant 9px.) If the theme is
asking for 9px, then we should get 9px on every screen, regardless of DPI value.
Comment 126•24 years ago
|
||
Yes, it would be a great mistake to redefine the point. What happens is a page
wants 36pt or 0.5 in fonts?
There is an interesting point (yes I meant that) here. I do like letters that
are about 9 or 10 pixels high. To get them on my 75dpi system I have to
force 12pt.
12pt is also "special" since it is, by far, the most common font size specified
int all the XFree86 distribution. Look at the app defaults, or the font aliases,
or the font server config files. I do believe they know something.
Comment 127•24 years ago
|
||
Forgot to add that mozilla/xpcom/ds/nsUnitConversion.h has a fairly large set
of conversion functions. Perhaps they weren't available when the code was written.
I also hate to harp on this but talking pixels to the X server is a mistake.
Assignee | ||
Comment 128•24 years ago
|
||
you're right eric, I'm not sure what I was thinking a few hours ago since
pixels-per-inch will vary from machine to machine. I think the true DPI of a
monitor is going to be the only real way to compare & contrast machines.
I guess maybe what we need to do is figure out how the modern theme sets it's
menu font size, and decide on a correct pixel value at 75, 85, and 100DPI?
Ultimately I'd like to express this in pixels so that it can be verified once
and for all. At 85dpi I would personally like to see 9 pixel menus. How about
75DPI? 100DPI? Measure your monitor, play with the resolution preference, and
post here.
Assignee | ||
Comment 129•24 years ago
|
||
ok, more interesting information. With the following patch, the thresholds I
described above move to 80/81dpi and 97/98dpi. The difference between the old
calculation and the new calculation is about 0.34%
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp,v
retrieving revision 1.67
diff -u -r1.67 nsDeviceContextGTK.cpp
--- nsDeviceContextGTK.cpp 2000/09/14 18:57:05 1.67
+++ nsDeviceContextGTK.cpp 2000/10/04 00:05:41
@@ -514,8 +514,8 @@
int pt2t = 72;
// make p2t a nice round number - this prevents rounding problems
- mPixelsToTwips = float(NSToIntRound(float(NSIntPointsToTwips(pt2t)) /
float(a- mTwipsToPixels = 1.0f / mPixelsToTwips;
+ mPixelsToTwips = NSFloatPointsToTwips(pt2t) / float(aDpi);
+ mTwipsToPixels = float(aDpi) / NSFloatPointsToTwips(pt2t);
// XXX need to reflow all documents
return NS_OK;
Comment 130•24 years ago
|
||
I use 1600x1200 on a 21" (which is actually about 15.5" wide, so actual dpi is
just over 100). The gtk "system" menu font (the font I get by default in gnome
app menus) is 9 pixels high.
If we ended up showing most people 9 pixels, it would probably be okay for most
people, but would leave visually impaired people without anywhere to go (unless
they knew to switch to the Classic skin).
Comment 131•24 years ago
|
||
I object to all this guessing. We should figure out a *real world* size (not
pixels) that is comfortable for normally-sighted people. I choose 12 points.
12 points is also a good size because the two most universal X fonts are Adobe
Times and Adobe Courier, both of which look spiffy at 12 points.
On my laptop which is 100 dpi, the font should be rendered 16.67 == 17 pixels
high. On my desktop, which is 130 dpi, the font should be rendered 21.67 = 2
pixels high.
In any case, the font should be chosen by the following algorithm:
pixles = round(font size in pt / 72 pt per in * resolution in dots per in)
Then Mozilla should request the font in that point size, and my X server will
choose the font which best matches given the font's scalability, etc.
The final question is how do we choose the font point size in this equation?
Simply, we ought to use the system font size where available. In no case should
we start out by specifying the pixel size, which is sadly what New Modern does
everywhere.
Comment 132•24 years ago
|
||
> Then Mozilla should request the font in that point size, and my X
> server will choose the font which best matches given the font's
> scalability, etc.
Actually, the X server doesn't choose, the app does. Mozilla is
reasonably smart but can be better.
> ok, more interesting information. With the following patch, the
> thresholds I described above move to 80/81dpi and 97/98dpi. The
> difference between the old calculation and the new calculation
> is about 0.34%
0.34% should not make a big difference. The fact that it does
illustrates that there's something smelly in the chrome. I'm going to
attach a zip file with some examples of how fragile Mozilla is.
I must say that there is the implicit assumption going around that the X
code must be broken because Mozilla looks different than on Windows or a
Mac. I see no reason to assume that. The GTK code acts properly as far
as I can see. Instead of hacking the X code at the drop of a hat, it's
time to figure out how to make a cross-platform browser, not a Windows
one with tacked-on X support.
Comment 133•24 years ago
|
||
Comment 134•24 years ago
|
||
Actually Mozilla can only request fonts from the X server, and the X server
really is free to return something other than the requested font. For example,
if only :unscaled fonts are in my font path, X will return Times 12pt if Times
13pt is requested.
The only way Mozilla could get around that is by including its own font renderer
and screen blitter.
Comment 135•24 years ago
|
||
Well, yes if a program is silly enough to do that. Mozilla isn't. A call to
XListFonts reveals what is and isn't available.
Comment 136•24 years ago
|
||
I take that back. X will not fake things. Consider this with :unscaled.
--->xlsfonts -fn '-adobe-helvetica-medium-r-normal--43-*-*-*-p-*-iso8859-1'
xlsfonts: pattern "-adobe-helvetica-medium-r-normal--43-*-*-*-p-*-iso8859-1" \
unmatched
--->xlsfonts -fn '-*-helvetica-medium-r-normal--x-*-*-*-p-*-iso8859-1'
xlsfonts: pattern "-*-helvetica-medium-r-normal--x-*-*-*-p-*-iso8859-1" \
unmatched
It all depends on what question you ask.
Assignee | ||
Comment 137•24 years ago
|
||
0.34% doesn't seem like a big error I realize, but that error can grow depending
on how the numbers are manipulated. I was just saying that THAT particular
calculation was off by 0.34% - the actual calculation of font size could be off
by some multiple of that.
Also, understand that we're not implying that X is broken. It's mozilla's
X-specific code that is slightly busted. gtk must have a dpi-independant way of
choosing fonts. If a gtk-enlightened person wants to chime in and tell us what
they're doing, I'll be very pleased.
Comment 138•24 years ago
|
||
> Created an attachment (id=16118)
> 110K zip file showing current screenshots
Thanks for the screenshots. I'm not going to claim that the Unix Mozilla font
code is perfect, but I would also take a good look at the theme(s) to see what
they're requesting (and whether that's correct/appropriate).
Also, I realize that this bug report is out in the open (on bugzilla), but is
Netscape 6's default theme different from Mozilla's? (Silly question, but I have
to ask...)
Comment 139•24 years ago
|
||
Re tenthumbs' comment about looking different on Linux than it does on Windows:
the problem is not that they look different, it's that mozilla running on
Windows is readable while it isn't on Linux, using exactly the same resolution
and monitor. They needn't look the same, but if we don't make an effort to see
that mozilla on linux has the same level of readability it does on windows using
the same hardware, then we're penalizing linux users and encouraging them to
switch to windows or another browser.
Assignee | ||
Comment 140•24 years ago
|
||
Assignee | ||
Comment 141•24 years ago
|
||
Assignee | ||
Comment 142•24 years ago
|
||
you know, I don't see ANY place in the modern skin where the "default" font size
is set. Could we be falling back to some horrible system default?
Assignee | ||
Comment 143•24 years ago
|
||
ugh, there are typos with the 14 pixel/point samples in that file.
But with that sample page (typos fixed) on my system at 85dpi,
nsFontMetricsGTK::mPixelSize is getting set to: (with corresponding float that
it got rounded from)
8 point: mPixelSize = 9 (9.44444)
10 point: mPixelSize = 12 (11.805555)
12 point: mPixelSize = 14 (14.166666)
14 point: mPixelSize = 17 (16.527777)
8 pixel: mPixelSize = 8 (8.0277778)
10 pixel: mPixelSize = 10 (9.975694)
12 pixel: mPixelSize = 12 (11.982639)
14 pixel: mPixelSize = 14 (13.989583)
I find it interesting that the pixel-based font sizes don't match exactly, but
it's only off by about 0.07%
If I go back to the old method of calculating the mPixelsToTwips/etc, then the
pixel-based fonts nail the right sizes, no rounding required. I guess this isn't
surprising because we're basically pre-rounding during calculation anyway.
Comment 144•24 years ago
|
||
<erik> but is Netscape 6's default theme different from Mozilla's?
Yes. Netscape 6 defaults to modern, Mozilla defaults to classic.
Comment 145•24 years ago
|
||
I created a simple test file combo ( a xul file and a css file) that lets you
see the effects of using all 6 available system fonts. I am going to upload
those 2 files to the bug in a moment for external use. Internal users can simply
click on http;//blues/users/german/publish/openLocation2.xul when this is viewn
within NS6 or Mozilla.
Comment 146•24 years ago
|
||
Sorry I meant http://blues/users/german/publish/openLocation2.xul
Comment 147•24 years ago
|
||
Comment 148•24 years ago
|
||
Assignee | ||
Comment 149•24 years ago
|
||
Ok, talked with Erik. Here's what it LOOKS like. The modern skin is not
specifying a default size for fonts, so it seems to be falling back to a
12-point font.
This is happening here:
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsPresContext.cpp#82
However, Erik said he saw it trying to get a 170 twip, aka 8.5 point, which
would certainly explain the tiny fonts. So the 12-point fallback may actually be
a red herring. The next step is to figure out where this 8.5 is coming from. The
quick-hack fix would be to override this 8.5 default on unix to be 12 point or
something.
It seems like the "real" fix is to start using a system font like the "dialog"
font. The problem with this is that the modern skin is not scalable.
Specifically, the status bar and the url bar are not scalable. This means if we
switch to the system font on windows and mac, which currently use a hardcoded
font family and default font size, the skin will look odd. Compounding this is a
bug where images wont scale in certain situations on Linux.
(though the rounding bug should still be fixed)
Because this has gotten so large, I'll be marking this INVALID later today and
dividing it up into a few issues:
- the rounding bug
- using the "system" font in the modern skin
- fixing the modern skin so that the url bar and status bar are scalable
- fixing the linux image scaling issue so that we can scale the status bar.
I'll post bug numbers here when I have them.
Comment 150•24 years ago
|
||
I wouldn't get all that excited about round-off errors. There are errors in the
pixel_size field of some of the X bitmap fonts. That's one reason you really want
to talk in points to the X server.
8.5pt = 3mm which is a number that seems to crop up a lot.
And what is a system font in Unix anyway?
Assignee | ||
Comment 151•24 years ago
|
||
Whatever.
Assignee | ||
Comment 152•24 years ago
|
||
ok the bugs are:
bug 55463 - modern skin should use system fonts
bug 55464 - modern skin statusbar and urlbar not scalable
I want to make a reproducable testcase before I file the image scaling bug.
After talking to hangas, it soundsl like the image scaling bug isn't required to
make the statusbar/urlbar scalable.
Assignee | ||
Comment 153•24 years ago
|
||
ok, marking this WONTFIX once and for all - the issues should be covered by the
bugs I just filed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Comment 154•24 years ago
|
||
Noting the comments about Helvetica on the Mac (and the suggestion to use Geneva
instead): there is also a problem with Geneva. In both cases, the main difficulty
is the antialiasing (as previously mentioned) and simply changing to Geneva would
not fix the problem (at least on my sys9 implementation).
The only real fix is on the user end: Control Panels -> Appearance and click
off the antialiasing. At that point, *all* fonts behave better.
I have particularly noted both Arial and Geneva failures in windows *other
than* system windows -- in apps, basically. There is no single font I know of
that's safe, but there is also none that is more drastically ruined than
Helvetica (that I have seen).
This is G3-233 beige Sys9.0.
I use Helvetica as the normal user font on Mac, Linux and Windows. This
problem is only on the Mac, only system 9, and only with the (default) lousy
antialiasing (there is no similar problem on windows).
I have no suggestion for how this could be fixed in Mozilla (wontfix is
inevitable). Mac is singlehandedly ruining helvetica.
On the other hand, macusers who turn off the antialiasing will get it back
(if my system is any indicator).
Updated•23 years ago
|
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•