(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #301000 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=301000 Imported into Bugzilla on 03/31/99 02:43) ** This bug is split from #300221 which deals with the display part of the problem. This one is for Composer. ** Steps to reproduce: * in Composer set encoding to Western (MacRoman) * type in the PI sign (key combination on english keyboard is ALT p) * type in the cross sign (key combination on english keyboard is ALT t) * view source and see keys are written as &Yacute (cross) and &frac14 (PI) * save document and open in Browser * see that these two keys are not recognized (displayed as question marks) Composer produces "Ý" and "¼" for the cross and Pi symbols, respectively. These 2 letters are MacRoman only and they don't exist in ISO-8859-1 or Windows-1252 tables. "Ý" and "¼" seem to be erroneous representations of these characters also. I would think that under MacRoman encoding, you would have to generate these characters direclty as 8-bit characters since they don't match up to anything in the other charsets. Or else use Unicode-based NCRs. Andreas, can you look at other MacRoman only characters and see if they produce correct NER's? Also, can you look at all the ISO-8859-1 ones under Windows and Mac to see if the Composer is generating correct ones? Anything else, Kathy? The Composer team requested that we review the HTML entities under these 2 encodings in Mac and Windows clients. This way they can make all the necessary corections in the same bug fix.

in addition to the previous two characters, the following characters don't produce correct NER's and are not displayed: * uppercase PI (key combination on english keyboard is Shift ALT "p") represented as "&frac12;" * less equal sign (key combination on english keyboard is Shift "<") represented as "&frag34;" * medium dash sign (key combination on english keyboard is ALT "-") represented as "&shy;"

grabbing a bunch of mac composer bugs from Kathy, just cuz.

Assigning Kat as QA assigned

I'm getting of all bugs to be fixed in 5.0 off the Nova radar. We'll revisit them later. --- Marek

These bugs should not have been resolved remind; reopen them to keep them on 5.0 radar.

Is this bug still relevant with no codebase? Please respond.

These NERs are certainly going to be there in 5.0 and should be correctly generated. I'm not sure, however, the fix for this is something which will apply to both 4.x and 5.0. It could be that this might prove to be a problem area again in 5.0. Let's for now assign this to ftang and move it over to 5.0. ftang then can decide if this is being taken care of or not.

Momoi: please verify with 5.0 M3 and list the broken behavior for this bug in detail, thanks.

These problems require working Mac editor to verify. I don't believe time is ripe for that yet. Let's wait until we have a reliable HTML editor for Mac to verify if these problems still exist.

Mark it M7. Momoi cannot verify this untill Ender, keyboard handling, and IME is stable.

Frank will probably be out on paternity leave during M8. Moved to M9.

momoi, greg say you can use Debug:Output HTML menu to verify. Mark it WORKSFORME for now.

** Checked with 6/14/99 Mac build ** I tried "Debug | Output HTML" menu but that did not work. It would probably require a debug environment to be there for this menu to work. If you have checked the facts about the 5 characters mentioned in the original report, then you can go aheqad and mark it verified. Or else you can assign it to someone in I18n who has a debug enviroment.

** Checked with 10/7/99 Mac commercial build for M10 ** Really can't tell if this is working or not since all ALT (option) key input actions are disabled currently. Re-opening it until the opt key input is working.

Is there a bug for the ALT key input not working?

Moving to M11 whilst you work on it. If you feel a Release Note for M10 may be needed, please comment in http://bugzilla.mozilla.org/show_bug.cgi?id=14872

there is bug 13016 that deals with a particular instance of the alt key not working

Bug 13016 is about the special use of the Right-Alt key on PC in non-Latin 1 ISO languages, I think. This is a simple MacRoman option key problem. Maybe I'll enter a new bug.

I filed the Mac option key bug as Bug 15842.

kathy, this is a mac only bug, since you fix key event for Mac, can you verify this is fixed or not ?

** Checked with 10/21/99 Mac Netscape build ** I got mostly good results with this build. Here's what got generated by our Editor in the way of CERs. OPT + p --> &pi; OPT + P --> &prod; OPT + - --> &ndash; OPT + t --> &dagger; OPT + < --> &le; These seem OK except "OPT + P". This is supposed to be Uppercase "Pi" and there exists "&Pi;" as teh CER for that. However, we are producing "&prod;" which is a symbol for n-ary product. Of ocurse, n-ary product and uppercase Pi symbols do look alike. But shouldn't we be producing "&Pi;" instead? Any opnions?

The Unicode mapping table we are using indcates that "opt + P" should be "n-nary product" symbol. ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT I'm satisfied that we are doing the right thing now. Marking the fix verified.