Re: FW: where is the RECYCLE icon ?

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Wed Oct 27 1999 - 19:57:17 EDT


There's no reason why the non enclosing recycle symbol cannot
be treated like any other symbol. With markup languages breaking
the model of 'coding' symbols via special fonts, data interchangeability
really requires us to re-think the reasons for/against including such
pervasive symbols into the standard.

In my view the test to pass for a proposal really is "will there be
a critical mass of user agents that can display this symbol based
on its numeric character reference alone". If the answer is yes,
the symbol should go in.

I would be happy to leave the details of enclosure and of enclosing how
many character to markup. Still having a character code for the enclosing
symbol supports more generic markup where the symbols themselves are not
known to the markup, only their relationship (enclosing).

Food for thought.

A./

At 03:46 PM 10/27/99 -0700, you wrote:
>Markus Kuhn recently said:
>
>> The problem with making it a
>>
>> COMBINING RECYCLE ICON
>>
>> is exactly the same as with the existing
>>
>> U+20E3 COMBINING ENCLOSING KEYCAP
>>
>> There is no mechanism in Unicode to enclose more than a single
>> character, i.e. you can't even produce a [ESC], [Ctrl], [AltGr] or
>> [F4] keycap! Same for [PS] the recycle marker for polystyrene etc.
>>
>> I personally think, these more complex enclosing character, which
>> usually have to change their size/shape based on the content should not
>> be part of a character set such as Unicode. The word processor should
>> offer a mechanism to include resizeable (i.e., parameterized) vector
>> graphics into documents, which can also be used for arbitrary sized
>> brackets, square roots, etc. All these are more graphical elements than
>> characters (like underlining, table rules, figures, etc), especially due
>> to their shape variability, and therefore clearly outside the scope of
>> the Unicode standard (as the combing keycap probably also should have
>> been).
>
>U+0F3C and U+0F3D managed to get into Unicode.
>
>Ancient Egyptian poses several similar problems as I'm sure you're aware.
>
> Tim
>
>--
>Tim Partridge. Any opinions expressed are mine only and not those of my
employer
>
>



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:54 EDT