Re: Missing geometric shapes

No, I was clear throughout, using the same arguments, that encoding things
for the purpose of representing "empty", "full, "half filled" like if it
was a nuemric gauge was a bad idea.

When I spoke about the various represetnations of gauges (including with
photos) it was just to demonstrate that this is a domain where designers
and authors are extremely creative, and there's absolutely no standard way
of doing things right as each representation is a pure local decision.

Just consider the case of the classification of hotels and campings: they
are just given an integer number of stars, and whever these stars are white
(hollow/transparent filling), black (completely filled), multicolor, or
even half filled does not change the classification.

Now if you think about half-filled stars, there are also the case of
half-cut stars too (left side or right side shown) to represent as well
half units. Or stars with only 1 to 4 branches filled, with variation about
the position where branches are cut : in the middle of a branch, creating a
thiner triangle. Or between branches (that are kept as complete diamonds
extending up to the center. Variations as well in the number of branches
for the star itself.

(Someone here showed an example in Israel using 5-pointed stars, but in
Israel, one could easily fing many cases with 6-pointed stars i.e. using
the David's star, either dranw only on their external borders, or drawn as
two intersecting triangles creating an hexagone in the middle).

You could as well half-fill a star by varying the width of its border
toward the center (still maintainning a "white" star in the middle) : such
exampels are not difficult to find. Or by drawing a filled star in the
middle of an outer thin border, whose size will vary from zero up to the
outer border.

Then you'll find the issue of text direction if you start making
distinctions between left-half-filled and right-half-filled: CJK texts may
prefer using an horizontal cut with top-filled or bottom filled (and this
will be complicated by text orientation for the vertical layout, because
typically Latin letters may be rotated, not CJK sinograms or Hangul
syllable squares, but kanas in half-width form could follow the Latin
layout (think about ruby notations), but not full-width kanas : how will
you orient the stars, and where will you put the half-cut and which side
will be filled ?

For me all existing half-filled symbols that exist today are there for
compatibility reasons with older terminal character sets. They do not have
a true distinct identity. as they are completely dependant on their use of
a monospaced font and the older terminal technologies where texts could not
be reoriented.

IF we need to encode new characters now, it is (hopefully) for allowing
their use in today's and future softwares. plain-text only remains the
worst case for presenting a document to a user, even if it remains as
internal textual data : this data will be presented somewhere with some
additional layout and styles and will be adapted for accessibility (but you
can't design an accessible application if you just depend on pictograms
with unclear semantics).

For plain text even today, the best representation remains with using
standard digits. For the rest, a star remains a star and its color does not
matter.

Not everybody will see it and then later, nobady will give hints about the
value they represent if you need another non graphical representation :
this does not occur with letters, digits, or currency symbols, which remain
readable as such, independatly of their rendering style and used glyph, or
independantly of the tool used to draw them : a brush, a rollpen, a grphite
pen, a plum, will not be able to render the same kind of strokes and fills,
and filling a form with a rollpen (or even more with a plum and ink) is a
nightmare for handwriters that just draw want to strokes without filling
them : they'll just draw a star, but if something more precise is needed to
specify a numeric value, they'll write that value explicitly.

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. 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.

But can you only describe a well-defined usage pattern of these half-filled
stars symbols in a domain so well described and defined like maths? I bet
not simply because there's no standard and every author chooses what fits
their own desires.

A star is a star, just like a digit is a digit or a letter is a letter. And
then an numeric value assigned to a symbol is just a numeric value: the
assignment is not defined in any consistant standard, it may only be
consistant in a single document. So it is an orthoginal property that does
not depend on the glyph or even abstract character chosen to render it with
styles.

And we are clearly not in the same case as emojis that have a clear meaning
by themselves as pictograms explicitly showing what they mean. : an angry
face to mean angry for example, or a thumb up to mean the same gesture you
would exhibit in real life, or a raining cloud to mean rainy weather. And a
star to mean... a star.
Received on Sun Nov 11 2012 - 22:52:04 CST