26288 - Allow user to select system fonts in editor UI

Status: VERIFIED FIXED

(SeaMonkey :: Composer, enhancement, P3)

Description

[rubydoo123]

hook up system fonts

Comment 1

[Charles Manske]

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

Comment 2

[Charles Manske]

Since this is essentiall adding items to an existing menu, it is not a 
"new feature" and can wait 'till later.

Comment 3

[rubydoo123]

setting to correctness

Comment 4

[Charles Manske]

We decided not to support this in the first release

Comment 5

[rubydoo123]

adding helpwanted keyword

Comment 6

[rubydoo123]

in the bug I am about to dup, German has a ssuggestion about adding the css
terms as the default font values

Comment 7

[rubydoo123]

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

Comment 8

[rubydoo123]

forgot to add nsbeta3-

Comment 9

[Kathleen :Brade]

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

Comment 10

[Matthew T (active 1999-2002)]

Since this is an open-source project and all, could we please have a description 
which is slightly more informative than `hook up system fonts'?

Are you referring to allowing authors to format text in the CSS2 system font 
families (caption, icon, menu, message-box, etc)?

Comment 11

[Simon Fraser [no longer active]]

We need this for embedding.

Comment 12

[Simon Fraser [no longer active]]

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

Comment 13

[rubydoo123]

as sfraser notes, we need this

Comment 14

[Matthew T (active 1999-2002)]

[Resummarizing for clarity, based on an anonymous tip-off.]

Comment 15

[Charles Manske]

Attachment: Patch to put "Local Fonts" submenu under Format | Font menu

Comment 16

[Charles Manske]

Attachment implements local fonts in a separate submenu to discourage users
from using "local" (OS-specific) font faces.
BTY, why is this considered a requirement for embedding? Most embedding apps will
be implementing their own UI, and thus their own font menu, no?
If this solution seems reasonable, can I get reviews please?

Comment 17

[Matthew T (active 1999-2002)]

Ok, hands up how many AOL users know what `Local Fonts' means? I don't see many 
hands ... How about Netscape users? Still not many ... And anyway, nested 
submenus are evil.

I suggest calling the item `Other ...', and shunting the user into a dialog where 
they can either select one of the fonts on their system, or type the name of a 
font which isn't on their system (since that should be possible too). If you want 
a mockup of such a dialog, let me know.

Comment 18

[german]

agree with mpt, moving this to a second level UI should satisfy the needs of
this bug, yet will not confuse 80% of the users.
If we have to use a primary UI I don't think local fonts is the appropriate 
term for the CSS2 system preset fonts, as all other fonts on your machine are 
also local.

Comment 19

[Charles Manske]

Changin "Local Fonts" to "Other" is fine with me.
My original plan was to implement similar to Dream Weaver: Have an "Add font..."
item that allows user to select (from a dialog) which ones they want to appear
in the menu. The point about entering a font face name not necessarily installed
is a good one. So I think a simple dialog allowing user to select existing font
or type anything else is a good solution, though it does make picking the font
a bit less convenient. The other advantage of a dialog is we can have a
sample of what the font will look like in the dialog.
Changing milestone to 0.9 to implement this.

Comment 20

[Simon Fraser [no longer active]]

Why are we arguing about the font UI? The embedder will be able to control their 
own UI, so can add system fonts if they like. We just need to ensure that editor 
can deal with them, and use sensible fallbacks etc.

Comment 21

[Charles Manske]

We don't need to change anything in editor to handle and "font face" string.
I will add an "Other..." item to Font Face menu in UI that will bring up a
dialog, where you can select "local" fonts and show a preview of the font.

Comment 22

[Simon Fraser [no longer active]]

UI for picking system fonts is not an embedding requirement, but we need to be 
able to handle setting of system-specific fonts (which we already do). Taking off 
embed radar.

Comment 23

[Kathleen :Brade]

Move to mozilla1.0.1 since there doesn't seem to be any pressure to implement 
this and this bug will involve UI changes which will need to get i18n approval.

Comment 24

[Syd Logan]

spam composer change

Comment 25

[Kathleen :Brade]

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

Comment 26

[R.K.Aa.]

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

Comment 27

[David Grant]

Couldn't we just add a few more fonts to the list right now?  It doesn't hurt 
to add a few more like Verdana, etc...  A dialog box, or an Other... sub-menu 
can come later for 1.0.1.  I just hate having to copy and paste the 
word "verdana" into every <font face=...> statement in source view many, many, 
many times.  If the Find and Replace features were implemented for the source 
view, I could do this easily, but instead I have to re-open the html file in 
Windows Notepad...how annoying.

Comment 28

[Simon Fraser [no longer active]]

Verdana isn't on every machine, so, no. There is an nsIFontEnumerator interface
that is what the JS should use.

Comment 29

[Charles Manske]

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

Comment 30

[Blake Ross]

Who cares if Verdana isn't on every machine?  It's on quite a few machines.  So
is Tahoma.  Outlook Express lets me choose whatever font I want; why shouldn't
we?  Users that don't have the font get a more boring font; that's not a
problem.  Microsoft Word lets me choose any font I want, even though I may
e-mail the document to someone that doesn't have it.

Copying comments from bug 129963, in response to cmanske there:

I just don't understand this.  The reality is that 95+% of the consumer market
is using Windows.  Why are we penalizing all of them so that the minority can
read all fonts, especially when the penalty (falling back on a boring font)
isn't bad at all?  My mom is not going to figure out a Dreamweaver-like UI that
forces her to add fonts.  She will not hesitate to switch to Outlook Express,
which lets her choose the font she wants, just as Microsoft Word does.

Comment 31

[R.K.Aa.]

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

Comment 32

[Joel Nelson (don't send email)]

Why not just use a font chooser similar to the one in the Preferences ->
Appearance -> Fonts preference panel?   Users should be able to choose from any
font installed on the system when composing web pages or e-mail messages.  If
the font is not on the recipient's computer (or the computer of the person
viewing the web page) then their computer will select the fall-back font.   Just
use the font chooser that allows selection of any installed font, and program it
to write the "font-face" HTML code as soon as a selection is made.  
   The "add font" dialog box would be too advanced or too much time/work for
most users.   Using a submenu might work but probably isn't a good idea.  An
"other" dialog box would be seen as too much of a hassle.
   As stated in Comment #30...   just list any font installed on the system in
the font selection menus.    This is a feature a lot of users want.  If they
don't find it in Mozilla, they will use another program that makes it easier.
  My suggestion on how to do this menu:  At the top, "Variable Width" and "Fixed
Width".   Separator, then "Arial, helvetica", "Times", and "Courier".  Another
separator, then the list of every font installed on the system.   This menu
would be on the Format -> Font menu, and on the formatting toolbar in Composer
and in the Mail Compose window.
    Also tie this into the bug fix for bug 107877:  When the option to select a
default font for outgoing messages becomes available, then allow selection of
any font on the computer for default on outgoing messages.

  Don't we want Mozilla to be as user-friendly as we can?  Anything but keeping
all the fonts in one menu would not be as user friendly.   By putting the
multi-platform fonts at the top of the list, this will encourage a lot of users
to just one of those fonts.  To use another font, they would have to scroll down
the menu. 
   One other thing we could do...       by default, list every font installed in
the drop-down menu.   For most people, there are sure to be fonts they have
installed that they wouldn't use in an e-mail or web page.   In Preferences,
have an option to remove fonts from the list.   But don't make the default be to
list just some fonts and make the user have to ADD the other fonts to the menu. 

Comment 33

[timeless]

Personally, I think that putting the full font list into the menu is a brute 
force solution to the wrong problem, and that it will make the web worse.

I think that what we should do is encourage font family and set selection, we 
should make it easier for the user to define a sequence of fallback fonts.

So we should have a list of universal web fonts, and basic font families (I 
think we have those two), the user's created font famlies (add this) and an 
item to add new families (and this).  The font family editor should allow the 
user to select and order fonts installed on their system as well as enter fonts 
(not installed on their system) by name.  If a font is available on the user's 
system, then it should be preview(able|ed) in the font family dialog. 
Otherwise, the dialog should indicate that the font isn't available.

Comment 34

[Joel Nelson (don't send email)]

  What would "creating a font-family" involve?  Would this permit users to
select multiple fonts from their system to use as a group, so if one font is not
available on the recipient or web page viewer's system, the computer will try
the next font, etc.?  The first font listed would be the primary font, and the
following fonts would be fall-back fonts (in the order listed)?
   This font-family creation dialog could also be used to select one individual
font to add to the menu if the user desired, but there could be text in the
dialog to encourage the user to select multiple for increased compatibility.   
 
    I would recommend making the font-family dialog box accessible from a
"Customize menu..." or "Customize fonts..." tool in the font menu.  Link the
dialog to the menu so that changes or new families created from the dialog are
reflected in the font menu. 
  The existing font families should be editable (for example, switch the order
of the fonts listed in each family).  Right now, at least on the Mac OS X
version, if I select Arial,Helvetica, Helvetica is apparently listed first in
the font-family as that is what the page is displayed in as I create it.  The
Windows machines viewing the page attempt to display it in Helvetica instead of
Arial, and that doesn't always look good!  (The PCs try to display Helvetica
instead of displaying Arial.) 

     Also tie this in with the the fix for bug 107877 (nsbeta1+, mozilla1.0) so
that additional fonts are available for setting as default on outgoing e-mail.
   
As far as "standard web fonts", are we talking multi-platform fonts or Windows
fonts?   On Windows the standard fonts include Arial, Comic Sans MS, Courier
New, Georgia, Tahoma, Times New Roman, Verdana, etc.   On a Mac, standard fonts
are Charcoal, Geneva, Helvetica, Palatino, Times, etc.   Most PCs don't have the
Mac fonts and the Mac computers only have the PC fonts if Internet Explorer is
installed or was installed at one time (and if Mozilla is to be a replacement
for IE we don't want to have to be dependent on IE for fonts)!   I assume fonts
on other systems (i.e. Linux) are different from either the Mac or Windows fonts.

In closing, some e-mail programs (one example is Outlook Express for Mac) do not
know how to handle font-family HTML code.   I sent a message in "Arial,
Helvetica" to an OE for Mac (OS 8/9) user and their computer had to just use the
default mail font because there was no font installed specifically called
"Arial, Helvetica".  I don't know how many other programs also have this
problem.    OE for Mac can only handle individual fonts in e-mail messages.  For
compatibility with some programs (even though the programs are a minority) the
font-family dialog should at least be capable of choosing one individual font
and adding it to the menu.  There could also be an option in Preferences for
"use font-families" or "use individual fonts".  However, that could come later.
 For starters just get the dialog and font menu installed.  I would recommend
using the fix for 107877 along with this bug fix.  
   Suggesting nsbeta keyword.  (If not for the next version of Netscape, at
least for the version following that.)

Comment 35

[timeless]

paragraph 1: yes to all the binary questions.
paragraph 2: sure, a font family could have just one item. we could probably 
configure mail not use families, or set it up to warn.  I'm more focused on 
composer than message compose, but it's good to keep both in mind.
paragraph 3: sure, although i think 'customize' should be good enough (again 
other people can argue over the text).
paragraph 4: Should users be able to customize any of the ones predefined? 
that's fine with me (although I'm certainly not the last word).

It sounds like you aren't 100% opposed to this idea, :-). 

paragraph 6: As for standard fonts, I'll let someone else draw up the 
definitions, I'm more interested in the UI than some hard coded defaults.

Comment 36

[Joel Nelson (don't send email)]

I am in favor of this now.  :-)   I got to thinking that with some people having
100-200 or more fonts on their machine if the menu listed all those it would be
hard to manage.  Plus with web pages on the internet it is better to have more
standard fonts.  Web pages with fancy fonts don't work well on some systems when
the system has to use the default font because the specified font isn't found. 
The font-family idea is great for Composer if it really will be as discussed
here.    It was in Mail that I had some concerns.
   However, now that I think about it, if people have a lot of fonts installed
on their computer, the font menu in Mail would be hard to manage.  Maybe a
customizable menu for fonts in Mail would be a good idea.  In Mail you would
probably want an option in Preferences for "use font families" or "use
individual fonts".   Font families is an advantage in Mail also but I think a
lot of people coming over from Outlook Express would be disappointed if there
was only the font family choice.   The Mail program needs to be able to use
local fonts.  
    Should I file a separate bug for the Mail aspect of this or can this bug
cover both?
     

Comment 37

[David Grant]

I just want to add my opinion to the current discussion which has heated up a 
little bit in the last few days.

For me this is all I want at the current time out of Composer's font selection 
feature enhancements.

Currently when I start a new page in Composer the fonts are set to something 
like Helvetica, Arial, Courier (in that order) or something like that I can't 
remember.  I assume this is because these fonts are fairly standard.  For some 
areas of my HTML files, I like to use the Win2k font Verdana.  So I go through 
and add the word Verdana in every <font face=> entry.  In the Font selection 
menu/dialog, I think it should be able to select from every font on my system.  
If I change some text to Verdana, for example, Composer should FORCE Helvetica, 
Arial, Courier to be appended to the end.  In fact, users should be able to add 
any preffered fonts that they want.  But as long is there are some standard 
fonts appended, isn't this okay?

Combine this will Joel's ideas in comment #32 and I think this will be a big 
improvement.

Also, I don't understand this whole font family thing.  If I can't understand 
it, how will Joe User understand it?  Joe User wants to be able to use whatever 
font he pleases.  However you want to handle font standards is up to Moz 
developers.  But Joe User should still be able to make his entire webpage in 
Wingdings or that god-awful Comic Sans Serif MS, or Verdana, or the default 
fonts if he wants.

And this next comment is directed at [e-mail]: Your 
comment, "Personally, I think that putting the full font list into the menu is 
a brute force solution to the wrong problem, and that it will make the web 
worse."  Why will it make the web worse?  Don't users of Microsoft Front Page 
have access to the "full font list"?  Has this made the web worse?  I'm 
probably misunderstanding what you mean, but maybe you can expand on it for me.

Thanks.

Comment 38

[David Grant]

One quick solution to this problem is to be able to use "Find and Replace..." 
in Composer.  This would allow me to quickly replace "face=" 
with "face=Verdana," or something like that, without having to load up a text 
editor.  If anyone cares about this, please go and vote for the bug to add find 
and replace functionality to Composer.

http://bugzilla.mozilla.org/show_bug.cgi?id=76374

Comment 39

[Joel Nelson (don't send email)]

Filed bug 137290 for the Mozilla Mail&Newsgroups portion of this bug, leaving
this for Mozilla Composer and making 137290 a related bug for e-mail.

Comment 40

[Joel Nelson (don't send email)]

The Mail/News version of this bug is bug 119593, not 137290.

Comment 41

[timeless]

+---------------------------------------------------------------+-+
| Font List                                                     |X|
+---------------------------------------------------------------^-+
|/-Families -----v-\          /-Curly Fonts ---------v-\          |
|| Serif         |^|          |>Script MT Bold      <|^|          |
|| Sans Serif    | | [New  +] | Kaufmann BT          | | [Add  +] |
||>Curly        <| | [Up   ^] | Rage Italic          | | [Up   ^] |
|| Cursive       |*| [Rename] | Kunstler Script      | | [Change] |
|| Helvetica     | | [Down v] | Edwardian Script ITC | | [Down v] |
|| Stencil       |v| [Delete] | Blackadder ITC       |v| [Remove] |
|\---------------^-/          \----------------------^-/          |
|                             /-Sample-----------------\          |
|                             |     Script MT Bold     |          |
|                             |        AaBbYyZz        | [Cancel] |
|                             \------------------------/ [  Ok  ] |
+-----------------------------------------------------------------+

New creates a new font family, inserted after the currently selected family, 
scrolling it into view.
Add brings up the os font picker dialog.
up/down move the selected item(s) up/down.
If in place editing works then rename will activate it.
Change might bring up the font picker.

Selecting a family in the list on the left loads its font list on the right.
Selecting a font on the right loads a preview in the sample.
Sample isn't necessary, but it's something to discuss having, and it would 
allow us to indicate that a font isn't available on the system.  An alternative 
is to italicize fonts that don't exist on the system.

As always, wording and placement is subject to negotiation or whatever, this 
sketch is for people who find my words confusing.

Comment 42

[David Grant]

Thanks for the nice ASCII art!  So what exactly is the point of using these font
families again?  Would a font family be something that would be listed in the
<font face=> part of HTML code?  It sounds like a good idea.  But what about
novice users?  Will they will capable of using this?

Comment 43

[timeless]

either there or in css rules depending on your mode.

I just spent time using composer and of course the menu items there use lists.

the benefit of lists is that (except in the case Joel noted for some drunk mail 
client) the browser will try fonts in the order they are listed until it finds 
a matching font or runs out of suggestions.

A really cool feature in windows is the ability to sort fonts by family or 
similarity.  This means that, information like that is apparently available to 
applications, so perhaps mozilla could try to glean that information and offer 
it as suggestions to the user.  There's room in the sketch for this feature, 
but implementing it should be done at a later time (if at all).

As for new users, at the very least they should be able to get basic menu 
customization and be able to add single fonts.  While this falls considerably 
short of my goal, I think that it might be acceptable to them.  If/when we 
implement the other feature I described above, then they'd be able to build 
lists without too much effort.

So the only question would be how to explain to a user that a font might not be 
available on another computer and that they can use this dialog to specify 
alternative fonts ...

I'm not quite sure how to do that, but if we could do that, I'd be overjoyed.  
There's certainly room for a |?| what's this or [ Help ] button, but I'm not 
sure that's the right way to explain this. (Although I can't think of a better 
way and would hate to use lots of static text to explain it.)

So now, I'm just going to wait for the weekend to expire and for other people 
to comment :-).

Comment 44

[Cody 'codeman38' Boisclair]

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

Comment 45

[Joel Nelson (don't send email)]

This is targeted for Mozilla 1.0.1...   what is the current status? 

Also, how is Mozilla 1.0.1 different from 1.1a?   Are 1.0, 1.1a, 1.1b, 1.1, 
1.2a, etc.  the milestone releases and 1.0.1, 1.0.2, etc. branches that will 
be incorporated into the milestones?  I don't understand the different release 
numbers.

Comment 46

[Kathleen :Brade]

Reset milestone since 1.0.1 probably wouldn't take this "feature"; Charley will
probably reset to something that fits his schedule.
Adding keyword helpwanted (Charley--you should remove this if you want to do
this yourself).

Comment 47

[Charles Manske]

I have reviewed all the interesting discussion on this issue. It will not be
addressed by me for the mozilla1.0 or NS 7.0 releases, since we are past UI 
freeze for those. It will be in the next cycle for Netscape, I'm not sure how 
the mozilla milestones correspond anymore!

I still see lack of agreement on these fundamental issues: 
1. Use just a menu with all available fonts vs. separate dialog to select fonts.
2. Use "Font Family" grouping vs individual fonts. This issue is influenced by 
app. context: it seems in Mail Composer only individual fonts will work for 
better compatability with other apps.
3. Limiting the list of fonts available to a subset of system fonts. Should
default be to include all and let user remove them? Or start empty and make 
the user add them.
If we use an interface such Timeless's suggestion in comment #41, this issue
might be addressed by having "Add All" and "Remove All" buttons. 

There's the usual problem of simplicity for typical users (who probably don't
have many fonts installed) vs flexibility and complexity for the more advanced
user who probably has hundreds of fonts installed.
I'd like to support both extremes as much as possible. Having a pref similar
to those suggested by Joel might be a good idea to add the font family feature.
The default would be individual fonts (good for Mail Compose) and support for
Font Families would be available only in "Web Composer".

I do like the simplicity of having fonts directly available in the UI without
always going into a separate dialog. But I do think supporting the addition and
remove of fonts from that list should be supported. Here's a suggested strategy 
to start from:
1. When Composer starts, it checks a pref that says we haven't configured fonts
yet and builds the list of all available fonts. If it's some reasonable number 
(we can decide that later; under 30?), simply include them in the existing 
menulist on the toolbar and in the "Format | Font" submenu.
2. If the number is over our limit, popup a message dialog telling user how
many fonts we found and ask them if they want to configure the available fonts. 
If they say no, we include all fonts and tell them where in prefs they can go
to configure the fonts later if they change their minds. If they say yes now,
put them in a preference panel as suggested by Joel in comment #32 
that may look something like Timeless's design in comment #41.
It is here that the option to use "Font Families" vs "Individual Fonts" could
reside. Changing that option would morph the dialog appropriately.
Set the "Fonts-are-configured" pref so we don't repeat this every time we load
Composer. The currently-active list of fonts will be stored (in prefs? rdf?)
and used for subsequent Composer windows.

I don't want to go into any more detail about the configuration dialog here.
This is enough to continue discussion on this feature. Sorry it hasn't happened 
sooner, buy I've had to concentrate on other issues this release. It looks like 
there's plenty of interest in the feature and anyone else who wants to implement 
some of the excellent ideas suggested is certainly welcome to do so!
Even better though, is to write up a reasonably detailed spec with sample dialog 
layout so we all argree on the design before actually implementing it.

Comment 48

[Ben Bucksch (:BenB)]

> So the only question would be how to explain to a user that a font might not be 
> available on another computer

Yes, that's very important IMO. Having such a menu/dialog suggests to the author
that the readers on the web will see the same font, which will not be true in
many cases, but the author will never know, because it works just fine on his
system. (In fact, I don't think that specifying font for the web or mail has any
point at all, but I see that there are other opinions.)

Comment 49

[Charles Manske]

Now that I've seen the "roadmap" at http://www.mozilla.org/roadmap.html,
I think I can address this issue sooner. Moving to 1.2alpha

Comment 50

[Joel Nelson (don't send email)]

   Would it be possible to put text similar to the following in the Composer
font selection dialog box?   "Some fonts in this list may not be viewable on
other computers."   Or, just install the font selection dialog and mention this
in Help or Release Notes.  (Maybe even put a Help button in the dialog box.)
    Most other WYSIWYG HTML editors just have a font selection list or dialog. 
While I know it would be nice if most web pages could just use a few standard
fonts installed on most computers, this feature may not be well-liked by the
general public.  Features liked by those who work with computers at the advanced
level might not be well appreciated by novices.   Most users will probably
appreciate the simplicity of just having a font selection list.  
    My suggestion is to give a font menu with Variable Width and Fixed Width at
the top, the three font families, a list of common web fonts, then either a
sub-menu with all local (installed) fonts or else the local fonts just taking up
the remainder of the list.   In the Preferences pane, we could add an option for
customizing the fonts list.   This would include creating font-families, and
deselecting any local fonts on their system that they don't want in their font
list.  By default all fonts should be listed.
    For Mail&News, just leave it as simple as possible.   The Variable and Fixed
Width fonts should go at the top, then the three font-families, then all local
fonts beneath (or a sub-menu, but remember, keep it as easy to use as possible).  
The list of local fonts, and the list of font-families, can be edited in
Preferences.   As I stated above, by default all installed fonts should be
listed.   
    While the general user audience of Mozilla right now is computer programmers
and advanced users, isn't the goal to make Mozilla & Netscape widely used by the
general public?   Ease of use needs to be a high priority or the users won't be
pleased.   If we get too technical with the font selection issue many users
won't be able to understand it.   
    This is a little off-topic, but I will use it in conclusion:   While a lot
of advanced computer operaters do not care for heavy use of formatting and fonts
in e-mail and web pages, the general public (who use a web-page editor for
creating personal web pages and e-mail for informal letters to family and
friends) are going to want these font and formatting features.   These features
are found in other internet products (dare I say FrontPage and Outlook Express)
and a sizable amount of users may not want to switch if they lose these
features.    Just my 2¢.   :-)

Comment 51

[R.K.Aa.]

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

Comment 52

[Blake Ross]

Nominating for next release, this is pretty fundamental for a composer.

Comment 53

[Joel Nelson (don't send email)]

Re: comment #52

Agreed.   I don't know if the Netscape team will accept it for the next release, but we can 
at least suggest it.

Comment 54

[Joel Nelson (don't send email)]

Mark this 4xp -- Netscape 4.79 had this feature in both Composer and MailCompose.

Comment 55

[Blake Ross]

Reassigning to me since I have this working already in ishmail.

Comment 56

[Joel Nelson (don't send email)]

What will it take to import it from "ishmail" to Mozilla?

Comment 57

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 58

[Charles Manske]

Blake: Can I please see a bug or some design for this feature?
Obviously we have thought a lot about it, as the bug comments reveal!

Comment 59

[Blake Ross]

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

Comment 60

[Blake Ross]

This is the only bug I have on it.  To see it in action, download the latest
build of ishmail (cmanske: e-mail me for details).

I've read through much of this bug and don't understand what the problems are. 
All we need is a dropdown with the fonts on your computer.  This is pretty
standard in every word processing application I've ever used...

Comment 61

[Joel Nelson (don't send email)]

Just add the dropdown with all the fonts on the computer, and that will be GREAT!

Comment 62

[Simon Fraser [no longer active]]

The problem that you guys seem to be missing is what happens when you compose an
email in "MS Cursive fantasy oblique" and send it to someone who doesn't have
that font. We only show 'standard' fonts in the dropdown because we don't want
people creating content with composer (or composing emails) which won't appear
to the viewer as they look to the creator.

Comment 63

[Blake Ross]

I'm not missing that problem.  Outlook Express, AOL, Microsoft Word and
countless other programs are aware of this problem.  The system chooses the
closest font if the font the user is using isn't available on the recipient's
machine. Windows ships with a wide variety of fonts, and I'm willing to be many
users don't install their own fonts.  The convenience of being able to choose
from many different fonts far outweighs the inconvenience of the recipient not
seeing it exactly as you intended, which is a minor issue, imo.

Comment 64

[Blake Ross]

My main concern, btw, is e-mail compose, and the mail guys seem to want this.  I
know the editor team is concerned with ensuring that Composer outputs the best
possible document viewable by everyone, so they can make the call on Composer.

Comment 65

[Kathleen :Brade]

Comment on attachment 24262 [details] [diff] [review]
Patch to put "Local Fonts" submenu under Format | Font menu

This patch is unacceptable.  1) We need to show the "preferred" fonts first. 
2) Also, I don't think this patch handles large numbers of fonts.
3) localFonts should be named gLocalFonts or gCachedLocalFonts

Comment 66

[Simon Fraser [no longer active]]

> The system chooses the closest font if the font the user is using isn't
> available on the recipient's machine

By 'system' do you mean the OS? That's certainly not true on Mac. It's entirely
up to Gekco's rendering code to pick a fallback font if the one specified isn't
present. Of course if the content specifies alternatives or generics ("Times,
serif") then they'll be used, otherwise you'll probably just get the default font.

Comment 67

[Blake Ross]

Hmm...what is the system font? It seems to be Times New Roman on Windows, which
seems okay to me.  Anyway, I noticed kerz filed bug 158707 on adding this
ability to message compose.  I'm gonig to reassign this back to cmanske since
editor and mail compose don't have to attack this the same way (editor is much
more web developer-oriented).

Comment 68

[Charles Manske]

Attachment: Patch for "Font ->Face->Local Fonts" that sortof works

Blake's patch needed some help to make it work.
However, it doesn't get the correct font if list is very long and you scroll
past initially-visible fonts.
This is posted so people can test the concept of using a simple submenu.

I agree with Brade (and others in the long discussion above) that this is 
probably not the best solution. I still favor using a dialog instead of a 
submenu. In the dialog, the list of all fonts is the same, but it also has:
1. Sample text to show what the font looks like.
2. Some text to explain that using local fonts is generally not a good idea 
since many viewers may not have that font.

With either the dialog or submenu, I agree we should maintain a history list
of most recently-used fonts and put those names below the separator from the 
existing fonts and above the "Local Fonts" menuitem. 
One might argue that they should go below the "Local Fonts" menuitem so it acts

as a header that conveys that the fonts below are "local". 

Other issues that need to be addressed: 
1. This needs to be implemented so the local font list is shared with the
menulist on the toolbar (currently used in IM and Mail Composer, but it may be
made available to web Composer as well.)
2. The current fontface needs to be selected in the list, either in the submenu

or in the menulist in the proposed dialog.

Comment 69

[Blake Ross]

That isn't my patch!  Actually...it seems to be your patch, from 2001!

Comment 70

[Charles Manske]

Really? Sorry to blame you, Blake!

Comment 71

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

cmanske : blatantly stealing your patch and integrating its code into CaScadeS.
That's exactly what I was looking for...

Comment 72

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: screenshot of local fonts handling in CaScadeS

Comment 73

[Joel Nelson (don't send email)]

Looks good!  Still on track for 1.2?

Comment 74

[Joel Nelson (don't send email)]

1.2 alpha freeze date is very soon -- need to either land this patch or else
postpone to 1.2 beta or later.

Comment 75

[Charles Manske]

Sorry, this will have to wait for 1.2beta.

Comment 76

[Charles Manske]

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

Comment 77

[u51419]

I would be happy if I could just control the default behavior of the button that
says "Variable Width."

Comment 78

[Kathleen :Brade]

If you want to change the particular font that *you* see in that profile, you
can change prefs for Appearance > Fonts and set a different font if you don't
like your own default (note that this won't change the font others see when
viewing your page).

Comment 79

[jag (Peter Annema)]

-> me

Comment 80

[Samir Gehani]

Composer triage team: nsbeta1+/adt1

Comment 81

[Raj Rajagopalan]

Using local fonts is a necessity for those using non-latin alphabets. A definite no go for people thinking of switching to Mozilla from IE who write in another language.

Comment 82

[jag (Peter Annema)]

Attachment: Update to previous patch

I've moved the system fonts into the main fonts menu instead of a submenu, and
fixed it so we don't throw js exceptions when you hover over the menu scroll
arrows.

There's (what seems to me) a bug in editor code that makes "arial narrow" look
like "arial black" (it's doing a compare on the first 5 chars only).

Comment 83

[jag (Peter Annema)]

http://lxr.mozilla.org/seamonkey/source/editor/libeditor/html/nsHTMLCSSUtils.cpp#1240

The effect of that is that "arial narrow" will be marked as the style used for
the selection, even if it's "arial" or "arial black".

Comment 84

[[e-mail]]

Comment on attachment 115836 [details] [diff] [review]
Update to previous patch

>+ var enumerator = Components.classes["@mozilla.org/gfx/fontenumerator;1"]
>+                .createInstance(Components.interfaces.nsIFontEnumerator);
In lxr I see a mixture of getService and createInstance; without looking at
the definition of fontenumerator, getService sounds right to me...

Comment 85

[[e-mail]]

Comment on attachment 115836 [details] [diff] [review]
Update to previous patch

>+      var localFontsString = enumerator.EnumerateAllFonts(localFontCount);
Except this isn't a string, it's an array...

Comment 86

[[e-mail]]

Oh, you've been copying someone else's error :-/

Comment 87

[jag (Peter Annema)]

Attachment: Let's try that again...

I fixed that silly array -> string -> array thing, and used getService instead
of createInstance.

Comment 88

[[e-mail]]

Comment on attachment 116594 [details] [diff] [review]
Let's try that again...

>+  var menu = menuPopup.parentNode;
This appears to be superfluous.

Message Compose has an extra font menulist (also defined in editorOverlay.xul)
- should this also contain the system fonts?

Comment 89

[(not reading, please use [e-mail] instead)]

hey jag, sorry for the delay.

some quick questions:

1) what's the performance impact on the mail compose window? 

2) does this change play nice with the cached compose window?  (looking at it, I
think so.  but I want to make sure you tested with it.
http://www.mozilla.org/mailnews/arch/compose/cached.html)
  
3) double checking:  we only pay the price for html mail compose, and not for
plain text mail compose, right?

4) how many fonts are going to show up for mac or win32 users?  

I remember seeing a patch like this once on a branch, and *really* large number
of fonts showed up.

That might be ok for editor, but I'm not sure if the performance impact is worth
it for html mail compose.

5) won't your patch make it so helvetica, times, and courier show up twice,
since they are hard coded?

Comment 90

[jag (Peter Annema)]

1) what's the performance impact on the mail compose window? 

Nothing until the submenu is opened for the first time

2) does this change play nice with the cached compose window?  (looking at it, I
think so.  but I want to make sure you tested with it.
http://www.mozilla.org/mailnews/arch/compose/cached.html)
  
3) double checking:  we only pay the price for html mail compose, and not for
plain text mail compose, right?

There should be no price paid until the font submenu is opened. Both html
compose and plain text compose seem to have this submenu though.

4) how many fonts are going to show up for mac or win32 users?  

I remember seeing a patch like this once on a branch, and *really* large number
of fonts showed up.

That might be ok for editor, but I'm not sure if the performance impact is worth
it for html mail compose.

Well, the submenu takes a little longer to open up on my 900MHz w2k machine with
83 installed fonts, but not much longer. I'll try this on a slower machine at
some point, but I think it's going to be okay. If we're expecting our average
user to have 200+ fonts by default, we may need to rethink the UI for selecting
a font.

5) won't your patch make it so helvetica, times, and courier show up twice,
since they are hard coded?

Yes it will, this was OKed by Lori. It helps keep easy access to recommended
(web-safe?) fonts. Also note that those first three hardcoded items are really
short fall-back lists (e.g. times is "times new roman,times,serif"). Perhaps we
should change the labels to reflect that (like we do for "Helvetica, Arial")?

For those three items I'll have to fix the code though to see if the font-family
is all three instead of just one of the three.

What should we do with "unknown" fonts? E.g. some html has "font-family:
MyPetFont". I think with the current code that would be classified as "variable
width" (the first menuitem). I propose we don't select any font in the "unknown"
case (so only select the first menuitem if no font-family applies (how do I
detect this?)).

Comment 91

[jag (Peter Annema)]

Hmmm, and there's this odd thing going on where selecting "Wingdings 2" or
"Wingdings 3" doesn't result in that font being applied to the selected text.

glazou, do you know what's going on there?

Comment 92

[jag (Peter Annema)]

Correction, plain text mail compose doesn't have a format -> font submenu, so it
won't be affected at all.

Correction2:
2) does this change play nice with the cached compose window?  (looking at it, I
think so.  but I want to make sure you tested with it.
http://www.mozilla.org/mailnews/arch/compose/cached.html)

It should, if caching the window includes caching global js vars. It seems to
work just fine (i.e. it's not adding the list multiple times).

Mail html compose has a fonts <menulist> in its formatting bar. Should that list
get the same treatment, or should we keep it short and simple?

Comment 93

[timeless]

jag: our font handling takes the css holier than thou approach which insists
that windings are broken since they are index based instead of character based,
which means there are 0 characters mappable to glyphs. 

Comment 94

[jag (Peter Annema)]

Hrm, so how do we deal with this? Is there a way to detect which fonts our css
system doesn't support?

Comment 95

[timeless]

i'd imagine you could visibly detect which ones are being ignored, it's probably
also possible to get log output or run an applet to find out.

personally i'm hoping we'll abandon our posture and play nice with the dings.

Comment 96

[(not reading, please use [e-mail] instead)]

talked it over with jag, and there are few open issues (some that are
pre-existing, that should be spun off to new bugs), and some others that he
might be able to deal with.

> Mail html compose has a fonts <menulist> in its formatting bar. 
> Should that list get the same treatment, or should we keep it short and simple?

I think that's already covered by another bug.  (owned by shuehan?  or maybe she
owns the "default html compose" font bug, or both.)  
that's what I was concerned about affecting performance.

jag explained this fix is for the Format | Font menu, which only costs us if you
 go and use it.  I'm ok with that performance hit.

jag was saying that he still needs to address the "mark the current font as
checked" issue, so that last patch is not complete.

Comment 97

[(not reading, please use [e-mail] instead)]

Comment on attachment 116594 [details] [diff] [review]
Let's try that again...

since I know jag plans on ammending this patch, I'll clear review request.

jag, when you get a new patch, please request a new review.

Comment 98

[jag (Peter Annema)]

Attachment: This should be it.

Comment 99

[[e-mail]]

Comment on attachment 117841 [details] [diff] [review]
This should be it.

+	   break;
+	 }
+	 else
Bit of bad style here :-)

Comment 100

[jag (Peter Annema)]

Attachment: This should be it, really.

Comment 101

[(not reading, please use [e-mail] instead)]

Comment on attachment 117845 [details] [diff] [review]
This should be it, really.

sr=sspitzer

neil is a peer for editor, right?

jag, where there any spin off bugs that you found that should be logged?

Comment 102

[jag (Peter Annema)]

Bug 198546 for the "unknown font" problem.

glazou, what's the bug number for us only comparing the first 5 characters of
font names in the code I'm calling?

Comment 103

[Kathleen :Brade]

moa=brade

Comment 104

[Samir Gehani]

Resolving as fixed per jag.

Comment 105

[David Grant]

Did this make it into 1.4a?

Comment 106

[nebigredfan]

Yes, it did make it in 1.4a.   However, I have not been successful in getting it
to work.   :-)

Comment 107

[rubydoo123]

the font list is there, the submenu idea was pulled, the list displays the fonts
I have installed.

Comment 108

[Mike Cowperthwaite]

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