W3C home > Mailing lists > Public > www-i18n-comments@w3.org > October 2004

Re: Your comments on Character Model Fundamentals [LC076]

From: Martin Duerst <duerst@w3.org>
Date: Fri, 29 Oct 2004 14:48:29 +0900
Message-Id: <>
To: Bjoern Hoehrmann <derhoermi@gmx.net>, <aphillips@webmethods.com>
Cc: <w3c-i18n-ig@w3.org>, <www-i18n-comments@w3.org>

At 04:19 04/10/29, Bjoern Hoehrmann wrote:
 >* Addison Phillips [wM] wrote:
 >>We feel that there is a link between C068 and the use (or abuse)
 >>of private use area code points. The linkage, succinctly, is that
 >>if you follow the other requirements in CharMod, the only code
 >>points that are available for the form of abuse described
 >>(prohibited) by C068 are PUA code points.
 >That's surprising as that is already covered by C073,

That's a should, and just a negative, without giving an
alternative solution. C068 gives a solution for a particular
set of cases.


That's gone, because a commenter correctly pointed out that it's
very much the same as C038.

 >C038, and C039

These are specific to specifications defining assignements to
the PUA, or some mechanism that would allow to tie such assignements
to a document or some part of it,... They are not relevant for
simple use of PUA codepoints in content.

 >since if these requirements are met, you can hardly ever run into
 >a situation where this would apply to PUA code points. If this is about
 >PUA code points, I am also not sure how graphics and images would help,

Well, on the Unicode list, there is often a claim that the encoding
of something like a graphic or symbol is needed because otherwise,
it cannot be included in text. Likewise, people can argue that
they want to put a symbol or graphic in the PUA because it is not
encoded in Unicode. C068 tries to make sure that there is no such
need, because a better alternative will be available in specifications
that follow the character model.

 >I would not write Klingon using <img .../><img .../><img .../>... So it
 >would seem this is meant to be about implementations that cannot offer
 >loading arbitrary symbols as graphics from online resources

The "*inclusion of* or reference to" is there because some formats
(in particular SVG) allow to have graphics inline. We don't care
which ways a specification chooses, it's up to the spec writer
to choose the appropriate solution(s).

 >due to
 >resource constraints and want to offer them through other means such as
 ><cloud-with-rain-drops/> or something.

No, the basic example would be <img /> in HTML.

 >In this case the section needs
 >to be substantively clarified as that is not really obvious. I consider
 >C068 to be about "abuse" of assigned code points such as ASCII-art.

Where does it say that it is limited to assigned codepoints? It's in
the PUA section, so rather than complain about that fact and claim
that it is wrong, why not first think about why we put it there?

Also, much more than ASCII art, it is about things like pi fonts,
for example the rather (in)famous Bundesbahn font. If it helps
to make sure that people don't need to use ASCII art unless they
really want, then all the better.

 >But I also do not think that using the PUA for <cloud-with-rain-drops/>
 >is obvious either, I think C076, C068 and C041 merit their own section.

That's a possible point of view. We have choosen a different point
of view. And we have tried to explain why. To just shortly repeat:

C076 is at the place it is (immediately after C073) to make sure
that people don't throw out the baby with the bathwather ("oh,
I shouldn't use a PUA codepoint, so let's just (mis-)use a
predefined codepoint").

C068 and C041 serve a very similar purpose, namely to offer some
solutions after all the prohibitions.

 >It would probably also work to have them in "3.3 Units of visual
 >rendering" or to re-work "4.5 Private use code points" to include these
 >issues under a more general heading with a more general intro text.

Well, we could change "4.5 Private use code points" to something
like "4.5 Private use code points and how to avoid them, and how
to not make things even worse", but I'm really not sure this is

Regards,    Martin. 
Received on Friday, 29 October 2004 05:50:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:00 UTC