Closed Bug 39402 Opened 24 years ago Closed 7 years ago

Use Unicode fonts

Categories

(MailNews Core :: MIME, defect, P3)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: BenB, Assigned: BenB)

Details

Attachments

(1 file)

Fix, version 1
722 bytes, patch
Details | Diff | Splinter Review 
We used to use unicode font setting, because Mailnews emits Unicode. With bug
26182, we either try to manually set the font correctponding to the original
charset or set the (exclusively for Mailnews) user specified fonts. So, there is
no option to still get the original behaviour. But I liked it. It's OK to be
false by default. Not sure, if its worth UI.

Add a pref to not set any font (apart from honoring the plain text
fixed/variable width font pref), but let NGLayout decide.

I think, we just have to query the new pref in GetMailnewsFont and return a
failure, if true.
>no option to still get the original behaviour.
I think the orginal behavior was a side effect of the data is converted to UTF-8 
so not intended. What is a benefit of keeping this? It is not easy for the user 
to discover to set unicode font for the mailnews view.

- It fits well in my ideal world. Ideally, we wouldn't have to care about
charsets/encoding at all and fonts would support all Unicode chars. Maybe, I'm
missing something, but we were very close to this in Mailnews. Japanese "just
worked" for me on Linux, even with the old behaviour (I still works) and
although I never touched the Japanese font settings.
- Sorry to say that, but your fix for bug 26182 is a hack (I think, you think
the same, since you pushed for using LANG) and caused many bugs. I'm not sure,
we found all yet.
>- Sorry to say that, but your fix for bug 26182 is a hack 
The issue is not the implementation is a hack. Anyway, the pref might be useful 
for a debugging or a workaround. So, I don't care if this is a backend only 
pref.

>and caused many bugs. 
some of the bug had existed before my changes (e.g. serif, san-serif font 
selection),
>I'm not sure,we found all yet.
that applies to any features recently checked in
Sorry, Ben, the ideal world does not exist yet.

On Windows and Mac, if you have other Asian fonts, etc.
Mozilla  will try to use these non-Japanese fonts sometimes and the
results are disastrous. I don't want to see Japanese Chinese characters
displayed in Chinese glyphs! I'm sure the Chinese feel the same way about this.
On Unix, you claim that you can see consistent use of Japanese fonts for
Japanese messages. I have not seen the evidence of this at all. 
The fact is that we fallback on some akgorithm to pick glyhs when the 
encoding we use is Unicode for display. The user should have a way to designate
the fonts for Japanese messages -- otherwise, they display with wrong glyphs for
Japanese!
In my opinion, you need to prove conclusively that CJK users get to see their languages
displayed with their characters not by glyphs of other languages. This is not a  simple matter
of displaying characters -- the same character may have different glyphs among Chinese,
Japanese and Korean. And we don't want to see Chinese glyphs for the Japanese characters.
The onyl way to control this precisely is to allow users to set the fonts for their
languages.
Also in CJK languages, many subset fonts already exist on operating systems -- they are not
a singl;e big Unicode font. That is another reason why font control by language is important.

By the way, if you have a big Unicode which includes all the languages we care about, you can the
get the effect you'ee tallking about here by setting that Unicode font for Japanese. So we already
have a facility to take care of waht you're talking about this in this bug.
nhotta, you are right.



I was not speaking about your implementation (code), but the strategy used to

solve the bug. Of course, I don't have a better idea.
Status: NEW → ASSIGNED
About the strategy : I think the way to go is the lang attribute. 
I'm not sure rejecting it for bug 26182 was the good decision.

Currently the lang attribute is actually used in WWW pages to help the browser 
select the correct font according to the language of the page when it's encoded 
in utf-8 (see http://alkashi.citeweb.net/japchin.htm for an exemple with a word 
that should be displayed with chinese, corean, japanese font on a compliant 
browser, that 4 kanji expression is meaningful both in chinese and japanese), so 
I don't see why it wouldn't be used like that inside mail.

Because there is no way to go down to actual language resolution for ISO-88596-1 
?
Is it not possible to forge a european or western value ?

If a user wants to add LANG=fr as bobj said in bug 26182, can't this value be 
placed in a block inside the LANG=WE or LANG=EU to override it ?

Now that support of the lang attribute exists in html, there is one piece of 
code that gets the correct font from the language information.
There is a clear duplication of effort between that piece of code and what 
correction bug 26182 does to insert the correct tag according to preferences.
I agree with Jean-Marc Desperrier, but it is not part of this bug. Jean-Marc,
please add your comments to bug 26162. FYI: Bug 40547 is caused by that, too,
and is [nsbeta3-].

I have a similar problem with a new feature (bug 46993), so I fixed this
(workaround) bug.

Will attach patch. nhotta, can you review, please?
Target Milestone: --- → M18
Attached patch Fix, version 1 — — Splinter Review 

    
    

    
  
QA momoi, hope that is OK.
Keywords: review
QA Contact: lchiang → momoi

    
    

    
  
Do we really need this option? There is a font fallback mechanism already 
built in so we can see multiple languages currently without this option. If the 
user really wants to use a specific unicode font then that can be specified in 
the font pref UI.
I also have a concern that adding more option causes more complication and 
confusion to testing.


    
    

    
  
Is there another workaround for bug 40547? With that new feature (see above), I
see bug 40547 for many msgs (including all bugzilla spam).

    
    

    
  
I think the workaround for 40547 could be removing font size specification but 
not font family.

    
    

    
  
And how do I do that?

If you are suggesting to modify this patch to just skip the font-size spec, I
don't know why we should do that. Other bugs, similar bugs about the font-family
are likely to appear, and if we have such a workaround, why not remove both
specs at once?

Note that this pref is hidden (no UI). We don't even need a default pref. It
defaults to the old behaviour (setting the font specs).

    
    

    
  
If you are fixing bug 40547 then the patch should go to that bug.
As I said, font size issue and font familly issue are separate, we should not 
disable font familly feature to correct the font size problem.
I think the change not to specify font size can be done by the caller side. 
Since 40547 is HTML specific, that's the right place to check the option and 
disable font size.


    
    

    
  
No, it is not /exactly/ bug 40547. I am working (in part) on
ASCII-Art-recognition in plaintext fonts to make the variable width font work
better. So, I am switching from variable width font to a fixed width font (by
adding <tt>) in the middle of the msg. Basically the same problem, just that it
happens in the plaintext converter. Fixing it on the caller side would be a hack
IMO.

> As I said, font size issue and font familly issue are separate, we should not 
> disable font familly feature to correct the font size problem.

Well, if you really, really want different prefs for skipping font-size and
font-family, I think, I could add that. Do you?

    
    

    
  
We may need a pref to disable font size, I agree that. But I am not sure if we 
need a pref to disable font familly if the purpose is just to make plain text 
art look better.


    
    

    
  
nhotta, the problem is: Bug 26182 caused a lot of bugs for all users (which is
*not* your fault), while only giving an advantage for CJK users (correct me, if
I'm wrong). I know, it is very important for these users, but I was just
suffering from it.

I want a simple, bullet-proof workaround (as a "backend only pref") for those
many western users that don't need this stuff.

I just realized: If you want to override font-family or font-size specifically,
you can do that by adding e.g. ".text-plain, .text-flowed {font-size: inherit;}"
to your user-stylesheet. But these rules will be evaluated for all of Mozilla,
including the UI, so they mean a speed penality (not sure how large, however).

So, we have the following options:
1. Hidden pref to skip the font stuff completely
   + Already implemented
   + Very simple code
   - Unspecific
2. Hidden prefs for both font-size and font-family
   - Not implemented
   - More complex code
   + Allows specific overriding
3. Hidden pref for fone-size only
   - Not implemented
   - More complex code
   - Doesn't allow override of font-family (only by using option 4.)
4. Using UA stylesheet
   + Generic feature, already implemented
   - Slight speed penality

BTW:
> if the purpose is just to make plain text art look better.

I used "ASCII-art" as term for ASCII-pictures, tables (as used in bugzilla spam)
etc.. This appears *very* often. (Otherwise, I wouldn't spend my time on it,
since I don't really like it.)

    
    

    
  
I vote for 1., but if people stongly disagree, 4. is OK with me, too.

    
    

    
  
>while only giving an advantage for CJK users (correct me, if I'm wrong).
I don't think this is true. It applies to all the users who want to change font 
name/size for message view. The user has to discover that the unicode font 
values has to be changed in order to change mail font.
The other issue which may apply international users (not just CJK) is that 
unicode font quality. The user may want to assign unicode font to unicode range 
to view multilingual pages (to at least see the characters even when the font 
quality is not good). But that implicitly overrides the user's setting of the 
font choice of the user's language.
So using unicode font does not affect the user if the user is happy about the 
default unicode font selection as below and do not want to change.

winpref.js
 86 pref("font.name.serif.x-unicode", "Times New Roman");
 87 pref("font.name.sans-serif.x-unicode", "Arial");
 88 pref("font.name.monospace.x-unicode", "Courier New");
 89 pref("font.name.cursive.x-unicode", "Comic Sans MS");

For option 4, could you tell me more detail? Is there UI which allows the user 
to select?


    
    

    
  
> The user has to discover that the unicode font 
> values has to be changed in order to change mail font.

Right. I forgot that.

> The user may want to assign unicode font to unicode range 
> to view multilingual pages

OK. But *I* don't need that, do I? I know only western languages anyway.

> For option 4, could you tell me more detail?

Add

.text-plain, .text-flowed
{
  font-size: inherit !important;
  font-family: inherit !important;
}

to <profiledir>/chrome/user.css (you might have to create the chrome dir), and
the unicode fonts should be used again. Or did you want to know something else?

> Is there UI which allows the user to select?

No. And it will be hard to create one.

    
    

    
  
Okay, since no UI for any options, most of the user cannot use it.
I would chose number 4, we want to take advantage of this flexible feature. For 
UI, how about providing pre-defined css files (with descriptions) so the user 
may choose?
The second choice would be number 2 to be flexible, and the two prefs can be 
combined by UI if desired.


    
    

    
  
> how about providing pre-defined css files (with descriptions) so the user
> may choose?

Since the UA stylesheet is pretty generic, the user might already have other,
unrelated content there. So, you would have to parse the CSS file -> generic CSS
writer.


    
  
Target Milestone: M18 → ---

    
    

    
  
QA cntact to ji.
QA Contact: momoi → ji

    
    

    
  
-> default owner
Assignee: mozilla → rhp
Status: ASSIGNED → NEW

    
    

    
  
ops, the bug had a patch. back to me.
Assignee: rhp → mozilla
Product: MailNews → Core

    
    

    
  
Ben Bucksch, any reason to leave this old bug open?

    
  
QA Contact: ji → mime
Product: Core → MailNews Core

    
    

    
  
nope
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: