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 Mon Dec 17 2012 - 20:24:59 CST