112506 - Need font prefs panel item to turn AASB fonts on/off

Status: NEW

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

Description

[Roland Mainz]

Per discussion in bug 90813:
I think we need a item in the font prefs panel to turn AASB fonts "on"/off" ...

Comment 1

[Samir Gehani]

Font prefs, over to ftang for triage.

Comment 2

[kill this account]

from bug 112552
------- Additional Comment #3 From Roland Mainz 2001-11-28 17:51 -------

What about making this depend on bug 112506 ("prefs-item for AASB") and make a
"smart" option there:
Choices for the prefs item:
- Allways (both local and remove X11)
- Only local Xservers (=default)
- Never

Comment 3

[Frank Tang]

this mean we need platform spcific pref. 
give this to ue lori kapalan

Comment 4

[Andrew Schultz]

I have a patch for this.  I was waiting for bug #122032, which adds the pref to
anti-alias fonts remotely.

Comment 5

[Andrew Schultz]

Attachment: patch

patch to add pref to font panel for bitmap anti-aliasing (remotely / locally /
never) and also all sizes.

the following prefs can be set:
font.scale.aa_bitmap.enable
font.scale.aa_bitmap.remotely
font.scale.aa_bitmap.always
font.scale.aa_bitmap.*.enable	(*=language)
font.scale.aa_bitmap.*.always

font.scale.aa_bitmap.*.remotely  pref does not exist.

Comment 6

[Andrew Schultz]

Attachment: less buggy patch

correct language-specific prefs are font.scale.aa_bitmap.always.* and
font.scale.aa_bitmap.enable.*
fixed a couple of other problems.

Comment 7

[kill this account]

Do we need to talk to the UI people?

Comment 8

[Andrew Schultz]

also note that some language-specific prefs are set in unix.js, so the dialog
will not be able to unset those prefs.

Comment 9

[kill this account]

I am not an expert on the but as I understand it
unix.js is used before the profile manager dialog comes up and
prefs.js is used after the profile is selected.

Comment 10

[Andrew Schultz]

right, but if a pref is not set explicitly in prefs.js, then it falls back on
the other pref files (like unix.js).

In this case, the pref dialog attempts to remove the pref, so that a
language-specific pref will fall back and track the default settings.  But, if
the pref is set in unix.js, then the pref dialog will clear any relevant setting
from prefs.js, but cannot clear it from unix.js.

Comment 11

[Jesse Ruderman]

Isn't font-rendering an operating system setting?  I don't understand why this
pref should be in Mozilla.

Comment 12

[Hixie (not reading bugmail)]

What Jesse says is right on the mark. Anti-aliasing should _not_ be an
application-specific setting. That path leads to madness.

I recommend WONTFIX. We should follow the relevant platform-specific settings
for anti-aliasing (and most other font settings).

Comment 13

[Hixie (not reading bugmail)]

*** Bug 149574 has been marked as a duplicate of this bug. ***

Comment 14

[Andrew Schultz]

font anti-aliasing is done by the application and is therefore an
application-specific setting.  Acting like it is not by not including it in the
pref panel doesn't make sense to me.

The prefs in this bug (except for one) already exist.

Comment 15

[Hampton Maxwell]

For Windows, this is definitely a redundant pref best dealt with by system.

The problem here is that unix doesn't offer any particular set way of toggling
anti-aliasing settings (that I'm aware of).  Therefore it unfortunately becomes
an  ugly app specific situation where the app has to provide the functionality
that the system doesn't.  What really should be done here is to lobby someone -
probably the gtk folks, as that's the relevant toolkit - to provide the user
with anti-aliasing configuration.  If that's available, it should be used.  Only
if this can't be done should we see an anti-aliasing pref in the unix font prefs.

Comment 16

[Hixie (not reading bugmail)]

That's a bug in the relevant Unix desktop systems, not a bug in Mozilla.

Please let's not bloat our prefs UI because of deficiences in our host
environment. We have too many prefs as it is.

Comment 17

[John Levon]

Note that Qt does do this (via qtconfig), lending more weight to Hixie's
attitude.

Comment 18

[Andrew Schultz]

QT only helps if you compile to use qt, which is not the default (AFAIK)
FreeType also does anti-aliasing and is compiled in, but disabled by default and
generally does not look as good (IMHO) as anti-aliased bitmap fonts.

Pref-bloat is certainly a better reason for WONTFIX, but I still disagree.

The patch I attached is relatively large because I was attempting to set a lot
of prefs with one xul row (each font family has its own set of prefs).  Simply
being able to set the 2 main prefs (font.scale.aa_bitmap.enable and
font.scale.aa_bitmap.always) would help a lot, only need one menulist box with
three options, and would not need nearly as much javascript.

Comment 19

[Hixie (not reading bugmail)]

I meant pref bloat from a UI sense, not a code sense. The usability of our prefs
panel is inversely proportional to the number of prefs it contains.

Comment 20

[Dan Naumov]

One of the things I always liked about Mozilla was the fact that it had lots of
things you could tweak from Preferences.

Comment 21

[Andrew Schultz]

there are many prefs that unix users might use less than anti-aliasing.
and the javascript sniffes OS/desktop so that it only shows up on X.

One targetted pulldown menulist doesn't seem like UI bloat.

Comment 22

[Hixie (not reading bugmail)]

No, one doesn't sound bad. But 50 do. And 1x50 is as bad as 50x1 as far as the
user is concerned.

Users who want lots and lots of prefs should be looking for an editable
about:config or an external configuration tool, not a bloated preferences dialog.

Comment 23

[Matthew T (active 1999-2002)]

I think an appropriate solution here would be to do anti-aliasing unless a
particular environment variable (or gconf or qtconfig key, or whatever) is set
to OFF. If such a variable doesn't exist, we can invent one. Then people can
make whatever GUI they like to change it. The GUI certainly doesn't belong in
Mozilla.