Placement: Math signs, hyphen, braces should be horizontally aligned

For some reason all the dummy text got included in the report above, I used only maths signs. The bug report should read, "The math signs, hyphen, braces alignments can be improved. We'll re-work these for the next release V0.70. More further details see attachment."

Whilst I can see the need for the vertical central alignment of the math symbols I am doubtful of the alignment of 'hyphen', 'endash' and 'emdash'. They are not mathematical operators but used typographically. Accordingly, they should not be aligned with numerals and math symbols as their vertical position then sits in disharmony with caps and lowercases.

You will also find that the position of 'hyphen' and 'endash'/'emdash' is often not the same, as they do different things. The 'hyphen' needs to be aligned so that it works as best as possible with lowercases without being completely out of postion with caps and numerals.

Whilst I appreciate that many in the community work within a technical field that has strong mathematical requirement, at least as many do not. Again, I'd like to remind everyone that these fonts are already used outside the Ubuntu community by people who are designers, typographers and just simle users. We have to cater for those, too.

Bruno

Bruno: the critical pairs that need to be aligned are:

  -> <-
  <= =>
  -= +=

and ideally:

  *=

Paul: OK, in that case it makes more sense to align the operators with the hyphen. The * needs to stand high as it is used to indicate foot notes. This cannot be aligned.

I think the problem is that no-one really uses the minus-sign − (U+2212). Most programs do not, I think. If my keyboard layout would not have it, I would not use it either.
The minus sign harmonizes with the plus and the equality sign. I do not think this should be changed. Please do not confuse the en-dash (U+2013) with the minus-sign (U+2212), they really are different in the Ubuntu font (or does the minus sign get replaced as it is still not covered?).
The hinting is not always ideal but if the equality sign has a distance of two pixels, you cannot place the minus or the plus sign centered.

The pairs, that Paul mentioned have the same problem: the hinting. For very big font sizes I think the symbols are aligned. Even though I am not 100% sure. For programming this might really be considered for the monospace version, as here these pairs are quite frequent.

By the way, why does no-one use →, ⇐ or ⇒ instead?

Yup, I'm happy that * remains raised in the Regular families; it's the Monospace where '*=' wants to be aligned.

OK but I'd wager that someone will complain about the unusual positioning of the *. :-)
Again, I understand that the Monospace fonts are primarily used within a coding environment - at least that's the intention - but I guarantee you that these fonts will find their way into design and publishing and they will be used for typographical work. This is not meant to say that I think we mustn't do this - merely to point out the wider implications.

Wearing my C++ coder hat, I'd have grave reservations about the asterisk
being centrally placed. It should be raised for clarity IMO.

Dave

David: perhaps we could try (leaving) it centred in the Monospace for a few months and see what feedback we get. If we don't try things, we don't get the hard information to make future decisions based on. At the moment I fear that this bug report is straying.

I'm not sure the bug report is straying - we have successfully
identified several symbols which should vertically align with the hyphen
and equals.

However, the asterisk U+002A doesn't align with the equals, and isn't
supposed to align with the equals. Doing so in the monospace will make
the font more difficult to use for coders, and cause confusion with the
version which is supposed to align, at U+2217.

There doesn't appear to be any good reason to try it and await comments.

Dave

One can use ⁎ U+204E LOW ASTERISK for a non raised asterisk. It's not guaranteed that it will align with other symbols, and is no good for programming :-)

David: because it's a style issue... there are two (or more) opinions. I can happily chuck in my experience (also as a programmer who stares at monospace for 60+ hours per week) that I /do/ prefer and find an aligned '*' far easier to read than one that is raised and so disrupts the flow of the line. It is not just multiplication/pointer use in code, it is every bullet point in every wiki source code page . It is the progress bars I watch, the regular expressions; ... the two characters that disrupt the evenness of the line the most (for me) and these are the * and the ^ (plus the ~ if it has been placed on the top line rather than in the centre).

It is currently an opnion one vs. one (indeed, where one person would /prefer/ to remain nominally neutral) and with two people that was too closely associated, it is not a statically useful sample. We /can/ take a decision now, but that shortcuts the opportunity to make it better. It is somewhat preferable to get it "out there" to the 1,000s and then start looking at feedback rates.

The fonts are not (purely) for our own gratification, they are for users.

To the best of my knowledge, when I talked with Amelie three weeks ago, the +-=<> symbols (lets ignore the specific case of the * for the moment) were aligned in the Monospace. To the best of my knowledge they were aligned in the regular aswell, but clearly when I sat down with Malcolm to look at the case tag implementation they were not/no longer aligned, and that is why this bug is filed.

Since the Monospace (to the best of my knowledge) does not currently have an alignment problem, it is not afflicted... we can talk about it and discuss it /here/, but it only severs to dilute the original specific point and then we end up with another enthusiastically commented bug report where the original intent has been lost, when instead, if there /is/ an issue somebody will file a bug to say so.

To specifically choose to position U+002A centrally goes against the
previously decided guideline, and basic principle, that every character
in a monospace font be as distinct as possible. A central U+002A is
easily confused with a U+2217; a slightly superscripted U+002A, as
happens in almost every other monospace font ever designed, is not.

This isn't a style issue - it's a character confusability and usability
issue.

My reason for raising this now, and continuing to raise it, is to avoid
the extra work that will required to put it right later. Why don't we
implement the "normal" solution now and see if anyone raises a bug about it?

Dave

Having ∗ (U+2217) will be nice in the long run, but it's outside the initial contract and so is a long way off. It's also used vastly less frequently than * and not for day-to-day code, bullet points, password entry, multiplication and various other it unfortunately gets overloaded for.

A appropriate place for ∗ being used is a telephone keyboard and so it ideally probably wants to have the same kind of weight and apparent size as 0-9 and #. I would probably expect to find ∗ aligned with # (which is further away from the baseline than the - hyphen.

It's entirely possible that I was corrupted by the huge big beautiful star that the BBC Micro booted up with, but then again perhaps were so many other people... and I'd like to have the opportunity to hear from them.

> A appropriate place for ∗ being used is a telephone keyboard and so it
> ideally probably wants to have the same kind of weight and apparent size
> as 0-9 and #. I would probably expect to find ∗ aligned with # (which is
> further away from the baseline than the - hyphen.

∗ U+2217 is the proper mathematical symbol (its Unicode category is "Symbol, Math"). It would make more sense to have it aligned with other mathematical symbols.

2010-12-14 (Paul Sladen) Ubuntu Font Family version 0.70

  Release notes 0.70:
  * (Design) Add Capitalised version of glyphs and kern. (Rg, It, Bd,
    BdIt) DM (LP: #676538, #677446)
  * (Design) Give acute and grave a slight upright move to more match
    the Hungarian double acute angle. (Rg, It, Bd, BdIt) (LP: #656647)
  * (Design) Shift Bold Italic accent glyphs to be consistent with the
    Italic. (BdIt only) DM (LP: #677449)
  * (Design) Check spacing and kerning of dcaron, lcaron and
    tcaron. (Rg, It, Bd, BdIt) (LP: #664722)
  * (Design) Add positive kerning to () {} [] to open out the
    combinations so they are less like a closed box. (Rg, It, Bd,
    BdIt) (LP: #671228)
  * (Design) Change design of acute.asc and check highest points (Bd
    and BdIt only) DM
  * (Production) Update <case> feature. DM (LP: #676538, #676539)
  * (Production) Remove Romanian locl feature. (Rg, It, Bd, BdIt)
    (LP: #635615)
  * (Production) Update Copyright information with new
    strings. "Copyright 2010 Canonical Ltd. Licensed under the Ubuntu
    Font Licence 1.0" Trademark string "Ubuntu and Canonical are
    registered trademarks of Canonical Ltd." (Rg, It, Bd, BdIt) DM
    (LP: #677450)
  * (Design) Check aligning of hyphen, math signs em, en, check braces
    and other brackets. 16/11 (LP: #676465)
  * (Production) Pixel per em indicator added at U+F000 (Rg, It, Bd,
    BdIt) (LP: #615787)
  * (Production) Version number indicator added at U+EFFD (Rg, It, Bd,
    BdIt) (LP: #640623)
  * (Production) fstype bit set to 0 - Editable (Rg, It, Bd, BdIt)
    (LP: #648406)