Add a new version of Fira to the OS which includes expanded Latin support for a variety of languages specifically those found in Africa.

Hey Arky and Friedel, attached is the proposed glyph expansion to Fira. Can you please let me know (needs info me) if we're missing any glyphs? Thanks.

Hi Patryk. I could only take a brief look, but it covers everything needed for South Africa (with one exception, below), as well as the characters that I quickly assembled from the currently targeted language areas. It looks as if it was assembled from a authoritative source, so this is probably more complete than I can hope to assemble. The outstanding character is U+0149 that I mentioned in bug 1121355. It is formally deprecated, but I'm seeing quite a lot of use. If we can at all address the kerning problem mentioned in that bug, it would be great as well - the combination occurs very frequently and the current kerning is not right. The other thing I'm not sure if I should raise it here, is the matter of combining diacritics. I guess that is not what you are asking about, but we might want to check them as well, since they are used in some of the targeted markets, for example ɛ ɛ́ ɛ̂ ɛ̌ and ɔ́ ɔ̂ ɔ̌ - there are no precomposed versions in Unicode for these.

Hi The glyphs on the PDF seem to cover most West African languages I know. Fulah had an issue with not matching font substitution but now all the characters are in the pdf (bug: https://bugzilla.mozilla.org/show_bug.cgi?id=999083).

[Blocking Requested - why for this release]: Many locales in Africa are going to ship soon, on 2.0 (see mana for details https://mana.mozilla.org/wiki/display/PM/Firefox+OS+Wave+Launch+Cross+Functional+View) Given the dates we've heard from Bus Dev, any work needed should be ready soon. Any ETA on this please? Also, nominating for 2.0.

Flagging Bhavana so she can approve this. Bhavana: this would be needed in view of numerous partner launches in africa (https://mana.mozilla.org/wiki/display/PM/Firefox+OS+Wave+Launch+Cross+Functional+View)

Also, flagging :Patryk so this gets on his radar (sorry for noise!)

I am hoping we'll get the first cut of the African expansion this week... if not early next week, I'll keep you updated.

Hi Patryk. I just wanted to confirm: I haven't seen the issue I mention in comment 2 specifically addressed. Will the kerning of U+2019 U+006e be addressed by this update as well? It can be done by language specific kerning to minimise risk. It is probably even more important than the missing U+0149.

The new version of Fira has been uploaded to github: https://github.com/mozilla/Fira/tree/master/otf Monospaced has NOT been updated yet, but I don't believe we really use it in the OS (atleast not in the UI). Can you please put into the builds so we can get some testing done on it. Its should be final, but we often find a bug or 2 with the glyphs.

Hi. Not sure what the ni on me for is here? I don't speak the language, so sorry can't be of much help :/ Clearing the ni on me for now, thanks!

Friedel, Ibrahima, Arky: can you please take a look at link on comment 9 and give your input here please? Would be greatly appreciated :) thanks!

Converted the newer Fira OTF to TTF. Tested with sample texts provided for 11 official languages at http://salanguages.com/

It seems my system doesn't support OTF files automatically. What is the easiest way to test this? Is the font used at https://mozilla.github.io/Fira/ the up to date version? Arky, thanks for the screenshots. It would have been great, but doesn't cover the interesting parts due to incorrect orthography in the case of the language Venda. I also need to test the characters and combintations mentioned in bug 1121355. I'm still not sure if the kerning issue from bug 1121355 was attempted as part of this. I hope someone can shed some light on this.

(In reply to Friedel Wolff from comment #14) > It seems my system doesn't support OTF files automatically. What is the > easiest way to test this? Is the font used at > https://mozilla.github.io/Fira/ the up to date version? I don't think so. Let me share my notes, I used this article to learn how to batch convert OTF to TTF using Fontforge http://www.stuermer.ch/blog/convert-otf-to-ttf-font-on-ubuntu.html # Grab the Fira font sources https://github.com/mozilla/Fira/tree/master/otf # Create a bash script to convert OTF to TTF $ cat ~/bin/otf2ttf.sh #!/usr/bin/fontforge # Quick and dirty hack: converts a font to truetype (.ttf) Print("Opening "+$1); Open($1); Print("Saving "+$1:r+".ttf"); Generate($1:r+".ttf"); Quit(0); # Convert a batch of OTF Fonts with the script. $ for i in *.otf; do fontforge -script ~/bin/otf2ttf.sh $i; done # Remount the Firefox OS devices /system in read-write mode $ adb remount #Pushing many fonts to device for i in *.ttf;do adb push $i /system/font; done

Hi I am currently at MWC in Barcelona and will probably. Will test his when I return home.

Thanks to Arky's steps, I could convert to TTF and tested on my desktop. I wrote detailed feedback in bug 1121355 on the issues with the Afrikaans 'n often encoded as U+2019 U+006e or U+0149). Here something extra that I saw as illustrated in the screenshot: the circumflex below the venda letters are not consistent. In the case of the letter ṱ it is most clear: the circumflex seems to be positioned higher, especially at the smaller sizes. The circumflex under ḽ also doesn't look quite the same as the others. The text is not realistic in the language, but makes it clear that the circumflexes are not the same. I hope that helps.

Friedel, thanks for that, I was about to roll out this test myself and now I don't need to. Was that with combined characters or using combining diacritics? I assume the former. I guess it might be nice to ensure we can do both as that leaves some flexibility with input methods.

Dwayne, this was the precomposed forms. We should probably check the rest, but I don't believe I've seen any use yet.

(In reply to Friedel Wolff from comment #20) > Dwayne, this was the precomposed forms. We should probably check the rest, > but I don't believe I've seen any use yet. My view would be to make sure we do it correctly regardless as we never know if we hit some normalisation in the future.

Perhaps it is a good idea to create a testcase of these problematic characters and host it online (github/Ghpages or personal website.) That will make it easier for testing on Firefox OS device by simply opening the page using browser app.

NI Arky & Friedel as FYI I just uploaded v.4.002 of Fira to github, there are some minor tweaks and we added 200 glyphs per font: Latin Extensions A (uni0100 – 017F) Latin Extensions B (uni0180 – 024F) IPA Extensions (uni0250 – 02AF) Friedel per comment 18, if you can't use OFT which we ship on device, can you use the TTF provided in Github: https://github.com/mozilla/Fira/tree/master/ttf Just want to be sure if we are seeing something weird its in the font and not due to a conversion process. I'd also want to make sure we can duplicate it in the OFT.

Tested on device and it looks ok. I *think* this still has a higher line height than before, but it's not as high as I remember v3 was. There's more time for this release so I think we can try using the intended line height if it doesn't break too many reftests.

Shouldn't this be blocking 2.0M? Or do we really want all 2.0 devices to get these new fonts?

If we backport this to a 2.0 branch, we'll probably need a version with adjusted line heights (again).

(In reply to Michael Wu [:mwu] from comment #24) > Created attachment 8575552 [details] > Update moztt to Fira 4.002 > > Tested on device and it looks ok. I *think* this still has a higher line > height than before, but it's not as high as I remember v3 was. From looking at the metrics in the font, I believe this will increase the default line height by about 17%. > There's more > time for this release so I think we can try using the intended line height > if it doesn't break too many reftests. I'd suggest getting UX to do some side-by-side comparisons of devices before and after the change (looking at screens where line height is NOT explicitly fixed) to see whether that's desirable. It will mean that on typical pages where line height is left unspecified (or where it's expressed as a multiple of the default line spacing, rather than an absolute dimension) we'll get more widely-spaced text, and less information visible per screen. Reftests are a secondary consideration; in general, they shouldn't be dependent on the exact line spacing of the font, and if they are, we should fix them. But I'm not sure increasing the default line spacing is a good idea for mobile devices with limited screen real-estate, unless it's felt that the current setting actually looks too cramped.

Comment on attachment 8575552 [details] Update moztt to Fira 4.002 The patch looks fine, modulo the duplicated font names in the LICENSE files (commented on the PR). As noted above, I'm concerned that increasing the default line spacing may not be a good idea, but we should get UX review of that, comparing the effects on app layouts and also on a variety of web pages. (Some pages may set explicit line-height, and thus not be affected much if at all, while others that use multiples of the default will get spread out vertically by 17%.)

Hey Patryk - your call on line heights. I assume you like the current line heights in Fira as is, so it's probably a matter of how much checking you want to do. Also, see the PR for other changes needed to the LICENSE file. I just copy the LICENSE file directly from the Fira upstream. It looks like the license should be changed to reserve just Fira, not Fira Sans or Fira Mono. http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL-FAQ_web#7fba289b If you'll fix this in the next update, I'll leave things as is for now until the next update.

I updated the license date, do you have screenshots of the line height change or can you let me know when its up on master so I can see it on a flame? Thanks!

Oh, usually copyright dates turn into a range when they're updated. The font itself actually reports itself as copyright 2012-2015 so that's probably the best thing to update it to. We also need to update the reserved names in the license. I think it would be best for you to check the new font yourself on a device. You can try pushing the font on the device yourself or I can land this PR so everyone can check it out. Let me know what you prefer. To push the fonts on the device, do this in the Fira directory: adb remount adb push otf /system/fonts adb reboot

My bad, now the license should be good. I also loaded the new fonts (for some reason they are all very bold), but looks like the line heights are good!

Ah yeah, we don't install all the fonts, so you're probably getting some fonts selected that wouldn't actually show up in a normal build. I'll update the license again and land this.

Backed out for reftest failures, like every other attempt at updating Fira without trimming the line height. https://github.com/mozilla-b2g/moztt/commit/ed2cf97a6c37a4bbd0bbbbffe06ec7136d8c79ff

(In reply to Michael Wu [:mwu] from comment #25) > Shouldn't this be blocking 2.0M? Or do we really want all 2.0 devices to get > these new fonts? Hi Michael, Yes, We need this for 2.0 if any partner want to ship device with 2.0 in Arabic country. Patch land on 2.0 will be merged regularly to 2.0M. My question is why you need another version with adjusted line heights? Are fonts for 2.0 and 2.0M different?

(In reply to Josh Cheng [:josh] from comment #36) > My question is why you need another version with adjusted line heights? Technical details - don't worry about this part. Reftests will fall apart when line heights aren't maintained. Also it is an unnecessary risk. > Are fonts for 2.0 and 2.0M different? Yes. 2.0 never received the last Fira font update (bug 987872). The last font update *requires* changes in gaia and gecko to work correctly. Since 2.0M received the update, it can be updated to the newest Fira easily. If you want the latest Fira on 2.0, the previous Fira font update needs to land on 2.0 first.

(In reply to Patryk Adamczyk [:patryk] UX from comment #23) > you use the TTF provided in Github: > https://github.com/mozilla/Fira/tree/master/ttf > Just want to be sure if we are seeing something weird its in the font and > not due to a conversion process. I'd also want to make sure we can duplicate > it in the OFT. Thanks Patryk, Going to run my tests again with the TTF fonts. Will give feedback if I spot any problems.

I downloaded two TTF files from github of Fira 4.003 (FiraSans-Book.ttf, FiraSans-BookItalic.ttf). Both still show the issue I mentioned in comment 18. I tested in LibreOffice on my desktop as that is all I can do right now here.

Hey, I can't seem to replicate this issue, but I am using the OFT file (this is what we ship with). You should be able to run OFT in windows, can you please that try? Ideally for testing we should probably have a webpage to browse to, the font should be in the builds now and the firefoxos browser uses fira. I also confirmed with the font designers and they are puzzled by the issue, perhaps its a mix of software (LibreOffice) and the TTF.

(In reply to Friedel Wolff from comment #39) > I downloaded two TTF files from github of Fira 4.003 (FiraSans-Book.ttf, > FiraSans-BookItalic.ttf). Both still show the issue I mentioned in comment > 18. I tested in LibreOffice on my desktop as that is all I can do right now > here. This looks to me like an artifact of the hinting and rasterization of the TTF files. Fixing it might require manually adjusting the hinting of glyphs like ḽ and ṱ where the base shape has a curved/hooked bottom that dips slightly below the baseline, together with a diacritic below; I suspect that's the scenario that's causing the (auto?)hinting to behave poorly. At small sizes, the bottom of the base shape is "snapped" upwards to the baseline; then I think the diacritic is being moved in conjunction with it, which is not desired. If that's right, then it shouldn't affect FxOS, where we use the OTF files, which use a completely different hinting technology and so are not likely to show the same issues (although of course they could have separate issues of their own!)

Patryk, Jonathan, thank you for also looking into this. And sorry that I didn't try on the right platform. The screenshots look fine, so I'm happy to assume it is caused by the different hinting. I don't have Windows. I can try to squeeze in some time in the week to try and confirm here on a device - it was not possible in the last week, and time is quite tricky now still. Thanks again.

Latest Fira v.4.004 with bug fixes https://github.com/mozilla/Fira/tree/master/otf The line height change to 1.2x from 1.4x will happen in the next release. Can you push this in, Michael?

Remember that pushing this as-is will result in some reftest failures (because of how it'll change the meaning of line-height:normal). Perhaps we should bite the bullet and go through those failures to figure out how to make the tests more robust; in general, they *shouldn't* break as a result of changing the font, but in practice some of them are fragile. Alternatively, we can wait until we have the reduced-lineheight font before pushing it.

Michael, Would you mind review this?

Comment on attachment 8579480 [details] Update Fira to 4.004 The PR is correct, but it can't land as is until you fix the failing reftests.

As comment 47, we shouldn't land it. AIK, there will be a new version which can be landed soon.

(In reply to Michael Wu [:mwu] from comment #31) > To push the fonts on the device, do this in the Fira directory: > > adb remount > adb push otf /system/fonts > adb reboot mwu, I tried these steps and didn't see the required changes. Could it be that there is a typo in these instructions, or is the required language specific glyphs not being selected in Gaia for some reason? Thanks for any help.

AIUI, this is only necessary to support certain languages in Africa, and only devices based off 2.0M will be supporting those languages, so we can make this block 2.0M rather than 2.0.

Michael: all our contributors (for ex. Friedel in this thread, and Kevin Scannell) and localizers who are testing Africa products are on 2.0 builds for Flame. Can we please have this block 2.0 as well? thanks

(and then get approval to land on 2.0M, or something of the sort)

Landing this font on 2.0 requires a number of other bugs to land, and there's really no reason for 2.0 to get all those changes when we're only interested in them for 2.0M. I recommend switching to 2.0M if you really want to test the new fonts.

(In reply to Friedel Wolff from comment #49) > mwu, I tried these steps and didn't see the required changes. Could it be > that there is a typo in these instructions, or is the required language > specific glyphs not being selected in Gaia for some reason? Thanks for any > help. If you're on 2.0, it won't work. Fira had a name change in the last font update, so switching to 2.0M or 2.1 will be necessary for gecko to select the new fonts. Beyond just a name change, gaia also required some changes in order to select the right weights in the new Fira.

How do we get access to these builds? I was told that even internally we don't have access to partner builds - in this case 2.0M. If it's possible, I need to know. Also, how is community going to test these if 2.0M builds aren't available? They are the native speakers that can ultimately let us know if these are showing up correctly (see in this bug for example Ibrahima and Friedel are the ones we go to for feedback). They will need access to 2.0M in this case.

It looks like there's no build automation - otherwise we'd see builds in directories like http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g34_v2_1-flame-kk-eng/ . Kai-Zhen, do you know anything about this? We need 2.0M Flame builds at the very least, and hopefully 2.0M emulator builds too to run tests on.

We don't have automation build on 2.0M. Now only gecko/gaia/moztt get 2.0M branch. If we want to build flame/emulator 2.0M locally, I think we can create 2.0M branch for b2g-manifest and update manifest files accordingly.

Fira 4.1 landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1152798 . Do we still need to uplift to 2.0M?

(In reply to Michael Wu [:mwu] from comment #58) > Fira 4.1 landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1152798 . Do > we still need to uplift to 2.0M? Hi Michael, Yes please. Thanks!

Josh, I notice that pivanov already merged new version into master, I uplifted it to v2.0m. master: https://github.com/mozilla-b2g/moztt/commit/adb24954bf8068f21705b570450475d183336b2d v2.0m: https://github.com/mozilla-b2g/moztt/commit/f8bf6495a7ac6ae604b13de8521cf3d2484b1aaf

Comment on attachment 8579480 [details] Update Fira to 4.004 v4.1 is landed. We don't need this anymore.

Per comment 60. Pleas request approval for v2.1 and v2.2 if necessary.

Would be nice to get these in other branches. As we're shipping in Africa, other partners might come up and pick up other builds than 2.0M