Description: when adding a name to a contact after the letters L or W half of the o is missing because of kerning and spacing issues Repro Steps: 1) Update a Flame to 20141015001201 2) Create a new contact 3) in either name field type in the word lawbob Actual: o has kerning and spacing issues Expected: the o displays correctly Flame 2.1 Device: Flame 2.1 KK (319mb) (Full Flash) BuildID: 20141015001201 Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3 Gecko: 4853208cb48a Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency:100% See attached: logcat and screen shot

This issue occurs on Flame 2.2 KK (319mb) (Full Flash) half of the o is missing because of kerning Flame 2.2 KK (319mb) (Full Flash) Environmental Variables: Device: Flame Master KK (319mb) (Full Flash) Build ID: 20141015040201 Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6 Gecko: 62f0b771583c Version: 36.0a1 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 issue does NOT occur on 2.0 (319mb) (Full Flash) Flame 2.0 KK (319mb) (Full Flash) Environmental Variables: Device: Flame 2.0 KK (319mb) (Full Flash) Build ID: 20141015000206 Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00 Gecko: 24a2aa6bf1c4 Version: 32.0 (2.0) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Seems to be a minor graphical issue. Not nominating

I repro'd this issue in the message app too. On the attached screenshot, you can see that the "a" in "message", the "d" in "middle", and the "o" in "does" are affected.

I guess the issue is due to the font rendering in 2.1. Moving to graphics - text.

By the way, I'm not sure this is a regression as we changed the font to Fira in 2.1.

I don't think this is actually a font rendering issue; it looks to me like a problem with tiled painting. If you look at the glitches mentioned in comment 4 (in 'a', 'd', 'o', and 'o' on the four lines of the message), what's happening in each case is that a column of pixels has been lost, but not from the same place in the glyphs (at one edge or the other, as might be expected if it were related to kerning, for example); rather, the problems are all at exactly the same x-coordinate on the screen, regardless of where that happens to fall within the glyphs. Thus, of the two occurrences of 'o', for instance, the first has lost a column of pixels on the far right, making its right-hand side look too light and somewhat flattened (although the last bit of antialiasing is still present; meanwhile the 'o' on the next line has lost a column from the inside edge of its right-hand curve, making the internal hole look very straight-edged there. Similarly, the 'a' and 'd' above have each lost a column of pixels at the same position on the screen. My guess is that we're seeing a tile boundary here, and there's some kind of rounding/off-by-one issue causing a discontinuity in rendering. It should be possible to confirm this by tinkering with some of the tiled-rendering options, e.g. to show tile borders or to change the size of the tiles and see how this affects it. Moving to Graphics:Layers based on my guess above as to what's actually causing this.

Per bug 1147318.

Enabling "Draw tile borders" in Settings/Developer confirms that the graphical glitch here corresponds with a tile boundary. It looks like an off-by-one discrepancy between the content being painted in adjacent tiles. Updating the bug summary to more directly indicate the real issue here (as I understand it).

This sounds very similar to bug 1009306. Once I'm finally getting back to that one, I'll check whether it also fixes this bug. The fix is not going to make 2.2 in all likelyhood.

[Tracking Requested - why for this release]: When the dependent bug is fixed, this should be revisited