Font rendering does not look good in HVGA

RESOLVED INVALID

Status

Firefox OS
Gaia
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: GH to BZ, Assigned: patryk)

Tracking

unspecified

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [label:system][label:needsVISUALinput][LOE:S])

(Reporter)

Description

6 years ago
[GitHub issue by cgjones on 2012-06-26T12:40:23Z, https://github.com/mozilla-b2g/gaia/issues/1937]
This seems worse than it has been lately.  We have accidentally turned off hinting in Gecko.
(Reporter)

Comment 1

6 years ago
[GitHub comment by cgjones on 2012-06-26T12:48:39Z]
It looks like the font hinting code in gecko hasn't been touched recently.

Maybe we've switched to new fonts recently that don't have good hinting tables?
(Reporter)

Comment 2

6 years ago
[GitHub comment by timdream on 2012-06-28T17:49:51Z]
Is this resolved for demo phone. I don't think it is.
(Reporter)

Comment 3

6 years ago
[GitHub comment by autonome on 2012-07-19T15:21:16Z]
QA verification please.
(Reporter)

Comment 4

6 years ago
[GitHub comment by vingtetun on 2012-08-16T20:35:02Z]
@cgjones Is is still the case? Or can we close tis bug?
(Reporter)

Comment 5

6 years ago
[GitHub comment by cgjones on 2012-09-05T22:40:19Z]
I still see absolutely atrocious font rendering in some parts of the UI.  Here are two examples that particularly stand out
 - the text at the bottom of the "notification tray", "Wifi"/"Data"/etc.
 - the text in the "This application has crashed" notification

I talked to @timdream about the second case, and he says we're using the OpenSans Normal font for that text.  There's definitely not been any regression in Gecko related to font hinting.

I suspect we're just using a shitty font for low-res devices.  We need to either get a better-hinted version of OpenSans or find a different font.  There's nothing we can do for badly-hinted fonts on the platform side.

Reassigning.

CC @patrykdesign @jcarpenter
(Reporter)

Comment 6

6 years ago
[GitHub comment by jcarpenter on 2012-09-17T21:39:30Z]
> I suspect we're just using a shitty font for low-res devices. We need to either get a better-hinted version of OpenSans or find a different font. There's nothing we can do for badly-hinted fonts on the platform side.

I'll let @patrykdesign comment on this, but FWIW we do have a new font in the pipeline that will hopefully improve these issues.
(Reporter)

Comment 7

6 years ago
[GitHub comment by jcarpenter on 2012-09-17T21:42:37Z]
@patrykdesign I estimated LOE:S for this issue. Am not sure what (if any) work might be required. It is probably too late to swap in a different font (assuming there are even alternatives available), but I assumed you might do some rendering tests, etc. Up to you. Feel free to change LOE.
(Reporter)

Comment 8

6 years ago
[GitHub comment by timdream on 2012-09-18T05:38:56Z]
@cgjones I can verify the Open Sans TTF files we put into the machine is of the newest version can be found online.

I actually suspect that the TTF file comes with bitmap fonts in small sizes, but I am not sure get rid of them will make low-res Otoro look nicer or worse.

@jcarpenter The testing font in the repo (the UI Tests ones) right now doesn't look good either. Our vendor need to address that.
(Reporter)

Comment 9

6 years ago
[GitHub comment by cgjones on 2012-09-18T06:01:14Z]
We can just examine the fonts directly.  I don't have much experience with that, but ... @vingtetun sure does! :)
(Reporter)

Comment 10

6 years ago
[GitHub comment by patrykdesign on 2012-09-19T15:19:22Z]
@cgjones just want to make sure we're seeing the same thing... is this what you're seeing and calling poor rendering? http://cl.ly/image/2L2i2O1c3l1t or was it worse before? I am using 2012.09.18 build of the device.

@vingtetun @autonome @timdream @jcarpenter As we are testing the new font. This is what we've discovered... OpenType versions of the font render like crap... This is likely due to the limitations of our renderer (FreeType). TrueType versions of the font have much better anti aliasing and kerning. I suspect Open Sans on the device is OpenType. We're still evaluating what are the draw backs of using TrueType over OpenType... see a screenshot (on device) for quality comparisions. http://cl.ly/image/20050o0d1f30
(Reporter)

Comment 11

6 years ago
[GitHub comment by cgjones on 2012-09-19T18:18:44Z]
> @cgjones just want to make sure we're seeing the same thing... is this what you're seeing and calling poor rendering? http://cl.ly/image/2L2i2O1c3l1t or was it worse before? I am using 2012.09.18 build of the device.

That maybe looks better than before.

This is still not looking good: http://people.mozilla.com/~cjones/b2g-bugs/app-crashed-bad-text-rendering.png
(Reporter)

Comment 12

6 years ago
[GitHub comment by patrykdesign on 2012-09-19T21:18:16Z]
@cgjones I suspect that its because the font has an .otf extension and not .ttf. Once we switch to TrueType Fonts the kerning and anti alias will look good.
(Reporter)

Comment 13

6 years ago
[GitHub comment by jcarpenter on 2012-09-20T04:59:26Z]
@cgjones Any idea where OTF rendering problems seem to be coming from? Gecko? Graphics?
(Reporter)

Comment 14

6 years ago
[GitHub comment by cgjones on 2012-09-20T05:20:29Z]
OTF is just a wrapper format, and one of the formats it wraps is TTF.  But there were some very obviously badly hinted stems that lead me to believe we have a crappy font.  Gecko does just fine with well-hinted fonts in other contexts similar to this one.
(Reporter)

Comment 15

6 years ago
[GitHub comment by jcarpenter on 2012-09-20T05:39:46Z]
Maybe? This isn't just some random free font though. OpenSans is a credible, widely-used typeface among web designers. Mozilla has adopted it for all of our online needs. And it renders beautifully on my laptops and Mobile Safari. 

Maybe we need to play with our [Text-rendering](http://htmlcss.wikia.com/wiki/Text-rendering) values?
(Reporter)

Comment 16

6 years ago
[GitHub comment by cgjones on 2012-09-20T06:49:12Z]
All of the things you say could be true, and the font could also not be well-hinted for small screens.

Remember that apple commissioned a custom version of Helvetica specifically for the iphone.
(Assignee)

Comment 17

6 years ago
That is what we're doing here, we're getting a custom version of Meta (our brand font), modified for digital / mobile use. On top of that we're updating the glyphs to look more contemporary.
If we are shipping the pro(In reply to GH to BZ from comment #8)
> I actually suspect that the TTF file comes with bitmap fonts in small sizes,
> but I am not sure get rid of them will make low-res Otoro look nicer or
> worse.

Patryk, does our custom font contains Bitmap glyphs for small sizes? If not, have we explore the possibility with the vendor?
(Assignee)

Comment 19

6 years ago
> Patryk, does our custom font contains Bitmap glyphs for small sizes? If not,
> have we explore the possibility with the vendor?

We shouldn't need to use anytime smaller than 6 point, therefore no custom bitmaps needed for small sizes. Can you give me an example where we use bitmaps fonts?
Adding needs-info for Josh to help decide if this is still a blocker, and what priority it should have.
Flags: needinfo?(jcarpenter)
Is the new font a final version or WIP?

I'll say it if no else will --- the new font looks worse than the old font.

Comment 22

6 years ago
I am not sure whether I am seeing the same issue but on today's build the homescreen icon labels are bold and things look pretty ugly.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #21)
> Is the new font a final version or WIP?
> 
> I'll say it if no else will --- the new font looks worse than the old font.

Definitely WIP; there were no Bold face in the repo, but only Light, Medium, and Regular.

https://github.com/mozilla-b2g/moztt

This is what mainly contribute to what Andreas see on home screen. The "Bold" face currently is just the widen version of the Regular face.

(In reply to Patryk Adamczyk [:patryk] UX from comment #19)
> > Patryk, does our custom font contains Bitmap glyphs for small sizes? If not,
> > have we explore the possibility with the vendor?
> 
> We shouldn't need to use anytime smaller than 6 point, therefore no custom
> bitmaps needed for small sizes. Can you give me an example where we use
> bitmaps fonts?

https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/style/grid.css#L90

We are using 5pt at home screen icon labels. That should be corrected, but IMO at the miserable Otoro screen dpi we would need bitmap glyphs at the size of even numbers from 6pt to 12pt.
> We are using 5pt at home screen icon labels. That should be corrected, but IMO at 
> the miserable Otoro screen dpi we would need bitmap glyphs at the size of even 
> numbers from 6pt to 12pt.

I really don't think that bitmap glyphs are the answer. And obviously there's no way we're going to get them for v1. Also bear in mind that the "miserable" Otoro resolution is identical to what the iPhone had from version 1 to the 3GS, and they rendered their home grid text without bitmap glyphs.

As I said to our Friday triage meeting attendees, I think we need to wait until we see the new font on Unagi screens before we doing anything drastic.
Flags: needinfo?(jcarpenter)
(In reply to Josh Carpenter [:jcarpenter] from comment #25)
> > We are using 5pt at home screen icon labels. That should be corrected, but IMO at 
> > the miserable Otoro screen dpi we would need bitmap glyphs at the size of even 
> > numbers from 6pt to 12pt.
> 
> I really don't think that bitmap glyphs are the answer. And obviously
> there's no way we're going to get them for v1. Also bear in mind that the
> "miserable" Otoro resolution is identical to what the iPhone had from
> version 1 to the 3GS, and they rendered their home grid text without bitmap
> glyphs.
> 
> As I said to our Friday triage meeting attendees, I think we need to wait
> until we see the new font on Unagi screens before we doing anything drastic.

Make sense. I have jumped to conclusion to fast here. However the font size for home screen icon labels and the fact we don't have the bold face in the device should be fixed first.

P.S. The font does look superb on the lock screen clock.
(Assignee)

Comment 27

6 years ago
I loaded today's build and I finally see the new font. Here are some comments.

Homescreen: I see various labels having letters clipped... specifically "t" so something is wrong there. Also instead of BOLD use MEDIUM. 5pt should work there.

The status bar should set to at 6pt regular.
(Assignee)

Comment 28

6 years ago
The doesn't seem to be an issue with the new font "Moztt" you can see it renders well on the lock screen. Elsewhere in the system it seems to be getting stroked (looks too thick) but that's a separate issue that I am working on, once I figure out the right CSS, will submit a bug per app to fix it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
(Assignee)

Updated

6 years ago
Resolution: INVALID → FIXED
(Assignee)

Comment 29

6 years ago
Here is the homescreen bug which will get the fix first.
https://bugzilla.mozilla.org/show_bug.cgi?id=802797
(Assignee)

Updated

6 years ago
Resolution: FIXED → INVALID
(Assignee)

Updated

6 years ago
See Also: → bug 802797
The new font is being "synthetic bolded" (aka double-struck) on the homescreen and in many other places.  What's the bug for tracking fixing that?

I would personally rather back out the new font than show double-struck text to, e.g., my girlfriend :(.

Comment 31

6 years ago
Patryk, how much time do you think we'll need to fix the remaining font issues?
(Assignee)

Comment 32

6 years ago
We're using https://bugzilla.mozilla.org/show_bug.cgi?id=800322 to resolve this.
The issue is that we're having getting the system to detect the "bolder" weight which is medium. Trying to resolve this, this week.
Bug 804109 will give us true bold font.
Depends on: 804109
(Assignee)

Updated

6 years ago
See Also: → bug 804147
(Assignee)

Comment 34

6 years ago
I made a bug which should help tune the font rendering aka make it look better.
You need to log in before you can comment on or make changes to this bug.