On 11/11/2012 9:26 PM, Philippe Verdy wrote:
>
>
>
> 2012/11/12 Asmus Freytag <asmusf_at_ix.netcom.com
> <mailto:asmusf_at_ix.netcom.com>>
>
>
> However, the half-filled, five pointed stars are "garden-variety"
> type symbols, and, as I keep pointing out, they absolutely fall
> within the scope of geometrical symbols for which there is ample
> precedent supporting both plain text usage as well as a
> standardized encoding.
>
>
> I oppose your argument of "garden-variety" type symbols because
> consistancy of this usge with a defined pattern is not demonstated,
> included in the precise domain where they are found.
None of the geometric symbols have a "precise" domain where they are
used. Typical for these symbols is that they have a wide variety of use
and that therefore any encoding that tries to tie these characters to
only some specific usage is doomed to fail.
That does not mean that it's not important to show that there is "at
least one" usage for that that is consistent with plain-text.
>
> The suggested characters (they haven't actually been formally
> proposed yet) would in no way push the envelope.
>
> [1] We should only encode characters that users would reliably
> draw manually using a plum or rollpen, independantly of color,
> or of the width of the tool used to draw strokes, or possibly
> to fill them : basic orientation of glyphs however will be a
> candidate if its variation in the same text orientation is
> significant (this includes mirrored, or upside down
> characters, or significant changes of size and position
> relative to the baseline.
>
>
> [2] Some exceptions are given to maths symbols (including
> letter-like) which are encoded specifically with their maths
> semantics for use in maths, but not for general purpose text.
>
> This is an entirely novel theory of encoding, and one, that I
> would like to point out, is very much your personal view. It does
> not have a foundation (or echo, or equivalent) in anything that
> really defines how encoding is done for the Unicode standard.
>
>
> [1] The first part is a good real-life expression of what is meant by
> abstract character and the fact that we don't encode glyphs. So this
> is not so much a novelty (this is stated in the standard that we don't
> encode glyphs but only abstract characters independantly of orthogonal
> styles and tools used to render them).
This is not how abstract characters are defined.
>
> [2] The second part is the expression of the exceptions that have been
> made ONLY because there REALLY was a well-defined pattern of usage
> where the additional meaning of a precise style is consistant (and
> really HAD TO be)... Allowing then these exceptions (the other
> exceptions have been for interoperability with older character sets
> for terminals that had almost no graphic capabilities). So this is
> also not a noverlty.
>
> For now we lack the evidence of a consistant meaning in any given
> domain (not too much specialized to a single source at a single place
> for this consistancy).
This whole thing comes down to a misunderstanding of "semantic" in the
context of the statement that abstract character represent a semantic
over a presentational aspect.
The "semantic" of a letter "a' is it's "a-ness" - in contrast to all the
other letters of the same script. The semantic of an integral sign is
"integral sign" in contrast to the other mathematical operators. (If
there were two alternate notations for integral, then Unicode would not
encode the "concept" of integral, but the several concrete symbols used
to denote that concept - see for example, element of, where there is
such variation).
The semantic of a FULL STOP is to be a dot on the line. It can represent
many different concepts (from sentence period, to abbreviation, to
domain name separator to decimal mark, but all of these are a matter of
convention external to the encoding standard.)
Finally, the semantic of geometrical shape is in essence the shape -
how it is used in the context of text will give it additional meaning,
but those meanings are not what is standardized.
A./
Received on Mon Nov 12 2012 - 00:22:02 CST
This archive was generated by hypermail 2.2.0 : Mon Nov 12 2012 - 00:22:03 CST