On 12/17/2012 10:55 PM, Michel Suignard wrote:
Asmus
TR25 today takes an intermediate approach (ref page 19), the diamond
exceeds the height but its sides are smaller than the ‘equivalent’ square.
Which is what I suggested below.
In fact, in smaller sizes, there is equivalences between sides of
diamond and squares, but in larger sizes the square sides become
increasing larger than the diamond sides. At some point, you can’t fit
the diamond into the EM box without bleeding over the edges which is
not acceptable.
In a true mathematical font you have very tall glyphs that are not
appropriate for a mere "symbol" or "dingbat" font. Just consider the
integral signs.
If you take the ink area rule to the letter, you would have to
decrease significantly the ink for the larger squares to match the
diamond ink for the same ‘size’. Again, if you look at the current
version of TR25 (page 20), the ink for the diamonds is quite smaller
than the ink for the same ‘sized’ squares in the context of large sizes.
In an ideal world we would define all geometric shapes consistently,
but they were created in an ad hoc manner and it becomes increasingly
difficult to define consistent and uniform rules without creating
regression issues.
It is inherently difficult to use the same scale progression between
shapes that fit nicely the EM box (squares and circles) and spiky
shapes (diamond, lozenge).
Added to that, the STIX fonts which are a common implementation of
math symbols tend to size squares and circle even larger than the
Unicode charts. So any effort to size down these shapes (implied by an
alignment with the diamond sizes) would go opposite from current practice.
I think trying to solve this on the character encoding level, without
double checking that with the wider mathematical/typographic community
is a mistake.
We did some outreach when we came up with the specifications in the
original TR#25, but it may well be that this could use some updating
based on new input, new experience and the new characters.
STIX is an important element for this, but perhaps not the only one - if
you know you are using the STIX fonts you can adjust your styles or
glyph (character) selection to "tweak" the outcome, something that isn't
an option for a generic prescription.
A./
Michel
*From:*Asmus Freytag [mailto:asm...@ix.netcom.com]
*Sent:* Monday, December 17, 2012 6:22 PM
*To:* Michel Suignard
*Cc:* philip chastney; unicode List
*Subject:* Re: wrongly identified geometric shape
In relating the size of different series of geometric shapes with each
other, the relevant aspect is not the height of the ink but the area,
in my opinion.
I'm currently not able to take the time to sift through various
documents and propose any resolution, but I would like to make sure
that this point is not lost.
A diamond of the same height as a square, becomes effectively an
inscribed diamond. When you compare the areas, the difference is 50% (!)
Seen in running text (and not next to each other) the diamond will
look smaller, even though it has the same height.
For the other shapes, the same effect exists, but is not always as
severe. Whether one matches the size of a hexagon with that of a
pentagon by height or area, for example, may not result in obvious and
observable difference in the impression of their relative size.
Ideally, as an author or font designer, I would aim for a set of
symbols that have the same "optical" weight, or "impression of
weight". Shapes that are more compact, might be allowed to have a
little more area, because they might otherwise look "short". But in
this balancing act, I would expect the most functional (and pleasing)
choices for mathematical use to be those where the shapes end up
rather closely (but perhaps deliberately not perfectly) matched in area.
As to whether the exact size progression within each series is best
realized as a geometric or linear, or some other progression, I can't
suggest a definite answer right now.
In terms of text sizes for CSS, the concept of fixed ratios seems to
be prevalent. Ideally we would have some more input from mathematical
typesetters and font designers. Whatever the progression ends up being
would require that all steps can be distinguished in on-screen viewing
at some point size (and traditional, not bleeding edge, set of DPI
values).
A./
On 12/17/2012 3:37 PM, Michel Suignard wrote:
Philip,
It would have helped if you had updated your critique of N4115 to
the current proposed code points. The updated version is N4384
(L2/12-368). The number of characters proposed and their
allocation have changed although the status for geometric shapes
has no changed much.
I spent some times analyzing your documents and I can see you are
trying to harmonize the size of the diamond and the square shapes
by applying the concept that the length of a side should dictate
the ‘size’, not the ink height. By doing so you force the rule
found on small sizes to the larger sizes which makes you deviate
from the current TR25 recommendation, basically you are sizing
down all the squares to match the diamonds. For example, now the
regular size square side would be slightly above half the EM box
side, which is what a medium square is today. And at the end you
still have to add a new XL size which is not part of TR25. I also
looked at the current font implementations of squares and they are
all over the place in relative sizes but all have bigger sizes
than what you propose. By far the more consistent set is the
Wingdings set, but there are some many size inter correlations in
geometric shapes that I can’t just put them in the charts. What I
have found consistently among implemented fonts is a large gap
between ‘small’ and ‘very small’ which reinforce my introduction
of ‘slightly small’. As long as we don’t try to force the diamond
scaling onto the square scaling I don’t see an issue with the
current schema. The name ‘slightly small’ is not exactly pretty
but we are running out of adjectives here.
If you made the same arguments a year or more ago, it would have
been easier to influence the content of amendment 1, now it is
quite late. Geometric shapes representation is always subjective
and various schemas can be used. The one use in 4115 does not try
to merge the size scale between square and diamonds (I don’t think
there was a mandate to do so). Another goal was to take into
consideration existing practice among math fonts. None of that is
cast in stone, and I am sure we will see more fine tuning when
math fonts implement the full set of these geometric shapes. The
mapping of Wingdings/Webdings into Unicode is not frozen and TR25
is still a work in progress.
Always open to civilized discussion. Using terms such as ‘idiot’
and ‘the arithmetic involved shouldn't challenge the average
12-year old’ will guarantee no answer from my part in the future.
Best regards,
Michel
*From:*philip chastney [mailto:philip_chast...@yahoo.com]
*Sent:* Sunday, December 16, 2012 10:45 AM
*To:* Michel Suignard
*Cc:* unicode List
*Subject:* Re: wrongly identified geometric shape
On 2012/Dec/08 02:34, Michel Suignard wrote:
*> From:*philip chastney
> anybody converting a document currently using Wingding fonts to
one using Unicode values and Unicode fonts instead, using the
transliteration proposed in N 4384, will find their squares
somewhat diminished in size (in this case, by one third)
>
>this is because the terminology used for "size" in N 4384 is at
variance with the terminology used heretofore in UTR 25
No such a thing as a Unicode font. We produce the charts using
complicated size adjustment and 100s fonts provided by various
providers and then anyone is free to create their own.
I meant the term "Unicode Fonts" as used here:
http://www.unicode.org/resources/fonts.html
There is nothing normative about relative size. TR25 does some
work at classifying these relative sizes and this is in fact
explored in detail in section 5 of N4384 (that I wrote). N4384
aims at expanding the size set exposed in TR25 while staying
compatible with its principle.
TUS does not list relative sizes among the//normative behaviours,
true, but anyone who draws U+2295 CIRCLED PLUS bigger than U+2A01
N-ARY CIRCLED PLUS OPERATOR is an idiot, and the font is not
compliant with TUS, because the character identities have not been
preserved
TUS does not dictate /actual/ sizes, provided the specified
relationship between glyph sizes is maintained, and that may
perhaps be what you meant
Some reality check with common Math fonts show that they tend to
use larger size for their geometric shapes than what is presented
in the current chart (and in TR25). In fact I am now working in
harmonizing the rest of the chart geometric shapes with the
Wingdings set and that may result in some size adjustment in
future charts. I have been looking at the STIX fonts for example.
This would in fact solves the concern expressed here by making
25FC and 25A0 a tad bigger.
size adjustment of one or two glyphs in an actual font is not an
encoding issue
the original msg gave just one example of the sort of anomaly that
results from the introduction, in N 4115, of two entirely
unnecessary distinctions
the story so far is given in
www.chastney.com/~philip/shapes/slightly_small_%28revised%29.pdf
<http://www.chastney.com/%7Ephilip/shapes/slightly_small_%28revised%29.pdf>
www.chastney.com/~philip/shapes/size_9_centered.pdf
<http://www.chastney.com/%7Ephilip/shapes/size_9_centered.pdf>
www.chastney.com/~philip/shapes/N4115_an_alternative_encoding.pdf
<http://www.chastney.com/%7Ephilip/shapes/N4115_an_alternative_encoding.pdf>
the arithmetic involved shouldn't challenge the average 12-year
old but, because it's unlikely anybody will bother working through
it all, check out the last page of
"N4115_an_alternative_encoding", which shows how Wingdings shapes
can and do, already, fit harmoniously with Table 2.5 from UTR 25
and (assuming "extra large" is not intended to be a graduated
size) does so without needing to expand the size set exposed in UTR 25
this is because the graduation of sizes has a number of implicit
constraints:
(i) the "small" size needs to be big enough to be visible at small
point sizes;
(ii) the "large" size must be less than the font's body height;
(iii) the difference between adjacent sizes needs to be
discernible at, say, 12pt.
this leaves the font designer with just 3 degrees of freedom:
-- the size of the start point
-- the size of the end point
-- the transition from one size to another,
other sizes being obtained by interpolation or extrapolation
if (iv) the "very small" size is somewhere round about the width
of a vertical stem,
and (v) the "regular" size is somewhere about caps height,
there's just the transition function to be decided
the transition function might consist only of a number of
different sized steps, but add in the observations that
(vi) the transition function might as well be smooth, and
(vii) given the preponderance of small sizes, a geometric
progression works well,
there isn't a lot left to do, in the way of design
a font like STIX, which uses a number of different sized steps,
will necessarily (because of the implicit constraints) be within a
few %age points of a GP
/phil chastney
