Re: wrongly identified geometric shape

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: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:56:58 CST