Closed Bug 951593 Opened 11 years ago Closed 10 years ago

Move icon font from gaia [BB] to moztt

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: arnau, Assigned: arnau)

References

Details

Attachments

(2 files, 4 obsolete files)

patch in github
271 bytes, text/html
mwu
: review+
Details
pull-request (master)
44 bytes, text/x-github-pull-request
mwu
: review+
Details | Review 
      No description provided.
Assignee: nobody → arnau
Comment on attachment 8349449 [details]
patch in github

jfkthame and I are valid reviewers for this repo.
Attachment #8349449 - Flags: review?(sjochimek)
This pull request adds a font but does not actually install it to the system image. You'll need to edit fonts.mk to make it work. Also, all our other fonts are versioned.
Attachment #8349449 - Flags: review?(mwu) → review+
CCing jfkthame in case he is interested in this off label use of fonts.
I'm not sure putting an application-specific icon font into the system fonts directory is a good idea. See bug 948856 comments 33 and 34 for more detail.
(In reply to Jonathan Kew (:jfkthame) from comment #5)
> I'm not sure putting an application-specific icon font into the system fonts
> directory is a good idea. See bug 948856 comments 33 and 34 for more detail.

https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 is showing some evidences that it is good for load time. This font will host icons for many different apps so it's more Gaia specific than app-specific.

It will also let people use our building blocks (I'm not saying this is a good thing) but have the icons updated without having to update the building blocks if we decide to change the icons.
Jonathan, after the :mwu review and Vivien's approval, I would like to land this and see what happens. We could always back it out if we decide going another way. WDYT?
Flags: needinfo?(jfkthame)
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6)
> (In reply to Jonathan Kew (:jfkthame) from comment #5)
> > I'm not sure putting an application-specific icon font into the system fonts
> > directory is a good idea. See bug 948856 comments 33 and 34 for more detail.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 is showing some
> evidences that it is good for load time. This font will host icons for many
> different apps so it's more Gaia specific than app-specific.

OK, so it belongs as part of Gaia. But not part of Gonk or Gecko.

> It will also let people use our building blocks (I'm not saying this is a
> good thing) but have the icons updated without having to update the building
> blocks if we decide to change the icons.

IMO, this is a strong reason we should try to *avoid* putting it in the system's fonts directory. If we make it available there, we're in effect adding a set of Private Use Area codepoints to the FirefoxOS platform, which means it's no longer fully standards-based. Having the icons available to other apps will tend to lead app developers to use them, and those apps will then NOT be fully compatible with the Web platform - they'll only appear as intended when this particular Private Use Area icon font is available.
(In reply to Arnau March from comment #7)
> Jonathan, after the :mwu review and Vivien's approval, I would like to land
> this and see what happens. We could always back it out if we decide going
> another way. WDYT?

See comment above: ISTM this violates our commitment to a standards-based platform, and will be damaging for the interoperability of apps between FirefoxOS and the rest of the Web.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #8)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6)
> > (In reply to Jonathan Kew (:jfkthame) from comment #5)
> 
> > It will also let people use our building blocks (I'm not saying this is a
> > good thing) but have the icons updated without having to update the building
> > blocks if we decide to change the icons.
> 
> IMO, this is a strong reason we should try to *avoid* putting it in the
> system's fonts directory. If we make it available there, we're in effect
> adding a set of Private Use Area codepoints to the FirefoxOS platform, which
> means it's no longer fully standards-based. Having the icons available to
> other apps will tend to lead app developers to use them, and those apps will
> then NOT be fully compatible with the Web platform - they'll only appear as
> intended when this particular Private Use Area icon font is available.

People can still take the open source font and use it in their app if they want no? The only difference is that instead of copy-pasting our icons everywhere, they will just copy the font in their app in order to works on other platforms. Not sure what will be broken ?
Putting the PUA icon font into /system/fonts has the effect of exposing private-use codepoints as part of the API that Firefox OS offers to the apps that run on it. That's something we should avoid. If an app wants to use PUA codepoints to render particular icons, it should be responsible for providing the appropriate font itself, because PUA codes are by definition not standardized except by private agreement between specific parties. That's counter to the spirit of the Web platform - unless you can get some W3C working group or similar to publish a standard for icon codes!

Sure, app developers who are aware of the issue could work around it by extracting that part of the Firefox OS platform and adding it to their app (with added code to load the font, etc, which wouldn't be needed on FxOS). But we'd in effect be creating an OS that has decided U+E000 is a speech balloon icon, U+E002 is an airplane icon, etc., which is NOT an interoperable part of the standards-based Web platform. This enables (and implicitly encourages) app developers to use these non-standard codes when they want to display certain icons, *without* requiring them to make sure they ship and use the appropriate font as part of their app. Such apps will not be interoperable with the standard Web.
(In reply to Jonathan Kew (:jfkthame) from comment #11)
> Putting the PUA icon font into /system/fonts has the effect of exposing
> private-use codepoints as part of the API that Firefox OS offers to the apps
> that run on it. That's something we should avoid. If an app wants to use PUA
> codepoints to render particular icons, it should be responsible for
> providing the appropriate font itself, because PUA codes are by definition
> not standardized except by private agreement between specific parties.
> That's counter to the spirit of the Web platform - unless you can get some
> W3C working group or similar to publish a standard for icon codes!
> 
> Sure, app developers who are aware of the issue could work around it by
> extracting that part of the Firefox OS platform and adding it to their app
> (with added code to load the font, etc, which wouldn't be needed on FxOS).
> But we'd in effect be creating an OS that has decided U+E000 is a speech
> balloon icon, U+E002 is an airplane icon, etc., which is NOT an
> interoperable part of the standards-based Web platform. This enables (and
> implicitly encourages) app developers to use these non-standard codes when
> they want to display certain icons, *without* requiring them to make sure
> they ship and use the appropriate font as part of their app. Such apps will
> not be interoperable with the standard Web.

Sorry, I'm not an expert in fonts, but could not happen that same thing with Fira Sans? I mean, they live in the same directory, and can be inspected the same way. If the issue is because of PUA, would it be better using Latin letters? And a last question, what if we have a SVG sprite instead of the icon font? Then we would only be using background-position to get an icon.
As Vivien said, we could provide the link to that SVG/icon font for 3rd party apps using icons in non Firefox OS environments, so they could add it to their apps same way they do now with building blocks.
Flags: needinfo?(jfkthame)
The situation with Fira Sans is quite different. This isn't about the particular -design- of the font (the shapes of the Fira letters, or the Gaia icons), but about the -semantics- of the character codes that an app is asking the platform to render. That is part of the API that the platform is making available to app developers.

Displaying text with Fira Sans (etc) is based on Unicode, so the meaning of each character code (U+0041 for "A", etc) is clearly defined in a public standard. If an app is run on a different implementation of the Web platform where different fonts are available, the glyphs will look a bit different but the semantics (and hence functionality) of the app is unaffected; the text will still clearly say the same thing. That's interoperability, and it's what standards are about.

But displaying icons with the Gaia icon font is dependent on *non-standard* private use codes, and if an app renders the same character codes on any other implementation of the Web platform, the result is undefined because there is no standard for what those codes mean.

It's fine for apps (either ours or third-party ones) to use icon fonts based on private-use codes *if* the necessary font is included as part of the app, and explicitly selected for displaying the relevant characters. Then the unstandardized (private) encoding is purely an implementation detail within the app. But if we put the Gaia Icons font into the core system fonts directory, we're exposing that non-standard encoding as part of the platform API; some apps will (deliberately or otherwise) end up using it ("oh, look, if I just put \uE031 into this element, I get the .... icon") and thus become FxOS-platform-dependent instead of purely Web-based, and will not work consistently across other Web environments. That negates what we're trying to do with FxOS, and (in a small way) starts us down the path of balkanizing the Web, just like the prevalence of -webkit-prefixed CSS that only works on iDevices.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #11)
> Putting the PUA icon font into /system/fonts has the effect of exposing
> private-use codepoints as part of the API that Firefox OS offers to the apps
> that run on it. That's something we should avoid. If an app wants to use PUA
> codepoints to render particular icons, it should be responsible for
> providing the appropriate font itself, because PUA codes are by definition
> not standardized except by private agreement between specific parties.
> That's counter to the spirit of the Web platform - unless you can get some
> W3C working group or similar to publish a standard for icon codes!
>

I doubt that even if we can get the Private Area standardize by the w3c, it will really mean anything for UTF-8.

I didn't realize that this patch use the private area. If this is the core issue, will it be OK if each icon use a meaningful utf-8 code (not sure this is doable) ?

I'm less worried by the specific settings icons than by the core widgets that are used across FirefoxOS, like the back button or the close button for example, and that are part of the building blocks.

I guess Arnau issue is slighty different and he would like a unified solution across all icons.
I assume that one way to still use icon fonts for other icons but make it load faster would be to :
 - not use the private area of an already big font
 - load it as a font and not as a base64 string
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #14)
> (In reply to Jonathan Kew (:jfkthame) from comment #11)
> > Putting the PUA icon font into /system/fonts has the effect of exposing
> > private-use codepoints as part of the API that Firefox OS offers to the apps
> > that run on it. That's something we should avoid. If an app wants to use PUA
> > codepoints to render particular icons, it should be responsible for
> > providing the appropriate font itself, because PUA codes are by definition
> > not standardized except by private agreement between specific parties.
> > That's counter to the spirit of the Web platform - unless you can get some
> > W3C working group or similar to publish a standard for icon codes!
> >
> 
> I doubt that even if we can get the Private Area standardize by the w3c, it
> will really mean anything for UTF-8.

Yes, I don't think this is really a feasible option; but as long as it's not standardized, I don't think we should be using ad hoc codes there in a public API, which is what happens if we put a font like this into the base system - any and every thing that displays text on FxOS would have access to these icons via *non-standard* codepoints.

> 
> I didn't realize that this patch use the private area. If this is the core
> issue, will it be OK if each icon use a meaningful utf-8 code (not sure this
> is doable) ?

For some of the icons, there are standard Unicode values (in the various Symbols, Dingbats, or Emoji blocks) that would be appropriate. Re-encoding the icons to standard Unicode positions would address the issue just fine; e.g. ✈ U+2708 AIRPLANE instead of  U+E002 as used in the current Gaia-icons. (That'll most likely show up as a hexbox here, but might be some other random symbol, depending on the fonts you happen to have.) Then apps that use them and are then used on a system with different fonts will still get the desired symbols; the exact designs might vary, but the semantics would remain correct.

However, I suspect that quite a few of the icons do not correspond to symbols currently encoded in Unicode, so we'd still need a solution for those.

> 
> I'm less worried by the specific settings icons than by the core widgets
> that are used across FirefoxOS, like the back button or the close button for
> example, and that are part of the building blocks.
> 
> I guess Arnau issue is slighty different and he would like a unified
> solution across all icons.
> I assume that one way to still use icon fonts for other icons but make it
> load faster would be to :
>  - not use the private area of an already big font

I'm not sure what you mean by this... the Gaia-icons font here isn't a big font, it contains only around 40 icons, nothing else.

>  - load it as a font and not as a base64 string

Perhaps; I don't know how loading performance compares between a data: URL embedded in the CSS or a separate font file.

Another thing I've wondered (see bug 948856 comment 36) - but I'm not sure if anyone has attempted to test yet - is whether we can make the Gaia apps that need the font load it earlier during startup. Normally, when a font is referenced via @font-face, we don't even begin to load it until we're reflowing a page and encounter some text that actually needs this font. But if we know at launch time that the Settings app, for example, is going to need the Gaia-icons font, perhaps we can trigger a font load earlier, so that by the time we're ready to render the app's first screen, the font may already be available.
(In reply to Jonathan Kew (:jfkthame) from comment #15) 
> > I guess Arnau issue is slighty different and he would like a unified
> > solution across all icons.
> > I assume that one way to still use icon fonts for other icons but make it
> > load faster would be to :
> >  - not use the private area of an already big font
> 
> I'm not sure what you mean by this... the Gaia-icons font here isn't a big
> font, it contains only around 40 icons, nothing else.
>

I asked to Arnau. I thought they used the default font we use all across FFOS and just moved some icons into the private area. But he confirmed me he didn't, which makes my previous statement meaningless.
 
> 
> Another thing I've wondered (see bug 948856 comment 36) - but I'm not sure
> if anyone has attempted to test yet - is whether we can make the Gaia apps
> that need the font load it earlier during startup. Normally, when a font is
> referenced via @font-face, we don't even begin to load it until we're
> reflowing a page and encounter some text that actually needs this font. But
> if we know at launch time that the Settings app, for example, is going to
> need the Gaia-icons font, perhaps we can trigger a font load earlier, so
> that by the time we're ready to render the app's first screen, the font may
> already be available.

I guess it will require some hacks to the manifest format. This will let us start to load the font in parallel while some other content is loading. Worth exploring.

Arnau, do you need help to explore the proposal here ?
Vivien, I would need help with that :)
Vivien, do you mean invent a manifest syntax to notify gecko to preload the font?

ex: 

"preload": [
     {'Gaia-icons.ttf':'application/octet-stream'}
]


With a more generic {'local file path':'MIME type'} syntax that can preload a limit number/size of sources based on memory will help. And we can support ttf MIME first than see if there's a need to expand the API to support other resources in the future.
(In reply to Fred Lin [:gasolin] from comment #18)
> Vivien, do you mean invent a manifest syntax to notify gecko to preload the
> font?
> 
> ex: 
> 
> "preload": [
>      {'Gaia-icons.ttf':'application/octet-stream'}
> ]
> 

Yes. But maybe instead of 'preload' something like 'resources'.

> With a more generic {'local file path':'MIME type'} syntax that can preload
> a limit number/size of sources based on memory will help. And we can support
> ttf MIME first than see if there's a need to expand the API to support other
> resources in the future.

I will like to prototype something like this to see if it can help load time by parallelizing some loads. And yes, at first it would be nice to try with font. Do you have any spare time to help here ?
'resources' is also in my first thought, but I find it does not provide a meaningful hint for webapp developer.

I'd like to try if its not urgent and you can mentor me :)
Since I've not tried gecko side patch yet, it might take extra time.
(In reply to Fred Lin [:gasolin] from comment #20)
> 'resources' is also in my first thought, but I find it does not provide a
> meaningful hint for webapp developer.
> 
> I'd like to try if its not urgent and you can mentor me :)
> Since I've not tried gecko side patch yet, it might take extra time.

Don't hesitate to ping me on IRC. I'm more than happy to find someone to help here!
Could we use <link rel=prefetch href=gaia-icons.ttf> in the application?
Will try that in my patch an see what happens :)
I think that adding the font to the system is not a good idea. Mainly because it will be hard to maintain it in the long run: 
 - you need to land a patch to the system before you are able to work on the visual updates.
 - conflicts with other developers that used same codepoints for different icons. (multiple apps doing a visual refresh at same time + conflicting pull requests)
 - if font is tied to the system it will make it harder for a front-end dev to test and manipulate it. (I never built b2g for instance)
 - each app might need a different pixel grid for the fonts (eg. if icons on system app uses a 48x48px grid, the calendar app uses 32x32, icons wont look sharp and will be harder to align).

But what we really need to consider is what was said on comment #11 ("counter to the spirit of the Web platform").

Dingbats are a terrible idea! Icon fonts should use private use areas (PUA). PUA are not read by screen readers; seeing a standard letter when the font is not loaded, makes no sense, it also encourages bad practices.

We need to find a way to not have too much performance hit while still keeping a sane development workflow.
(In reply to Anthony Ricaud (:rik) from comment #22)
> Could we use <link rel=prefetch href=gaia-icons.ttf> in the application?

I've tested this and performance is still the same :(
I don't know anything about <link rel=prefetch...>, but I think to get a benefit from "pre-loading" the font, you'd need to do something that causes us to actually instantiate the downloaded font via @font-face, so that it gets into our in-process userfont cache. Just fetching the resource won't make much difference, if any - it's already a local file, after all.

So perhaps something like creating an element containing some text styled with the same @font-face you're going to be using in the real content, and forcing it to be measured or painted (somewhere invisible) so as to trigger reflow, font selection, and hence @font-face instantiation.

(Untested, but I hope you get the general idea...)
(In reply to Miller Medeiros [:millermedeiros] from comment #24)
> I think that adding the font to the system is not a good idea. Mainly
> because it will be hard to maintain it in the long run: 
>  - you need to land a patch to the system before you are able to work on the
> visual updates.

That's ok. We can modify a little bit the process so the font can live into Gaia and can be flashed on the device from here.

>  - conflicts with other developers that used same codepoints for different
> icons. (multiple apps doing a visual refresh at same time + conflicting pull
> requests)

I don't think app owners have to maintain this font. It belongs to the UI team. They should edit the font themselves and so there should be no conflicts.

>  - if font is tied to the system it will make it harder for a front-end dev
> to test and manipulate it. (I never built b2g for instance)

Again that's an easy to solve issue. As a front-end developer you can load the font directly with font-face or we can add it into the thing we are building, called the Mulet (see bug 943878), so it will be used by default.

Not having this font uses by default is an issue, as it makes some of the integration tests unreliable when they run on Travis versus when they run locally.


>  - each app might need a different pixel grid for the fonts (eg. if icons on
> system app uses a 48x48px grid, the calendar app uses 32x32, icons wont look
> sharp and will be harder to align).
>

I have been told that icon font can scale easily.
 

Jonathan, with Jonas comment (https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c46) that basically state that we can use a system font limited to certified app, can we proceed to land a specific system font, and open a followup to limit it to certified app only ? (I have no idea how to do that, any suggestions ?)
Flags: needinfo?(jfkthame)
I'd like to be sure that we at least have a reasonable idea of how we're going to limit it, before we move forward. Does Gecko have some way of knowing whether or not it is running a certified app? Might the same Gecko process run both certified and non-certified apps, or can we be sure that any given process only handles one or the other?
Flags: needinfo?(jfkthame)
Vivien, could we have someone helping test what Jonas suggested? 
We really need to push vector icons in gaia.
Flags: needinfo?(21)
(In reply to Jonathan Kew (:jfkthame) from comment #28)
> I'd like to be sure that we at least have a reasonable idea of how we're
> going to limit it, before we move forward. Does Gecko have some way of
> knowing whether or not it is running a certified app? Might the same Gecko
> process run both certified and non-certified apps, or can we be sure that
> any given process only handles one or the other?

Processes are of one type. The list of types can be seen here: http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsIPrincipal.idl#171 and the current type can be retrieved from the principal.

That said and you should know much better than me, I wonder if the big performance gain described in https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 does not come from the font beeing loaded into the preallocated process.

The preallocated process does not yet have a type until an application is loaded inside it. If the performance gain comes from here, could we keep the load of the font into the preallocated process, but prevent non-certified app to load the font resources ?

Maybe the performance gain comes from somewhere else, i'm not sure.
(In reply to Arnau March  [:arnau] from comment #29)
> Vivien, could we have someone helping test what Jonas suggested? 
> We really need to push vector icons in gaia.

It's not clear exactly which types of helps you need ?

Having this font available only to certified app should be pretty transparent to you.

IMHO the easier way to test / develop font icons would be to move the font into $GAIA/shared/fonts and beeing able to flash it to /system/font/ on the device instead of having to PR the moztt repo everytime.

It also makes more sense in the sense that those icons are related to Gaia.

Just want to double check with Michael Wu that this is something we may want to do ?
Flags: needinfo?(21) → needinfo?(mwu)
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #30)
> (In reply to Jonathan Kew (:jfkthame) from comment #28)
> > I'd like to be sure that we at least have a reasonable idea of how we're
> > going to limit it, before we move forward. Does Gecko have some way of
> > knowing whether or not it is running a certified app? Might the same Gecko
> > process run both certified and non-certified apps, or can we be sure that
> > any given process only handles one or the other?
> 
> Processes are of one type. The list of types can be seen here:
> http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsIPrincipal.idl#171
> and the current type can be retrieved from the principal.
> 
> That said and you should know much better than me, I wonder if the big
> performance gain described in
> https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 does not come from
> the font beeing loaded into the preallocated process.

Yes, I'm pretty sure the gain there is because the font was already loaded into the system font list during platform initialization (instead of being loaded from the filesystem during initial reflow of the app screen that wants to use it, as happens with @font-face resources).

> The preallocated process does not yet have a type until an application is
> loaded inside it. If the performance gain comes from here, could we keep the
> load of the font into the preallocated process, but prevent non-certified
> app to load the font resources ?

Hmm. That's a bit messy. Currently, all fonts from /system/fonts are loaded into the platform font list, and so become globally available. If we knew at process launch time whether we're going to be running certified apps or not, we could include or exclude the icon font from the font list at that time, and there'd be no further impact. But if we don't know until later, we'll need to maintain two font lists, or a flag on each font in the list to record whether it's a certified-only font or a universal one, and then check that later.

ISTM that what you probably want is for us to support a second location for fonts, besides /system/fonts (maybe /system/private-fonts/, or a subdirectory like /system/fonts/private/, or something...). Then we could make the FT2FontList code scan both directories at startup, but ignore the "private" fonts when we're running non-certified apps. Does that sound reasonable?
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #27)
> (In reply to Miller Medeiros [:millermedeiros] from comment #24)
> >  - conflicts with other developers that used same codepoints for different
> > icons. (multiple apps doing a visual refresh at same time + conflicting pull
> > requests)
>
> I don't think app owners have to maintain this font. It belongs to the UI team. They should edit the font themselves and so there should be no conflicts.

just need to be sure they don't replace existing code points unless they are sure the changes should affect all the apps that might be using the font. Imagine the case where calendar app started a visual refresh a month before the settings app, during this period calendar needs the new icons but if I replace all the icons I'm also going to affect the settings (which is still not ready for the changes).

not saying that it can't be done, just saying that it comes with limitations... whoever updates the font needs to be fully aware of what he is doing. - never overwrite old icons, only remove unused icons after all apps complete the visual refresh.

it can also be considered as a benefit, since you don't need to update icons in multiple places (specially for building blocks).

> >  - each app might need a different pixel grid for the fonts (eg. if icons on
> > system app uses a 48x48px grid, the calendar app uses 32x32, icons wont look
> > sharp and will be harder to align).
> >
> 
> I have been told that icon font can scale easily.
>  

I think you misunderstood my comment. I'm talking about [Pixel Hinting](http://en.wikipedia.org/wiki/Font_hinting). If icon is designed to fit a different grid size, it might not look sharp at different scales; so we might actually need to create more than 1 font, or change the icons so they always fit same grid and still look sharp at the size they need to be used.
(In reply to Jonathan Kew (:jfkthame) from comment #32)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #30)
> > (In reply to Jonathan Kew (:jfkthame) from comment #28)
> > > I'd like to be sure that we at least have a reasonable idea of how we're
> > > going to limit it, before we move forward. Does Gecko have some way of
> > > knowing whether or not it is running a certified app? Might the same Gecko
> > > process run both certified and non-certified apps, or can we be sure that
> > > any given process only handles one or the other?
> > 
> > Processes are of one type. The list of types can be seen here:
> > http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsIPrincipal.idl#171
> > and the current type can be retrieved from the principal.
> > 
> > That said and you should know much better than me, I wonder if the big
> > performance gain described in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 does not come from
> > the font beeing loaded into the preallocated process.
> 
> Yes, I'm pretty sure the gain there is because the font was already loaded
> into the system font list during platform initialization (instead of being
> loaded from the filesystem during initial reflow of the app screen that
> wants to use it, as happens with @font-face resources).
> 
> > The preallocated process does not yet have a type until an application is
> > loaded inside it. If the performance gain comes from here, could we keep the
> > load of the font into the preallocated process, but prevent non-certified
> > app to load the font resources ?
> 
> Hmm. That's a bit messy. Currently, all fonts from /system/fonts are loaded
> into the platform font list, and so become globally available. If we knew at
> process launch time whether we're going to be running certified apps or not,
> we could include or exclude the icon font from the font list at that time,
> and there'd be no further impact. But if we don't know until later, we'll
> need to maintain two font lists, or a flag on each font in the list to
> record whether it's a certified-only font or a universal one, and then check
> that later.
> 

Sadly there is no way to know what's going to be loaded into the preallocated process until the user decide what to pick.

> ISTM that what you probably want is for us to support a second location for
> fonts, besides /system/fonts (maybe /system/private-fonts/, or a
> subdirectory like /system/fonts/private/, or something...). Then we could
> make the FT2FontList code scan both directories at startup, but ignore the
> "private" fonts when we're running non-certified apps. Does that sound
> reasonable?

That sounds reasonable to me.
(In reply to Jonathan Kew (:jfkthame) from comment #32)
> ISTM that what you probably want is for us to support a second location for
> fonts, besides /system/fonts (maybe /system/private-fonts/, or a
> subdirectory like /system/fonts/private/, or something...). Then we could
> make the FT2FontList code scan both directories at startup, but ignore the
> "private" fonts when we're running non-certified apps. Does that sound
> reasonable?

Not sure this is the right place to ask, but I'm looking for something similar to support Firefox OS fonts on desktop environments (Simulators and B2G Desktop). Making firefox ask for the desired fonts is relatively easy (by changing font prefs and LookAndFeel methods), but actually having the fonts available is tricky, since we can't install them on most hosts. Having a way to specify a second location for system fonts would help, because that way we could store the fxos fonts in a Gaia (or Gecko) profile and tell firefox to use them. Would that make sense? Do you see other ways to address this problem?

For reference, I'm talking about bug #992210, and my current plan is to tweak Gaia's build system to enable the installation of fonts inside a profile. Then I'd need a way to tell firefox how to find them, either by specifying a second location for system fonts, or maybe with a CSS file using @font-face to register them through resource urls.
Flags: needinfo?(jfkthame)
(In reply to Jan Keromnes [:janx] from comment #35)
> (In reply to Jonathan Kew (:jfkthame) from comment #32)
> > ISTM that what you probably want is for us to support a second location for
> > fonts, besides /system/fonts (maybe /system/private-fonts/, or a
> > subdirectory like /system/fonts/private/, or something...). Then we could
> > make the FT2FontList code scan both directories at startup, but ignore the
> > "private" fonts when we're running non-certified apps. Does that sound
> > reasonable?
> 
> Not sure this is the right place to ask, but I'm looking for something
> similar to support Firefox OS fonts on desktop environments (Simulators and
> B2G Desktop). Making firefox ask for the desired fonts is relatively easy
> (by changing font prefs and LookAndFeel methods), but actually having the
> fonts available is tricky, since we can't install them on most hosts. Having
> a way to specify a second location for system fonts would help, because that
> way we could store the fxos fonts in a Gaia (or Gecko) profile and tell
> firefox to use them. Would that make sense? Do you see other ways to address
> this problem?

In desktop environments, implementing a "second location for system fonts" sounds tricky, because we don't manage fonts directly by enumerating files in a directory, nor access them via file APIs; our font management is built on the operating system's font APIs.

> 
> For reference, I'm talking about bug #992210, and my current plan is to
> tweak Gaia's build system to enable the installation of fonts inside a
> profile. Then I'd need a way to tell firefox how to find them, either by
> specifying a second location for system fonts, or maybe with a CSS file
> using @font-face to register them through resource urls.

Given that (AIUI) this is for development/testing use, rather than a feature we actually need to ship to end users, I would be reluctant to tamper with our integration with OS-level font management in order to slip in an extra set of "system" fonts. I think it'd be better to handle this by loading them via @font-face in a standard piece of CSS that the simulator or B2G Desktop would load. There'll be some perf cost to this, I guess, but for the use-cases I see here, that doesn't seem too critical.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #36)
> (In reply to Jan Keromnes [:janx] from comment #35)
> > For reference, I'm talking about bug #992210, and my current plan is to
> > tweak Gaia's build system to enable the installation of fonts inside a
> > profile. Then I'd need a way to tell firefox how to find them, either by
> > specifying a second location for system fonts, or maybe with a CSS file
> > using @font-face to register them through resource urls.
> 
> Given that (AIUI) this is for development/testing use, rather than a feature
> we actually need to ship to end users, I would be reluctant to tamper with
> our integration with OS-level font management in order to slip in an extra
> set of "system" fonts. I think it'd be better to handle this by loading them
> via @font-face in a standard piece of CSS that the simulator or B2G Desktop
> would load. There'll be some perf cost to this, I guess, but for the
> use-cases I see here, that doesn't seem too critical.

I certainly agree that @font-face is better suited to this problem, since there is no extra maintenance cost like there would be with adding some new system font resolution path.

However, I tested @font-face ~6 months ago for this purpose and found it did not work for at least the following reasons:

* Nearly all of Gaia does not specify an "actual" font family, but instead just uses "sans-serif", etc. and it did not seem like @font-face could replace those system font family definitions
* @font-face fonts take some time to load, and so may not be available for all purposes
  * Specifically (at the time, at least) Everything.me render its app folders by writing text to a canvas, and the @font-face fonts were not loaded fast enough to be used in this manner, at least not without changing the E.me code as well

If we can overcome these issues, then perhaps it will indeed work, and I would be happy if we could make it happen.  But previous testing suggests to me that it may not work out for our needs here.
(In reply to J. Ryan Stinnett [:jryans] from comment #37)
> * Nearly all of Gaia does not specify an "actual" font family, but instead
> just uses "sans-serif", etc. and it did not seem like @font-face could
> replace those system font family definitions

This is by design. We do not specify font family for i18n reason.
Gecko gets to decide what the font should use based on document language.

That said, if you want to control what maps to generic font names, you should simply overwrite Gecko pref ("font.name.*" and "font.name-list.*"). Just don't mess up the Gecko behavior the rest of the web expects.

(Will we ended up creating "font-certified-app.name.*" pref?)
See Also: → 972871
Thanks for your reply Tim! Let's continue the discussion in bug 992210 as this is getting off-topic.
Attached patch read.system.fonts.private.patch (obsolete) — — Splinter Review 
Jonathan, are you looking for something like that ?

This patch loads the private/ fonts for the preallocated processes, but prevent non-certified content to use it.

There are 2 things that makes me sad about this patch for now, and I'm not sure how to make it better:
 - The privateFont flag is vehiculated into many code paths. It would have been cool to not have to forward it this way.
   This flag comes from the layout/ code path, since it needs to get the principal of the document, which seems very far from the font subsystem.

 - The check for the app status of the app into nsLayoutUtils.cpp looks overkill. I assume that this method is killed quite a few times. Any suggestion to move this code or to make it lighter ?

The patch could also not be the right way at all to handle that. That's the first time I look at the gfx/thebes folder and I may have missed tons on things!
Attachment #8416393 - Flags: feedback?(jfkthame)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #40)
> Created attachment 8416393 [details] [diff] [review]
> read.system.fonts.private.patch
> 
> Jonathan, are you looking for something like that ?
> 
> This patch loads the private/ fonts for the preallocated processes, but
> prevent non-certified content to use it.
> 
> There are 2 things that makes me sad about this patch for now, and I'm not
> sure how to make it better:
>  - The privateFont flag is vehiculated into many code paths. It would have
> been cool to not have to forward it this way.
>    This flag comes from the layout/ code path, since it needs to get the
> principal of the document, which seems very far from the font subsystem.
> 
>  - The check for the app status of the app into nsLayoutUtils.cpp looks
> overkill. I assume that this method is killed quite a few times. Any
> suggestion to move this code or to make it lighter ?

Is it true that any given Gecko process is only running one kind of code - certified or not - at a time? If so, could we check this once when the app is launched, and set a global flag somewhere like gfxAndroidPlatform? This could then be directly checked by the font-list code during font lookup, without having to pass it all the way down from layout through nsDeviceContext, nsFontMetrics, etc, on every call.

> The patch could also not be the right way at all to handle that. That's the
> first time I look at the gfx/thebes folder and I may have missed tons on
> things!

The general idea here seems OK, but there are a few things that I think might work better if you take a slightly different approach. Suggestions:

(1) I know I suggested something like /system/fonts/private/ above, but on second thoughts, I'm a little uneasy about that. I can imagine some Android vendors (many of whom like to mess with the contents of /system/fonts/ in unexpected ways!) might have the same bright idea and put weird things in there, which Firefox on Android will find confusing.

Let's either make the code to scan that directory platform-specific (#ifdef MOZ_WIDGET_GONK), so we only look there on B2G, or use a directory that's not likely to appear on non-B2G devices (e.g. /system/b2g/private-fonts/). WDYT?

(2) I'd prefer to avoid adding the mIsPrivate flag to gfxFontFamily, given that we're not intending to support "private" fonts like this across all platforms.

An alternative suggestion: give gfxFT2FontList a second array of font families (mPrivateFamilies) in addition to the standard mFontFamilies member. Make FindFonts() populate mFontFamilies and mPrivateFamilies with the fonts found in the respective directories, so the public and private fonts will be kept in two separate lists.

Then you can give gfxFT2FontList an override of FindFamily() to first call gfxPlatformFontList::FindFamily, and then if that returns null and private fonts are allowed, check the mPrivateFamilies list.

Does that sound feasible to you?
Comment on attachment 8416393 [details] [diff] [review]
read.system.fonts.private.patch

Clearing feedback? for now; :21, see above for some thoughts on how this could go forward.
Attachment #8416393 - Flags: feedback?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #41)
> (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails,
> needinfo? please) from comment #40)
> > Created attachment 8416393 [details] [diff] [review]
> > read.system.fonts.private.patch
> > 
> > Jonathan, are you looking for something like that ?
> > 
> > This patch loads the private/ fonts for the preallocated processes, but
> > prevent non-certified content to use it.
> > 
> > There are 2 things that makes me sad about this patch for now, and I'm not
> > sure how to make it better:
> >  - The privateFont flag is vehiculated into many code paths. It would have
> > been cool to not have to forward it this way.
> >    This flag comes from the layout/ code path, since it needs to get the
> > principal of the document, which seems very far from the font subsystem.
> > 
> >  - The check for the app status of the app into nsLayoutUtils.cpp looks
> > overkill. I assume that this method is killed quite a few times. Any
> > suggestion to move this code or to make it lighter ?
> 
> Is it true that any given Gecko process is only running one kind of code -
> certified or not - at a time? If so, could we check this once when the app
> is launched, and set a global flag somewhere like gfxAndroidPlatform? This
> could then be directly checked by the font-list code during font lookup,
> without having to pass it all the way down from layout through
> nsDeviceContext, nsFontMetrics, etc, on every call.

I think I explained it in a poor way last time :/

So basically a process is of one type, determined by the level of privileges of the app. It can be hosted, privileged or certified. This type is fixed and won't change over time.

But an app of any type, can load arbitrary content into <iframe> or via call to window.open. And so it makes it tricky to mark the related platform code with a flag.
Attached patch read.system.fonts.private.patch (obsolete) — — Splinter Review 
This patch use 2 separate lists, but because of what I explained in the previous comment it makes it tricky to get rid of all aIsPrivate flag. So I add to keep it onto gfxFontGroup and add a to overidde a bit more methods than expected :/

Jonathan, what do you think ?

Also, do you have some free cycles to take over the patch ? I keep beeing distracted by some other subjects than fonts, but our UI team wants this for 2.0.
Attachment #8417288 - Flags: feedback?(jfkthame)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #43)
> So basically a process is of one type, determined by the level of privileges
> of the app. It can be hosted, privileged or certified. This type is fixed
> and won't change over time.
> 
> But an app of any type, can load arbitrary content into <iframe> or via call
> to window.open. And so it makes it tricky to mark the related platform code
> with a flag.

Thanks, I think I understand better now.

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #44)
> Created attachment 8417288 [details] [diff] [review]
> read.system.fonts.private.patch
> 
> This patch use 2 separate lists, but because of what I explained in the
> previous comment it makes it tricky to get rid of all aIsPrivate flag. So I
> add to keep it onto gfxFontGroup and add a to overidde a bit more methods
> than expected :/
> 
> Jonathan, what do you think ?
> 
> Also, do you have some free cycles to take over the patch ? I keep beeing
> distracted by some other subjects than fonts, but our UI team wants this for
> 2.0.

OK, I'll try to polish this up a bit further. At least one remaining issue is that I think the nsFontCache (in nsDeviceContext) needs to check the private-font flag, otherwise it may return a cached fontgroup with the wrong setting.

Also, what do you think about changing from /system/fonts/private/ to something more B2G-specific such as /system/B2G/private-fonts/ (see para (1) in comment 41)?
Flags: needinfo?(21)
(In reply to Jonathan Kew (:jfkthame) from comment #45)
> (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails,
> needinfo? please) from comment #44)
> > Created attachment 8417288 [details] [diff] [review]
> > read.system.fonts.private.patch
> > 
> > This patch use 2 separate lists, but because of what I explained in the
> > previous comment it makes it tricky to get rid of all aIsPrivate flag. So I
> > add to keep it onto gfxFontGroup and add a to overidde a bit more methods
> > than expected :/
> > 
> > Jonathan, what do you think ?
> > 
> > Also, do you have some free cycles to take over the patch ? I keep beeing
> > distracted by some other subjects than fonts, but our UI team wants this for
> > 2.0.
> 
> OK, I'll try to polish this up a bit further. At least one remaining issue
> is that I think the nsFontCache (in nsDeviceContext) needs to check the
> private-font flag, otherwise it may return a cached fontgroup with the wrong
> setting.

Thanks!

> 
> Also, what do you think about changing from /system/fonts/private/ to
> something more B2G-specific such as /system/B2G/private-fonts/ (see para (1)
> in comment 41)?

I used #ifdef MOZ_WIDGET_GONK in this patch but I have no strong opinion on any solution, so whatever you prefer.

But at first I would have preferred to load the fonts into %PROFILE/fonts/private in order to avoid collision and to make it clearer that this font is Gaia specific. But content processes can not access this folder directly.

It's not clear to me if the platform support for font will just workaround this if the font has already been opened and loaded by Freetype in the master process ?
Flags: needinfo?(21)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #46)
> But at first I would have preferred to load the fonts into
> %PROFILE/fonts/private in order to avoid collision and to make it clearer
> that this font is Gaia specific. But content processes can not access this
> folder directly.
> 
> It's not clear to me if the platform support for font will just workaround
> this if the font has already been opened and loaded by Freetype in the
> master process ?

Apparently not. I experimented with a version of this patch that looks for fonts in %PROFILE/fonts/private, and tried to use such a "private" font within the Settings app. Although the font was found in the font list (because that list had been created by the master chrome process), freetype wasn't able to use it, so the content fell back to the next in my font-family list.

(The same font installed in /system/fonts worked fine.)

The reason it fails when installed within the profile is filesystem permissions. The profile directory is located at

  /data/b2g/mozilla/XXXXXXX.default/

(where XXXXXXX is a random string), and at least on my device, I found that the directories from b2g downwards all had permissions

  drwx------ root     root              2014-05-06 14:13 b2g

i.e. owned by root, and not accessible to other users. This prevents the content process, which doesn't run as root, accessing the font files found in the profile, even though it knows the correct path.

To confirm that it's the filesystem permissions that are the stumbling block here, I changed the b2g directory and its subdirs to be

  drwxr-xr-x root     root              2014-05-06 14:13 b2g

so that all users can access them, and restarted the Settings app; immediately, my "private" font showed up correctly.

It was *not* sufficient to relax the permissions on the actual %PROFILE/fonts/private directory in order to make the font accessible; I had to go all the way up the tree.

I assume we do not actually want to relax permissions on the data/b2g tree, so we should go with the option of installing "private" fonts in /system/fonts/private (or how about /system/fonts/certified-apps?) instead of under %PROFILE.
Needinfo'ing fabrice and pauljt has they may know better than me about the restrictions on the profile folder.
Flags: needinfo?(ptheriault)
Flags: needinfo?(fabrice)
The profile folder permissions are "drwx------ root     root', so it's only accessible to the parent process. We are very unlikely to change that.

Also, remember that this directory is removed when we do a factory reset and does not exists when we flash the phone.
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #49)
> The profile folder permissions are "drwx------ root     root', so it's only
> accessible to the parent process. We are very unlikely to change that.
> 
> Also, remember that this directory is removed when we do a factory reset and
> does not exists when we flash the phone.

Thanks for the info. So /system/fonts/certified-apps sounds OK then.
Here's an updated version of the patch that appears to work OK in my initial testing, at least. Vivien, if you could try this and see if it provides the behavior you need, that'd be great - thanks. Private fonts should be placed into /system/fonts/certified-apps/ for this patch to find them.
Assignee: arnau → jfkthame
Status: NEW → ASSIGNED
Attachment #8418912 - Flags: feedback?(21)
Attachment #8417288 - Flags: feedback?(jfkthame)
Fixed up a couple further issues: build bustage on Windows, and failure for private fonts to work properly with text-transform or small-caps styling.
Attachment #8418912 - Attachment is obsolete: true
Attachment #8418912 - Flags: feedback?(21)
Attachment #8419305 - Flags: feedback?(21)
Comment on attachment 8419305 [details] [diff] [review]
support "private" fonts that are available only to certified apps on b2g

Review of attachment 8419305 [details] [diff] [review]:
-----------------------------------------------------------------

I'm pretty sure that the patch will do what we need. So f+.

I would like Arnau to confirm that everything is OK for him.

Arnau, can you try the revive your icon fonts patch for settings in bug 948856 by putting the icon fonts into /system/fonts/certified-apps/ and check that it does what you are looking for ?

If you need any help to set up anything, don't hesitate to ping me on IRC.
Attachment #8419305 - Flags: feedback?(arnau)
Attachment #8419305 - Flags: feedback?(21)
Attachment #8419305 - Flags: feedback+
I think fabrice already answered the directory question (thanks!)
Flags: needinfo?(ptheriault)
Comment on attachment 8419305 [details] [diff] [review]
support "private" fonts that are available only to certified apps on b2g

Review of attachment 8419305 [details] [diff] [review]:
-----------------------------------------------------------------

I have not tested the patch, but f+ after talking to Vivien on IRC
Attachment #8419305 - Flags: feedback?(arnau) → feedback+
Depends on: 1008458
I think we should spin off the Gecko platform work here to a separate bug, so we can track that separately from the management of the Firefox OS font resources in Gaia and moztt. Things can easily get confusing when we try to track both Gecko mercurial patches and github pull requests in the same bug.

So I've filed bug 1008458, and will post the Gecko patch there for review. Once that's reviewed and landed, we can return here and deal with installing the icon font.
(In reply to Jonathan Kew (:jfkthame) from comment #11)
> Putting the PUA icon font into /system/fonts has the effect of exposing
> private-use codepoints as part of the API that Firefox OS offers to the apps
> that run on it. That's something we should avoid. If an app wants to use PUA
> codepoints to render particular icons, it should be responsible for
> providing the appropriate font itself, because PUA codes are by definition
> not standardized except by private agreement between specific parties.
> That's counter to the spirit of the Web platform - unless you can get some
> W3C working group or similar to publish a standard for icon codes!
> 
> Sure, app developers who are aware of the issue could work around it by
> extracting that part of the Firefox OS platform and adding it to their app
> (with added code to load the font, etc, which wouldn't be needed on FxOS).
> But we'd in effect be creating an OS that has decided U+E000 is a speech
> balloon icon, U+E002 is an airplane icon, etc., which is NOT an
> interoperable part of the standards-based Web platform.

It seems to me we should not be performing system font fallback for PUA characters.

If we fixed that, then we could just add the Gaia-icons font to FirefoxOS like any other font and apps would not use it unless they explicitly specified Gaia-icons in font-family. If they do that, it's just like specifying a platform-specific font on any other platform.

Am I missing something? :-)
Flags: needinfo?(jfkthame)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #57)

> It seems to me we should not be performing system font fallback for PUA
> characters.

We don't, I believe.

> If we fixed that, then we could just add the Gaia-icons font to FirefoxOS
> like any other font and apps would not use it unless they explicitly
> specified Gaia-icons in font-family. If they do that, it's just like
> specifying a platform-specific font on any other platform.

No, it's not the same. There's a crucial difference between specifying a platform-specific font for standard Unicode text:

(1)  <span style="font-family: Nirmala">&#x0950;</span>

and specifying a platform-specific font for PUA characters:

(2)  <span style="font-family: Gaia-icons">&#xe123;</span>

In the former case, because the character code is standardized, the browser can use font fallback to ensure that the text is still rendered with a valid, readable glyph that has the intended meaning, even if the platform-specific font that the author specified isn't available. The user will still see the text "ॐ", even if fallback results in a slightly different glyph design.

But in the latter case, if the exact font specified isn't available, the browser has no chance of rendering anything useful; whatever meaning was supposed to be communicated to the user by that character has been completely lost.

IMO, putting Gaia-icons into the "public" font list on b2g is in effect handing a giant footgun to app developers. It invites them to do things like (2) above when they want to display icons, and this makes their apps b2g-specific instead of being portable to any environment that supports the open, standard Web APIs and technologies. It becomes equivalent to writing apps that are dependent on -webkit-prefixed CSS. We should not be exposing this as part of the platform.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #58)
> (1)  <span style="font-family: Nirmala">&#x0950;</span>
> 
> and specifying a platform-specific font for PUA characters:
> 
> (2)  <span style="font-family: Gaia-icons">&#xe123;</span>
> 
> In the former case, because the character code is standardized, the browser
> can use font fallback to ensure that the text is still rendered with a
> valid, readable glyph that has the intended meaning, even if the
> platform-specific font that the author specified isn't available. The user
> will still see the text "ॐ", even if fallback results in a slightly
> different glyph design.
> 
> But in the latter case, if the exact font specified isn't available, the
> browser has no chance of rendering anything useful; whatever meaning was
> supposed to be communicated to the user by that character has been
> completely lost.
> 
> IMO, putting Gaia-icons into the "public" font list on b2g is in effect
> handing a giant footgun to app developers. It invites them to do things like
> (2) above when they want to display icons, and this makes their apps
> b2g-specific instead of being portable to any environment that supports the
> open, standard Web APIs and technologies. It becomes equivalent to writing
> apps that are dependent on -webkit-prefixed CSS. We should not be exposing
> this as part of the platform.

#2 is basically the same as writing <span style="font-family:Wingings"> on Windows, right? Should we be blocking that? Is there any evidence that's been a problem?
Flags: needinfo?(jfkthame)
OK, but no bug was ever reported to us about Wingdings PUA usage undermining the Web platform, and no-one ever worried about it before, right?
Flags: needinfo?(jfkthame)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #61)
> OK, but no bug was ever reported to us about Wingdings PUA usage undermining
> the Web platform, and no-one ever worried about it before, right?

It's not been expressed in those terms (AFAIK), but we've certainly had bug reports (that we've typically closed as invalid or wontfix) regarding the non-interoperability of wingdings (and more generally, custom "symbol-encoded" fonts; e.g. see bugs 31538, 33127, 192890, 232819, 236854, 429017. People found a handy way to display certain icons/symbols in IE6 on Windows (for example), went ahead and wrote web pages accordingly, and then complained when things didn't work in Firefox.

We're trying to promote a fully standards-based, interoperable Web platform. I don't want to see StackExchange questions in a year's time where people complain "My app looks great on FirefoxOS, but when I run it on a Brand X device that also claims to support the web platform, all the icons are missing. I thought the web platform was supposed to be interoperable..."
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #62)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #61)
> > OK, but no bug was ever reported to us about Wingdings PUA usage undermining
> > the Web platform, and no-one ever worried about it before, right?
> 
> It's not been expressed in those terms (AFAIK), but we've certainly had bug
> reports (that we've typically closed as invalid or wontfix) regarding the
> non-interoperability of wingdings (and more generally, custom
> "symbol-encoded" fonts; e.g. see bugs 31538, 33127, 192890, 232819, 236854,
> 429017. People found a handy way to display certain icons/symbols in IE6 on
> Windows (for example), went ahead and wrote web pages accordingly, and then
> complained when things didn't work in Firefox.

As far as I can tell, those bugs, and the links in comment #60, are all about people trying to use Windings/Symbol with characters outside the PUA and complaining because we don't support that. But, as far as I can tell, we've always supported use of Wingdings (I'm not sure about Symbol) with PUA characters. So those bugs and the comment #60 links are about a different issue.

> We're trying to promote a fully standards-based, interoperable Web platform.
> I don't want to see StackExchange questions in a year's time where people
> complain "My app looks great on FirefoxOS, but when I run it on a Brand X
> device that also claims to support the web platform, all the icons are
> missing. I thought the web platform was supposed to be interoperable..."

Right, I see the risk. But there is an analogous risk for Wingdings (and maybe Symbol), which is people complaining "My page looks great using Wingdings in Firefox for Windows, but when I run it on a non-Windows device the icons are missing." Is there any evidence that has been a problem in practice? I see warnings to not do it in http://www.alanwood.net/demos/wingdings.html, but that's all I can find. I can't find any bugs (open or closed) directed at us indicating that happened.
For authors who use Wingdings, the issue isn't "when I run it on a non-Windows device", but rather "when I run it in Firefox", but the principle is the same: the platform being exposed to and used by the author deviates from the relevant web and unicode standards, and this hurts the web because it leads directly to broken pages for users with standards-compliant browsers. E.g. http://www.sunnyneo.com/avatars/wingdings.php (see the "Important" note on the page). That page shows the icons as the author intended in both Chrome and IE on Win8, but not in Firefox.

Fundamentally, letting the FirefoxOS browser expose

  <span style="font-family:Gaia-icons">&#xe123;</span>

as a technique for web authors to render a particular icon is not much different from Mobile Safari exposing

  .mywidget { -webkit-whizzy-effect: foobar; }

as a technique to achieve some slick visual or user-interaction effect. It invites and tempts authors to write pages (or apps) in a way that relies on a particular vendor's extensions to the web platform, and thereby fragments the web.

The fact that some existing platforms include fonts like Wingdings that can be used in non-standards-based ways to create non-interoperable sites does not make it OK for us to do the same in FirefoxOS. And the more successful and widespread FirefoxOS becomes over the next few years, the more important it will be to have NOT started down this path.
I'd love to use standard symbols, but if our VD team needs to represent something non-standard we have to provide that icon.
There are tones of icon font on the internet, we will create our own. That font will be provided as open source to whoever wants to use it. App authors will be able to use it to mimic our UI if that's what they want. The only difference is that they will need to have the font file in their apps and for certified apps the font will be already in gecko.
Roc: see also sicking's comment in bug 998844 comment 12 (ignoring the slightly confused CSS, but it's the same feature requirement).
What we should do here is have a

font-face: -moz-icon-font;

which *only* works in certified apps, and not in privileged apps or normal webpages. This way our internal solutions doesn't leak out to the web. However webpages could still replicate what we do by simply embedding the same font file in their app and using @font-face. This way their content would still work cross-browser.
(In reply to Jonas Sicking (:sicking) from comment #67)
> What we should do here is have a
> 
> font-face: -moz-icon-font;
> 
> which *only* works in certified apps, and not in privileged apps or normal
> webpages. This way our internal solutions doesn't leak out to the web.
> However webpages could still replicate what we do by simply embedding the
> same font file in their app and using @font-face. This way their content
> would still work cross-browser.

The patches in bug 1008458 achieve exactly this, except that the CSS needed isn't

  font-face: -moz-icon-font;

but

  font-family: "Gaia-icons";

(or whatever we decide to name the font; and we could potentially have more than one such font, if the need arises). Patch #6 there checks for APP_STATUS_CERTIFIED, and only in this case will the private font be used.
Awesome, thanks. Clearly it's been a while since I've been styling my web pages :-)
Flagging Patryk and Tim to see if they can facilitate a decision here. This is expected to land by FC on June 9.
Flags: needinfo?(timdream)
Flags: needinfo?(padamczyk)
What's the decision to make and what does it has to do with me? I thought we are working on a platform solution here...
Flags: needinfo?(timdream)
This is dependent on bug 1008458, where we don't yet have agreement on what to actually implement in the platform... :(
Also it is a blocker for bug 1002904 which is a perf regression. A decision ought to be made on this. Thanks.
Clearing my flagged name, as the solution is not being discussed in the email thread: Icon Fonts on FXOS.
Flags: needinfo?(padamczyk)
Bug 1030829, which has just landed on inbound, should provide a solution that can be used for the Gaia-icons font. Once that's safely merged to central, we can follow up here.
Depends on: 1030829
Can we land these patches now?  This is blocking Bug 1002904 which is a huge regression in the calendar launch time.
Flags: needinfo?(jfkthame)
Flags: needinfo?(bugs)
Attachment #8419305 - Attachment is obsolete: true
Flags: needinfo?(jfkthame)
Attachment #8416393 - Attachment is obsolete: true
Attachment #8417288 - Attachment is obsolete: true
The patches here - which ended up being spun off to bug 1008458 - are obsolete; that was wontfix'd, and we have an alternative solution based on bug 1030829.

So what Gaia needs to do now, to reduce the launch-time cost of using the icon font, is this:

(1) Install the Gaia-icons font into /system/fonts/hidden/Gaia-icons.ttf. (Or use .woff? I don't know which will perform better, though I suspect the difference will be negligible. Using uncompressed .ttf may make for a slightly larger system image, but may also reduce RAM demands slightly by avoiding the need to decompress into RAM. It's a tradeoff.)

One way to do this, presumably, would be to import the font into the moztt repo and set the appropriate installation path in fonts.mk there, but if it can be managed more directly as part of Gaia, I think that'll be easier to maintain.

(2) Generate a data: URI that corresponds to the "hidden-installed" version of the font: something like

  echo -n "data:font/opentype;base64," > Gaia-icons.dataURI
  base64 Gaia-icons.ttf >> Gaia-icons.dataURI

(If using the .woff version, make that "data:font/woff;base64," instead.)

(3) In the Gaia CSS, use that data: URI to specify the font, and use the family name "gaia-icons" (exactly as found in the font itself, but lowercased):

  @font-face {
    font-family: gaia-icons;
    src: url(data:font/opentype;base64,AAEAAA...ztNmKw==);
  }

With this recipe, Gecko should recognize that the URI in the @font-face rule corresponds to the already-installed (but hidden - i.e. not present in the main font list) version of the font, and use the preinstalled one instead of going through the full font loading process.
Flags: needinfo?(bugs)
Please see Comment 77 above.  What is it going to take to get those changes landed?  Do we need a new bug to track that work?
Flags: needinfo?(rnowmrch)
Dave, I will update my patch above (Attachment 8349449 [details]) as a first step lo land the font.
This font includes some icons in setiings app. It would be good if you could provide me the icons you need and I'll make sure they land in moztt repo.
Flags: needinfo?(rnowmrch) → needinfo?(dhuseby)
Unassigning myself here, as the work remaining to be done is in Gaia and the FxOS build process, which is pretty much outside my area of knowledge. I'll keep an eye on the bug, though, in case of questions about how to work with the underlying platform feature, etc.
Assignee: jfkthame → nobody
Status: ASSIGNED → NEW
I've got an ni? out to James Lal to find somebody working on calendar to get the calendar icons into the patch here.
Flags: needinfo?(dhuseby) → needinfo?(rnowmrch)
:huseby, the calendar icon font is inside https://github.com/mozilla-b2g/gaia/tree/master/apps/calendar/style/fonts we have a WOFF font and a JSON file that you can import on http://icomoon.io/app/ (web app) and export the glyphs as multiple SVG files or as font files.

what do I need to do? should I just create a pull request introducing a new font "Calendar-icons-1.00/Calendar-icons.woff" (adding it to the PRODUCT_COPY_FILES) or we will actually need to include all the icons needed by gaia inside the same font?
Flags: needinfo?(dhuseby)
You could have separate icon fonts for various apps, but there'll be some per-font overhead for preloading them all. So my suggestion for the Gaia team would be to consolidate icons into a single Gaia-icons font.
Assignee: nobody → rnowmrch
Flags: needinfo?(rnowmrch)
I'll add in this patch all available icons provided by the UX team, that also includes calendar ones, once the patch is landed, I'll do a second one (bug 948856) duplicating the icon font in base64 as explained in comment 77, in the shared directory.
This way apps will only need to link to shared/style/icons.css
Merged: dc5ca96695cab87b4c2fcd7c9f046ae3415a70a5
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(mwu)
Flags: needinfo?(dhuseby)
Resolution: --- → FIXED
Blocks: 1035670
No longer depends on: 1035670
(In reply to Jonathan Kew (:jfkthame) from comment #77)
>   @font-face {
>     font-family: gaia-icons;
>     src: url(data:font/opentype;base64,AAEAAA...ztNmKw==);
>   }
> 
> With this recipe, Gecko should recognize that the URI in the @font-face rule
> corresponds to the already-installed (but hidden - i.e. not present in the
> main font list) version of the font, and use the preinstalled one instead of
> going through the full font loading process.

Can you explain why when we use .woff fonts we should use 'data:font/woff;base64,' prefix, but when we use .ttf fonts we use 'font/opentype;base64,' prefix?
We will be hosting the gaia-icons [1] font externally. Is there any magic way we can get it to be pulled in from there when b2g builds? We're likely to be making tweaks frequently.

If that is not possible it would be great if we could get merge rights for moztt repo so that we can update gaia-icons without bothering people.

[1] http://github.com/gaia-componennts/gaia-icons
Flags: needinfo?(jfkthame)
(In reply to Wilson Page [:wilsonpage] from comment #87)
> (In reply to Jonathan Kew (:jfkthame) from comment #77)
> >   @font-face {
> >     font-family: gaia-icons;
> >     src: url(data:font/opentype;base64,AAEAAA...ztNmKw==);
> >   }
> > 
> > With this recipe, Gecko should recognize that the URI in the @font-face rule
> > corresponds to the already-installed (but hidden - i.e. not present in the
> > main font list) version of the font, and use the preinstalled one instead of
> > going through the full font loading process.
> 
> Can you explain why when we use .woff fonts we should use
> 'data:font/woff;base64,' prefix, but when we use .ttf fonts we use
> 'font/opentype;base64,' prefix?

Because these are the media-types[1] for WOFF and OpenType fonts respectively, and that's what the code in gfxFT2FontList.cpp expects to see. Note that .ttf files are OpenType fonts (TrueType being a subset of OpenType), as are .otf files; for either of these, the font/opentype media-type should work. WOFF files are a distinct format and have their own media-type.


[1] That's not true, actually. They are proposals for the future, but are not yet registered. Fortunately, the media-type isn't really important for the font to work; but it does have to match what gfxFT2FontList expects in order to get the benefit of the preloaded system copy of the font.


(In reply to Wilson Page [:wilsonpage] from comment #88)
> We will be hosting the gaia-icons [1] font externally. Is there any magic
> way we can get it to be pulled in from there when b2g builds? We're likely
> to be making tweaks frequently.

I don't know enough about the build system to comment on this, but in principle I think it should be done this way. Ideally, the build would automatically pull in the font and install it to /system/fonts/hidden, *and* regenerate the data: URI in the shared CSS file. Maintaining that by hand is a recipe for frequent breakage.
Flags: needinfo?(jfkthame)
jfkthame: Thanks for the quick reply and such valuable info! Are we able to get some kind of push rights to moztt before a build strategy is implemented?
Flags: needinfo?(jfkthame)
I don't know who's ultimately responsible for moztt - better check with :mwu.
Flags: needinfo?(jfkthame) → needinfo?(mwu)
jfkthame: The W3C spec states the correct mime-type for WOFF fonts is `application/font-woff`. Should we still be using `font/woff`?
Flags: needinfo?(jfkthame)
Well... media types for fonts have historically been a bit of a mess, and are probably still evolving. It turns out that last year, the type 'application/font-sfnt' was successfully registered (I'd forgotten about that), so as of now, the "most correct" practice would be to use

  application/font-sfnt   for .ttf and .otf fonts
  application/font-woff   for .woff fonts

That's reasonably clear, at least.

However, in practice I don't think application/font-sfnt has gained much traction (yet, at least); it's far more common to see application/x-font-truetype or application/x-font-opentype or the generic application/octet-stream (or, of course, poorly configured servers using things like text/html or text/css!)

As for WOFF, although the type application/font-woff was registered by the W3C WebFonts WG, there's quite a lot of use of font/woff in the wild (I believe the Google web-fonts service uses it, for example).

Moreover, while this is the current position (AIUI), there's been ongoing discussion within the WebFonts WG about trying to register a new font/ top-level type, so that we'd then have things like font/woff and font/opentype (or maybe font/sfnt?). So depending what happens with that proposal, things may yet change in the coming few months/years.

Anyhow, in practice the type doesn't matter for use of the font, but it does have to match what gfxFT2FontList expects if you're going to get the benefit of a preloaded system font. And what I wrote in the patch at bug 1030829 (somewhat arbitrarily, I admit) was the font/opentype and font/woff types, in anticipation that these will become the standard in the future (perhaps!). So that's what you need to have in the CSS.

http://hg.mozilla.org/mozilla-central/file/7790d48f1451/gfx/thebes/gfxFT2FontList.cpp#l1437

I'd have nothing against changing this to use the currently-registered application/font-{sfnt,woff} types if people would prefer that. It won't make any difference to the functionality. All that matters here is that the CSS you deploy in Gaia matches what the Gecko code expects. So whatever we decide in the one place, we need to ensure the other agrees with it.


In summary: as things stand, you need to use font/woff or font/opentype. If you'd prefer to be using application/font-woff or application/font-sfnt, file a bug requesting this, and I'll post a patch to change Gecko accordingly. I don't really care either way.
Flags: needinfo?(jfkthame)
(In reply to Wilson Page [:wilsonpage] from comment #88)
> We will be hosting the gaia-icons [1] font externally. Is there any magic
> way we can get it to be pulled in from there when b2g builds? We're likely
> to be making tweaks frequently.
> 

We can add gaia-icons as a new repo in our device manifests and include it from moztt.

> If that is not possible it would be great if we could get merge rights for
> moztt repo so that we can update gaia-icons without bothering people.
> 
> [1] http://github.com/gaia-componennts/gaia-icons

That's also possible. In general, if you're only updating font data, without touching any of the build related pieces, it's not a problem.

Of these two options, I think I actually prefer having a separate repo. However, if you're using a separate github organization to store this repo on, it may make things more difficult to integrate into our build structure since we have a fixed list of remotes we pull from.

A third option may be to put the fonts in gaia. That way, you can atomically update gaia with gaia icon font updates, and the fonts are stored in a place you have easy access to.
Flags: needinfo?(mwu)
The other thing to remember is that whenever you update the font (regardless of what repo it's stored in), and make the corresponding change to the CSS in gaia, you'll need to ensure the new font actually gets copied to the device. Just flashing either gaia and/or gecko doesn't do that, afaik.

If there was some way that "./flash.sh gaia" could be made to install the font from its source location in the gaia repo to the /system/fonts/hidden destination on device, I think that'd make people's lives easier. But I don't know anything about the flash/update process, and what can or can't be done there.
(In reply to Jonathan Kew (:jfkthame) from comment #95)
> The other thing to remember is that whenever you update the font (regardless
> of what repo it's stored in), and make the corresponding change to the CSS
> in gaia, you'll need to ensure the new font actually gets copied to the
> device. Just flashing either gaia and/or gecko doesn't do that, afaik.
> 
> If there was some way that "./flash.sh gaia" could be made to install the
> font from its source location in the gaia repo to the /system/fonts/hidden
> destination on device, I think that'd make people's lives easier. But I
> don't know anything about the flash/update process, and what can or can't be
> done there.

Doesn't need to modify 'flash.sh', it can be done just modifying the 'Makefile' and the 'Android.mk' of gaia.
Comment on attachment 8349449 [details]
patch in github

We need this backed out now that we are syncing gaia-icons directly from Gaia repo. Keeping moztt in sync would be an ongoing nightmare.
Attachment #8349449 - Flags: review+ → review?(mwu)
Comment on attachment 8349449 [details]
patch in github

Resetting review flag.
Attachment #8349449 - Flags: review?(mwu) → review+
Attached file pull-request (master) — 
Patch to backout
Attachment #8467853 - Flags: review?(mwu)
Comment on attachment 8467853 [details] [review]
pull-request (master)

r=me assuming the font file is also removed.
Attachment #8467853 - Flags: review?(mwu) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: