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

[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]