Closed Bug 86777 Opened 23 years ago Closed 13 years ago

MfcEmbed needs Character coding menu + Intl font download/install support

Categories

(Core Graveyard :: Embedding: APIs, defect, P1)

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: teruko, Unassigned)

References

Details

(Keywords: helpwanted, intl) 

Related to Bug 66953 which is encoding menu in GtkEmbed build.

Currently MfcEmbed and WinEmbed build does not have Character coding menu.

Tested 6-19 Mtrunk MfcEmbed and WinEmbed build.
Added Keyword and changed QA contact to myself.
Keywords: intl
QA Contact: andreasb → teruko
This is a very, very important bug for testing.
Priority: -- → P1
how long will it take to implment one ?
After discussion with Radha I am moving to Chak's plate to implement.

We don't need WinEmbed. Just MFCEmbed at this point. WinEmbed is essentially 
obsolete with the available MFCEmbed.
Assignee: yokoyama → chak
Summary: MfcEmbed and WinEmbed need Character coding menu → MfcEmbed need Character coding menu
[Sorry i could not get to this sooner as i've been on vacation for the past 3 weeks]

I'd appreciate if someone can briefly explain :

1. What is that i need to implement(i.e. should it be exactly similar to
mozilla's char encoding menu)?

2. Where's the code for Mozilla which implements this functionality(i can dig
around the source but your help will definitely speed things up)

Thanks...Chak
Status: NEW → ASSIGNED
Chak, #1. 
I expect to see the same Netscape 6.1's character coding menu in MfcEmbed.

Roy, please answer Chak's #2 question.  Thanks.
I think a context menu would be sufficent, and it may be quicker to clip the 
source from Komodo CS.
chak:  To answer your #2 question, I agree with Michael Dunn. 
I'd be suprised of Komodo is doing this properly/legally. bstell, did you get
your changes in to do this publically?
What is the current plan relative to this bug? Is there a schedule? Does more 
functionality need to be made public? 
bstell : Could you please add your comments regarding making these interfaces
public [as asked by Jud above]?

Once i get more info from bstell, i'd like to sit down with Frank or someone
else from the i18n team to determine what's the minimum functionality that needs
to be added to MfcEmbed so that QA can proceed with their i18n testing.
Component: Internationalization → Embedding APIs
Please can we have some action or schedule related to this bug? It is very
important for testing to have a suitable reference platform which comprehends
the embedding API.

Could someone please characterize the blocker here? Do we need to complete work
to make public necessary i18n related APIs? 
To put up a charset menu three things are needed:

 1) a list of encodings
 
 2) a way to find the documents current encoding
 
 3) a way to set/override the documents encoding

For MfcEmbed:

The list for #1 should just be hardcoded (KISS).

For #2/#3 (get/set) we have a public API for getting/setting the documents 
charset. This is what the javascipt/Xul currently use in Mozilla/Netscape.

http://lxr.mozilla.org/seamonkey/source/intl/chardet/public/nsIDocCharset.idl

 55 interface nsIDocCharset : nsISupports
 56 {
 57     
 58     /**
 59      * Get/sets the encoding (converter) used to read the 
 60      * document. Get returns the encoding used. Set forces 
 61      * (overrides) the encoding. After forcing the charset the 
 62      * embedding application will need to cause the data to be 
 63      * reparsed in order to update the DOM / display.
 64      *
 65      * A force also sets the fallback encoding for this frame.
 66      */
 67     attribute wstring charset;
 68 
 69 };

Not being an expert in this area, here's what i understand from bstell's comments:

1. MfcEmbed will have a CharacterCoding menu with the following items under it:
     Western(ISO-8859-1)
     Japanese(Shift_JIS)
     Western(Windows-1252)
     Unicode(UTF8)
     English(US-ASCII)
     Cyrillic(Windows-1251)

2. When someone chooses the CharacterCoding menu we would highlight the
appropriate submenu with the currently loaded document's character set
When someone selects a submenu under the CharacterCoding menu we set the doc's
charset appropriately
In both the cases above we use nsIDocCharset to get/set the charset appropriately

Questions:

1. How to i get hold of nsIDocCharSet
2. In 6.1, when viewing an English web page and selecting different char
encodings via the menu does nothing. How do i test this feature to make sure
things are working?


Chak -

Localize web page versions can be found at:
http://international.netscape.com/international/main.tmpl?cp=hop08fi10

I test japanese shift-jiis:
http://home.netscape.com/ja/index.html

You can test this on an english OS, but you need the language font pack from MS 
installed on the windows OS. I will find the language pack and forward to you.


Chak, You can get nsIDocCharset by GI'ing off nsIDOMWindow or QI'ing of 
docShell.

var docCharset = 
domwindow.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterfa
ce(Components.interfaces.nsIDocCharset);

once you get docCharset you can do getCharset or setCharset.
Chak for your second question 
"when viewing an English web page and selecting different char
encodings via the menu does nothing.".
you need to first go to a particular language page to see the page in that language.
1. go to netscape home page.
2. At the bottom you see all the languages say select Japan.
3. You will go to another page.Then click on link
  "Welcome! Visit Netscape Japan". If you already have a font then it will
display the page in japanese. If you dont have the font it will ask you whether
it should download the font.
4. Then check view->character encoding. It will be set to Japanese.
When i go to http://home.netscape.com/ja/index.html in 6.1/Mozilla/MfcEmbed it
does not prompt me to download the Japanese font and obviously my page is not
displayed correctly.

However, in all of the programs i see a small window which pops up [there's no
content in that window] and goes away pretty quickly. I'm not sure what that
window is since it does not appear to be a popup ad.

I'll put a breakpoint in MfcEmbed and see what's going on.

[BTW, i'm running Windows2000 and i've not downloaded a Japanese font to my system]
The window which opens up when i go to http://home.netscape.com/ja/index.html
is being invoked by the FontPackageHandler[see the brief stack trace below]:

nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x00ad3a74, nsIDOMWindow *
0x00000000, const char * 0x03077df8, const char * 0x018b7ab0, const char *
0x018b7a88, int 0, unsigned int 0, long * 0x00000000, nsIDOMWindow * *
0x0012e518) line 552 + 71 bytes
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x00ad3a70, nsIDOMWindow *
0x00000000, const char * 0x03077df8, const char * 0x018b7ab0, const char *
0x018b7a88, nsISupports * 0x00000000, nsIDOMWindow * * 0x0012e518) line 437 + 48
bytes
nsFontPackageHandler::NeedFontPackage(nsFontPackageHandler * const 0x0306acf8,
const char * 0x0012e56c) line 76 + 71 bytes
nsFontPackageService::NeedFontPackage(nsFontPackageService * const 0x0306ab9c,
const char * 0x0012e56c) line 70
It's trying to load the following URL into the window via WindowWatcher:
   http://www.mozilla.org/projects/intl/fonts/win/en/package_ja.html

However, nothing gets loaded into the window and the window disappears in a
second or two. Not really sure what's going on here.

Again, this happens in 6.1 and MfcEmbed.

Cc:ing Danm for some windowwatcher info. in this context.
1. Changing summary to better reflect the bug.

2. Adding dependency on : http://bugzilla.mozilla.org/show_bug.cgi?id=93982
[Font Downloading support for XP and Windows 2000]

3. Some comments from Roy on current font related issues with XP and Windows 2000:

Current Windows font packages are located at the following MSFT sites:
(Korean)
http://msvaus.www.conxion.com/download/ie5/ime/5.02/w9xnt4/en-us/komondo.exe
(Japanese)
http://msvaus.www.conxion.com/download/ie5/ime/5.02/w9xnt4/en-us/jamondo.exe
(Chinese Simplified)
http://msvaus.www.conxion.com/download/ie5/ime/5.02/w9xnt4/en-us/scmondo.exe
(Chinese Traditional)
http://msvaus.www.conxion.com/download/ie5/ime/5.02/w9xnt4/en-us/tcmondo.exe

However, we are investigating a better way.  Currently, downloading above
packages require an user to install and REBOOT his/her system.   Plus the above
packages are not supported in W2K and XP.
There is a bug already logged for a better implementation.
Depends on: 93982
Summary: MfcEmbed need Character coding menu → MfcEmbed needs Character coding menu + Intl font download/install support
w2k just requires the user to add the stuff in the regional options control 
panel. [I just check all the boxes; click advanced, check all the boxes, click 
ok. click ok]. As for the ime, that requires me to actually run some install 
binary in system32 or something.
->1.0
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
I don't have the slightest idea what "MfcEmbed" means, but I guess the target
milsetone is way overdue!
Assignee: chak → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: mozilla1.0.1 → ---
Filter on "Nobody_NScomTLD_20080620"
QA Contact: teruko → apis
Mass marking all MFCEmbed bugs as wontfix, since bug 377410 removed it. If this bug was erroneously included (or say equally applies to winEmbed), please reopen & accept my apologies.

Filter bugspam on mfcEmbedwontfix.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.