Closed Bug 100880 Opened 23 years ago Closed 23 years ago

I18n applet does not work correctly with JRE 1.3.1

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: teruko, Assigned: James.Melvin)

References

(
URL
)

Details

(Keywords: intl, Whiteboard: [PDT],[JRE+], [ETA 10.05])

Attachments

(1 file)

Java compatability (HTML vers of comment)
4.41 KB, text/html
Details
Under JDK 1.1.8 i18n features in http://babel/java (these applets are come with in JDK 1.1.8), I got the following result for i18n. 1. Collation- in the locale field, Japanese characters are not displayed correctly. 2. Date time format - in the locale field, Japanese characters are displayed correctly, However, Japanese characters the New date and Pattern are not displayed correctly. 3. Message format-in the locale field, result, and pattern, Japanese characters are not displayed correctly. When I type Japanese characters in the field, Japanese characters are displayed as "???". 4. Number format-in the locale field, Japanese characters are not displayed correctly. When I type Japanese characters in the field, Japanese characters are displayed as "???". These worked fine in JRE 1.3.0_01 on Japanese Windows system. Tested 9-19 0.9.4 build with j2re-1_3_1_01_win-i.exe and j2re-1_3_1_win-i.exe.
Keywords: intl, nsbranch
QA Contact: pmac → teruko
Summary: I18n applet does not work correctly with JRE 1.3.1 → I18n applet does not work correctly with JRE 1.3.1
nsbranch+ to get it on the PDT radar.
Keywords: nsbranch → nsbranch+
cc'ing momoi for some clues :-)
There seems to be a simple workaround for this problem. Workaround: 1. Locate the directory where the new JRE is installed, e.g. ...Javasoft/JRE/1.3.1/lib 2. In this directory, you will find a file 'font.properties.ja' 3. Locate the following lines: # name aliases # # alias.timesroman=serif # alias.helvetica=sansserif # alias.courier=monospaced 4. and uncomment them as follows: # name aliases # alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced 5. Go to http://babel/java and re-test the cases. 6. You should not see the problems any more. We shipped with the alias lines commented in NS 6.1 and it worked. But for some reason, in this new version of JRE, they changed how aliasing works. I guess the test cases somehow got caught in this new change. In any case, correct fonts to display Japanese characters are not used without aliasing with this version of JRE and the particualr sets of test cases. It is one text file and we can make the changes easily. That is what I would recommend if the QA can verify that this works.
The problem will not be limited to Japanese, and so I recommend uncommeting the alias lines for all the font.properties.xx files as well. If you don't want to go that far, then at least the font.properties.ja file. But any language can use this change for the new JRE. The other possiblity is to get the JRE engineers to fix the cause of this regression. I suspect that the change they made for NS 6.0 or 6.1 did not get picked up the new JRE version.
This falls squarely in Jim's realm.
Assignee: edburns → James.Melvin
Adding PDT and JRE+, because we need to gte these visbility, and attention - PDT.
Whiteboard: PDT,[JRE+]
It seems the one on http://java.sun.com/applets/jdk/1.1/demo/i18n are working since they change the Utility.java file to use "Serif" and "SanSerif" as font name instead of "TimesRoman" The test cases in your internal test sites are based on JDK1.1.8, and are not working. I ask teruko download J2SE 1.3 and see what is in it. The question is, what kind of backward compatability do we plan to support, back up to JDK 1.2? or 1.1.8? If we want to backward compatable with classes generated by JDK 1.1.8 (or modified from JDK1.1.8 sample files), then the new bits is not good. If we don't care of those pages, then we are fine now.
Let me add here that IE 5.5 works OK with both the NS-internal test cases and the modified JavaSoft test cases. I suggest supporting legacy font names for the next Netscape release. Before shipping Netscape 6.0, we asked Sun to modify the plug-in to support legacy font names. They did that -- see Bug 46449. Now this is broken. It is a regression from NS 6.0/6.1. I don't believe this is a good product shipping practice. There should be consistency in our approach.
I downloaded j2sdk-1_3_1_01-win.exe and installed it. However, demo directory does not include i18n applets.
For Netscape 6.0, I think we may have provided Netscape with a binary containing the commented out font aliases. This binary was available from netcenter.com specifically for Netscape customers. The solution was not seen as optimal for the general case, i.e. customers beyond Netscape. So, these changes, I believe, only existed in the netcenter.com binary, and not in the java.sun.com binary. Does this ring a bell with someone? Can you refresh my memory? Do I have this right?
> Does this ring a bell with someone? Can you > refresh my memory? Do I have this right? This does not contradict my memory of the events surrrounding this issue last year. I believe that is what Stanley Ho provided us in response to Bug 46449.
Whiteboard: PDT,[JRE+] → [PDT],[JRE+], [ETA 09.28
Last night I had a phone conference with Brian Beck from Sun and Arun. Brian proposes to alias all 3 virtual font names to sanserif instead of just uncommenting them in the build Sun will provide for 6.2. So instead of # name aliases # alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced Brian proposes using # name aliases # alias.timesroman=sansserif alias.helvetica=sansserif alias.courier=sansserif Brian says this is the behavior of the special JRE that Sun delivered to Netscape for the 6.0 release. The code Sun added, has a single fallback if the font name does not match a real font name. The fallback is sanserif. Sun plans to make the same code change for this fallback in an updated JRE available to everyone (not just Netscape). Brian believe this is the best change because it will be compatible with Netscape 6.0 and with the planned JRE update. For Japanese (based upon current font.properties.ja), sanserif and monospaced map to the same font, MS Gothic (in Japanese). So these 2 virtual fonts will work as they did in Netscape 4.x and older JREs. However serif maps to MS Mincho (in Japanese), so characters will be displayed but in a different font (MS Gothic instead of MS Mincho). We probably can live with that. Korean (based upon current font.properties.ko) is similar to Japanese in that serif is mapped to a different font. Chinese(s) (based upon current font.properties.{zh,zh.NT4.0,zh_TW}) seems OK because all three (serif, sansserif and monospaced) are mapped to the same font. For non-CJK, courier will not use monospaced and any applet depending upon monospaced character spacing will not work (e.g., lining up columns). Bottom line: Brian's proposal is an improvement in that at least characters will be displayed, and provides compatibility with 6.0 and future JRE updates.
I changed the font.properties file as Brian Beck suggested and tested Japanese applets. This worked fine. However, I realized the Japanese font was different in http://babel/java/Blink/1.1/example1.html Japanese characters are displayed as MS Gothic. I compared with JRE 1.3.0_01. The Japanese font what I see in the applet is different. It looks MS Mincho. I compared the font.properties.ja files on both. Sans Serif maps to MS Gothic on both font.properties.ja files. Serif maps to MS Mincho. Should we map to Serif instead of San Serif?
We looked at the applet sources. The old applets on babel, e.g., http://babel/java/jdk1.1/i18n/Collate/example1.html (Source: http://babel/java/jdk1.1/i18n/code/CollateDemo.java) uses "TimesRoman": private static final Font editFont = new Font("TimesRoman",Font.PLAIN,18); private static final Font ruleFont = new Font("TimesRoman",Font.BOLD,14); So when we alias timesroman=serif, it should display as MS Mincho and when we alias timesroman=sanserif, it should display as MS Gothic. The old applets on babel, e.g., http://java.sun.com/applets/jdk/1.1/demo/i18n/Collate/index.html (Source: http://java.sun.com/applets/jdk/1.1/demo/i18n/code/CollateDemo.java) uses "Serif": private static final Font editFont = new Font("Serif",Font.PLAIN,18); private static final Font ruleFont = new Font("Serif",Font.BOLD,14); so it will not be affected by any changes to the aliases for timesroman, helvetica or courier and should always display as MS Gothic.
> so it will not be affected by any changes to the aliases for timesroman, > helvetica or courier and should always display as MS Gothic. Except that the "Serif" font is "MS Mincho" and not "MS Gothic".
> Except that the "Serif" font is "MS Mincho" and not "MS Gothic". Whoops. What he said!
> > Except that the "Serif" font is "MS Mincho" and not "MS Gothic". > Whoops. What he said! And this means we still have unexplainable phenomena, which leads me to a guess that there might be a JavaVM default system font and somehow MS Gothic font is used. Quite possibly, > private static final Font editFont = new Font("Serif",Font.PLAIN,18); > private static final Font ruleFont = new Font("Serif",Font.BOLD,14); do not cover all the font uses in the Collate Demo.
ftang raised another old issue that may not be known to everyone who have not been involved with these issues since the 6.0 development time... (This was an issue that we raised with Sun back in 6.0. It was unclear why it is OK to have these aliases for US systems, but not for non-US systems.) The font.properties (without .xx locale extension) which is used by US (and Western European) Windows systems includes the aliases in question: alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced Only in the font.properties.xx files have these alias line been commented out. The behavior of applets when using these virtual font names will continue to be compatible with Netscape 4.x and older JRE releases on US (and Western European) Windows, but not compatible on Japanese and other Windows. Additionaly, ftang points out that "ASCII text will be shown differently on US machine and Japanese (or other language) machines." So that the same applet will display ASCII (or Latin1) text using 3 different fonts on a US Windows system, but with only one font on non-latin based Windows systems. This is another drawback of the Sun proposal, but I still feel it is acceptable because at least the correct glyphs will be displayed even though not rendered with the typeface or proportional/fixed-width font as the applet writer expects.
> And this means we still have unexplainable phenomena, which leads me > to a guess that there might be a JavaVM default system font and somehow > MS Gothic font is used. > Quite possibly, > > > private static final Font editFont = new Font("Serif",Font.PLAIN,18); > > private static final Font ruleFont = new Font("Serif",Font.BOLD,14); > > do not cover all the font uses in the Collate Demo. Teruko and I just looked at the source of the Collate Demo. And this is explainable. Some of the widgets in the applet are in MS Gothic, but the applet does not explicitly set the fonts for those, so they are defaulting to some Java default. The scrollable text widgets: textentry (on the left side) and ruleEntry (on the right side) are the ones which are explicity set to "Serif". Those are displayed as MS Mincho as we expect.
I spoke to Brian Beck from Sun and he explained Teruko's test results. In the JRE 1.3.0_01 release that Sun provided Netscape for 6.0 and 6.1, the font fallback (described in previous comments) was implemented for AWT and not the lower level 2D drawing methods. Some of the http://babel/java/ demos (e.g., Blinking Text, Nervous Text, Growing Text) use the 2D drawing methods (e.g.,drawChars, drawString) and display Japanese text as MS Mincho instead of MS Gothic. This is consistent with Teruko's results withhttp://babel/java/Blink/1.1/example1.html. Other demos (e.g., collate) use AWT drawing methods which in JRE 1.3.0_01 performs the font fallback to sansserif, so Japanese text is displayed as MS Gothic (with the aliases commented out). This is consistent with Teruko's results. Brian said that the font fallback will be added for the 2D drawing methods in the next JRE update, so thenthe applets will display Japanese text as MS Gothic just like AWT.
Here's the compatibility summary. I'll attach a more readable HTML document too. -bob JRE and Japanese Font Compatibility Java Release timesroman helvetica courier AWT 2D AWT 2D AWT 2D Netscape 4.x Java Mincho Mincho Gothic Gothic Gothic Gothic JRE 1.3.0_01 (NS 6.1) Gothic Mincho Gothic Mincho Gothic Mincho JRE 1.3.1 w/Modified Gothic Gothic Gothic Gothic Gothic Gothic font.properties.xx (NS 6.2) Future JRE Update Gothic Gothic Gothic Gothic Gothic Gothic Netscape 4.x Java: The Java shipped with Netscape 4.x (and earlier) included font.properties.xx file with these aliases: alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced JRE 1.3.0_01 (NS 6.1): JRE 1.3.0_01 was shipped with Netscape 6.0 and 6.1. This was a special build from Sun for Netscape which included a patch for fonts to fallback to sansserif for AWT. The patch was not applied to 2D drawing methods. The font.properties.xx file had these aliases commented out: #alias.timesroman=serif #alias.helvetica=sansserif #alias.courier=monospaced JRE 1.3.1 with Modified font.properties.xx (NS 6.2): The patch (see JRE 1.3.0_01 above) for the font fallback was not applied to this release. A secondary installer created by Netscape will overwrite the font.properties.xx included in the JRE. The proposal is that the new files will alias all of the old virtual font names to sansserif: alias.timesroman=sansserif alias.helvetica=sansserif alias.courier=sansserif Future JRE Update: Brian Beck from Sun said that Sun will update JRE after 1.3.1 to include a patch for the font fallback to sansserif for both AWT and the 2D methods. The font.properties.xx file will have these alias commented out: #alias.timesroman=serif #alias.helvetica=sansserif #alias.courier=monospaced
Whiteboard: [PDT],[JRE+], [ETA 09.28 → [PDT],[JRE+], [ETA 10.05]
Attachment #51963 - Attachment description: Easier to read HTML version of previous comment → Java compatability (HTML vers of comment)
Mozilla does not bundle JRE. For Netscape, the resolution will be for Netscape to create modified font.properties.xx files which will be provided in an additional installer package that will be overwrite the JRE 1.3.1 font.properties.xx files. We need a way for Mozilla users to fix this problem for Japanese (and other) Mozilla users. For Mozilla, here are instructions how to get Java: http://www.gerbilbox.com/newzilla/mozilla/usingmoz07.php But since Netscape 6.0/6.1 shipped with a special JRE, I don't know how current Mozilla users resolved the problem with the stock Sun JRE 1.3.0... Are there instructions anywhere explaining how to fix it via font.properties.xx? For Mozilla users, we probably should either document the font.properties.xx changes or better make versions available for download.
The patch is in http://bugscape.netscape.com/show_bug.cgi?id=9979. Can this be resolved for the branch?
teruko- we think the installer now install the JRE font property patch now. Please verify that on the m0.9.4 branch with NEtscape build. Thanks.
Status: NEW → ASSIGNED
mark it fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Please see the comment on bugscape bug 9979.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Moving Teruko's comment to this bug from bugscape. I tested this with 10-08-05-0.9.4 build on Winnt 4.0, Win2k, WinXP, WinME, Win98, and Win95. This works on Winnt 4.0, Win2k, WinXP. However, this does not work on Win95, Win98, and WinME. After I installed the build on Win95, Win98, and WinME, 9 font.properties files are not changed.
from bugscape 9979 >------- Additional Comments From Sean Su 2001-10-09 17:28 ------- >1.1 patches have been checked into the trunk and branch. >Teruko, this will fix the problem under win9x systems. close this bug again to triger QA. Teruko, please verify this again.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Bugscape bug 9979 is workaround of this bug. Should we keep this open until the original bug is fixed?
Here's what I would like to suggest: 1. Verify this bug for trunk and branch builds. 2. Then re-open it with a note that this problem will be re-verified when Sun publishes JRE1.3.1_x revision which will be equivalent in behavior to the workaround fixes incorporated into Mozilla branch and trunk. **Jim Melvin is to notify through this bug report when the revised JRE 1.3.1 is published. 2b. Then resolve this bug when the new JRE 1.3.1 is out. QA will then verify the fix and then close the bug. 3. I will be publishing a doc on how to deal with Stock JRE1.3.0 and JRE1.3.1_01 problems for Mozilla and Netscape users incorporating some of the historical background of this issues for clarification. This document will probably include the workaround fixes.
I verified this as fixed for now as Kat suggested. Tested 2001-10-10-05-0.9.4 Win32 build and 2001-10-10-09-trunk Win32 build on Win95-J, Win98-J, WinME-US & WinME-J, WinNT 4.0-J, Win2k-J, and WinXP-US & WinXP-J with Full installer and Custom installer. After I install NS, I tested I18n applet. Everything works fine.
Status: RESOLVED → VERIFIED
Re-opening it so that Sun's fix can be verified when it is published at java.sun.com. The fix should provide identical test results to the ones reported for Netscape side's workaround fixes. Jim Melvin, please announce in this bug when the modified version of 1.3.1 JRE is out.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Can we open a seperate bug for the Sun fix on their web site? This was this client issue can be resolved fixed for the trunk and the branch. The other issue is really outside the client code.
See bug 103926. I think greggl is doing the work and you may want to let him know about the this extra stuff in this bug.
I think bug 103926 is for N.com, not java.sun.com. Either way, this bug should be Resolved | Fix. All other issues, should be migrated to other bug(s).
> Can we open a seperate bug for the Sun fix on their web > site? This was this client issue can be resolved fixed > for the trunk and the branch. The other issue is really > outside the client code. It is a matter of procedure. We have done similar things before this way. As far as we are concerned this bug has been resolved for nsbranch. So, you can remove nsbranch+. We have all the history of this issue in this bug, I thought it would be easier to understand the issues involved this way. Jaime, I don't mind someone filing a new bug on this if that is preferred, I thought we can accomplish the same task by removing nsbranch keyword.
There needs to be a bug (this one or a new one) which enables us to track the status (e.g., FIXED, VERIFIED) of the workaround, etc. for the eMojo release.
Resolving this one as Fixed for the client (094 branch and the Trunk). Pls new bugs for all other issue(s) which need to be resolved.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Since teruko already verified the fix for this bug, I will now mark this bug as verified/fixed. Per agreement with Sun, checking with the promised new JRE 1.3.1 from Sun Java site will be conducted in http://bugzilla.mozilla.org/show_bug.cgi?id=105211
Status: RESOLVED → VERIFIED
removing item for this fixed bug from release notes
Blocks: 145287
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: