Subject: IPP> ASIAN languages in IPP.

From: Yuji Sasaki <[email-masked]>
Date: Mon, 03 Nov 1997 12:59:09 -0700

Dear IPP members,

 I'm still concerning what language should be used when the text attributes
becomes mixed language, such as :"%%[PrinterError:Offending command while
printing file ******.ps%%]" (please assume ***** as a Japanese kanji anything
you like such as "TEMPURA" "FUJIYAMA" or "GEISHA"). Should it be English,
Japanese, or we don't have to care??

 I have another concern to use Unicode in multilanguage environment.
I know it is a IPP client/browser issue more than a protocol issue,
But it is improtant for Asian like me.

 We have at least three Kanji codes: Chinese, Japanese, and Korean. But
in the specification of ISO10646-1(UCS-4), most of them were combined into
a sigle page, called "CJK charcter set".
 The problem is, some of Kanji charcters in CJK are "Looks similer" but
have defferent "faces" depending on the language which the charcter
"belongs to".

 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)

 In that case, even RFC2069 (Adding a language information to each strings)
is not enough. Much less, current version of IPP could have only one
language information for all text attributes within a session.

In HTML4.0, "LANG" tag is defined so we can describe like:

The document named <LANG="chinese">Woo Hoi Chang</LANG> was printed from
<LANG="japanese">Aoyama Tokyo</LANG>.

 But I don't feel like to use HTML as IPP 1.0 presentation layer, it's too
heavy to implement for clients.

 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.

 Do you think it is okay to use "native language" as default language to
handle CJK charcters (in other words, "depends on implementation")? 
 I think we have no alternetive other than it. This will spoil the excact
international interoperability from IPP, but the problem is rooted on
Unicode CJK itself, not the matter of IPP. I hope future version of IPP
(and Unicode) will solve this problem.

 Sorry for persistance of this issue and (I gueess) make you guys confused.
But I'm afraid if IETF people point out that it is unclear how to handle
CJK charcters in IPP specification.

Well, it is clear. Just say, "Depends on implementation" ;-).

Sincerely,
--------
Yuji Sasaki
E-Mail:[email-masked]

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 3 Nov 1997 15:48:05 PST

Yuki,

Formally, we can allow any character set allowed by the whole ISO 10646
standard over the IPP protocol, not only the UNICODE subset. Does that
solve your problem? My expectation though, is that nobody will actually
support the full ISO 10646 in a workstation. If the USA and Europe supports
Unicode, is there another subset that you would implement in Japanese or
Chinese language workstations?

Carl-Uno

>The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo".
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Tom Hastings <[email-masked]>
Date: Tue, 4 Nov 1997 09:28:49 PST

>Japanese, or we don't have to care??

Interesting question, since an error message attribute could have such
an example.  Lets assume that the user submitted the request and specified
that Japanese was the natural language, because the client submitted
the "attributes-natural-language" with the value 'jp' (is that the
correct language code for Japanese?) and the "attributes-charset" with,
say, 'utf-8'.  Then there is no ambiguity in your example.  The Japanese
glyphs, not the Chinese glyphs, will be chosen for the file name.

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.

PROPOSAL FOR AFTER IPP V1.0:

After version 1.0 of IPP is forwarded, I'd like to see us register two
new Job Description attributes that contain error messages encountered
during processing, such as the one in your example.  One attribute
would have a 'keyword' value for programs, and the other would have
a 'text' value for human users.  Maybe they should be multi-valued,
so that an implementation could indicate a number of problems if the
implementation wanted, but would not be required to.

Perhaps, call these attributes:

job-processing-error-id (1setOf type3 keyword)

This attribute indicates one (or more) errors encountered during the
processing of the job.  

The intent of this attribute is for program consumption while the intent 
of the corresponding "job-processing-error-message" is for human consumption.

job-processing-error-message (1setOf 'text)

This attribute indicates one (or more) errors encountered during the
processing of the job.

The intent of this attribute is for human consumption while the intent 
of the corresponding "job-processing-error-id" is for program consumption.

ISSUES for discusion would include: 

1. Do we want to include warnings or not.  If so, how are they 
indicated? Do all keywords have the suffix "-error" or "-warning" in them?

2. In order to improve interoperability, we should list a whole bunch of
keywords with the registration of this attribute.  This is why we can't
take the time now for IPP V1.0 for this attribute.

3. Should the type of the keyword be type2 so that review could eliminate
duplicates, or type 3 so that there is no review after our initial set).

>The document named "Woo Hoi Chang" was printed from "Aoyama Tokyo".

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.

The 'text/plain' document format would not be able to distinguish
the Chinese from the Japanese.

>heavy to implement for clients.

Agreed.

>we are still strugging to use too many charcters in the limited capacity

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.

>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?

>(and Unicode) will solve this problem.

See if my explanation solves your problem.  We hope it does, since that
is why we included the override mechanism in IPP/1.0.

---

From: Yuji Sasaki <[email-masked]>
Date: Tue, 04 Nov 1997 11:08:31 -0700

Hello, Tom.

>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?

>specifications, such as HTML and PostScript, not for IPP.
 I think so. The example above is an extreme case, not usual.

>attributes in different languages.
 I checked out the model document(model-06.txt) but I couldn't found
"override language" description.

>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:[email-masked]

---

From: Yuji Sasaki <[email-masked]>
Date: Tue, 04 Nov 1997 11:08:21 -0700

Thanks,

>Chinese language workstations?

 I checked out the IPP model document, then realized that "attributes-
charset" is not limited only to use UTF-8, but "SHALL" support it.
 I also found a syntax error at Line 1154 in draft-ietf-ipp-model-06.txt
(raw text version), "attributescharset" should be "attributes-charset" .

--------
Yuji Sasaki
E-Mail:[email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Tue, 4 Nov 1997 12:11:51 PST

> Japanese, or we don't have to care??
I just want to point out that this is not just an 'ASIAN language'
issue.

The content-language attribute of a string is used for a variety
of purposes, such as determining hyphenation (German and French
and English hyphenate differently), as an aid in text-to-speech
translation, as well as a way of controlling presentation (such
as might occur with Chinese and Japanese language strings.)

As you point out, simple text strings have no way to indicate
in-line language shifts. The same problem would occur, for example,
if a message were both in French and English, and was sent
to a text-to-speech processor without further annotation.

As you say, a technical solution (use HTML instead of text)
might well be to allow additional markup, the cost of supporting
that markup for simple strings returned from printer errors
 might be higher than we want to impose on simple clients.

> particular persons/places, mostly because historical reasons.

Most of the discussions I've seen on this issue (on many mailing lists)
have actually petered out because there has never been a realistic
example submitted; the issue seems to be theoretical and political rather
than practical. For example, do you actually have a client that
supports both renderings of characters that would otherwise be
ambiguous, and scenerio in which the difference matters, or is it
just a theoretical matter?

Martin Duerst, Martin Dürst, which one do you mean? But of course, he
puts up with being mis-identified.

Larry
-- 
http://www.parc.xerox.com/masinter