Like many other apps (e.g., IE), the font prefs dialog shows a sample of the font being selected to greatly improve usability. We should do do the same. This may end up being 3 platfrom specific bugs for Win, Mac and Linux.

Reassigned to ftang. Moved to future milestone for post-6.0 (unless we get an outside-netscape mozilla contribution).

mark as assign

It would also be neat to be able to see all the fonts at once (in the dropdown menu or elsewhere).

I think we should consider adding this for the next one. clear the Future from the Taget milestone. reassign this to nhotta@netscape.com

mozilla0.9 for now

Changed QA contact to ylong@netscape.com.

Reassign to jbetak.

[--> Preferences]

adding dependency to Gerv's CSS-compliant new pref style

remove moz1.0 from the milestone.

move to future.

re-assigning to gerv who is hacking the Fonts prefs dialog in bug 61883.

rbs I see the good work your are doing on font preferences. Still, out of courtesy please refrain from reassigning my bugs. I can and will comply with reasonable requests and had honestly no idea about the most recent effort yourself, gerv and others are putting into the fonts prefs. The i18n group at Netscape has been historically involved with font handling, since it affects presentation of non-Latin sites and people like erik and bstell have quite respectable expertise in this area. If there is anything I or others from the i18n group can contribute, please let us know. cc'ing bstell, bobj@netscape.com

Juraj, if you would like to take this back, I suggest that you do so. I also would like to suggest that you talk to Gerv who is currently on the Netscape campus as an intern at Mozilla.org. You can collaborate with him on changes he is planning on. One major concern I have is about testing any changes in font display. This concern would be addressed better by the Netscape i18n people's involvement. They have both the facilities and personnel resources to test a variety of languages and in an organized manner. I would particularly feel better about CJK display on various platforms. In general I would like to suggest active involvement of NS i18n people on both backend and front-end/UI issues relating to fonts.

Re-reassigning :-) rbs has rewritten the fonts prefs backend, but I _believe_ that the old front end will do the right thing, so there's no immediate rush to change to a newer front end which exposes more spiffy stuff. When that happens, this bug may happen also. Exactly who does it depends on juraj's and my priorities :-) Gerv

Oh la la... It is common knowledge/practice that bugs that are targetted as "Future" means it is not in the immediate agenda of the assignee (whether a Netscape engineer or someone else) and anyone eager enough can pick-up the torch. Moreover this bug has the "helpwanted" keyword. I have received a few bugs myself following that principle. Claiming the bug back when a planned fix is in the making or re-assigning back is also simple. Anyway, it wasn't my intention to play games with people' sensibilities. BTW, this bug is not as daunting as it may seem. So if you can help, that will be great. If someone else wants to pick the torch, please don't stop them, let them have a try too. That's how Mozilla will shine even more at the end of the day. A possible solution is to have the following: <div> <font id="monospace" face="monospace" size=".">...l10n text</font> <font id="serif" face="serif" size=".">...l10n text</font> <font id="sans-serif" face="sans-serif" size=".">...l10n text</font> ... </div> Then, one can keep the sample in sync as a particular size is changed with: (DOM+JS).getElementById(...).setAttribute("size", ...)

> not in the immediate agenda true enough - this has been retargeted a few times, although I was toying around with some prototypes a while back. > play games with people' sensibilities no sensibilities here, it's just I'd like to support the Netscape's i18n group's involvement in the font preferences, be it in an observer or collaborator mode. As of late their expertise and voice has been largely ignored, which is IMHO not a positive development (see Momoi-san's comments). > anyone eager enough can pick-up the torch Typically such bugs are assigned to "nobody@mozilla.org". In my experience courtesy prevails and if the bug has an owner, bugs are typically reassigned on request by the last owner. However this is a controversial technicality, I just felt I need to raise my voice, because there is a number of people on Netscape's i18n team, who would like to be kept in the loop in regards to fonts preferences (momoi@netscape.com, bobj@netscape.com, ftang@netscape.com and bstell@netscape.com). ><div> > <font id="monospace" face="monospace" size=".">...l10n text</font> > <font id="serif" face="serif" size=".">...l10n text</font> > <font id="sans-serif" face="sans-serif" size=".">...l10n text</font> > ... ></div> Agreed - and I'd be happy to reassign this to you. Although from my past experience the real issue here is usability and overall speed of the preference panel. NS 4.x displayed each face name in the drop down list using the corresponding font. That seemed like a good idea, but it decreased the readability. IE has since come out with different design approaches, I believe erik was particularly interested in IE 5.5 Mac font interface.

OK, I see that there was a bigger fish. BTW, bstell and ftang have been in the loop for the back-end -- both via bugzilla and in private emails. I guess if there are/were serious issues, they would point them out and cc:ed others. Also, speaking in a general sense (not only the Fonts prefs), the loop is open[-source] and people can join in, follow the development, and provide comments on the proposed solutions and patches attached to bugzilla bugs. But it is pretty hard to keep up in everything since there are so many bugs being addressed at the same time. And understandbly, yes some people (e.g., i18n) would like to be notified on some bugs (e.g., Fonts prefs). "Agreed - and I'd be happy to reassign this to you." -- no need for the typical parenthetical comment often lashed out at outsiders. I have been a long time contributor, in much more complex areas -- though that is not to say that what I suggested is freed from issues. Let's get back to bug fix, which is why I am here... there is a screenshot of the Fonts prefs for the MacIE5 (although the site seems to be down at moment) http://www.chasms3.com/macie5/mie5pref3.htm Care to enligthen us on the prototypes that you tried? Hope you don't mind trying what I suggested (if it you hadn't tried it before). My guess is that doing that won't affect performance since layout is needed to display the other texts anyway. [Of course, there could be other refinements such as displaying "(^) Loading..." like the sidebar does, but this is not what this bug is about.]

>OK, I see that there was a bigger fish. BTW, bstell and ftang have been in the >loop for the back-end -- both via bugzilla and in private emails. I guess if >there are/were serious issues, they would point them out and cc:ed others. good - this is exactly, what I was concerned about. >no need for the typical parenthetical comment often lashed out at outsiders. I >have been a long time contributor, in much more complex areas -- though that >is not to say that what I suggested is freed from issues. this is no way meant as inflammatory or condescending, although - and regrettably so - I've been amazed at the often confrontational style of Bugzilla discussions. Bstell's mandate are - as far as I can see it - font backend and APIs with special focus on i18n issues. My mandate - as I understand it - are front-end changes with focus on i18n. I wanted to make it heard and understood, since we have not dealt with each other before. If you feel that I was attacking or questioning your role in the Mozilla effort in any way or was acting condescendingly - I do apologize if I caused that perception, as this was not my intent. I'm only defending the i18n interests and my mandate related to their efforts. >Care to enligthen us on the prototypes that you tried? Hope you don't mind >trying what I suggested (if it you hadn't tried it before). My guess is that Again, no need to be inflammatory, I'll post my ideas - time permitting - and spent some time with gerv and mpt on the new UI proposal. I do look forward to seeing this implemented.

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

let's shoot for M097. I'd like to post a preliminary patch and screenshots soon to solicit some more feedback.

jbetak: I'm just getting into entirely rewriting this panel to support the new features in the backend that rbs put in. This is bug 61883. The new code, from my preliminary investigations, promises to be significantly different to the old. I plan to do this next week. As I see it, we have a couple of options here. Either you can take over that work (which I'd love you to do ;-), or you can wait for me to finish it. It seems a waste of someone's time for you to do this enhancement, and then someone has to integrate it into the new code. Someone would either be you or me, depending on who finished first. What do you think? Gerv

Gerv: thanks for the heads-up. Obviously, you are right - we should try to coordinate this and I could possibly help with the new font prefs dialog. I'm up to my neck in some performance optimization mess, but I'd love to spend some cycles on UI. Please let me know how I can help - have you written any code for bug 61883?

Not too much; I dived in, and then sent a message to blake and ben asking for some guidance. The XUL is done, but the JS is pretty complex. How far I get depends on how quickly they respond :-) If you are going to do this quickly, I could hold off - but you might find that when you try, you end up doing a lot of the stuff I would be doing anyway. Gerv

will this display the selected text?

on the assumption that this is what the user is trying to adjust

jbetak's contract is up. Bulk move bugs to ftang

ok. Mark it as m1.0

ftang: this is feature work - do you really think it's essential for mozilla1.0? Gerv

give this to lori kaplan for UE design. Don't think we have immediate need for this. But it is a nice suggestion. remove target milestone

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

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

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

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

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

Yes, still valid. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1pre) Gecko/20090610 SeaMonkey/2.0b1pre Alas, I cannot confirm bugs.

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

restoring NEW since this bug is an enhancement.

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

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

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

Comedy :-) Restoring to NEW. I think kairo's algorithm for making these changes had a few bugs ;-) Gerv

Request still valid, while I'm not sure how it would fit in current UI, the only way which doesn't make Fonts section two times bigger is to write font name with that font...