Diacritic: Bold: í acute accent is too to left

[Unai Uribarri]

Rendered in 24pt Bold

Sample Glyphs:

Description:

The tilde over the í letter is displaced one point to the left. Common spanish caligraphic rules mandates that the i leter and its tilde should be aligned to the left.

UA String:

Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4

[Unai Uribarri (unaiur)]

Automatic Screenshot

[Paul Sladen (sladen)]

Bumping this up a notch as a duplicate has just been filed noting the same issue with acute accents in the Bold face.

[Paul Sladen (sladen)]

PDF showing asymetric comparison of i-acute and i-grave.

When other the equivalent o-acute and o-grave are mirrored they overlay exactly.

[Shiraaz Gabru (shiraaz)]

It is not a rule that the i-acute and i-grave should be symmetrical. This is a design decision, I've attached a pdf demonstrating theasymetric comparison in the Georgia font. This therefore can't be regarded as a bug.

[David Marshall (dave-daltonmaag)]

This is absolutely correct. The eye is almost always deceived by
symmetry in type design - if you make a design truly symmetric, it looks
off-centre.

Dave

[Paul Sladen (sladen)]

Shiraaz: note the asymmetric serif at the top, the acute being "centred" on that.

[Paul Sladen (sladen)]

I don't think anyone doubts the value of _intentional_ asymmetry in design.

I would characterise both this bug report and bug #651680 regarding the capital M (and which has a similar response) as being "_accidental_ asymmetry"... in programmers' terms, an "off-by-one" error.

If it had been intentionally asymmetric designed to "look right", we would have had zero bug reports ... the best design being that which goes consciously unnoticed. In this case we got two independent bugs reports.

[David Marshall (dave-daltonmaag)]

No, both the instances you mention are absolutely definitely intentional
asymmetry. The bug reports are no doubt arising because people expect
there to be numerical symmetry and are actually going looking for it.
The accent placement appears both correct and balanced to me.

A monoline sans M is almost never a symmetrical design, despite what the
eye may tell you - there's actually a famous example of this, the "M" in
Univers looks like a symmetrical design, until you see it mirrored, and
then it very obviously isn't and looks very wrong indeed.

Likewise, accents should always be placed optically not numerically - we
want them to look balanced and centred, even if that means they're not
numerically so.

A lot of what a type designer does to bring harmony, elegance, and
symmetry to characters is actually just fighting against the optical
illusions which naturally arise from strokes and shapes intersecting. If
it looks right, it is right, no matter what the ruler tells you.

Dave

[Vincent Connare (vince-daltonmaag)]

This is what I wrote last century about accents and their placement.

It also mentions a Polish preference for a liking for a flatter acute
and grave; while the French preference is for an almost vertical acute
and grave see the original specimens of the type of Pierre Simon
Fournier 1712-1768.

What I wrote is below taken from:

http://www.microsoft.com/typography/developers/fdsspec/diacritics.aspx

=====

Composite character placement rules

/Vertical placement/ : Most commonly vertically placed so the space
between the bottom of the acute and grave are offset approximately 5 to
10% of the em above the top of the lowercase overshoot height. In a 2048
em the space is usually between 100 and 200 units. Uppercase accents are
usually closer to the tops of the base glyph than lowercase accents.

/Example/ : Palatino Linotype regular has 98 units between the /acute/
and /uppercase O/. There are 130 units between the /acute/ and
/lowercase o/. Georgia regular has 54 units between the /acute/ and the
/uppercase O/. There are 96 units between the /acute/ and the /lowercase
o/. Georgia accents are considered very tightly spaced. In both fonts
the em is 2048.

/Horizontal placement/ : Horizontally diacritics are to be placed in the
visual center of the glyph. The two most difficult glyphs to center are
the /acute/ and /grave/. There are two common theories when centering
these glyphs. A common way is to place the acute or grave so the front
goes through an imaginary line of the visual center of the base glyph.

diagram

The second method was taught at the type foundries of Monotype and
Mergenthaler Linotype. The acute is placed so 1/3 of its black width is
on the left of the imaginary centerline of the base character and 2/3
are on the right of that line. The grave has 2/3rds on the left and 1/3
is on the right. This is considered a starting point and visual
adjustment is made dependent on the design.

diagram

All other diacritics are placed so they visually center on an imaginary
center line of each base glyph.

    /Note/ : In the Polish language the preferred angle of the acute is
    steeper than the acute diacritic's angle in most typefaces. For help
    on the design and position of the acute diacritic for the Polish
    language see Adam Twardoch's <http://www.twardoch.com>
    recommendations for the acute diacritic. A language dependent
    substitute would a good solution for the Polish language.

On 09/11/2010 16:13, David Marshall wrote:
> No, both the instances you mention are absolutely definitely intentional
> asymmetry. The bug reports are no doubt arising because people expect
> there to be numerical symmetry and are actually going looking for it.
> The accent placement appears both correct and balanced to me.
>
> A monoline sans M is almost never a symmetrical design, despite what the
> eye may tell you - there's actually a famous example of this, the "M" in
> Univers looks like a symmetrical design, until you see it mirrored, and
> then it very obviously isn't and looks very wrong indeed.
>
> Likewise, accents should always be placed optically not numerically - we
> want them to look balanced and centred, e...

[Paul Sladen (sladen)]

Vincent: it was a very interesting read, but the report is about the unintended artifacts of being slightly off, not the very real and intended placement in the first place.

The tiny off-by-one is getting exaggerated at the hinting stage and therefore ending up in the next pixel, where by it now appears to be massively off intended placement.

David: for the capital M, not that the regular /is/ (for all intents and purposes) basically symmetric, but in the case of the boldface has one of the four strokes about 20% bigger than the other three.

[David Marshall (dave-daltonmaag)]

This seems to be the wrong way round. We design in order to deliver the
highest possible aesthetics regardless of the numerical values, and it's
the hinting stage where we adjust these divergences to make them look
consistent at smaller sizes. Hinting introduces regularity and
consistency where the design optically had it but numerically didn't.
Adjusting the design to introduce numerical consistency will result in
an inferior design that looks wrong to the human eye.

The accents are placed so they are optically, not numerically, centred
over the main character. If there are problems with the placement at
specific rasterized sizes, the hinting can be adjusted to counteract it,
but it would be wrong to compromise the design just to make it rasterize
right at small sizes, when we have hinting to do specifically that.

I do repeat that it is *absolutely intentional* that the four strokes of
the M in Ubuntu Bold are completely different numerical widths, by a
very large margin - in this case a 22% difference between thinnest and
thickest stroke. Open any monoline sans serif font in a font editor and
you'll find exactly the same thing - despite appearing monoline, there
is always an apparently large numerical difference between the strokes,
with the difference increasing rapidly as the weight increases.

Look at the M as it's designed - does it look balanced and consistent
despite an apparent 22% "error"? Yes - because it's designed to *look*
right not *measure* right. To give the strokes identical numerical
widths would result in a design that simply looked wrong - the third
stroke (the second upstroke) would look much too heavy compared to the
rest, despite being numerically the same. Again, hinting is used to
normalize the values at smaller sizes - we don't and won't compromise
the design and aesthetics just to make the hinting easier.

Dave

[Paul Sladen (sladen)]

Can't see this getting fixed except with a large number of delta overrides in the hinting, and that won't solve the rounding in the wrong direction for the autohinted common case anyway.