Bugzilla – Bug 594780
Corupted strings in GUI installer for all dialogs.
Last modified: 2010-07-15 07:18:20 UTC
Created attachment 353163 [details] CHT_iMan2.7_GUIInstaller Build Number: 20100330_060001_Install OS Server: SLES 10 SP3 32bit OS Client: SLES 10 SP3 32bit Steps to Reproduce: 1. Run Installer. Actual Results: Corupted strings in GUI installer for all dialogs. Expected Results: Should be corrected.
Created attachment 353164 [details] ENU_iMan2.7_GUIInstaller
Repro for zh-tw locale, not repro for zh-cn locale
Hi Trevor, this looks like whole setup dialog doesn't support Japanese and Traditional Chinese characters. Strings are correctly translated in FwResources_lang.properties so it probably cannot be fixed in our side. I don't see any difference (in NLWs) between zh_TW and zh_CN which works. Could you please reassign this to DEV. Thanks Tom
I've done some more investigation and it seems this issue is platform dependent. RHEL Server 5.4 GUI installer appeared fine for both Chinese and Japanese - see screenshots. SLES 10 SP3 GUI installer appeared corrupted for BOTH Chinese (simplified, traditional) and Japanese - see screenshots. There is the same Java version installed on both systems. However I don't think this issue dependent on Java installed in system rather on Java bundled in installer itself. I would say there is something wrong with Java bundled in iManager installer, e.g. it uses nonstandard font that is not supported on SLES for Asian languages. I've also tried to launch installer of other Novell product that uses bundled Java (it was Sentinel Collector Manager) on the SLES 10 SP3 and it appeared fine for both Chinese and Japanese - see screenshot.
Created attachment 354081 [details] 594780_ja_RHEL54.png
Created attachment 354082 [details] 594780_ja_SLES10.png
Created attachment 354083 [details] 594780_java_RHEL54.png
Created attachment 354084 [details] 594780_java_SLES10.png
Created attachment 354085 [details] 594780_zh-cn_RHEL54.png
Created attachment 354086 [details] 594780_zh-cn_SLES10.png
Created attachment 354087 [details] 594780_zh-tw_RHEL54.png
Created attachment 354088 [details] 594780_zh-tw_SLES10.png
Created attachment 354089 [details] other_zh_tw_installer_SLES10.png
Hi Kiran, I have just one more comment. There is Java 1.6.0_02-b05 included in the build. The java has probably wrong link to fonts folder because when we are installing latest java we need to do following steps. # Go to Java fonts directory: * cd /usr/lib/jvm/java/lib/fonts # Enter the following command to create symbolic link to the SLED truetype fonts directory: * SLES/SLED 10: o ln \endash s /usr/X11R6/lib/X11/fonts/truetype fallback * SLES/SLED 11: o ln \endash s /usr/share/fonts/truetype fallback IMHO when there is used old java from the build it may use wrong path to fonts. Regards Tom
BTW it's not repro on RHEL and we are also not making these steps on RHEL.
Hi, I have created a new vm and bundled as part of the Installer. Still I am seeing this issue for Chinese and Japanese languages. I think its not the problem with java we are using but something else causing the issue. The same issue I can reproduce in 2.7 FCS as well as 2.7.4 Install. I am investigating further to find out which is causing this issue.
What fonts are bundled with the new VM?
This might be similar to GroupWise bug #608919. The workaround there is to upgrade to SLE 11 SP1. Tomáš, does making the symbolic links in comment #14 make the double-byte characters display correctly in the installer?
(In reply to comment #18) > This might be similar to GroupWise bug #608919. The workaround there is to > upgrade to SLE 11 SP1. > > Tomáš, does making the symbolic links in comment #14 make the double-byte > characters display correctly in the installer? Upgrade to SLES 11 SP1 doesn't fix the issue. Making the symbolic links in comment #14 doesn't fix the issue because we have that symbolic links set up in all of OS images by default.
What version of Java is installed on RHEL?
Java version 1.6.0_18 is installed on our SLES10/11 and RHEL 5.4 images Java version 1.6.0_20 is installed on our SLES11 SP1 images According to comment #14 installer is using bundled Java anyway.
Bohumir, how does this affect the console installer?
(In reply to comment #22) > Bohumir, how does this affect the console installer? It does not.
I wonder if this is related to the values in jre/lib/fontconfig.SuSE.properties.src ? The SuSE version only specifies latin-1 fonts. The versions for RedHat and Ubuntu are much more extensive and include more detailed fallback instructions for double byte languages. The fontconfig design seems to have changed from JRE 1.4. I built a non-VM version of the installer and some of the Chinese text did appear correctly when using JRE 1.4.x I don't really know enough about the JVM to be sure though.
More information about Fontconfig : http://java.sun.com/j2se/1.5.0/docs/guide/intl/fontconfig.html
And this thread seems to cover some of this: http://osdir.com/ml/linux.suse.m17n/2006-09/msg00008.html
OK. I think this is almost definitely to do with the fontconfig for SuSE in the Sun JRE we are using for InstallAnywhere. I built a non-VM version of the installer and running it against the the IBM 1.6 JRE the Chinese characters do display correctly. If I removed the SuSE fontconfig files in the IBM JRE the Chinese characters do not display. Kiran, can you build an installer with the IBM JRE instead of the Sun one?
There is more information on this in http://blr-nld.blr.novell.com/artifacts/InstallAnywhere/installer_vms/Readme.txt "2007-02-09 Paul Thomas (pthomas@novell.com) The following VMs were modified for the Identity Manager installers: SunJRE160_00LinuxINTEL.vm SunJRE160_00LinuxAMD64.vm SunJRE150_03SolarisAMD64.vm IBMJRE150AIX_pap32dev-20070201.vm have been modified to add a jre/lib/fonts/fallback directory that contains fonts that are required for the IA installers to display characters in the following languages: Japanese (ja): sazanami-gothic.ttf sazanami-mincho.ttf Chinese Simplified (zh_CN): gkai00mp.ttf gbsn00lp.ttf fonts.scale.gbsn00lp fonts.scale.gkai00mp Chinese Traditional (zh_TW): bkai00mp.ttf bsmi00lp.ttf fonts.scale.bkai00mp fonts.scale.bsmi00lp I received help in figuring this out from Mike Fabian (mfabian@suse.de) and Shinkichi Yamazaki (syamazaki@novell.com)." We need to apply these changes to newer VM's too.
No change observed in iManager 2.7.4 build 20100708_060001_Install RHEL 5.4: Not reproducible SLES 10 / SLES 11 Reproducible for Asian languages - Japanese, Simplified Chinese, Traditional Chinese
Bohumir, can you check the embedded JVM in that build to see if the new files made it in?
I've compared jdk-1.6.0_18-1.noarch.rpm file from following path in build structure \iManager\installs\linux\packages\jvm\rpms\ between 20100708 build and 20100330 build and there are identical. If this file is embedded JVM use by installer then the new files haven't make it to the new build. I've also searched unpacked build for *.vm and new *.ttf files and there are not there.
Additional note to comment #32: While installer of iManager in progress I’ve searched the /tmp for *.ttf font files and are no *.ttf font files mentioned in comment #28 to be found
Assigning to Build engineer to make sure the updated JVM is incorporated into the build process. Thierry, when this is build you will need to deliver this to Moravia for GMC testing.
Please note this is still reproducible in iManager 2.7.4 Install build 20100712_113244_Install. There is a new bundled Java version 1.6.0_20 in the build hovewer font files mentioned in comment #28 and comment #29 are still not there.
This bugs blocks testing GMC on double_bytes languages
closed as fixed in iManager 2.7.4 build 20100714_120454_Install