Closed
Bug 206716
Opened 21 years ago
Closed 20 years ago
Composer can not use Chinese font.
Categories
(SeaMonkey :: Composer, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: youying, Assigned: mkaply)
References
Details
Attachments
(4 files, 1 obsolete file)
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Brade
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mkaply
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
We choose Chinese font while composing, but no effect.
If Western font chosen, it's all ok !
Reproducible: Always
Steps to Reproduce:
1. Open Composer or Open New Message(MailNews)
2. Choose Chinese font and then edit.
Actual Results:
While choosing Chinese font, Mozilla Composer should work as choosing Western Font.
Reporter | ||
Comment 1•21 years ago
|
||
All western fonts work, but Chinese fonts fail.
Reporter | ||
Comment 2•21 years ago
|
||
Bug still exists in 1.4 RC1
Comment 3•21 years ago
|
||
It still can't use in 1.4 RC3.
Only useful in English font.
Assignee | ||
Comment 4•20 years ago
|
||
I'm assuming you mean a font with a Chinese name?
Assignee: sspitzer → composer
Component: Composition → Editor: Composer
Product: MailNews → Browser
QA Contact: esther
Assignee | ||
Comment 5•20 years ago
|
||
OK, the main fix I did for this was in ComposerCommands.js, but looking at
ComposerCommands.cpp, these change should be everywhere.
In these cases, they were working with a wide string anyway, so the extra
conversions were unnecessary.
Assignee | ||
Comment 6•20 years ago
|
||
My change is too far reaching - it breaks stuff.
To really fix just this problem. we just need one change to composerCommands.js
I'm continuing to investigate.
Assignee | ||
Comment 7•20 years ago
|
||
In looking at this patch, the only thing that needs fixing is
ComposerCommands.js in two places.
The right stuff is happening inside Composer.
When I tried to change ComposerComands.cpp, I ended up breaking Midas commands.
So I'm focusing on the problem at hand.
Assignee | ||
Updated•20 years ago
|
Assignee | ||
Updated•20 years ago
|
Attachment #149341 -
Flags: review?(daniel)
Comment 8•20 years ago
|
||
This patch worries me a bit because of the nsComposerCommands.cpp counterpart.
I don't see why something like nsParagraphsStateCommand still relies on
a getCStringValue() in the c++ code while the JS calls a setStringValue()
through a doStatefulCommand(), and relies on a getStringValue() in
pokeMultiStateUI()... Can you please explain me how things were broken with
your cpp changes ?
brade: what do you think ?
Assignee | ||
Comment 9•20 years ago
|
||
With my CPP changes, things in the Midas demo like doing an execCommand to set a
URL failed.
I didn't debug it yet.
Comment 10•20 years ago
|
||
Comment on attachment 149341 [details] [diff] [review]
Just fix ComposerCommands.js
these are probably the right fixes but I'd like to see more context please...
:-)
Assignee | ||
Comment 11•20 years ago
|
||
More context
Comment 12•20 years ago
|
||
Comment on attachment 149351 [details] [diff] [review]
More context
r=brade
Attachment #149351 -
Flags: review+
Assignee | ||
Updated•20 years ago
|
Attachment #149341 -
Flags: review?(daniel)
Assignee | ||
Updated•20 years ago
|
Attachment #149351 -
Flags: superreview?(kinmoz)
Assignee | ||
Updated•20 years ago
|
Attachment #149351 -
Flags: superreview?(kinmoz) → superreview?(dveditz)
Comment 13•20 years ago
|
||
Attachment #149351 -
Flags: superreview?(dveditz) → superreview+
Assignee | ||
Updated•20 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 14•20 years ago
|
||
2004-06-15-07(trunk)/Win-2K used font of Japanese Font Name successufully in
both HTML mail composition and HTML editing by Composer.
Original problem of this bug has been resolved.
However, there are problems in font-family specification in HTML source.
(1) Font name was always converted to lower case.
For example, "Times New Roman" was converted to "times new roman".
This conversion was done even on DBCS alphabet letters of Japanese Font Name.
Is this conversion to lower case is intentional?
This did not cause font use problem by Mozilla on MS Windows.
However, this may cause font use problem by Mailer/Browser on other systems.
Won't this cause problem? (especially on Unix)
(2) If font name contains space characters, font name was not enclosed by quotes.
HTML became <SPAN STYLE="font-family: times new roman;">
This should be <SPAN STYLE="font-family: 'times new roman';">
Workaround:
After font selection from Format/Fonts menu, add single quotes manually
through "Advanced Properties/Inline Styles" of the tag.
This problem is not so small in Japan because most popular Japanese Fonts,
"MS Mincho" and "MS Gothic" on MS Wondows by Microsoft,
contain space in the font name.
Assignee | ||
Comment 15•20 years ago
|
||
The lower casing happens here:
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/html/nsHTMLCSSUtils.cpp#873
glazou: how can we be more selective about our lower casing? And shouldn't we be
quoting stuff?
Comment 16•20 years ago
|
||
Assignee | ||
Comment 17•20 years ago
|
||
Comment on attachment 151362 [details] [diff] [review]
in answer to mkaply's question; this does not deal with the quotes problem
r=mkaply
Attachment #151362 -
Flags: superreview?(kinmoz)
Attachment #151362 -
Flags: review+
Comment 18•20 years ago
|
||
Reopen bug since it has an active patch.
Daniel--can you please wrap the || to a new line? Thanks!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 19•20 years ago
|
||
Comment on attachment 151362 [details] [diff] [review]
in answer to mkaply's question; this does not deal with the quotes problem
sr=kinmoz@netscape.net
Attachment #151362 -
Flags: superreview?(kinmoz) → superreview+
Assignee | ||
Comment 20•20 years ago
|
||
Checked in to trunk.
I did not wrap the || per brade because it would have made the code look very
strange.
I don't think we need to fix the quote problem, since CSS says the quotes are
unnecessary.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Comment 21•20 years ago
|
||
(In reply to comment #20)
> I don't think we need to fix the quote problem, since CSS says the quotes are
> unnecessary.
You are right.
CSS says that quoting is required only when leading/trailing space(s) or
consecutive spaces are included in font name.
Therefore "not quoted" is not problem when "Times New Roman", "MS Mincho" and
"MS Gothic".
Sorry for my mis-understanding.
This fix caused bug 249682. Who is going to step up and fix it for 1.8?
Assignee | ||
Comment 23•20 years ago
|
||
stephen, I was just about to start debugging that.
Comment 24•20 years ago
|
||
this bug is fixed; please move discussion to bug 249682
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 25•19 years ago
|
||
The first patch for this bug caused bug 289625. Shouldn't _all_ getters/setters
of state_attribute been updated to get/setStringValue off the bat instead of
waiting for regressions to crop up? Some are now using CStringValue while
others use StringValue, which presumably causes the problem....
Comment 26•19 years ago
|
||
(Disclaimer: I don't have a tree to test this theory right now)
The problem with ComposerCommands.js is that goUpdateCommandState() can call
pokeMultiStateUI() and cmdParams may have a cstring or a string.
doStatefulCommand() also calls pokeMultiStateUI() but cmdParams is always
consistent there.
One solution would be to make all commands pass the same string type (get rid of
all cstrings).
Another option is to make pokeMultiStateUI() able to handle either type (instead
of calling getStringValue() it could call getValueType() and then call the
appropriate string getter method).
Given that this bug is resolved fixed, I will put this comment also in bug
289625 since I assume that is where the fix/patch will be posted.
You need to log in
before you can comment on or make changes to this bug.
Description
•