bugFree UCS Outline Fonts - Bugs: bug #52450, Wrong shape and/or size of U+22C4...


bug #52450: Wrong shape and/or size of U+22C4 DIAMOND OPERATOR

Submitted by:  David Corbett <dscorbett>
Submitted on:  Sun 19 Nov 2017 04:02:25 PM UTC  
Category:  individual character(s) Severity:  3 - Normal
Item Group:  glyph(s) incorrect Status:  Fix posted
Privacy:  Public Assigned to:  Steve White <Stevan_White>
Open/Closed:  Open Release:  development

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 26 Nov 2017 11:36:54 AM UTC, comment #9:

I adjusted all these. In SVN.

I'm especially having problems to arrange a gradation of three sizes between the white bullet and the math ring operator. The ring operator is visually strong -- similar to a plus or times. It's usually smaller than the bowl on small letters, but not half the size. But the bullet is usually decidedly smaller than the bowl on small letters, too.

Anyway, I managed to arrange something that looks OK to me.

I'm afraid again the Unicode people have screwed up, confusing the meaning of encodings with the exact physical appearance. It would have been so much better to have simply encoded a range of black and white circles with an explanation of relative sizes, and left the sizes of operators and bullets a separate question.

That's all hindsight, of course. And I know people who take an extreme view that Unicode encodes shapes -- patent nonsense, to me.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sat 25 Nov 2017 04:52:43 PM UTC, comment #8:

In FreeMono (all styles), U+2219 is the same size as U+2022. U+1F78D should be smaller than U+25AA. U+1F799 should be smaller than U+2B25. U+1F79F should be smaller than U+2B27.

In FreeSerif Bold, U+2219, U+2022, and U+2981 are the same size. U+25E6 and U+26AC are the same size.

In FreeSerif Italic, U+2022 and U+2981 are the same size.

David Corbett <dscorbett>
Sat 25 Nov 2017 02:35:57 PM UTC, comment #7:

OK, I touched each of these.

A note: the math ring operator (used to indicate functional composition) is always depected in books as a small light ring, substantially smaller than the bowls of small letters. But as to whether it is bigger or smaller than a bullet surely depends on the font. I have my doubts aboout encoding such stylistic information in these letters.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Fri 24 Nov 2017 10:57:44 PM UTC, comment #6:

In all the fonts, U+2022 BULLET (the small circle) is essentially the same size as U+2981 Z NOTATION SPOT (the medium small circle).

In FreeMono, U+1F78C BLACK TINY SQUARE is a tad bigger than U+2B1D BLACK VERY SMALL SQUARE.

In FreeMono, U+1F78D BLACK SLIGHTLY SMALL SQUARE is essentially the same size as U+25AA BLACK SMALL SQUARE.



In FreeSans, U+2218 RING OPERATOR (the very small circle) is bigger than U+25E6 WHITE BULLET (the small circle).

David Corbett <dscorbett>
Wed 22 Nov 2017 12:22:29 PM UTC, comment #5:

have a look!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 21 Nov 2017 11:00:21 PM UTC, comment #4:

I agree that the math diamond operator ought to be a rotated square, despite the latest glyph samples.

Based on that UTR#25, I made a lot of changes to most of the ranges (bold obliques might have to wait), to make the main circle, square, diamond, lozange, triangle symbols to
-- display a reasonable gradation of sizes
-- lay on a center line to whatever degree mades sense (that is, not for the biggest figures)
-- be about the same across faces of each style, especially not taking oblique forms in oblique faces
-- show thickening of strokes in the white versions
-- include the Unicode 10 1F78x characters

I probably introduced some other bugs. Messy business. In SVN.

Test file updated.

(file #42455)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 20 Nov 2017 10:43:27 PM UTC, comment #3:

That version of UTR #25 is old. The most recent version is at http://unicode.org/reports/tr25/ and in that version, U+22C4 is a rotated square.

The code chart does depict U+22C4 as a lozenge. Huh, I didn’t know that. UTR #25 doesn’t mention this particular discrepancy, but it does mention some other differences from the code charts. I guess it isn’t wrong to render it as a lozenge, but I still think FreeFont should use a rotated square glyph: FreeFont includes many mathematical characters and it supports the MATH table, so it would be appropriate for it to follow the “Unicode Support for Mathematics” technical report.

David Corbett <dscorbett>
Mon 20 Nov 2017 10:40:21 PM UTC, comment #2:

Here's a test file.
There are several glyphs that could use some improvement.

Note: several of the characters listed in the TR as being geometrical symbols really aren't specifically geometrical. Mid-dot in particular is not round in all fonts, and the block drawing character 2588 is often not square.

Another point here: there are issues with font styles and weights. I have been making the squares to be geometrical squares even in oblique faces, because an oblique letter A is just that: an oblique square is not a square. With weights, a one could make a big black triangle bigger and call it bold, but some of these I wanted to be of maximal size in the main range -- there's nowhere to go. Also, boldness shouldn't be a matter of size, but of stroke width, so it really doesn't apply to a black circle. Therefore, a bold black circle is no different from a normal black circle. (The stroke width of the white version of the same circle should be heavier though.)

(file #42447)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 20 Nov 2017 08:17:41 AM UTC, comment #1:

Hi David,

In UTR #25, table 2.4,
U+22C4 is in the column labled "Diamonds", and is depicted substantially narrower than tall. The narrower depiction is consistent with the code chart, and with the FreeFont faces. I don't see how this is a "rotated square" -- it's a horizontally squished square.

Note: I guess UTR #25 pre-dates the "Miscellaneous Symbols and Arrows" block -- it doesn't mention the large white square, for instance.

FreeSerif Bold doesn't have U+2B26. I could add it.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 19 Nov 2017 04:02:25 PM UTC, original submission:

In FreeMono, FreeSans, FreeSerif, and FreeSerif Italic, U+22C4 DIAMOND OPERATOR looks like a lozenge instead of a diamond. (“Diamond” means “rotated square” in Unicode.) It should look like a white version of U+2B29 BLACK SMALL DIAMOND according to Unicode Technical Report #25.

In FreeSerif Bold, U+22C4 looks like U+2B26 WHITE MEDIUM DIAMOND. U+22C4 should be smaller than U+2B26 according to UTR #25.

FreeSerif Bold Italic doesn’t have the other diamonds to compare against, but U+22C4 is the same size as in FreeSerif Bold, so it should be smaller in FreeSerif Bold Italic too.

David Corbett <dscorbett>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by dscorbett (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-22 Stevan_White StatusProceeding => Fix posted
    2017-11-21 Stevan_White Attached File- => Added geom-symbol-sizes.html, #42455
        StatusNeed info => Proceeding
    2017-11-20 Stevan_White Attached File- => Added geom-symbol-sizes.html, #42447
    2017-11-20 Stevan_White StatusNone => Need info
        Assigned toNone => Stevan_White

    Back to the top

    Powered by Savane 3.4