33340 - font sample display in font prefs

Status: NEW

(SeaMonkey :: Preferences, enhancement)

Description

[bobj]

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.

Comment 1

[bobj]

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

Comment 2

[Frank Tang]

mark as assign

Comment 3

[Jesse Ruderman]

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

Comment 4

[Frank Tang]

I think we should consider adding this for the next one. clear the Future from
the Taget milestone.
reassign this to [e-mail]

Comment 5

[nhottanscp]

mozilla0.9 for now

Comment 6

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 7

[nhottanscp]

Reassign to jbetak.

Comment 8

[Matthew T (active 1999-2002)]

[--> Preferences]

Comment 9

[[e-mail] (away - not reading bugmail)]

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

Comment 10

[Frank Tang]

remove moz1.0 from the milestone. 

Comment 11

[Frank Tang]

move to future. 

Comment 12

[rbs]

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

Comment 13

[[e-mail] (away - not reading bugmail)]

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, [e-mail]

Comment 14

[Katsuhiko Momoi]

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.

Comment 15

[Gervase Markham [:gerv]]

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

Comment 16

[rbs]

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", ...)

Comment 17

[[e-mail] (away - not reading bugmail)]

> 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 "[e-mail]". 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 ([e-mail], [e-mail], [e-mail] and 
[e-mail]).

><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.

Comment 18

[rbs]

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.] 

Comment 19

[[e-mail] (away - not reading bugmail)]

>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.

Comment 20

[[e-mail] (away - not reading bugmail)]

Attachment: sample text by language group from ftang's old prototype

Comment 21

[rbs]

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

Comment 22

[[e-mail] (away - not reading bugmail)]

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

Comment 23

[Gervase Markham [:gerv]]

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

Comment 24

[[e-mail] (away - not reading bugmail)]

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?

Comment 25

[Gervase Markham [:gerv]]

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

Comment 26

[kill this account]

will this display the selected text?

Comment 27

[kill this account]

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

Comment 28

[Frank Tang]

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

Comment 29

[Frank Tang]

ok. Mark it as m1.0

Comment 30

[Gervase Markham [:gerv]]

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

Gerv

Comment 31

[Frank Tang]

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

Comment 32

[rbs]

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

Comment 33

[Robert Wall]

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

Comment 34

[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 35

[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 36

[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 37

[hhaamu]

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.

Comment 38

[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 39

[(mostly gone) XtC4UaLL [:xtc4uall]]

restoring NEW since this bug is an enhancement.

Comment 40

[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 41

[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 42

[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 43

[Gervase Markham [:gerv]]

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

Gerv

Comment 44

[Phoenix]

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...