>The Printer object should have responded with the entire string in
>Japanese, not just the file name. However, I realize that PostScript
>only returns English error message text. However, I suspect that
>we don't really have a problem with IPP, if the message is in a
>charset that supports ASCII characers and Kanji, such as UTF-8, Shift JIS, or
>EUC JIS, since the first part of your example message would be
>"ASCII" characters, which even in Japanese are displayed as:
>
> %%[PrinterError:Offending command while printing file
>
>If the Printer object also supports one of the Japanese charsets, such as:
>'JIS_C6226-1983' or 'JIS_X0212-1990' or 'Shift_JIS' or 'EUC-JP'
>or 'Windows-31J' there also is no problem, because they all contain
>ASCII characters for the english part of your example. Thus the client
>could have supplied one of these charset values, provided that the
>Printer object also supported it.
Do you mean I can use language as "Japanese" even if the whole text was
alphabetical because it could be displayed?
>> In extreme cases, one string can include several languages like:
>>
>>The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo".
>> ~~~~~~~~~~~~~ ~~~~~~~~~~~~
>> (Chinese Kanji) (Japanese Kanji)
>
>Such an example could even occur in IPP attributes, if the error
>message was in, say, Japanese, but the file name was in, say, Chinese.
>However, the chances are small and so the file name would get presented
>in Japanese, instead of Chinese.
>
>The most likely occurrence of mixed Chinese and Japanese would be
>in the document data itself, which is a problem for the document format
>specifications, such as HTML and PostScript, not for IPP.
I think so. The example above is an extreme case, not usual.
>> Practically, we Asian can know what does the word mean evenif the details
>>are slightly different (like you guys can know "colour" is the same word
>>as "color").
>> And I think we will implement CJK difference as "assuming native language".
>>In the case above, all kanjis will be displaied as "Japanese Kanjis" in
>Japan,
>>and will be "Chinese Kanjis" in China.
>>
>> But the problem still remains, especially for describing human names or
>>name of places. We have to know EXCACTLY CORRECT kanjis to identify the
>>particular persons/places, mostly because historical reasons. Like in
>>English, "Colour" and "Color" is the same but "Kristen" and "Cristen" are
>>definitely different.
>> Unfortunatelly, we don't have the standard method to use CJK in multi-
>>language environment(except HTML4). Even in a single language(e.g Japanese),
>>we are still strugging to use too many charcters in the limited capacity
>>of Unicode CJK.
>
>Fortunately, for IPP, each 'name' attribute is separate, and so can have
>its own "override natural-language", so that a job can contain 'name'
>attributes in different languages.
I checked out the model document(model-06.txt) but I couldn't found
"override language" description.
>> Do you think it is okay to use "native language" as default language to
>>handle CJK charcters (in other words, "depends on implementation")?
>
>So the client requests attributes to be returned in the user's natural
>language, say, Japanese. If the message contains ASCII characters,
>they should be displayed correctly. They could even contain accented
>Latin characters, or Cyrillic charactes. Its only for the CJK characters
>that the ambiguity becomes a problem. But the Japanese user requesting
>IPP attributes from a job with one or more Chinese name attributes, could
>still present each Chinese name in the correct Chinese glyphs to the
>Japanese user, becuase the IPP Printer returns the natural-language
>override on the name attributes indicating that the name is in Chinese,
>not Japanese as requested. Ok?
I'm sorry I don't understand what do you mean with "natural-language
override". Does it mean IPP server could have several "text" values
according to the language for single atrribute?
--------
Yuji Sasaki
E-Mail:sasaki@jci.co.jp