1121355 - Firefox OS font not ideal for U+0149 and U+2019 U+006e

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Friedel Wolff]

Firefox OS font does not display U+0149 well at small sizes. I've mainly tested it in the messaging app, but I assume this will be a problem everywhere. In some circles in the Afrikaans community this character is used quite a bit, and we could even consider it for the UI (it might help slightly with tighter layout in a few cases).

While I don't know if this can easily be addressed, or what the amount of work involved is, I'm not providing a detailed description, but can do that with a font designer when required.

Arky, Chris Hofmann recommended that I CC for input. Any idea how to go ahead with this?

Comment 1

[arky [:arky]]

Friedel, It would be really helpful if you could attach a screenshot. Thanks!

Comment 2

[Friedel Wolff]

Attachment: screenshot

This is what it looks like on my Flame  (current Gaia 2.2). The third line shows the apostrophe completely above the letter, almost looking like an 'h'.

Comment 3

[arky [:arky]]

Thanks Friedel. Can you please shed some light on this issue?

Comment 4

[Friedel Wolff]

The glyph should (as a very basic implementation) look like the middle line (apostrophe + _n_), but preferably with much tighter kerning.

I don't yet know what the font or its design goals were, but if saving space horisontally was a big goal, it don't think it needs to be a concern here - it is already a very short word (the character on its own is a complete word and should never be part of a bigger word), and we're talking about a few pixels difference (Afrikaans also doesn't tend to be excessively long otherwise). In fact, using this character (if properly used) gives the opportunity to save a few pixels due to improved kerning compared to written out two characters (' + n).

The apostrophe should extend left of the _n_, whereas the screenshot shows how the _n_ goes further left than the apostrophe. The bad part is the position of the apostrophe in the screenshot making the glyph look like _h_ which could be downright confusing (not just aesthetically non-ideal).

Any more details might gradually get harder for me to discuss in plain text, so I'll stop here for now until we know someone is able to look into this.

Comment 5

[Dwayne Bailey]

I think that U+0149 (http://codepoints.net/U+0149) (which by the way is in fact deprecated in Unicode) is being displayed based on its composition mapping of 006E + 02BC.

My font knowledge is rusty but IIRC the placement of the ' can be adjusted for that character in the font itself. In the same way that they can be adjusted for other combining characters placement on certain letters.  Or simply that character needs to be created and added to the font.

Comment 6

[Dwayne Bailey]

If we are going to make sure U+0149 is rendered correctly I would also look at how we treat 'n and 'N - i.e. typed by the user as two characters.  When typed as two characters it should display correctly i.e. the same as U+0149 would display.  IIRC that would involve created a ligature for 'n[sp] that applies only to Afrikaans.

Comment 7

[Friedel Wolff]

I think Dwayne is right - the display of _'n_ (a very, very common word in Afrikaans) is not ideal, and should be fixed, and it shouldn't be different from U+0149 that I discussed first or U+02BC + U+006E (middle one in the screenshot). It will make a big difference in the visual quality, exactly because it is such a common word.

Comment 8

[Friedel Wolff]

Just to be clear about my comment 7: the kerning is far too wide between the apostrophe and the _n_ They don't need to overlap horisontally, although it is ok/good if it overlaps a bit (some fonts do it).

Comment 9

[Friedel Wolff]

Just a correction: the combination at stake is U+2019 U+006e (’n). I incorrectly mentioned U+02BC above.

Comment 10

[Friedel Wolff]

Sorry, I see now that Unicode defines U+0149 as approximately equivalent to U+02BC U+006E, so maybe we need to handle all of these to be as prepared as possible. However, the combination U+2019 U+006E is used in the UI localisation of Gaia, so it will get lots of use, and the non-ideal kerning is frequently visible in many parts of the UI.

Comment 11

[Patryk Adamczyk [:patryk] UX]

Attachment: fira4.jpg

Perhaps you can try with Fira 4.001, attached is how it looks in Photoshop with the new font update? Otherwise I think its a system issue.

Comment 12

[Friedel Wolff]

Thank you for the update, Patryk. The screenshot you attached looks a little better. I still think the apostrophe is not far enough left of the _n_. At this size the left-most pixel of the apostrophe is only one pixel left of the leftmost part of the _n_.

I assume the webfont used at https://mozilla.github.io/Fira/ is not updated, since that still seems to give the same result as what I posted in the original screenshot.

Patryk, is the kerning I mentioned above of the separate code points on the radar as well? The combination U+2019 U+006e (the middle one in the screenshot I attached) is used frequently in the current Afrikaans UI localisation, and the rendering is not ideal.

Comment 13

[Friedel Wolff]

I tested the fonts with instructions from bug 1126641. I'll attach things here with a screenshot made on my desktop system, and also then upload a manually edited version that is closer to the way it should look.

Comment 14

[Friedel Wolff]

Attachment: fira_5_sizes.png

This is a screenshot from my system with 5 sizes as indicated. I used LibreOffice and RGB subpixel rendering is enabled. I'm sorry if that complicates things.

I show all three of 
 - U+0027 U+006e (very common ASCII only encoding, hard to justify correct styling)
 - U+2019 U+006e (fairly common, and used pervasively in the Gaia UI)
 - U+0149 (used quite a bit by some)
They all encode the same thing semantically for Afrikaans.

Here are some comments to understand what is on screen:

In the first two renderings, the space between the apostrophe and the letter n is quite wide, and is non-ideal. It isn't unreadable, but it isn't pretty. It reminds of the effects of a mono-spaced font.

The third line is the "precomposed" form. It still looks mostly like the letter h. It isn't clear that there is an apostrophe and a letter n, mostly because the apostrophe is positioned horizontally too close to the letter n, and the gap between the two is too small (with the subpixel rendering they actually touch in all these sizes).

This apostrophe indicates left out letters, just as in the English word "didn't". So the apostrophe here has to come left of the letter n since that is where the letters are left out.

Comment 15

[Friedel Wolff]

Attachment: better_5_sizes.png

This is a picture based on the second line of the previous attachment, but manually edited to be closer to what I believe to be correct. It isn't ideal, partly because of time and skills, but also because the subpixel rendering complicates this, and I'm not sure how to do this different right now.

Here the horizontal positioning is between that of the second and third line of the current Fira. I believe the apostrophe and the letter n is reasonably clearly distinguishable, even at size 8, and doesn't look like the letter h to me. Size 9 and 10 in my manually edited version is maybe not quite perfect: the gap is a tiny bit too much in 9 and a tiny bit too little in 10, but this is maybe mostly a problem of consistency between the sizes shown (they only differ in terms of sub-pixel rendering in this specific rendering - the height doesn't differ, for example). Both at 9 and 10 in my version would be an acceptable positioning, I believe.

Both encodings (U+2019 U+006e and U+0149) mean the same thing and should look the same. Both exist in the wild and could be received in an email, for example.

Patryk, does this help if I explain things this way?

Comment 16

[Patryk Adamczyk [:patryk] UX]

Looks like this a kerning pair that can be adjusted, I'll forward this to Ralph Carrois, the type designer.

Comment 17

[Jonathan Kew [:jfkthame]]

I looked at the glyph for U+0149 in the 4.002 font, and it has clearly been adjusted/improved since 3.x, but the spacing between the apostrophe and n still looks a little tight to me; at smaller sizes I think it's going to almost run together visually, which it shouldn't. The apostrophe should be clearly to the left of the n, IMO, whereas 4.002 still has it roughly centered above the left-hand edge of the n's left leg.

My suggestions for Ralph, therefore:

(a) in U+0149, move the 'n' to the right by something like 50 font units, or perhaps a bit more, to create separation from the apostrophe, and increase the glyph width to match.

(b) for the sequences <02bc, 006e> and <2019, 006e>, either provide a ligature rule replacing them with the same glyph as U+0149, or kern the pairs about 100 font units closer together. Likewise, for <0027, 006e> provide a similar kern.

The kerns or ligatures in (b) should probably be implemented as a localized feature for Afrikaans (language system tag AFK).

Comment 18

[Patryk Adamczyk [:patryk] UX]

A) appears to be fixed now in v.4.003.
https://github.com/mozilla/Fira/tree/master/otf

I asked Ralph to create a bugzilla account, so he can best answer B) but if we put the fix under a pref for AFK that makes sense to me.

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Patryk Adamczyk [:patryk] UX from comment #18)
> A) appears to be fixed now in v.4.003.
> https://github.com/mozilla/Fira/tree/master/otf

Not quite; the placement of the apostrophe looks much better, but the glyph width wasn't increased (or the 'n' component moved to the right), so now the apostrophe projects significantly to the left. I think some additional space on the left is needed, otherwise in the usual case where ʼn follows a space, it'll look almost as though the space is missing. And if it follows a non-space, the apostrophe will look like it's associated with the preceding letter or punctuation rather than with the 'n'.

Comment 20

[Carrois’]

Hi all.

Thanks Friedel and Johnathan for your input.

Referring to comment 17 by Johnathan:

(a) Yes, we moved the apostrophe to the left because Friedel stated earlier that uni0149 would only be used as a standalone to the left. So we thought this would avoid a too large gap if preceded by a space (similar to capital /Etatonos in Greek). But no problem to do it the other way round (n to the right) if you say this would be more appropriate.

(b) Good idea.
So let’s make a locl feature and replace all different combinations by 0149.
Questions:

(1) Which language tag would I have to use for Afrikaans?
(2) Is it sure that this only affects Afrikaans or does the combination occur in other languages as well which should be covered by the feature?
I could forward these questions to a specialist for African languages if needed.

@ Patryk: Should we fix this with 4.004 by the beginning of next week or within the CYR GREEK Extension (4.1) in 2 weeks?

Thanks.
Anja

Comment 21

[Dwayne Bailey]

(In reply to Carrois’ from comment #20)
> (1) Which language tag would I have to use for Afrikaans?

AFR

Based on this post http://www.glyphsapp.com/tutorials/localize-your-font-accented-dutch-ij the use seems to be of ISO639-2/3 code. In which case for Afrikaans it is AFR https://en.wikipedia.org/wiki/Afrikaans

> (2) Is it sure that this only affects Afrikaans or does the combination
> occur in other languages as well which should be covered by the feature?
> I could forward these questions to a specialist for African languages if
> needed.

If anything it would occur in Dutch, but I don't think they do this specific construct at all. It doesn't affect any other African languages.

Comment 22

[Jonathan Kew [:jfkthame]]

(In reply to Dwayne Bailey from comment #21)
> (In reply to Carrois’ from comment #20)
> > (1) Which language tag would I have to use for Afrikaans?
> 
> AFR
> 
> Based on this post
> http://www.glyphsapp.com/tutorials/localize-your-font-accented-dutch-ij the
> use seems to be of ISO639-2/3 code. In which case for Afrikaans it is AFR
> https://en.wikipedia.org/wiki/Afrikaans
> 

No, it's AFK; see http://www.microsoft.com/typography/otspec/languagetags.htm. OpenType's *language system* tags are not the same as ISO639 *language* tags.

(In part, at least, because "language system" in OpenType does not mean the same thing as "language" in ISO639.)

Comment 23

[Friedel Wolff]

Thanks for all the work on this. I _think_ Jonathan is right about the positioning and width. I just tested briefly here: http://www.carrois.com/fira-4-0/ and saw an interesting effect that the apostrophe is clipped on the left if it is the first character. Now in proper typography it might not matter if the apostrophe extends slightly left of the margin (similar to how thin punctuation would at the right of justified text), but we can't afford having it clipped, and this is a real concern (it will often be the first word of a sentence/heading).

The horisontal space between a word and the apostrophe in running text (e.g. "word ʼn hond") should probably be as it would be in normal text, which as I understand is what Jonathan is arguing for as well.

Doing this as a localised feature sounds like the right solution: it brings minimal risk of non-ideal layout in other contexts, and should at least cover the Afrikaans GUI and web pages and email with correct markup.

Just to confirm what Dwayne said: this should only affect Afrikaans.

Comment 24

[Carrois’]

Attachment: Bildschirmfoto 2015-03-16 um 09.28.32.png

Thank you. 
Please have a look at the screenshots and tell me wether the leftSB works for you now.

(1) uni0149
(2) uni2019 + n (feature preview)
(3) uni0027 + n (feature preview)

If everything’s fine, we’ll upload the new files today.

Comment 25

[Friedel Wolff]

The spacing on the left seems a bit smaller than on the right, and doesn't feel natural. I might have worded things badly when I said "The apostrophe should extend left of the _n_" - I was only referring to the relative horisontal positioning between the two glyphs, not the font metrics.

So while I guess there might be some room for tweaking inter-word spacing in this case, it is too little now left of the U+0149 (and others) in the screenshot. Making the left and right spacing equal will be quite a safe choice, I guess.

By the way, is the webfont at http://www.carrois.com/fira-4-0/ up to date with the changes you are describing? It will make testing very easy if I can rely on that.

Comment 26

[Carrois’]

Attachment: Bildschirmfoto 2015-03-16 um 14.30.04.png

No it’s not up to date, still version 4.003. That’s why I’m sending screenshots to avoid producing and uploading the fonts (32 OTFs, 128 Webfonts) multiple times if there are still changes.

To be honest, I don’t really see your point.
Please have a look at the new screenshot:

(1) this morning’s draft
(2) added 20 units to the left
(3) "normal" spacing

In my opinion, (2) is not much better compared to (1) if you consider the white space and rhythm of the line. I would be ok with (2) but to make spacing equal to the left and to the right as you suggested does not sound typographically correct to me because you have to optically imply the white space beneath the apostrophe to the overall spacing.

So, I don’t want to make a big deal out of this, but do you go along with (2)?
If so, I would upload the fonts ;)

Comment 27

[Carrois’]

Good morning. 
Any comment on (2) or is this the way to go?!

Comment 28

[Jonathan Kew [:jfkthame]]

Personally, I think (2) may be OK, though I'd still consider increasing the spacing (on the left of the apostrophe) a little more. I wonder how it looks if there isn't a normal word-space before it. What if you try (ʼn) in parentheses, or “ʼn” in quotes?

But we should see what Friedel has to say before finalizing anything.

Comment 29

[Carrois’]

Attachment: Bildschirmfoto 2015-03-17 um 09.20.17.png

above: (1) – version with less SB (0 in regular Master)
below: (2) – version with 20 additional units.

Both works out. I guess we’re somehow getting lost in details within this discussion. But yes, Friedel – you came up with the topic, you should be satisfied.
I don’t want to bring up a quarrel, I’ll add even more to the left if you want.

Comment 30

[Carrois’]

We could also make left sidebearing equal to quote (wich implies additional space). 
Would that be the way to go?

Comment 31

[Dwayne Bailey]

(In reply to Carrois’ from comment #29)
> Created attachment 8578492 [details]
> Bildschirmfoto 2015-03-17 um 09.20.17.png
> 
> above: (1) – version with less SB (0 in regular Master)
> below: (2) – version with 20 additional units.

I'd say (2) looks less cramped with the quotes.  But yes ultimately Friedel is the daily user and I'm an occasional user.

The following other cases might help as I think we're looking at unusual cases in some of the examples and these map more closely to real use cases.

'n Vriend - start of line/start of sentence
"'n Hond" - souble quotes
''n Hond' - single quotes
einde. 'n Nuwe - start of sentence
word 'n hond - middle of sentence as we've been looking at already

I've had a look at the images and my mind starts going fuzzy about spacing and I have to rely on font designers to spot the subtle differences.

Comment 32

[Friedel Wolff]

Thanks for clarifying about the webfont.

I think we are getting closer, but it is not quite ideal, yet. To make sure this is not just me, I had a look at a fairly large number of books on my shelf. Most use serif fonts, but I was able to find a number who use sans for parts of the text. Although I would love to scan them all and measure it carefully, I obviously didn't have the time and had to do a brief look by eye. However all of them seemed to have equal spacing left of the apostrophe and right of the _n_. It might be because of the limitations of fonts used for computer typesetting, but at least some of them looked really nicely typeset. As uploaded here, it still looks a bit strange to my "native eye".

The spacing in the case with brackets (ʼn) doesn't look right. The left bracket should be more spaced out to the left to look balanced. The quotes are also a bit too close tot the apostrophe in ‘ʼn’ - at small sizes it might start looking like a double quotation. The apostrophe here represents part of the word - maybe that is why we view it that way. I also ran this screenshot with brackets past a colleague who commented on the same issues without me having to lead him towards it.

On Dwayne's suggestion, here is a text that captures some variety of use:
  ‘n Mens koop ‘n hond en “‘n kat”—‘n gemors. ‘n Woord (‘n sin).

Comment 33

[Carrois’]

Attachment: Bildschirmfoto 2015-03-17 um 12.35.39.png

Ok, linked the apostrophe of /uni0149 to the left side bearing of quote. To me, this seems to be be logical metrics linking.

That means + another 20 units in regular compared to (2) of the last screenshot. 
Ok now? (Also have look at the bottom line showing general spacing of uni0149)

Thanks for helping with this. In the end, your native eye is what we should rely on in case of insecurity.

Comment 34

[Friedel Wolff]

Thanks. This is looking better, I believe.

The space between the quotes and the apostrophe in _“‘n_ is still slightly unfortunate - I guess this is hard (most fonts handle this quite badly). The distance between the quotes and the apostrophe looks smaller than the distance between the apostrophe and the _n_. Only a very subtle change would be necessary here, I believe. Since the rest looks ok, I guess that might mean a custom kerning pair :-/

Don't worry about the spacing on your bottom line: the combination under discussion is always a word on its own.

If possible, please render in a single line, and maybe at a slightly smaller size - it might help to keep things closer to the usual case. I'm reducing the size of the picture, but concerned that it might affect things.

I know I'm splitting hairs, but I'm very excited about this. Thanks for allowing my comments!

Comment 35

[Carrois’]

Attachment: Bildschirmfoto 2015-03-17 um 16.30.58.png

Seems like we’re finally approaching the last "OK" ;)

I introduced a kerning pair +50 between /napostrophe and all upper quotes. Metrics stayed the same. Please give me another short hint, if you’re ok with that.
Like that we can generate the fonts today (UTC +1h).

Comment 36

[Friedel Wolff]

Thank you so much for the work on this. I think we can let it rest now. The quotes look better. I haven't yet tested on the device - I've just been too busy. I'll try to get round to that eventually.

Thanks again for your perseverance!

Comment 37

[Patryk Adamczyk [:patryk] UX]

Should be fixed in v.4.004 now, await :mwu to push it into master.
The font is here: https://github.com/mozilla/Fira/tree/master/otf

Comment 38

[Patryk Adamczyk [:patryk] UX]

I believe this has been fixed, can you please confirm. Thanks!

Comment 39

[Patryk Adamczyk [:patryk] UX]

I am pretty sure this has been fixed now, if not, please NI me and reopen the bug.