International Information For Communicator 4 For Windows, Rubatex Information

	Rubatex Information	Search


	Rubatex Rubatex Adhesive Rubatex Bedford Rubatex Bedford Va Rubatex Com Rubatex Corp Rubatex Corporation Rubatex Foam Rubatex Insul Tube Rubatex Insulation	rubatex 1800 rubatex 320 rubatex 373 rubatex rubber rubatex tape rubatex closing rubatex closed cell gasketing felpro gaskets poly products supplies poly hunting feeders shoreline 13171 17 neoprene neoprene pads neoprene seat covers rubber manufacturer industrial insulated foam

Directory

Links

International Information For Communicator 4 For Windows

International information for Communicator 4 for WindowsBrowser: Browsing or displaying Unicode pages/mail/news (UTF-7, UTF-8, UCS-2) is now supported for many languages. Communicator can use appropriate font glyphs matching the Unicode code points from the user\'s local fonts. New encoding menu items, UTF-7 and UTF-8 have been added. Though not in the encoding menus, UCS-2 auto detection is supported. Unicode support includes Western, Eastern European, Cyrillic, Greek, Chinese, Korean, Japanese, and Turkish. It does not include bi-directional and complex-ligature languages. Communicator supports official IANA MIME Charset names. Improperly labeled pages, e.g. \'euc-kr\' as \'ks_c_5601-1987\', \'big5\' as \'x-x-big5\', and \'utf-8\' as \'gb_2312-80\', may not display properly. US Windows 95/NT users can now display Chinese, Japanese, and Korean pages/mail/news if appropriate fonts are installed. A native OS (such as Japanese Windows 95) is not required for display. If you use native Windows 95/NT systems such as Japanese Windows 95, you can display other Asian languages, e.g. Chinese and Korean, with appropriate fonts. The input in CJK does require appropriate native OS\'s or equivalents. In Windows 95/NT, it is no longer necessary to make registry modifications to use Unicode fonts. Communicator can now use appropriate native or Unicode fonts automatically. Communicator can use many different language fonts as long as they adhere to TrueType font specifications. Some public domain fonts which do not follow them therefore may not work well with Communicator. Dynamic Fonts (Webfonts) can now display multi-byte languages. Dynamic fonts allow web page designers to create font objects from local fonts and use them to display prepared pages exactly as designed. Since display fonts are provided along with the document, this makes it possible for page visitors to view languages for which they may not have local fonts. Encoding menu names have been standardized across all platforms and products. All Unicode conversions are now based on Unicode Standard 2.0. NCR (Numeric Character References) and NE (Named Entities) display properly if the character in question is available in the chosen encoding. NCR\'s are interpreted as Unicode code points in the decimal format following the standards in RFC 2070. If the corresponding character does not exist in the chosen encoding, then "?" will be displayed. Many new languages have been added in the Accept-Language Preferences Window for convenience. Accept-Language option is used to indicate the user\'s preferred language(s) when sending requests to HTTP servers, which in turn can use this information to send back documents matching the user\'s preferences. Communicator now automatically sends out Accept-Charset indicating the default character set of Communicator\'s locale version and UTF-8 as \'minimally\' acceptable character sets. Accept-Charset information may be used to improve communication between Communicator and directory servers by providing the servers the information on what character sets Communicator can accept from them. No UI is available to change this. Japanese automatic encoding detection has been improved, particularly for EUC. Korean browsing now features automatic encoding detection between ISO-2022-KR and EUC-KR. Users can now display all Cyrillic encodings with Windows Cyrillic (CP1251) fonts. (E.g. KOI8-R fonts are not needed to display KOI8-R pages.) Composer: The HTML Composer now automatically adds character set information to the edited document in the form of a Meta Charset attribute within the <HEAD> ... </HEAD> tags. By default the Composer preserves the existing character encoding when saving a document. However, the user can also change it if so desired. Multilingual UTF-8 pages can now be composed using Windows multilingual keyboard IME\'s and Asian IME\'s. Copy/paste and drag/drop from/to different encodings are possible between Composer and Browser windows. This editing function is currently not available between multiple Composer windows. In prior versions, there was a problem that prevented the toggle between English and Chinese Input Method in document and mail composition under Chinese Windows.This problem has been fixed. Messenger/Collabra Discussion Groups: Each folder within the Messenger Mailbox window or Collabra Discussion Groups window can have a different encoding setting. For example, the user may store mail messages in one language in one folder and those in another language in another folder. When the user opens a folder, Communicator will automatically switch to that folder\'s encoding. When multiple Mailbox/Newsgroup folders are opened from Discussion Groups window, each window can have its own encoding setting. For example, the user can have multiple Mail/Newsgroups windows open at the same time, all with different encodings, and Communicator will automatically switch the encoding setting to that of the current window. An encoding menu is now available in the new Mail Composer window. This convenient feature allows users to easily change the encoding for each message without going back to the Mail Folder window. You can now compose and send rich-text mail (HTML) in all the languages supported. Searching and filtering in European /Asian languages in the local Mail folders work properly except for European language search/filter in the body of HTML mail. Searching and filtering in European /Asian languages are not currently supported for directories in IMAP4 servers. Directory search with European/Asian strings is now supported.Communicator converts the data sent to Directory Server to UTF-8 (Unicode), and converts data received back to the current encoding. UTF-8 display of such results is not supported currently.For example, Japanese results require a Japanese encoding to display correctly. All Address Book /vCard fields such as First Name, Last Name, Nickname, Company, etc. now accept input in European accented-characters and Chinese/Japanese/Korean 2-byte characters. You can enter European/Asian Nicknames or First Names in the "To: " field, and they will be resolved to e-mail addresses from the Address Book entries. Searching in European /Asian languages is also supported in the local Address Book. Korean mail messages are now transmitted using the 7-bit ISO-2022-KR encoding. News articles are posted using the EUC-KR encoding. Currently, the same message cannot be sent to both the mail and news servers except in the 8-bit EUC-KR. We recommend sending messages separately to the mail and news servers in such a case. Cyrillic mail is sent out using KOI8-R encoding. You can now create and delete IMAP4 folder names in European and Asian languages. This requires the user to set "set default encoding" first.There may still be a slight problem in handling certain CJK characters, however. On NT4/NT3.5x, Communicator used to incorrectly insert the PST/PDT Time Zone into the mail header when the user\'s Time Zone does not use Daylight/Summer Saving time. For example, most Asian countries would be affected. This problem is now fixed. Java/JavaScript: Windows 95/NT Communicator can now display Chinese, Japanese, and Korean strings in Java applets if the appropriate fonts are available on the system. No registry changes are required to use Unicode fonts. Titles of applets can now use CJK names.They will display correctly under native OS\'s only. Chinese, Japanese, and Korean input is now possible in Java AWT TextArea and TextField windows.This requires the setting of the default encoding to match the language of the input method. Communicator does not provide its own input method, and so the user\'s system must have native input methods for these languages. All the JDK 1.1 internationalization classes have been incorporated into Communicator. Passing multi-byte text from Java to JavaScript and from JavaScript to Java now works if the document encoding is correctly set to the source encoding. JavaScript String functions do not handle multi-byte characters correctly. JDK1.1 Patch, which includes among others AWT1.1, is now available. Visit for downloading information. Known Problems: UTF-8 page display under US Windows 95 may not work properly when the Windows 95 system has been installed using the \'Custom Install\' option. In such a case, re-installing the Windows 95 system under the "Typical" install option should eliminate the problem. We are currently working on a simpler solution. Copying and pasting of CJK characters into a UTF-8 form has a limitation and may not work well if the copy source itself is in UTF-8. In cases where there is a mismatch between HTTP Charset from servers and the document\'s own Meta Charset , the document\'s Charset Tag may predominate. On Windows NT, Cyrillic/Greek/Turkish/Central European characters may not display correctly in TextArea and Text Input for HTML FORM. Using View/Page Info may cause the original page to misdisplay when the Page Info window is closed.Reloading the problem page will restore correct display. When multi-frames are created by JavaScript, the 2nd or later pages may be assigned a wrong charset. For example, a search result page may be generated this way. In such a case, re-sizing the window or re-loading the frame restores the correct display. Page designers can avoid this problem by initially loading multi-frames using conventional HTML rather than by JavaScript. Communicator supports only 1 encoding for multiple layers. HTML Composer cannot save documents into ISO-2022-JP (Japanese) or ISO-2022-KR (Korean). (The following problem has been fixed beginning with US version 4.02 and Japanese version 4.01 or later.)
Under Chinese/Japanese/Korean encodings, when more than 1 ASCII spaces are inserted in HTML mail and documents, all but the last one will be converted into full-width spaces in that particular encoding, rather than into non-breaking spaces. When you reply/quote to English messages which contain multiple ASCII spaces or non-breaking spaces (NBSP) under CJK encodings, they will also be turned into whole spaces.When you view such mail messages/documents under the Western encoding, the whole spaces will display as unintelligible strings.A typical case of this problem under a Japanese encoding would be reply/quoting an English mail message which contains 2 ASCII spaces or NBSP\'s between sentences.For composing HTML mail and documents which contain only ASCII (e.g. English only), it is recommended to use one of the following methods. Use the Western encoding to compose such mail/documents. (This is the recommended method.) If an Asian encoding is used, then insert only 1 space between sentences and avoid Tabs.(This is not perfect but works OK if not quoting original Western language messages.) An Address Book/Mail Header name resolution may insert an equivalent of ASCII backslash "\" in the display of certain Japanese and Chinese characters. This is a cosmetic problem likely to occur only with Shift_JIS (Japanese) and Big5 (Taiwan) encodings. E-mail address resolution should work all right and messages can be sent. There may be a slight imperfection in the Address Book resolution when there are multi-byte (C/J/K) language entries. Document by: Global Applications Group

Last updated: Wednesday, November 12 1997 20:03 MSK DST