RE: wrongly identified geometric shape

Asmus
TR25 today takes an intermediate approach (ref page 19), the diamond exceeds the height but its sides are smaller than the ‘equivalent’ square. 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. 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.

Michel
From: Asmus Freytag [mailto:asmusf_at_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_chastney_at_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

Received on Tue Dec 18 2012 - 01:01:29 CST