56441 - Need font banning

Status: RESOLVED WONTFIX

(SeaMonkey :: Preferences, enhancement)

Description

[Matthew Brealey]

It would be nice to ban certain fonts - some pages can be impossible to read as 
a result of the attractive but illegible font (Tahoma springs to mind) chosen.

So:

prefs for:

Don't ever subject me to this ugly font again
Don't ever subject me to this font as body text

Obviously you can't know for sure what body text is, but treating all text 
below a certain size would work; text in <p> elements is obviously *always* 
body text.

This is obviously useful on all platforms, but on some more than others - I 
have experienced machines that have illegible Helvetica and Arial fonts, and 
since these are very commonly specified, it would be nice to be able to ban 
them.

Comment 1

[Matthew T (active 1999-2002)]

Would it not be better to allow the user to select their favorite fonts for each 
of HTML/CSS family (bug 28899)? Then your request could be effected by unchecking 
the `Allow documents to use other fonts' checkbox. Well-behaved authors would 
still have a selection of six typefaces to choose from, which the user would be 
guaranteed to like (because they're her prefs).

Comment 2

[Hixie (not reading bugmail)]

(For the record: <p> is _not_ guarenteed to be body text; it is guarenteed to 
be a paragraph. A paragraph could easily appear in a sidebar or in a footer, 
neither of which are "body text".)

Comment 3

[Matthew Brealey]

> <p> is _not_ guarenteed to be body text

It should at least be non-heading text - the point is that one might be 
prepared illegible or ornate fonts in headings but not elsewhere.

Comment 4

[sairuh (rarely reading bugmail)]

->samir, future.

Comment 5

[Roland Mainz]

Stealing, this is an easy one - however I can only provide the code for the
Xlib, Xprint, PostScript and GTK+ toolkits ...

Comment 6

[Gervase Markham [:gerv]]

Please don't CC me on random font bugs - my interest in fonts is confined solely
to the prefs panel, and not even there at the moment. Thanks :-)

Gerv

Comment 7

[kill this account]

would this be the UI part of bug 104075?

Comment 8

[Roland Mainz]

Brian Stell wrote:
> would this be the UI part of bug 104075?

AFAIK this bug requests font banning for CSS font names (e.g. crossplatform font
banning based on CSS font names) ...

Comment 9

[Frank Tang]

I don't understand why this feature is needed for Mozilla. Should this be a
system feature?

Comment 10

[Roland Mainz]

What about implementing this via accept/deny regex filters... any suggestions ?

Comment 11

[Andrew Hagen]

Workaround: delete the font from your system. Would be nice though if you could
just disable (ban) the font in Mozilla.

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 18

[Karsten Düsterloh]

Rather limited use, and if really needed for certain aspects, userContent.css is your friend. => WONTFIX