Re: [VCARDDAV] Questions about text handling in vCard 4.0 (rev 11)

[Daisuke Miyakawa <[e-mail]>]

One additional note. In Japanese mobile phones, NOTE field would be full of
Emojis, so this is not imaginary something but from actual use cases.

2010/7/6 Daisuke Miyakawa <[e-mail]>

>
>
> 2010年7月6日22:46 Simon Perreault <[e-mail]>:
>
> On 2010-07-06 00:53, Daisuke Miyakawa wrote:
>> >     Can you please suggest text for what you have in mind? Probably a
>> >     sentence or two to be added at the end of 3.3...?
>> >
>> > Here's an arbitrary example.
>>
>> I meant text that we should add to the vCard 4 specification and that
>> would address your concern...
>>
>> > The problem here is we cannot estimate potential Unicode which harm
>> > actual readability/edit-ability/xxx-ability caused by receiver/editor
>> > side's limitation. Even readability is part of my concern.
>>
>> What we're talking about here is how Unicode characters get encoded in
>> vCard. The current method is to encode them as-is. You are suggesting to
>> use \xNNNN, and your argument is readability. I think this argument is
>> weak because:
>>
>> - Unicode characters may actually be *more* readable than \xNNNN notation.
>>
>
> Please see the font issue I described bellow. When no font is available, it
> cannot be read at all.
> Rather, it may corrupt the way other characters are shown.
>
>
>> - Do we really care about readability of vCard data that is going to be
>> displayed exactly the same to the user regardless of the encoding?
>
>
>
>>
>
>  > Another example: a final fallback method users will use during reading
>> > and editing vCard would be just opening the file and editing it
>> > manually. Then how can they edit unknown characters like Chinese,
>> > Japanese, Korean, V...?
>>
>> I don't see a problem. What do you mean by "unknown"? I can just use vi
>> on any UTF-8 file and edit it without any difficulty. One can do the
>> same with Microsoft Word or any other editor that understands UTF-8 I
>> would assume.
>
>
> Hmm, "unknown" was unclear.
>
> If no font for the locale is available, it is "unknown" to the machine.
> For example, Unicode 5.2 allows Mahjong tiles in text
> http://www.unicode.org/charts/PDF/Unicode-5.1/U51-1F000.pdf
>
> I don't think usual PC is able to render it
>
> You can try the tiles http://0xcc.net/jsescape/
>
> I can see \U0001F002 as just a square (🀂 looks almost same as □)
>
> Unicode 6.0 will support emoji, pictgraphs used in Japan.
> [?] can be sent in text format. I don't think usual editors support it at
> first.
> At that time, it will be displayed with unreadable something.
>
> In my PC, I guess no Hebrew font, while Unicode has it. Fonts for all
> characters in Unicode
> cannot be expected even in usual PCs.
>
> Unicode has 22bits and potentially it may grow. Relying on the assumption
> all usual computers are able to
> show them when seeing vCard is a bit difficult.
>
> I agree that \xNNNN (or \xNNNNNNNN, \UNNNNNNNNN) does not solve this issue
> completely, but
> without taking care of it, I think usability will not improve enough.
>
> One proposal I can do is that composer side are allowed (but not
> recommended) to use the format only when they cannot emit the word (like
> when users want to edit foreign friends name without an appropriate IME) but
> know codepoint for that characters.
> Receiver side MUST be able to decode \xNNNN to appropriate Unicode form.
> This is a kind of dirty compromise but there's no technical difficulty nor
> theoretically insufficiency. I suppose I can implement sender/receiver
> easily.
>
>
> Simon
>> --
>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
>> STUN/TURN server        --> http://numb.viagenie.ca
>> vCard 4.0               --> http://www.vcarddav.org
>>
>
>
>
> --
> Daisuke Miyakawa (宮川大輔)
> [e-mail]
>



-- 
Daisuke Miyakawa (宮川大輔)
[e-mail]