Tested 6-09-10 Win32 build.
After you type some Japanese characters in the Editor and select menu File|Save to save the file,
the Japanese characters you typed in the file are missing.
Step of reproduce
1. Launch Apprunner
2. Select menu Tasks|Editor to open the Editor
3. Type Japanese character in the Editor
4. Select menu File|Save and save as a file
5. Open the file you saved in step #4 from Browser
You cannot see any Japanese characters in the page.
Naoki, please handle this since you are the most knowledge person about Ender in
our group. Thanks.
I don't see that there is a charset menu in Editor yet.
I have been able to save Latin1 high-bit characters, however.
This seems to indicate that we are defaulting to Latin 1 in Editor.
I am going to put charset menu for M8 (identical one as mail compose).
Then I will reassign to Ender group. Adding Steve Clark to cc.
Correction to my last comment. Plan to make the menu identical to browser not
I added a charset menu for HTML editor. This is UI only change and the menu is
Please reassign this to someone in Ender.
Could somebody in I18N please explain what this menu is supposed to do?
I can guess that it is supposed to call nsIDocument::SetDocumentCharacterSet,
but I don't know how we are supposed to know what string to pass in as the char
After some research, I think I understand this issue better. I think the editor
needs to do 2 things in response to a Character Set menu selection:
1. create/change a META tag in the head to reflect the new character set
2. store the character set choice internally, so on output XIF can choose the
The interface on nsIDocument is irrelevant for our purposes. It causes a
re-parse of the document which is something we DON'T want while editing.
Assigned to Akkana.
Move XIF/I18n bugs to M9; they're dependant on stubs which I18n is trying to get
in for M8.
Changing summary; it was misleading, this isn't an output/XIF issue, it's an
issue of implementing the charset menu. Not clear who owns this; it doesn't
seem to appear on our editor schedule.
A spec for implementing this is coming soon.
I think fixing this bug (really a feature request) requires 2 things:
1. code to create the meta tag properly (finding/creating <HEAD>, scanning
<META> tags for the charset attribute, inserting/replacing the charset attribute
in the right META tag)
2. storing information in the editor about the current charset, so that
information can be passed along to I18N converters on output.
Akkana, I will add the editor portions of this to the editor schedule.
For clarification, what I meant by "spec" is a UI spec. Engineering
details will be left to engineer assiged and I18n consultants.
Reassigning to momoi, since we can't do anything about this until we know what
we're supposed to do. Please reassign back to the editor group when the spec is
ready. Also adding brade to cc list.
Working on this. It will be a few more days. Accepting it.
Basic encoding menu is now in via Bug 11687.
We'll keep this bug open to implement other UE specs of
this menu item.
We now have a working proposal for implementing this menu here:
Re-assigning to tague with M11 milestone.
The menu is there, but it's not changing the meta tag in the document to reflect
the changed charset. This has caused the problems described in bug 12085.
*** Bug 12085 has been marked as a duplicate of this bug. ***
cata, I will let you handle "charset" menu work, including this. Tague and Naoki, please help cata. Thanks
change platform to ALL
Change OS to ALL
PDT - Frank - please explain further why this ought to be +
Without it, you cannot create any HTML in Japanese encoding.
Changed QA contact to firstname.lastname@example.org.
Putting on [nsbeta2+] radar for beta2 fix.
teruko, msanz thinks this is fixed..can you re-test.
After discussing with Kat:
This bug is no longer pertinent, it has been replaced with a bunch of bugs
describing the work to be done in better details.
Agreed. This original request now has all the pieces filed in separate bugs broken down into