You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Known Issues for Mozilla 1.8 Alpha6 - International

General

Mozilla has been designed to display many different languages without extra steps. The user should be able to browse and use e-mail without complicated setups or efforts when necessary fonts are available on the system.

Mozilla can be used with more than one language packs, which lets the user change the menu language and relevant URLs.

Contents of Sidebar tab and Bookmark will not change when you choose another region -- they are bound to a specific profile by design. (Bug 87939)

If you are using Chinese, Korean or Japanese language Windows 9x/ME and launching fails or crashes, read the Java section below for possible causes.

On platforms which support file names in Unicode, it is possible to create files and folders bearing names in scripts which fall outside of the system locale. Other browser operations which involve such folder or file names may not succeed, e.g. saving into such a folder, or opening a file whose path contains such characters. Using only characters supported by the default system language avoids this type of problems. (For details, see Bugs 58866, 100243, 100344, 100364, 100396, 101573, 128380, 104305, 162361) On Linux/Unix under UTF-8 locales, most of these problems don't exist.

Display

What can be displayed in the window title bar is platform-dependent. On platforms where Unicode is natively supported (Windows 2000/XP, Unix/Linux with UTF-8 locales, and Mac OS X), any Unicode character can be displayed in the title bar as long as you configure a font that contain characters used for the title bar. On other platforms (Windows 9x/ME and Unix/Linux with non-UTF-8 locales), only characters within the repertoire of the current locale can be displayed. (Bug 9449. See Bug 150131 on how to avoid by this problem by choosing Unicode-aware Windows Manager and setting fonts appropriately on Linux.)

The default for contextual numeric alteration has changed since Mozilla 1.4 Western digits in Arabic documents are no longer automatically replaced with Arabic digits in a context-sensitive manner. To activate the contextual replacement of Western digits with Arabic ones, type about:config in the location bar and set the value of the preference item bidi.numeral to 1 (Bug 181711). Alternatively, you can edit user.js by locating the file in the profile directory and using a text editor that can handle UTF-8 encoding.

Rendering of complex scripts such as Devanagari, Tamil, Thai, and Hangul Jamos is platform/toolkit dependent.

  • On Windows 2000/XP, Devanagari, Tamil, Thai and possibly other South and Southeast Asian scripts as well as Hangul Jamos are rendered well with the native OS APIs once you activate support for one of these scripts. All versions of Windows 2000/XP come with support tools and fonts for these scripts regardless of the language version of the Windows OS.
  • On Windows 9x/ME, Thai renders well only on Thai language version of Windows. Tamil and Hangul Jamo rendering by contrast is supported on any language version of Windows 9x/ME. (Bugs 140013, 177877 ) Devanagari and other Indic scripts (other than Tamil) are not properly rendered, though. (Bugs 166520, 218887 )
  • Mozilla for Linux/Unix renders Devanagari and Thai well as long as you have necessary fonts and Mozilla is built with CTL (Complex Text Layout) enabled. In the default release of Linux binary, it's disabled. Enabling it would enables Mozilla to render Devanagari on Windows 9x/ME. (Bug 201746) as well.
  • You need the following fonts for complex script renderings.
  • On Mac OS X, complex scripts are not rendered correctly at the moment. (Bugs 205476, 121540 )
  • ZWJ/ZWNJ don't work as intended at the moment. For this and other issues in Devanagari (and Indic script) rendering, see Bug 202352.
  • Now that bug 176290 was resolved, Mozilla-Xft build renders Tamil and Korean well by default and Thai as well with CTL enabled. However, Devanagari and other Indic scripts are not yet supported. (Bugs 203406, 204286, 215219, 214719)
  • The cursor movement and selection/highlighting don't work as expected, yet. It takes multiple keystrokes to delete or move by what's usually perceived as a unit in complex scripts because Mozilla works in terms of Unicode characters instead of graphemes. For the same reason, the boundaries of the text selection/highlighting can fall between Unicode characters making up a single grapheme. (Bugs 79286, 85420, 100173, 122552, 157534, 229896 )

The font selection is dependent on the value of lang (HTML) or xml:lang (XML) specified in the document. However, there isn't yet a way to set the language of documents in Unicode without the language specified. "View | Set Language" option is necessary for them. (Bug 121193) Even if this feature is implemented, it's strongly recommended that authors of HTML and XML documents explicitly specify the language of a document or a part thereof with lang (HTML) and xml:lang (XML).

Content-Language in the http header is not honored, either. (Bug 122779)

Unrecognized language tags used to be considered as synonymous with Western (Latin), but are now considered synonymous with x-unicode (Unicode). As a consequence, the fonts to render those pages with a language tag not handled by Mozilla can be controlled by configuring fonts for Unicode. This is handy to configure fonts for text in a language for which there is not yet a separate language group in Mozilla's font preference panel. (Bug 256383)

In addition, on some platforms, the font preference setting for Unicode is ignored and the font preference setting for the current locale is used for documents in Unicode without the language tag. (Bug 91190)

Line breaking algorithm is not based on UTR 14 (Line breaking) but based on JIS X 4051. It's not language-dependent except for CJK and Thai. Moreover, characters below U+0100 (most Latin letters and punctuations used for Western European text) are not subject to line breaking rules at all. (Bugs 206152, 203016, 164759, 255990)

Invisible characters need to be rendered invisible even if there are fonts with visible glyphs for them on the system (Bug 205387)

Mozilla now has a separate font selection menu for zh-HK, Traditional Chinese (Hong Kong). To view web pages with Hong Kong SAR specific characters, you need to download big5hkscs-0.enc file from the XFree86 CVS, compress it with gzip and install the compressed file in /usr/X11R6/lib/X11/fonts/encodings/large after compressing it with gzip. (For more details on the procedure and font downloading information, see bugs 226183 and 152264)

Mozilla does not support Dynamic Fonts. (Note: It was supported in Communicator 4.x.)

Auto-detect All/Universal may not be able to detect encodings in some cases on pages which don't supply document encoding information. You may instead try other auto-detection modules with a smaller scope for detection, e.g. Simplified Chinese, in such a case.

With the Windows 2000, IME, most of the new Japanese IME features (e.g. reconversion) are supported but some features may not work correctly. (Bug 18680)

When opening a file under a folder with multi-byte folder name, the path name in multi-byte characters is escaped in the title bar of Composer window. (Bug 136221)

In the window without menu and toolbar, there's no way to change character coding. Neither is there a way to change the character coding of a (focused) frame. (Bugs 63054, 70830, 98395, 26353)

The search sidebar (with Google as the default) works well for any language regardless of the current locale. As of 1.7 Beta, the default keyword server is google and looking up non-ASCII keywords in the location bar works well. (Bug 119825)

Linux only: Bold and Italics styles may not work on ASCII characters when editing a CJK page. This is most likely to happen on CJK locales without good ASCII fonts. For example, you may be using open-source CJK locale support files. On commercial Linux distribution, particularly recent ones, the support files contain better CJK fonts and this problem is less likely to occur. (Bug 91145)

On RedHat Linux 8, users may not be able to input Japanese characters with the default Kinput2 XIM server without considerable difficulty when using the default "on-the-spot" input style. This is known to be due to a bug in RedHat 8 Windows Manager, Metacity. RedHat 9 uses a later version of Metacity and does not have this problem. A workaround is either to upgrade to a newer version of Metacity Windows Manager or to use the "over-the-spot" input style. (See Bug 210134 for details.)

Mozilla crashes under CJK UTF-8 locales when one of CJK XIMs is used due to a bug in XFree86 prior to 4.2.0. A workaround is to use over-the-spot input style instead of on-the-spot. XFree86 4.2.0 or later doesn't have this problem. (See Bug 128875 for details.)

Mac OS: Non-ASCII non-Latin 1 info stored in Internet Config will not show correctly in auto-fill fields such as "Your name" field in the Mail account setup dialog. If this happens, you can manually correct auto-filled entries. (Bug 5721)

Mail

Filtering by body key is not implemented.

The Character Coding menu cannot correct the thread pane display of non-MIME encoded headers. (See RFC 2047.) Mozilla does not use a fallback of regarding those headers as in the charset of the message body (specified in Content-Type header), either. If the message displayed lacks MIME charset information, the thread pane display obeys the default message display charset set via the folder properties dialog (set via the menu "Edit | Folder Properties ..."). Correctly setting this option to the charset most often used in the user's mail viewing helps avoid display problems of this type. (Bug 90584)

Non-ASCII names of files attached to mail messages are not encoded in compliance to RFC 2231 (Bug 193439).

Printing

Windows: You may be unable to print out Japanese characters from Win98-J with HP Laser Jet driver (Japanese version). Workaround: Install the driver that comes with the Japanese Windows 98 installation CD. Or go into printer properties, choose details tab, choose spool settings, choose "print directly to printer option". (Bugs 86989, 130083)

Windows: If you have WinME-Ja, you may not be able to print to a HP LaserJet 5Si/5Si MX using the HP LaserJet 5Si/5Si MX PS printer driver In this case, you should change the driver to HP LaserJet 5Si/MX. Or go into printer properties, choose details tab, choose spool settings, choose "print directly to printer option". (Bugs 86989, 130083)

Linux/Unix: There are two different printing methods, direct PostScript and Xprint:

PostScript
The direct PostScript printing method comes in two flavours:
Normal mode
(Requires PostScript Level 2 printer and/or Ghostscript)
To use the PostScript module with non-Latin 1 languages, you have to set print.postscript.nativefont.x-cyrillic to a Cyrillic PostScript font on your system. (where x-cyrillic is for Cyrillic. For other scripts, use langGroups corresponding to them. For instance, zh-CN is for simplified Chinese and el is for Greek.) either typing about:config in the location bar or editing user.js. For CJK, you may also have to set print.postscript.nativecode.ja (or zh-TW, zh-CN and ko) to the character coding used in your PostScript (composite or CID-keyed) font. (EUC-JP, EUC-KR, Big5, gb18030, UTF-8). Because only one font can be designated for each script/language, the distinction between different font families, font-weight and style variants are lost in the print output.
Note that using print.postscript.nativefont.* assumes that the referenced fonts are built-in printer fonts or are downloadable/embeddable by an external filter like Ghostscript or WPrint.
FreeType2 mode
(Requires PostScript Level 3 printer and/or Ghostscript + FreeType2 shared library)
The default Linux binary now comes with freetype2 printing enabled. This dramatically enhances the printing result of documents with characters outside Latin-1 repertoire. (Cyrillic, Greek, CJK) In addition, the families and styles of fonts in the print output can more closely follow what you see on the screen rendering with this.method than is possible with the normal mode. For details, see Mozilla freetype project page. (Bugs 144668, 144669, 185935).
However, if you use a Gtk2+Xft build (included in most Linux distributions these days), you do not need to do anything special to set up truetype font directories. As is the case for the screen rendering, fontconfig is used to discover and select fonts for printing, which makes it possible to generate an even more faithful replication of the screen rendering in the printed output.
Note that PostScript files generated in this mode have to be filtered through Ghostscript even for a PS printer unless it supports PS level 3. If you use one of recent Linux distributions, there's not much, if any, to do, but on other flavors of Unix, you may find it useful to refer to http://www.cups.org and http://www.linuxprinting.org. Filtering PS files generated by Mozilla through ghostscript results in a rather low quality output with some PS printers (Bug 234182).
Xprint
(Requires Xprint server)
The default Unix/Linux binary comes with an alternate print module called Xprint which features CUPS, LPRng, MathML, TrueType fonts and PostScript/PDF/PCL output support.
For more information see http://xprint.mozdev.org for a thorough and very detailed guide and Mozilla.org's Xprint project pages.

Java

Some cases have been reported in which Windows 9x/ME Japanese users have a problem starting Mozilla when there is a prior installation of older JDK or JRE under the operating system in use. The JRE 130_02 (or later) that Mozilla users can download from a Netscape ftp site contains many fixes since the official release of JRE 1.3. If you are using an older version of JRE 1.3 or the US version of JRE 1.3 under Japanese/Chinese/Korean Windows, you may experience this non-start problem.

To determine if the non-starting problem is due to Java installation, follow these steps:

  1. Locate the Plugins directory (which is found in the same directory as the Mozilla executable).
  2. Remove all the Java plugin files from the Plugins directory, i.e. the files whose names begin with "npjava...". Remove also the NPOJI610.dll file if you find one. Back them up in another directory so that you can restore them later.
  3. Restart Mozilla . If Mozilla starts, then you have a Java related non-start problem.

If you have the Java problem as described above or want to install updated JRE 130_02 (or later) that you can download from a Netscape ftp site, follow these steps (Note: This type of problem has not been reported for Windows NT4/2000, but if you experience this problem on the latter two platforms, follow these steps for those platforms also):

Flash Plugin

On Linux and other platforms where XFree86 is used, Mozilla crashes while rendering a web page with flash animations if XIM server is active (Bug 211213). The crash is due to a bug in XFree86 that was fixed recently. As of Mozilla 1.7 Beta release, XFree86.org had not yet released a new version with this bug fixed. However, most Linux distribution builders have released updates to XFree86 with this fix so that you can avoid the crash by updating XFree86-related packages. If the latest XFree86 package in your distribution doesn't include this fix, you may take a couple of workarounds :

  • Run mozilla in a locale with which your XIM server does not work. For instance, running mozilla with the following command env LC_ALL=C mozilla enables you to avoid the crash
  • Disable your XIM server before running Mozilla. The following command can be used: env XMODIFIERS= mozilla