1035471 - [B2G][2.0][l10n][SMS] Tamil: "(No Recipient)" string is cut off in the messages list.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect, P3)

Description

[Martin Shuman [:Marty]]

Attachment: No_Recipient_Screenshot.png

Description:
"(No Recipient)" string is cut off along the bottom of the text line in Tamil 

Repro Steps:
1) Update a Flame device to BuildID: 20140707000200
2) Change language to Tamil (தமிழ்)
3) Restart device
4) Open a new SMS message and save a draft without a recipient.
5) Note the "(No recipient)" string in the messages list.

Actual:
"(No Recipient)" translated string is cut off.

Expected:
No cut-off occurs.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140707000200
Gaia: ef67af27dff3130d41a9139d6ae7ed640c34d922
Gecko: f53099796238
Version: 32.0a2
Firmware Version: v122
2.0 - Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Keywords: Tamil, SMS, Truncation

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/12588/
See attached: Screenshot

-------------------------------------------------------

This issue does not occur on 1.4 Flame.

Environmental Variables:
Device: Flame 1.4
BuildID: 20140630000201
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Tamil was not an available language.

Comment 1

[அருண் குமார்-Arun Kumar]

I have checked with Keon device with Build(20140722223137), It is not to do with Translation, because the localizied Tamil strings(date & No receipent) are apearing fine except cut off. 

The strings bootom portion(tiny) is cut off. It may be due to default Tamil font size/height.

Please advice us.

Comment 2

[Martin Shuman [:Marty]]

Moving this to Gaia:SMS.  Tamil appears to be the only language affected here.

This issue does NOT occur on Flame 2.1.
"(No Recipient)" translated string appears appropriately.

Device: Flame Master
Build ID: 20140725040205
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

-------------------------------------------------------------------

This issue DOES occur on Open-C 2.0 and Open-C 2.1.

"(No Recipient)" translated text is cut off at the bottom.

Environmental Variables:
Device: Open_C Master
Build ID: 20140725040205
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140725000201
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-------------------------------------------------------------------
I was unable to test this on the Buri device, as Tamil is not an included language in the Buri builds.

Comment 3

[Julien Wajsberg [:julienw]]

Do we have different fonts on Flame and Open C?

Gaia::SMS is not the right component for this but I don't know who we can NI for this...

Comment 4

[Arun Prakash]

For your information, for tamil we recently changed the fonts to noto. It is changed for keon, and yet to change for flame. Flame is still using Lohit fonts.

Comment 5

[Julien Wajsberg [:julienw]]

Ok, so this is probably the reason of the discrepancy. Any ETA for Flame?

Comment 6

[Arun Prakash]

I am not very sure, but look at this, https://bugzilla.mozilla.org/show_bug.cgi?id=1022311#c2

Comment 7

[Julien Wajsberg [:julienw]]

Hey Pike, do you know if this bug is INVALID because we don't use the correct fonts on Flame? Do you know a path forward?

Comment 8

[Axel Hecht [:Pike]]

Attachment: list of my fonts on 2.0

I updated my flame to 2.0, and uploaded the Noto fonts, and removed the Lohit fonts, and rebooted, and I still see the same cut-off behavior.

Comment 9

[Julien Wajsberg [:julienw]]

Pike, do you see the exact same thing than attachment 8451969 [details]?

I'd like to be sure we have the same outcome with the right fonts on all devices, because the differences are puzzling me so far.

Pike, do you know if this would be a release blocker?

Comment 10

[Axel Hecht [:Pike]]

Attachment: censored screenshot

Here's what I see locally, edited-out my personal text messages on there.

Comment 11

[Julien Wajsberg [:julienw]]

Thanks, so it's the exact same font, so I can safely say the problem arises with the new font.

NI me to investigate further and find possible solutions.

Comment 12

[Julien Wajsberg [:julienw]]

Actually, we see that the "today" text is also cut off in the bottom.

Comment 13

[Julien Wajsberg [:julienw]]

I tried with both fonts and I see the same issue in both fonts. So maybe I'm not looking at the right place.

Marty, can you please put a screenshot of a case where this works appropriately?

Comment 14

[Julien Wajsberg [:julienw]]

I see the same on a Open C 1.3 upgraded to a v2.0 Gecko+Gaia (coming from a Flame build).

Comment 15

[Martin Shuman [:Marty]]

Attachment: Tamil_No_Cut-off.png

I do not see the cut-off issue in Flame 2.1, and have attached a screenshot.

Environmental Variables:
Device: Flame Master
Build ID: 20140729040211
Gaia: fadfafa17f5175203b8b9457bfb95e5816f54f58
Gecko: b17cad2d1e5e
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 16

[Jonathan Kew [:jfkthame]]

I'm not sure exactly which elements we're looking at here, but I suspect the issue is that the associated CSS is setting an explicit line-height that is only slightly larger than the element's font-size. I see plenty of such styling in https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/sms/style/sms.css, for example. This may lead to clipping (at least if overflow-y is set to 'hidden') for non-Latin fonts where ascenders and/or descenders may extend considerably further than is typical for Latin script.

Some of the CSS there (e.g. at [1]) even sets line-height equal to font-size, which is likely to lead to unwanted clipping even for Latin script when accented capital letters are present. With styles based on that fragment, I see clipping in a testcase like

data:text/html;charset=utf-8,<div style="font-family:Fira Sans OT;padding: 0 0 0.7rem;
  font-size:1.5rem;line-height:1.5rem;overflow:hidden">Fira S&%23x301;ans&%23x301;

So I suspect this is primarily an app styling issue: the designers have used overly rigid styling that is based on the dimensions of the English text, and other scripts simply don't fit in the same space.

[1] https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/sms/style/sms.css#L776

Comment 17

[அருண் குமார்-Arun Kumar]

Hi Team,

Please confirm us(l10n-ta), is this also reason for more truncations in fxOS V2.x than FxOS V1.3 ?

Since we are reducing the words in our translation(it looks funny) to reduce the truncation issues for fxOS V2.0 .

Comment 18

[Julien Wajsberg [:julienw]]

Martin> Thanks

Jonathan> Yep, I agree this is the likely cause. But I try to see where is the issue to fix it. It's also strange that it does not happen in other versions with the same font, since we did not change anything in this regard, so I want to understand this before doing anything else.

Kumar> I don't think this is the reason for more truncations.

I still want to know if this is a likely 2.0 blocker, or if a 2.1 timeframe is good enough.

Comment 19

[Julien Wajsberg [:julienw]]

Release Management: can you check with product to know if this makes a 2.0 blocker?

Comment 20

[Jonathan Kew [:jfkthame]]

(In reply to அருண் குமார்-Arun Kumar from comment #17)
> Hi Team,
> 
> Please confirm us(l10n-ta), is this also reason for more truncations in fxOS
> V2.x than FxOS V1.3 ?
> 
> Since we are reducing the words in our translation(it looks funny) to reduce
> the truncation issues for fxOS V2.0 .

Note that this is about clipping the bottom (or top) of the glyphs, which is a separate issue from truncation at the end of the text because of being too long horizontally. You may be able to fix that kind of truncation (text too long for the space provided) by modifying the translation to use shorter words and phrases.

(In reply to Julien Wajsberg [:julienw] from comment #18)

> Jonathan> Yep, I agree this is the likely cause. But I try to see where is
> the issue to fix it. It's also strange that it does not happen in other
> versions with the same font, since we did not change anything in this
> regard, so I want to understand this before doing anything else.

Comparing the screenshots from attachment 8451969 [details] (with clipping) and attachment 8464055 [details] (no clipping), it looks to me like there's a slight difference in line spacing: the latter screenshot has about 1px more space between the slanted "(no recipient)" text and the time/message text below it. That 1px probably corresponds to the difference between clipped and not-clipped. But I don't know exactly what styles are controlling this.

Oh, here's another thought: does the change here coincide with an update to the Fira Sans fonts? If the vertical metrics of *those* fonts have changed, that could explain slightly different vertical positioning of the text. Note that in the later screenshot (where the Tamil is not clipped at the bottom), the baseline of all text -- even the current time in the status bar at the very top -- seems to be shifted slightly higher. That could be affected by the metrics of the default font, I think.

Comment 21

[Martin Shuman [:Marty]]

Looks like julienw and jfkthame have answered this in comment #18 and comment #20.

Comment 22

[Jason Smith [:jsmith]]

Triage Question - What user impact is there in this bug to understandability of the Tamil language here?

Comment 23

[Jason Smith [:jsmith]]

Delphine - Is this a blocker for l10n?

Comment 24

[Joshua Mitchell (Inactive)]

It seems the screenshot from comment 15 satisfied the QA-Wanted tag in comment 13, removing tag

Comment 25

[Delphine Lebédel [:delphine - Use needinfo]]

This would be a blocker for Tamil if, because of the clipping, the text becomes completely unintelligible.
I doubt that, but we need the Tamil team to confirm that it is still understandable. Considering it's a shipping locale, if the sense is lost, it would then be a blocker.

Comment 26

[அருண் குமார்-Arun Kumar]

We can proceed, since attachment 8464055 [details] looks fine.

Arun Prakash, kindly put your words here.

Comment 27

[Jason Smith [:jsmith]]

Backlog per comment 26.

Comment 28

[Arun Prakash]

This is not a blocker. User can read the above text.

Comment 29

[Julien Wajsberg [:julienw]]

Given our issues with arabic fonts (UI vs non-UI flavors), could we have the same happening Tamil? Is there a flavor of a Tamil font that has the same size characteristics than usual latin fonts?

Comment 30

[Jonathan Kew [:jfkthame]]

(In reply to Julien Wajsberg [:julienw] from comment #29)
> Given our issues with arabic fonts (UI vs non-UI flavors), could we have the
> same happening Tamil? Is there a flavor of a Tamil font that has the same
> size characteristics than usual latin fonts?

We currently have Noto Sans Tamil in moztt. There is a Noto Sans Tamil UI variant that is designed to be vertically more compact, so it would probably help here.

Comment 31

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 32

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(