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)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: blizzard)

References

Details

Attachments

(2 files, 3 obsolete files)

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).
Component: Layout → Layout: Fonts and Text
Attached patch patch (obsolete) — Splinter Review
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.
Attached patch patch (obsolete) — Splinter Review
Localization added. Not tested with anything but Xft fonts. Need to do a bit more testing.
Attachment #112195 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Forgot the manifest change.
Attachment #112282 - Attachment is obsolete: true
Attached image screenshot
This is what the fonts panel looks like with this patch.
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?
Attached patch patchSplinter Review
Patch that addresses jag's comments.
Attachment #112317 - Attachment is obsolete: true
Attachment #112764 - Flags: review?(jaggernaut)
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+
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.
Ah, hrm. So far I think we've relied on versioning of language packs and authors keeping their language packs up to date.
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.
ftang + rbs - can you guys look at the screenshot here and tell me if you think this is sane?
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.
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.
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.
ftang? Any feedback?
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.

Attachment

General

Created:
Updated:
Size: