Closed
Bug 172779
Opened 22 years ago
Closed 22 years ago
Xft builds need better font pref defaults
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dbaron, Assigned: blizzard)
References
Details
Attachments
(2 files, 3 obsolete files)
59.49 KB,
image/png
|
Details | |
4.13 KB,
patch
|
jag+mozilla
:
review+
|
Details | Diff | Splinter Review |
Xft builds don't have good font pref defaults when starting them for the first
time and going to the font prefs dialog. For non-xft builds, the defaults in
unix.js work, but for Xft builds they aren't part of the list of fonts. There
are a number of possible solutions that I can think of:
* Use different font pref names for Xft font prefs. This would have the
advantage of allowing Xft and non-Xft builds to coexist on the same profile, but
the disadvantage of complicating the font prefs UI a lot.
* Add an additional preferences default file in addition to unix.js, with
defaults for Xft that would override the defaults in unix.js. I think there's a
way to do this. This seems like a "good enough" solution, especially for
distributors (who could even just patch unix.js directly).
Reporter | ||
Updated•22 years ago
|
Blocks: xft_tracking
Updated•22 years ago
|
Component: Layout → Layout: Fonts and Text
Assignee | ||
Comment 1•22 years ago
|
||
This is a patch that adds the idea of a "system default" to the fonts dropdown.
Needs to be localized so it's not done yet.
Assignee | ||
Comment 2•22 years ago
|
||
Localization added. Not tested with anything but Xft fonts. Need to do a bit
more testing.
Attachment #112195 -
Attachment is obsolete: true
Assignee | ||
Comment 3•22 years ago
|
||
Forgot the manifest change.
Attachment #112282 -
Attachment is obsolete: true
Assignee | ||
Comment 4•22 years ago
|
||
This is what the fonts panel looks like with this patch.
Comment 5•22 years ago
|
||
Comment on attachment 112317 [details] [diff] [review]
patch
Instead of doing the whole string bundle thing, add another <stringbundle> to
pref-fonts.xul, or just add this string to the prefutilities.properties file.
After the while loop, strDefaultFontFace will always be "DEFAULT". Is that what
you meant?
Assignee | ||
Comment 6•22 years ago
|
||
Patch that addresses jag's comments.
Assignee | ||
Updated•22 years ago
|
Attachment #112317 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #112764 -
Flags: review?(jaggernaut)
Comment 7•22 years ago
|
||
Comment on attachment 112764 [details] [diff] [review]
patch
+ try {
+ sysDefaultStr = gPrefutilitiesBundle.getString("systemDefault");
+ }
+ catch(e) {
+ sysDefaultStr = "[System Default]";
+ }
Typically we don't try/catch on getString(), based on the reasoning that we're
not expecting this to fail unless we screwed up (as opposed to, say, something
timing out or unexpected (user) input).
r=/sr=jag
Attachment #112764 -
Flags: review?(jaggernaut) → review+
Assignee | ||
Comment 8•22 years ago
|
||
I'm not sure what happens if someone is using a language pack that is missing
that string. That's why there's a try/catch block there.
Comment 9•22 years ago
|
||
Ah, hrm. So far I think we've relied on versioning of language packs and authors
keeping their language packs up to date.
Comment 10•22 years ago
|
||
Not sure if that's the best strategy, but hardcoding the English strings in some
fallback code "just in case" doesn't seem much better generally speaking.
Assignee | ||
Comment 11•22 years ago
|
||
ftang + rbs - can you guys look at the screenshot here and tell me if you think
this is sane?
Comment 12•22 years ago
|
||
Looks sensible but I was wondering if it wouldn't be more user-friendly to find
out (programmatically) what that mysterious system/browser default is going to
be, and then select that. Right now the user is somewhat left in the dark as to
what is the actual font being used. How do you ultimately find out the system
default? Might be nicer to let it come to the user, no? (e.g., by saving it in
the pref, or by extending one of the nsIFontList API so that it can be obtained
via JS). [Also, there is the option of overwriting unix.js as initially proposed].
I just cc:ed you on bug 142511 which is a proposal to make the font choices more
extensive.
Assignee | ||
Comment 13•22 years ago
|
||
I thought about trying to display what the default font would be, if you
resolved it. However, there are a couple of problems with doing that:
1. The default font is really a _list_ of fonts, not so much a single font,
depending on what unicode you throw at it. Are we going to show a list? The
first font in the list? I thought that would just confuse things further.
2. Do we save the new default? The default font for the system can change,
depending on what fonts you have installed at least with Xft. I thought this
might cause more confusion down the road, too.
As for bug 142511 I thought that displaying all the fonts (or grouping them) was
a fine idea. I'm all for it.
I'd also like to see a preview area at some point in the future.
Comment 14•22 years ago
|
||
Ah, glad that you document your rationale.
There is a provision these days for multiple default fonts (font.name-list.* =
"a CSS font-family list"), although only one font is shown/seleted on the font
pref dialog to keep the UI simple. The font list helped i18n requirements.
However, while the first primary default can be changed, the fall-back list is
hard-coded (hand-picked by i18n people), and is only searched by the back-end of
Gfx-Win at the moment.
Indeed, trying to interact with a font list on the UI would increase the
complexity of the UI without much gain. A preview (bug 33340) of the "system
default" will be okay later on. The user will at least see how it looks like.
I am okay with your patch.
Assignee | ||
Comment 15•22 years ago
|
||
ftang? Any feedback?
Comment 16•22 years ago
|
||
Fixed via bug 142511.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•