xkcd: LTR
http://xkcd.com/1137/ Finally, an xkcd for Unicoders. :-) Debbie
Re: Best smart phones apps for diverse scripts?
iPhone 4 supports Unicode in SMS messages. Furthermore, the SMS standard provides for Unicode in messages: http://en.wikipedia.org/wiki/SMS I haven’t encountered any problems sending Unicode SMS messages on ATT in the US. Debbie On Oct 29, 2010, at 8:13 AM, Ed wrote: That's an interesting question Don. I recently bought a so-called ChiPhone (Chinese phone) which has message catalogs and input methods for English, Français, Español, Português, Italiano, Deutsch, Bahasa Melayu, Bahasa Indonesia, Türçe, Tiếng Việt, русский язык, Arabic, Persian, Romanian, ไทย, 繁體中文 and of course 简体中文. The phone has a side slide-out QWERTY keyboard which is very convenient. The input method for 简体中文 is decent enough. However, overall the software on the phone sucks, and a number of the other language input methods are awkward or bordering on unusable. The lack of Japanese is also annoying. And there is another big problem: at least here in the U.S., it looks like at least some major carriers refuse to accept Unicode text messages outside of the ASCII range. I wish I knew more specifically what is or is not accepted. I know I have had problems trying to send Chinese text messages with T-Mobile: the carrier refused to accept messages containing symbols. Very annoying. Does anyone on this list know specifically what limitations carriers in the U.S. impose on unicode SMS messages? Are there specific encoding issues? I think it would be especially valuable to know if the iPhone4 using ATT in the U.S. deals with Unicode properly? The reason I single out the iPhone4 is because its high-resolution screen is very much superior to a typical smart phone, especially when it comes to reading scripts with many strokes like Chinese, or with many small diacritical marks, like Vietnamese or Thai. (If you have not done so yet, try reading a Chinese web page on your typical smart phone, and then do the same on an iPhone4 to see the difference). - Ed On Fri, Oct 29, 2010 at 8:20 AM, Don Osborn d...@bisharat.net wrote: What do users of this list find to be the most Unicode friendly smart phones? Apps for those phones? Best input systems for texting beyond ASCII (and potentially multiscriptly)? Thanks in advance for any feedback. I’m back in the US and in the market for a new phone, and if I pay for high-end, don’t want to be limited to ASCII. Don
Cake Wrecks: My Thai Font
http://www.cakewrecks.com/2010/06/my-thai-font.html It’s not often you get computers and wedding cakes in the same post… Debbie
Re: Cake Wrecks: My Thai Font
If you’re amazed by that, you probably don’t read Cake Wrecks regularly. ;-) Debbie On Jun 5, 2010, at 12:30 PM, Clark S. Cox III wrote: On Jun 5, 2010, at 11:33 AM, Deborah Goldsmith wrote: http://www.cakewrecks.com/2010/06/my-thai-font.html It’s not often you get computers and wedding cakes in the same post… I'm actually amazed that the decorator went through the trouble to accurately reproduce the mojibake gibberish. -- Clark S. Cox III clarkc...@me.com
Re: Nicest UTF
On Dec 3, 2004, at 2:54 AM, Andrew C. West wrote: I strongly agree that all Unicode implementations should cover all of Unicode, and not just the BMP, and it really annoys me when they don't; but suggesting that you need to implement supra-BMP characters because they are going to start popping up all over the place is wrong in my opinion (not that Doug suggested that, but that's my extrapolation of his point). Software developers need to implement supra-BMP characters because some users (probably very few) will from time to time want to use them, and software should allow people to do what they want. Actually, about 10% of the glyphs in the Japanese fonts that ship with Mac OS X are represented by characters in plane 2. The main reason they are there is because they are used in names (people, places, and companies). So there are real customers who want to use characters outside the BMP. I would not characterize it as very few. That's true of the vast majority of SMP characters, but not all of them. Deborah Goldsmith Internationalization, Unicode Liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Looking for a C library that converts UTF-8 strings from their decomposed to pre-composed form
I think he's saying he wants to convert to NFC *from* Mac OS X data, in which case the fact that Mac OS X's file system normalization is not strict NFD doesn't really matter. Also, he says he's running on Solaris, which would make it a tad difficult to call a Mac OS X API. ICU should do the trick. It's worth pointing out that there is no such thing as precomposed Unicode. Normalization form C (NFC) could be called as precomposed as possible. There are some sequences of Unicode that can only be expressed using combining marks. Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Nov 8, 2004, at 5:17 PM, Markus Scherer wrote: Tay, William wrote: Is there any C library available that converts the decomposed UTF-8 byte streams into the pre-composed equivalent? MacOS X does decompose filenames, but it does not use standard Unicode normalization (because it was designed before Unicode's normalization was finalized.) I suggest you search the mailing list archive for this list for more details. You probably need to use a MacOS system function. ICU has options for normalization (some defined with internal constants only) which may or may not match, or get close to, MacOS filename normalization: http://oss.software.ibm.com/cgi-bin/icu/nbrowser markus
Re: Grapheme clusters
UAX 29 provides for language-specific tailoring of break behavior, and this seems like a situation where you'd want grapheme break to be tailored. See section 3 of UAX 29 for a discussion of this. Which language are we discussing here? Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Oct 5, 2004, at 9:09 AM, Chris Harvey wrote: Ysgrifennodd Christopher Fynn [EMAIL PROTECTED] ar y 05-10-2004 am 10:42: It would of course be possible to have these pair combinations replaced by a single ligature glyphs using the locl feature in OpenType under a specific language tag. Are ligatures what Im looking for? The letters of the consonant cluster like kw are not joined together visually in any way. Also, when I use OpenType for ligatures like ffi st etc. the parts of the ligature are deleted one at a time. I think the UAX#29 or UAX#28 discusses the differences between grapheme clusters and ligatures. Is there a locale setting for this language? - Many applications now automatically tag documents with the current input locale. There is no locale setting. The Native American language has a very small speaker base. You can tell these people that the PUA is no real solution since you can get some very unexpected glyphs displayed for PUA characters. (Microsoft Windows automatically maps a bunch of non-BMP CJK characters to PUA codepoints and sometimes these will display instead of the glyphs in your font. In fact, I have been continuously sending them lists of all the reasons not to use PUA, the CJK problem being only one of many. The problem is, they feel the PUA solves their two biggest issues, backspacing the clusters and collation, without realising that a whole new and bigger batch of problems arises. Thanks, Chris Harvey -- Gwlad heb iaith, gwlad heb galon www.languagegeek.com
Re: Problem with accented characters
FYI, by far the largest source of text in NFD (decomposed) form in Mac OS X is the file system. File names are stored this way (for historical reasons), so anything copied from a file name is in (a slightly altered form of) NFD. Also, a few keyboard layouts generate text that is partly decomposed, for ease of typing (e.g., Vietnamese). Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Aug 23, 2004, at 11:51 AM, Doug Ewell wrote: Problem with accented charactersWilliam Tay wrote: Can anyone explain why an accented character is sometimes represented as a base character plus its accent? For example, the utf-8 representation for é is 65 CC 81, which is the utf-8 representation for e and the accent, instead of C3 A9? I find that this is how MacOS X represents accented characters. The two characters U+0065 and U+0301 (é) are canonically equivalent to the single character U+00E9 (é). That is, the two-character combining sequence is supposed to be considered equivalent to the single precomposed character. Apparently MacOS X, or at least one application running under it, does use the combining sequence. How can a C application that receives such utf-8 encoded characters handle them correctly? Appreciate your comments. It must understand normalization. See TUS 4.0, section 5.6 for more information. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: MacOS character sets
The native character set for Mac OS X is Unicode. Earlier versions of Mac OS used Apple-proprietary character sets, and some applications still use those character sets on Mac OS X, though their use is deprecated. The mappings for Apple's old character sets are available at: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Jul 12, 2004, at 7:39 AM, Tay, William wrote: Hi, I'd like to understand what character encoding an application that runs on MacOS uses. Just as Windows applications generally use code pages and UNIX applications use ISO-8859-X character set, what about MacOS applications? Is there any website that shows the encoding of characters of the MacOS character sets? Thanks. Will
Hebrew modifier question
I'm in the process of grooming some data for the CLDR 1.1 release and
have run into an issue with use of a modifier letter in Hebrew.
There appears to be a usage of a modifier letter or punctuation to
annotate transcriptions of non-Hebrew words. This is appearing in the
country and language data. Here are some examples using U+0027
APOSTROPHE:
AZ { ' }
CL { ' }
CZ { ' }
GS { '' ' }
cs { ' }
I have two questions:
1. Is this considered punctuation or a modifier letter? I.e., would the
proper character come from U+2xxx (punctuation) or U+02xx (modifier
letters)?
2. What is its proper typographic shape? Is it really a straight mark
like U+0027, or does it look like U+2019, U+2018, or something else?
I'd appreciate any information anyone has on this mark.
Thanks,
Deborah Goldsmith
Internationalization, Unicode liaison
Apple Computer, Inc.
[EMAIL PROTECTED]
Re: Panther PUA behavior
On Feb 4, 2004, at 4:42 PM, Dean Snyder wrote: Doing font substitution on PUA code points was causing problems, because we have found a lot of fonts have garbage entries in their cmaps in the PUA, due to the implementation details of certain font-editing applications (which use the PUA part of the cmap as a scratch area). Did this cause real problems for users? Yes. There are an alarming number of fonts out there that have garbage entries in the PUA region of their cmap. Not to mention the GB 18030 and HK-SCS fonts that have PUA entries that *cannot* be removed until the relevant characters are encoded in Unicode (don't get me started on that decision...). We cannot decree what font vendors do: the fonts are out there, and some of the foundries that produced them aren't even in business any more. We cannot force end users to upgrade their entire font collection to eliminate less-than-squeaky-clean fonts (there would be a lot of empty Fonts folders). Users tend to consider such problems to be OS problems, not font problems, however unfair that may be. The system was basically picking a random font in many cases. Rather than have a font substitution mechanism that picks a random font, we disabled font substitution for PUA characters. But I suggest that that randomness can actually be controlled by users - by font installation or code point re-assignment. We always try to keep the needs of non-expert users foremost. We continue to refine our implementation of font substitution; we will keep this issue in mind and look for ways to accommodate expert users of the PUA. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Panther PUA behavior
On Feb 2, 2004, at 9:20 PM, Dean Snyder wrote: I hope Apple re-thinks this, because it makes PUA useless in plain text. Doing font substitution on PUA code points was causing problems, because we have found a lot of fonts have garbage entries in their cmaps in the PUA, due to the implementation details of certain font-editing applications (which use the PUA part of the cmap as a scratch area). The system was basically picking a random font in many cases. Rather than have a font substitution mechanism that picks a random font, we disabled font substitution for PUA characters. I agree this causes problems for things like file names in the Finder, but I worry whether that is an appropriate use of PUA characters. When Cuneiform is encoded, all these file names will have to be reentered. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: corporate/users PUA ranges (was: Cuneiform - Dynamic vs. Static)
On Jan 13, 2004, at 7:10 PM, Philippe Verdy wrote: For Panther: user part of PUA == everything not in the corporate part of the PUA corporate part of PUA == the set of corporate PUA characters that Apple defines on Mac OS Which is? Obviously, it's: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT So I wonder how Panther can do want you said: FYI, Panther was changed to not do font substitution in the user part of the PUA (it still does it in the corporate part). without using some arbitrary limit in the middle of the PUA range of the BMP, by assuming that Apple has not assigned (will not assign) corporate characters in these PUA code points. Because the assignments in the corporate area only change when we release a new version of Mac OS, not in between. The set of corporate characters is fixed for Panther. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Cuneiform - Dynamic vs. Static
On Jan 13, 2004, at 7:38 PM, Doug Ewell wrote: Sorry to belabor this, but: Based on http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT, this zone could start at U+F700 if you include the NeXT function key mappings, or U+F800 (actually U+F803) if you don't. Should we assume that Apple draws the line at U+F700? The UTC has always been careful never to draw the line themselves. It's always best to work up from the bottom of the PUA. If you want your font to work on Mac OS X, it's best to avoid the values in the file you cite. Apple adds new corporate PUA characters very infrequently; we try to avoid PUA characters at all costs. Beyond those statements I can't make any guarantees... Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Cuneiform - Dynamic vs. Static
On Jan 13, 2004, at 7:38 PM, Doug Ewell wrote: Sorry to belabor this, but: Based on http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT, this zone could start at U+F700 if you include the NeXT function key mappings, or U+F800 (actually U+F803) if you don't. Should we assume that Apple draws the line at U+F700? The UTC has always been careful never to draw the line themselves. It's always best to work up from the bottom of the PUA. If you want your font to work on Mac OS X, it's best to avoid the values in the file you cite. Apple adds new corporate PUA characters very infrequently; we try to avoid PUA characters at all costs. Beyond those statements I can't make any guarantees... Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Cuneiform - Dynamic vs. Static
FYI, Panther was changed to not do font substitution in the user part of the PUA (it still does it in the corporate part). This was because different fonts can use the same PUA code point for different things (and do; this was not a hypothetical problem but one we have seen in practice). The idea going forward is that use of PUA code points needs to be accompanied by an explicit font specification. Picking the first font you find for a PUA code point does not seem like the right approach to us. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Jan 13, 2004, at 1:23 PM, Dean Snyder wrote: (RESPONSE) Not being a font designer, I called a font designer friend of mine and he DID say there are tool problems and operating system problems associated with non-code-point-specified glyphs in OpenType. He specifically mentioned Volt and FontLab. For what it's worth, I have seen a difference between Jaguar and Panther in how Mac OS X treats characters in the PUA - in Panther they commonly show up with the indeterminate glyph symbol even when a suitable font, that worked in Jaguar, is installed.
Re: Cuneiform - Dynamic vs. Static
On Jan 13, 2004, at 4:58 PM, Philippe Verdy wrote: Where is the limit between the user part of the PUA and the corporate part of the PUA? For Panther: user part of PUA == everything not in the corporate part of the PUA corporate part of PUA == the set of corporate PUA characters that Apple defines on Mac OS Also what is the status of planes 15 and 16? are they all in the user part Actually, I don't think planes 15 and 16 were covered by this change. Time to write a bug... Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Panther PUA behavior (was RE: Cuneiform - Dynamic vs. Static)
On Jan 13, 2004, at 5:47 PM, John Hudson wrote: If you have an existing document that already specifies a font, it should be fine. I believe Deborah's point is that Apple will no longer try to guess the best font to use when PUA codepoints are entered using another font or are found in a plain text document. Yes, that's exactly right. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: New MS Mac Office and Unicode?
On Jan 6, 2004, at 11:48 AM, Tom Gewecke wrote: MS Mac Office 2004 was announced at MacWorld SF today. Does anyone know whether this update finally brings the Unicode capabilities of the WinXP version to the Mac OS X world? I can now tell you that Mac Office 2004 does offer enhanced support for Unicode, in that it can input, edit, and display Unicode characters that are not part of any Mac OS legacy character set. I can't say yet to what extent the various components of Office support complex shaping behavior or bidirectional scripts (e.g., Arabic, Thai, Hindi), because I don't know. However, at the very least you will see access to expanded CJK repertoires, and access to languages like Icelandic and Greek. Mac Office 2004 will also include fonts with larger repertoires than previous versions of Mac Office. Here are some highlights from the PR information I received: - Can input, print, and display more than 30 languages - Larger font repertoires (e.g., Arial 296 glyphs - 1192, MS Mincho ~9000 glyphs - 16,031) - Japanese fonts included (MS P Mincho and Gothic) I've been told more details will be discussed in the coming months before MS Mac Office 2004 is released. Perhaps some of the Microsoft folks on this list can add more details? :-) Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: MS Windows and Unicode 4.0 ?
Microsoft Office v. 10 for Mac OS X uses the same document format as Office for Windows, so the documents are indeed stored as Windows. However, since Office v. 10 uses Apple's obsolete QuickDraw API set for text rendering, it cannot render text that is not in a Mac OS legacy character set (e.g., MacRoman, MacJapanese, etc.). There have been APIs available since Mac OS 8.5 for rendering Unicode text directly, but the applications Michael Everson mentions are not using them. In Office v.10, characters it can't render via QuickDraw show up as underscores. They're still there, but you can't see or edit them. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Dec 4, 2003, at 9:41 AM, Raymond Mercier wrote: Is it really the case that characters in Word in OS X are not stored as Unicode, even though they are so stored in Word in Windows NT (and later) on a PC ? If not stored as Unicode on a Mac, then how are they stored ?
Re: MS Windows and Unicode 4.0 ?
Actually, Mac OS X 10.3 Panther includes a set of Cherokee fonts. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Dec 3, 2003, at 8:59 AM, D. Starner wrote: It wouldn't hurt you at all to release them in some form, and it would help the Cherokee (for instance) to actually use Unicode for their language.
Re: MS Windows and Unicode 4.0 ?
Of far more value than Apple employees pressuring Apple's management to cough up the money for new fonts would be Apple's *customers* telling Apple's management they want to see such fonts. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Dec 3, 2003, at 7:55 AM, John Jenkins wrote: Personally, I'd rather pressure Apple's management to pay Michael for new fonts for additional scripts than to pay him to draw new localized versions of the LR font.
Re: Free Fonts
As far as I know there is no legal issue with adding hints to fonts. Any legal issue around font hinting is going to relate only to the software which takes fonts and produces rendered glyphs on a display device, not to the fonts themselves. Apple does not ask font developers to pay royalties for anything related to font development or distribution. So if you add hints to a font, no, you do not owe Apple any royalties, nor is there any other legal issue I'm aware of. We *want* people to produce high-quality fonts, including high-quality cross-platform fonts. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Dec 3, 2003, at 10:38 AM, Raymond Mercier wrote: Philippe Verdy writes Simple: for now the fonts are in beta, and do not include the hinting instructions. This may be in development, but faces some legal issues with Apple patents. So until there's a patent-free hinting mechanism, for use in fonts, or Apple agrees with a royaltee-free license on hinting mechanisms, hinted fonts cannot be freely distributed. What is the legal position if these fonts are taken into Fontlab and rehinted ? Surely if I make my own hinted font in Fontlab I do not owe royalties to Apple. Raymond Mercier
Unicode support in Mac OS X (was: Re: How can I have OTF for MacOS
Mac OS X currently supports Unicode in all Cocoa applications. Unicode support in Carbon applications depends on the application; the Finder and iTunes are examples of Carbon applications that support Unicode. Apple is migrating all of its applications to Unicode and strongly encourages developers to do the same. Apple does not currently provide tools for adding OpenType capabilities to fonts; such tools are available from Adobe and Microsoft. Apple does provide tools for adding AAT tables to fonts; as has been pointed out earlier, AAT and OpenType tables can coexist in the same font. Mac OS X does not currently recognize OpenType tables at the system level, though many applications do. To get system level support it is necessary to add AAT tables to a font. The tools and documentation are available from: http://developer.apple.com/fonts How to add keyboard layouts to Mac OS X is documented in Technical Note 2056, which I mentioned yesterday: http://developer.apple.com/technotes/tn2002/tn2056.html Keyboard layouts can either be the same binary form as was used on Mac OS 9, or a new XML format which is documented in the tech note. Two resources for creating the new XML-style keyboards without editing the XML directly are: http://homepage.mac.com/poorant79/software/ http://wordherd.com/keyboards/ Finally, information like date formats, collation order, and the like come from ICU, the open source library (as of Mac OS X 10.3, Panther): http://oss.software.ibm.com/icu/ The best way to add new locale data to Mac OS X is to contribute it to ICU via the Common Locale Data Repository project (see the ICU page). Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED] On Dec 2, 2003, at 3:22 AM, Mustafa Jabbar wrote: Dear Sir, Can you let us know about how we can have support of Unicode in MacOSX? What are the tools to create OTF for MacOSX and What are the tools for developing Keyboard for Uniocde under MAC OS X. What are the tools Apple is providing like VOLT and MSKLC? What are the applications supports Unicode? We have Bangla solution for Mac. But how we can update it for MacOSX? Fonts and the Keyboard? Apple should speak up. Mustafa Jabbar At 04:36 PM 01-12-03 -0700, John Jenkins wrote: On Dec 1, 2003, at 4:24 PM, Frank Yung-Fong Tang wrote: John What 'cmap' format Apple use in the MacOS X Devanagari and Bangla fonts? The formats are irrelevant; the Mac supports all the 'cmap' subtable formats for all subtables. For rendering complex scripts, however, the font can only be rendered through ATSUI (or Cocoa), because the old way to support complex scripts via an 'itl5' resource in the suitcase with the 'FOND' and 'sfnt' resources is not supported on X. Apple really, really wants everybody to move to using Unicode in their applications for all their text, and Apple really, really, *really* wants people to do it for complex scripts. John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage..mac.com/jhjenkins/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: How can I have OTF for MacOS
On Nov 24, 2003, at 6:47 PM, John Jenkins wrote: Keyboards are just XML files. If you're on Mac OS X 10.3, you can find samples inside /System/Library/Fonts/Unicode.bundle/Contents/Resources/*.keylayout. Documentation on the XML keyboard file format for Mac OS X can be found in Apple Tech Note 2056: http://developer.apple.com/technotes/tn2002/tn2056.html Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Unicode support for Khmer
On Oct 27, 2003, at 12:30 PM, Sue and Maurice Bauhahn wrote: Nothing of the sort is available on Macintosh (partly because Mac applications that support ATSUI appear to be even more rare;-(). Unicode support in applications is widespread on Mac OS X. In particular, all the built-in applications should be able to handle Khmer with a properly constructed font. The system already supports Thai out of the box, via Unicode. It's true that neither a font nor a keyboard for Khmer are included with the OS. Deborah Goldsmith Manager, Fonts / Unicode liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: About that alphabetician...
I already wrote this up internally as a bug. Thanks, Deborah On 2003/09/25, at 14:05, Tom Gewecke wrote: About the c-cedilla, it appears that OS X Safari does not pick up the charset on this page. If the default is set to UTF-8, the c disappears altogether. The correct character is displayed only if the browser is set by default or manually to Latin 1.
Re: Last Resort Glyphs (was: About the European MES-2 subset)
Apple's version of the Last Resort font is a (relatively) normal font. It just has a cmap that maps lots and lots of characters to the same glyph. :-) Deborah Goldsmith Manager, Fonts / Unicode Liaison Apple Computer, Inc. [EMAIL PROTECTED] On Saturday, July 19, 2003, at 12:15 PM, Michael Everson wrote: Um, that's what the Last Resort font does, outside of Unicode encoding space. (I don't think PUA characters are used, actually, but I could be wrong.
Re: Normalized text in OS X?
On Monday, March 10, 2003, at 05:07 AM, Michael Everson wrote: What does confuse me is that I then tried to search for the strings, and I found that the Find engine considered the two strings to be different. Should it? No, and the bug was filed a while back. :-) (I also found that when I saved and closed the file and reopened it, the combining ogonek was stripped out, which I suppose must be a bug.) Yes, that's a known bug, too. Deborah Goldsmith Manager, Fonts / Unicode Liaison Apple Computer, Inc. [EMAIL PROTECTED]
Re: Unicode keyboard layouts oddity in OS X 10.2.4
There are two problems we have seen with keyboard preferences. 1. Bringing up the force-quit dialog (command-option-escape) can sometimes disable keyboards in ~/Library/Keyboard Layouts. This can be worked around by moving them to /Library/Keyboard Layouts. Please let me know if this is part of the problem. 2. Sometimes other keyboards will not remain enabled over logoff/logon, even if they are not in ~/Library/Keyboard Layouts. Please do the following in Terminal: defaults read com.apple.HIToolbox Keyboard Menu The normal result is: The domain/default pair of (com.apple.HIToolbox, Keyboard Menu) does not exist If you get a different response, please contact me by private e-mail. Thanks, Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Wednesday, February 19, 2003, at 05:34 AM, Kino wrote: Greetings I have created several Unicode keyboard layouts for OS X 10.2.x which are available at http://quinon.com/files/keylayouts/ Usually I have activated two of them: LatinTL and ArabicQWERTY. After updating to OS X 10.2.4, Unicode keyboard layouts checked in Input Menu tag of Internet Preferences do not stick anymore. I.e. with each restart, they vanish from Flag menu and become unchecked in Input Menu. My settings in Input Menu tag of Internet Preferences have not always been retained even before 10.2.4. Sometimes one of checked keyboard layouts vanished or was replaced with another, e.g. my ArabicQWERTY replaced with Apple's Arabic. But these glitches were not always reproductible at least with 10.2.1-10.2.3. Now, even common keyboard layouts such as Unicode Hex Input do not seem to stick. I have not tested extensively with Apple keyboard layouts though. Of course, I suspected my system installation. So I clean installed OS X 10.2 on another partition and created a new user. I have not tested with each updater, but OS X 10.2.1 retains Unicode keyboard layouts I have chosen whereas 10.2.4 does not. Is this a bug? Or something is wrong with my keyboard layouts? Yusuke Kinoshita Yusuke Kinoshita
Re: BOM's at Beginning of Web Pages? Mac IE's Euro
I can't explain why IE 5.2.2 is displaying the UTF-8 BOM as a Euro. It's important to understand that IE 5.2.x does not use Unicode for rendering. It takes the following approach: 1. Convert the text from the specified character set to runs of text in various Mac OS encodings. 2. Draw each text run using a font appropriate for that Mac OS encoding. Any character that cannot be converted into a Mac OS encoding will be converted into ?. If you look at the source for the Unicode home page in IE, you'll see that there is indeed a ? at the beginning, as there is no mapping from U+FEFF to any Mac OS encoding. I have no idea why that is rendering as . I've already written a bug against Safari that it should handle BOMs (browsers need to handle lots of things that are not legal HTML). Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: How is glyph shaping done?
For information on how this is handled on Mac OS, please see: http://developer.apple.com/fonts/ Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Friday, January 31, 2003, at 11:03 AM, John Hudson wrote: On Windows, the shaping engines for complex scripts are part of Uniscribe (usp10.dll) and make use of OpenType font technology. An Arabic OpenType font will contain layout features for Initial init, Medial medi and Final fini substitutions (and possibly Isolated isol, e.g. to handle contextual variation of the letter heh). Uniscribe analyses strings of Arabic text, keeps track of the position of letters and their neighbours, and implements the appropriate layout feature for each letter. For more information, see http://www.microsoft.com/typography/developers/opentype/default.htm, and the MS Arabic font specification at http://www.microsoft.com/typography/specs/default.htm
Re: Quick ATSUI question
You should always keep ATSUStyle objects around as long as possible. Whether it's faster to keep ATSUTextLayout objects persistently or to create and then destroy them depends on your application. If you redraw the same paragraphs repeatedly, it's to your advantage to retain the ATSUTextLayout objects for those paragraphs in a cache. If you draw text once and then don't draw it again for a long time, you can either recycle the ATSUTextLayout object or create a new one; it's not that expensive to create the object. The things that are expensive are creating ATSUStyle objects and going through the layout process. For more information, see http://developer.apple.com/qa/qa2001/qa1027.html I strongly suggest you ask questions like this on the Carbon-Development mailing list rather than here on the Unicode list. You'll find many more people able and willing to help. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Wednesday, November 20, 2002, at 10:07 AM, Theodore H. Smith wrote: Hi list, I'd like to know which scheme turns out noticably faster. If neither is noticably faster, then thats good to know. 1) Using ATSUCreateTextLayoutWithTextPtr, then disposing the object, and creating a new one for each paragraph. This means I have to reset line controls and layout controls for each object. 2) Using ATSUCreateTextLayout, then setting the styles one by one using ATSUSetRunStyle? I will reuse the line controls and layout controls. Thanks for your answer. I'm guessing the answer will be 1, or 2, or neither :o). In other words, I don't need a detailed answer, but if the whim takes you then do so. -- Theodore H. Smith - Macintosh Consultant / Contractor. My website: www.elfdata.com/
Re: ATSUI text length parameters
On Tuesday, November 19, 2002, at 08:49 AM, Theodore H. Smith wrote: I want to pass some text to an ATSUI function. One of the params is UniCharCount iTextTotalLength. Does this include surrogates? IE, is this truely a CharCount as it's name? Or simple a ushort count, hence the size of the buffer / 2. I have a strange feeling that it is the ushort count, and not a char count like it claims. UniCharCount is, as its name implies, a count of UniChars. UniChar is a 16 bit data type representing one UTF-16 code unit. UniChar is a bit of a misnomer, but then again I think it dates from before surrogates were invented, so it can be forgiven. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: ATSUI for MacOS9
ATSUI is supported under Carbon on Mac OS X, Carbon on Mac OS 9, and native Mac OS 9. The native Mac OS 9 version and Carbon Mac OS 9 versions are frozen (the native one at an earlier level); the OS X version continues to evolve. I don't know why the demo doesn't do hit testing properly, but ATSUI is supposed to work on 9. I'd strongly recommend using the CarbonLib version. Speaking of which, run, do not walk, to: http://www.lists.apple.com/mailman/listinfo/carbon-development and sign up for the carbon-development mailing list. You will find it a more fruitful place to ask questions about Apple technologies. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Tuesday, November 19, 2002, at 07:33 AM, Theodore H. Smith wrote: Hi list, I hope ATSUI questions are allowed. ATSUI involves drawing of Unicode text on screen or into off-screen graphics buffers. I'd like to know if ATSUI can be used for MacOS9. The ATSUI demo for OSX works perfectly, but the ATSUI demo for OS9, can't do horizontal hit testing. :o( Why not? Is this a bug in the demo, or a bug in ATSUI for OS9? Does ATSUI for Carbon on OS9 work if ATSUI for Classic OS9 doesn't? If anyone knows ATSUI well, could you please contact me so I can ask a few more questions? Thanks a lot. -- Theodore H. Smith - Macintosh Consultant / Contractor. My website: www.elfdata.com/
Re: Info: Apple OSX Font Tools Suite 1.0.0 Released
Faster: option-click the link. It will force a download. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Tuesday, November 12, 2002, at 09:20 AM, John H. Jenkins wrote: Try control-clicking on the link and then selecting Save link to disk from the popup menu. On Tuesday, November 12, 2002, at 09:55 AM, Dean Snyder wrote: At 4:49 PM John H. Jenkins wrote: Cupertino 11/8/02: Today the Apple Font Group released its new suite of Unix command line font tools for OSX. These can be downloaded free from http://developer.apple.com/fonts/. The actual download URL is: http://developer.apple.com/fonts/FontToolsv1.0.dmg But I can't get it to download with any browser I've tried (IE, Opera, Mozilla) - they all display the binary disk image as garbled text instead of downloading it to disk. (I've fiddled with download helper preferences for .dmg files but that hasn't helped. Is the .0.dmg file name termination confusing the browsers?) Respectfully, Dean A. Snyder Scholarly Technology Specialist Center For Scholarly Resources, Sheridan Libraries Garrett Room, MSE Library, 3400 N. Charles St. The Johns Hopkins University Baltimore, Maryland, USA 21218
Re: entering JIS 0213, HKSCS and GB 18030 characters
On Thursday, October 31, 2002, at 01:05 AM, Eric Muller wrote: We have a very hard time assembling the following information: on MacOS X and Windows XP, how do users practically enter JIS 0213, HKSCS and GB 18030 characters? We are interested by both OS provided IMEs and third party IMEs. Of course, we are interested in the more recent characters in those sets, e.g. those in 0213 and HKSCS that map to Plane 2. Can anybody help? I'll summarize to the list. On Mac OS X, all of these require an application that supports Unicode input, such as TextEdit, Mail, the Finder, iPhoto, etc. Mac OS X 10.2 includes font support for the full JIS X 0213 and GB 18030 repertoires; there is not currently full font support for HKSCS. 1. JIS X 0213 - Our Japanese input method, Kotoeri, has words with JIS X 0213 characters in its dictionary, such as moriougai. The second candidate for ougai is a JIS X 0213 character, as indicated by the little green triangle in the candidate window. In this way JIS X 0213 characters show up just as any other characters. - Using the Character Palette (new in Mac OS X 10.2), JIS X 0213 characters can be entered either using the Japanese view (e.g., via radical/stroke lookup) or the Unicode view, which lists characters by Unicode blocks or code points, including Extension B. 2. GB 18030 - The Simplified Chinese input method has a direct GB 18030 code point entry method. - The Character Palette can be used as for JIS X 0213, and the Simplified Chinese view includes GB 18030 characters in the radical/stroke tab. - The SC input method is extensible, and we include a sample file with Pinyin support for GB 18030: /Applications/Utilities/Asia Text Extras/Plugin_Text_Sample/AllGB18030-PinYinPlugin.dat. If this file is copied to ~/Library/ChineseInputMethodPlug-in/, when you next login you will have this support. 3. HKSCS - At this time, the only way to enter all HKSCS characters is via the Character Palette. The subset that corresponds to MacTraditionalChinese can be entered via the Traditional Chinese input method. I hope this helps... Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Unicode Character names on Mac OS X 10.2
No, the names are the names from the Unicode character database, and so are always in English even when the system is running in French. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED] On Monday, October 14, 2002, at 08:14 AM, Patrick Andries wrote: Have the Unicode character names been localized, as MS Windows has done (at least for French and German which I have personally seen) ? In other words, have the official ISO 10646-1 and -2 French names been used in the French version of this tool, or must French readers see an English name for characters they know under a French name (all latin characters, arrows, etc.) ?
Tech note on Installable Keyboard Layouts
I'm happy to report that the Apple tech note on installable keyboard layouts for Mac OS X 10.2 has been published: Tech Note 2056, Installable Keyboard Layouts http://developer.apple.com/technotes/tn2002/tn2056.html Please report any problems directly to me. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mercury News: Hawaiian on a Mac
On Thursday, September 5, 2002, at 08:32 AM, Doug Ewell wrote: Does everyone (Apple included) agree that the kahakō is U+0304 COMBINING MACRON and the ʻokina is U+02BB MODIFIER LETTER TURNED COMMA? Our Hawaiian keyboard generates precomposed vowels with macron, not a combining macron. But yes, the kahakō is a macron. And ʻokina is U+02BB. The following was typed with the Hawaiian keyboard if anyone is curious: āēīōūĀĒĪŌŪʻ Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mercury News: Hawaiian on a Mac
On Thursday, September 5, 2002, at 03:43 PM, John Delacour wrote: Is there any news yet of that tech note on keyboards? I've knocked together a polytonic Greek keyboard using the old technology but I'm keen to get working on the xml version and it would save me a lot of time if there was some guidance available regarding all the different actions etc. There was a problem in getting it posted. I'm trying to get that resolved now. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Summary of Unicode/language features in Mac OS X 10.2 Jaguar
On Wednesday, August 28, 2002, at 04:09 AM, Lars Marius Garshol wrote: That function also applies the bidirectional algorithm to the text it displays. However, since the application needs to do all manner of strange formatting (colouring, interspersed images, first-line specials, first-letter specials, base-line adjustments, ...) it calls the method word for word, doing the formatting itself. This is why ATSUI (Apple's Carbon API for drawing Unicode text) is designed to deal with a paragraph at a time, supporting multiple fonts, colors, cross-stream shifts, with-stream shifts, baseline adjustments, leaving space for embedded images, etc. The new (to Jaguar) ATSUI Direct Access API allows direct program intervention in the low-level layout process as well. An API that renders Unicode text correctly only when it's all in one font isn't terribly useful. :-) Documentation on ATSUI Direct Access will be available whenever we update our online documentation to reflect 10.2, which should be over the coming few months, I believe. The header files are available now with 10.2, of course. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Summary of Unicode/language features in Mac OS X 10.2 Jaguar
On Wednesday, August 28, 2002, at 01:55 PM, Lars Marius Garshol wrote: We just need a single display function that does glyph shaping and no more. Is that available somewhere? It's possible to do that with the direct access API. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Summary of Unicode/language features in Mac OS X 10.2 Jaguar
On Tuesday, August 27, 2002, at 04:01 PM, Lars Marius Garshol wrote: Thank you very much for this. This kind of succinct no-nonsense summary is worth its weight in gold. (Collecting the same information through the normal sources might easily consume weeks.) Hmmm. Since it was sent electronically, I'm not quite sure what its weight in gold would be. :-) | 3. Unicode | | Support for text in bidirectional and complex writing systems | (e.g. reordering) is now available in all Unicode applications, | including Cocoa applications. It would be nice to know what this means in term of the rendering API. Is it possible to display RTL scripts without having the display system reverse the text? I hope it is, since without this capability proper bidi support is near-impossible to achieve. By default, RTL scripts are displayed in compliance with the Unicode bidirectional algorithm. It is of course possible to override this through use of directional override characters. It's also possible to use advanced APIs to disable bidi processing. Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mac OS X Keyboard Layouts (was Re: new version of Keyman)
There is lots of good news about keyboards in Mac OS X 10.2, none of
which I'm allowed to discuss until August 24, unfortunately. If you
have signed an Apple non-disclosure agreement, write me privately and
I'll blab about all of it. :-) I will be discussing all this and more
at the San Jose Unicode conference, which, thankfully, is after August
24.
I will try to post something on August 24 giving the basics.
Deborah Goldsmith
Manager, Fonts Unicode
Apple Computer, Inc.
[EMAIL PROTECTED]
On Thursday, August 15, 2002, at 02:13 PM, Alex Eulenberg wrote:
On Thu, 15 Aug 2002, Michael Everson wrote:
Apple have made no official announcements about what keyboards will
be included in the next or future releases of OS X.
...
More good news: I hope to be releasing soon an OS X Unicode keyboard
layout for Ogham, and of course I am developing OS X keyboard layouts
with support for Welsh, Scottish Gaelic, and Cornish.
Michael,
What do you (plan to) use to create your Unicode layouts for Mac OS?
ResEdit only lets you edit 8-bit layouts ('KCHR' resource). The only
tool
I know of to create Mac OS Unicode layouts ('uchr' resources) is my own
(free) web application, at
http://wordherd.com/keyboards/
On a related note I wonder if anyone can tell me whether the new Mac OS
10.2 Jaguar lets you drag and drop, or otherwise easily add custom
keyboard layouts, like with version 9 and previous, or whether you
still
have to jump into Terminal and make an unsupported hack to the Human
Interface Toolbox system files.
--Alex
Language name questions
Hi, I am trying to determine the names of a few languages in their own language. This is for a list of language names that a user can select, like: English Français 日本語 and so on. I need answers to some particular questions, but if someone could point me at a book or web site, then that would be even better. Here are the languages I'm trying to pin down: Hungarian: magyar or magyarul? Slovak: Slovenský? Slovenian: Slovenski? Slovensko? Any help would be gratefully appreciated! Deborah Goldsmith Manager, Fonts Unicode Apple Computer, Inc. [EMAIL PROTECTED]
Re: Language name questions
On Friday, May 24, 2002, at 05:43 PM, Mark Davis wrote: http://oss.software.ibm.com/cgi-bin/icu/lx/en_US/utf-8/?_=sk This has Slovenina, but we've also seen Slovensk. Deborah
Re: display issue on mac
On Tuesday, April 30, 2002, at 01:35 PM, Tom Gewecke wrote: Russian characters have an extra spacing on Mac in both browsers (no problem on pc). T h e c h a r a c t e r sl o o k l I k e t h I s there is no actual space between them. I have been testing on OS X using IE 5.1 and NS 6.2. This page has the same issue http://www.unicode.org/unicode/standard/translations/russian.html . I have spent more than 10 hours trying to figure out the problem, this is my last hope. It's because your browser is using the Japanese Hiragino font, with its double-width characters, for Cyrillic. Deactivate or remove this and it should look normal. Only a problem for OS X I believe. That is the problem, but it's more general. Shift JIS contains Cyrillic, and IE and Netscape on the Mac do not give a way to control the sequence of fonts used for UTF-8 display. It's getting to Japanese fonts before Cyrillic fonts. This is not specific to either Hiragino or OS X; it happens with any Japanese font and both OS 9 and OS X. One workaround is to specify a Cyrillic font for display of UTF-8 pages, but that requires the end user to configure their browser. Another workaround is to remove all Japanese support from the OS, but that is pretty draconian, and is not supported on OS X (/System/Library/Fonts on OS X is only modifiable by the superuser). Deborah Goldsmith Manager, Fonts Apple Computer, Inc. [EMAIL PROTECTED]
Variant locales?
I had a recent inquiry from inside Apple as to whether there was a registry of variants of the standard ISO locales, e.g. ja_JP.kana for Japanese written only with kana. Does anyone know if there is any standard that attempts to describe such things? Thanks, Deborah Goldsmith Manager, Fonts Languages Apple Computer, Inc. [EMAIL PROTECTED]
NTT DoCoMo i-Mode graphic characters contact?
Apple is investigating whether and how to propose the encoding in Unicode of the graphic characters used on i-Mode phones in Japan. In doing so it would be very helpful to have a contact at NTT DoCoMo who is involved in the definition of these characters and who might want to participate in a standardization effort. If anyone knows of any such contacts, I would very much appreciate it if they could put me in touch with them. Deborah Goldsmith Manager, Fonts Languages Apple Computer, Inc. [EMAIL PROTECTED]
Re: GB 18030 question
Thanks to everyone for researching this question! Deborah On Monday, February 4, 2002, at 06:25 PM, Qingjiang (Brian) Yuan wrote: Frank and Deborah, After I saw the e-mail from Deborah, I asked our Beijing office to contact the CESI. The follow is the information we got: -- Have contacted with CESI. It is really a glyph bug. They have fixed it, but they did not notify us! CESI will not give us the updated fonts until tomorrow morning. It was said that there are serial glyph have been updated in the new version of the bitmap fonts. -- Thanks. Brian. Yung-Fong Tang Wrote: I looks like both Mac/Linux/Window N6.2 and current Mozilla map that to FFE3. Looks like IE on winXP do the same way. We, mozilla i18n group, got the GB18030 mapping table from sun. B Yuan, any comment? Michael Everson wrote: At 11:23 -0800 2002-02-01, Deborah Goldsmith wrote: There is an error on page 10 of the GB 18030-2000 standard, in that the character with code point A3FE maps to U+FFE3 (FULLWIDTH MACRON), but is shown with a glyph that corresponds to U+FF5E (FULLWIDTH TILDE). The position of the character in its code block would also seem to indicate that tilde was intended. Does anyone have any idea of which should be considered correct, the glyph or the Unicode mapping value? Glyphs are informative in JTC1. I can only assume that the GB standards would follow suit.
GB 18030 question
There is an error on page 10 of the GB 18030-2000 standard, in that the character with code point A3FE maps to U+FFE3 (FULLWIDTH MACRON), but is shown with a glyph that corresponds to U+FF5E (FULLWIDTH TILDE). The position of the character in its code block would also seem to indicate that tilde was intended. Does anyone have any idea of which should be considered correct, the glyph or the Unicode mapping value? Deborah Goldsmith Manager, Fonts Language Kits Apple Computer, Inc. [EMAIL PROTECTED]
Re: Kana and Case (was [totally OT] Unicode terminology)
On Monday, November 27, 2000, at 06:55 PM, [EMAIL PROTECTED] wrote: You mean this? _|_ || |_ /| \/ \|_/\ Yes. How do you *say* it? I haven't a clue... Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Kana and Case (was [totally OT] Unicode terminology)
on 11/22/00 3:00 PM, Kenneth Whistler [EMAIL PROTECTED] wrote: It isn't really nonce usage, but rather the adoption of the formal spelling mechanism of Katakana into Hiragana to indicate prosodic length. The place you'll see this usage of the prolonged sound mark fairly frequently is in Japanese comics, which are rather loose and inventive in their use of spellings and "paraspellings" to convey tone of voice and other prosodic information. Another example is the use of dakuten on characters they're not normally applied to (e.g. U+3042 U+3099). Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Open-Type Support (was: Greek Prosgegrammeni)
on 11/22/00 4:19 AM, Marco Cimarosti [EMAIL PROTECTED] wrote: - AAT/ATSUI (see in http:/www.apple.com). Most of the "intelligence" is in the font itself, which also includes a state machine to operate substitution. The behavior of the smart fonts may be influenced by external user settings. John Jenkins already related most of the relevant information, but I'll just add that: http://fonts.apple.com/ is a much better place to go if you're looking for information on AAT, and http://www.apple.com/developer/ is the place to go for information on ATSUI. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mac support of UCAS in Unicode 3.0
On Friday, October 27, 2000, at 12:15 PM, Aki Inoue wrote: OmniWeb is one of few Web browsers that display UTF-8 encoded Web pages. As long as you have UCAS font with Unicode cmap, you should be able to display it with the browser. More precisely, all Mac web browsers can display UTF-8 encoded pages, but all of them are limited to the subset of Unicode supported by the union of Mac OS encodings, except for OmniWeb. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mac support of UCAS in Unicode 3.0
on 10/26/00 3:55 PM, Nesbitt, Gavin [EMAIL PROTECTED] wrote: To focus this advice, perhaps I can ask whether Unicode syllabic encoded web pages would be technically viewable on Macs? If so, what would be required to do so and if not, what might be required to get it supported...? All currently available Mac web browsers, to the best of my knowledge, render web pages using Mac OS character sets. If they receive Unicode characters, they convert them to Mac OS encodings first, then display the results of that conversion. The only exception I am aware of to this rule is the OmniWeb application which runs only on Mac OS X. Some web browsers use the Mac OS Text Encoding Converter to convert from Unicode to Mac OS encodings. Theoretically, you could write a TEC plugin to handle UCAS. However, I don't know if these browsers will recognize additional encodings provided via a plugin and make them available, since I haven't tried it. There has been an API (ATSUI) in Mac OS since Mac OS 8.5 which can render all of Unicode. No web browser that runs on Mac OS 8.x/9.x uses this API, to the best of my knowledge. I think that Mozilla did at one point, but I don't know if that support is still enabled. Developers are starting to adopt ATSUI and the text editing API based on it (MLTE), but not any browser vendors I'm aware of. Basically, there is not a lot of software on OS 8 and 9 that supports Unicode directly (i.e., all of Unicode, not just the subset Mac OS could already handle). Mac OS X has lots of applications that use Unicode directly, including the Finder and the built-in mail program and text editor. If you want web browsers to support UCAS on Mac OS 8.x/9.x you will need to talk to the browser vendors: Microsoft, Netscape, and iCab being the most well-known. Feel free to contact me directly for more information. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mac Questions
on 10/9/00 10:19 AM, Yung-Fong Tang [EMAIL PROTECTED] wrote: I tried MLTEDEMO, it seems it support TSM 1.5 so I can finally see how "Extended Roman (U)" and "Unicode Hex Input" keyboard layout work. Does this app support 'utxt' clipboard format ? Any app does ? MLTE Demo and SUE ought to handle 'utxt', since the clipboard is handled by MLTE. You can tell by copying from either of them and pasting into the Scrapbook. The scrapbook lists all the scrap types that have been pasted in. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
Re: Mac/PC interoperability
On Saturday, August 19, 2000, at 08:50 AM, RenE J.V. Bertin wrote: I have a preliminary version of the fonts ready. It works, but there seems to be an issue with the conversion of the "currency" character and the character replacing it, in documents coming from Mac. All other characters are translated correctly, and some programs also convert that currency character correctly (i.e. from 0xdb on Mac, to 0xa4 on PC), but others (e.g. RagTime5) do not. This happens with Word documents, but also with RTF files. As far as I have been able to determine, the reverse direction, PC - Mac goes without problems. In addition, Word97 on PC does not perform any of the necessary conversions on Macintosh RTF at all! Is there anyone who has experience with this kind of problem in general? What is the matter with that one specific character? I contacted the RagTime help desk (they were very kind, even though I only have a demo version), and they suggested me to ask "somebody at unicode", since their program uses unicode internally. In Mac OS 8.5, the definition of 0xDB in the MacRoman character set changed from U+00A4 (currency sign) to U+20AC (Euro). Mac OS 8.5 and later treat 0xDB as the Euro. If you are omitting characters that don't translate, then perhaps you should omit this one... I hope this helps. Deborah Goldsmith Manager, International Toolbox Group Apple Computer, Inc. [EMAIL PROTECTED]
