Jonathan Kew [:jfkthame] Assignee
	Description • 11 years ago

See bug 951593 for background discussion.

Gaia wants to have a PUA icon font available as a "system" font, to avoid the font-loading overhead of pulling it in via @font-face in each app. But we don't want to expose this font as part of the Firefox OS platform to apps in general.

So the proposal here is that, in addition to the standard list of fonts found in /system/fonts, the platform font list on b2g will support a list of "private" fonts loaded from a separate directory. When a gfxFontGroup resolves the font-family names to actual platform fonts, it will ignore the private fonts unless it was explicitly told that they're allowed.

The patches here began life in bug 951593, but I've split this off as a separate bug for review and landing so that we can track the Gecko and Gaia parts of the work separately.

	Jonathan Kew [:jfkthame] Assignee
	Comment 1 • 11 years ago

I've split the patch (from bug 951593 comment 52) into a series of logical pieces for more manageable review; the functionality is unchanged from what was posted there, aside from fixing a Linux build failure.

Tryserver run with the patch series to be posted here, to check that existing tests don't break: https://tbpl.mozilla.org/?tree=Try&rev=51ac930144fe. We don't have any tests for the new (B2G-only) functionality yet; that should be added when Gaia starts to use this.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 8 • 10 years ago

Comment on attachment 8420424 [details] [diff] [review]
part 1 - add the mAllowPrivateFonts flag to gfxFontGroup.

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

OK, I still think the problem we're trying to address isn't worth addressing, but I have failed to convince people of that so let's go ahead.

However, I don't think this is the right way to address it. I think the right way to address it is to disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. I prefer that over this solution because a) it seems to me the code will be simpler and b) it tackles the underlying problem directly.

	Jonathan Kew [:jfkthame] Assignee
	Comment 9 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> Comment on attachment 8420424 [details] [diff] [review]
> part 1 - add the mAllowPrivateFonts flag to gfxFontGroup.
> 
> Review of attachment 8420424 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> OK, I still think the problem we're trying to address isn't worth
> addressing, but I have failed to convince people of that so let's go ahead.
> 
> However, I don't think this is the right way to address it. I think the
> right way to address it is to disable use of PUA characters in local fonts
> on all platforms except for FirefoxOS certified apps. I prefer that over
> this solution because a) it seems to me the code will be simpler and b) it
> tackles the underlying problem directly.

Yes, it would be simpler, but I suspect it would break too many people's pages. I'm confident there'll be existing usage of PUA characters with local fonts, primarily aimed at Windows fonts such as Symbol, Wingdings and Webdings:

  data:text/html,<span style="font:60px Symbol">&%23xF022;</span>
  data:text/html,<span style="font:60px Wingdings">&%23xF022;</span>
  data:text/html,<span style="font:60px Webdings">&%23xF022;</span>

All this will not work across platforms, of course, but that doesn't prevent people writing such things - perhaps for limited, internal use where they don't care about wider compatibility - and being unhappy if we break them.

There's also the use-case where people write code that will use a local font (e.g. for a well-known icon collection) if installed, and download it otherwise:

  @font-face {
    font-family: OcticonsWeb;
    src: url(.....);
  }

  .icon { font-family: Octicons, OcticonsWeb; }

If we disable the use of PUA characters with local fonts, we'd regress performance in a case like this by forcing it to download the font even though the user already had it installed locally.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 10 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> Yes, it would be simpler, but I suspect it would break too many people's
> pages. I'm confident there'll be existing usage of PUA characters with local
> fonts, primarily aimed at Windows fonts such as Symbol, Wingdings and
> Webdings:
> 
>   data:text/html,<span style="font:60px Symbol">&%23xF022;</span>
>   data:text/html,<span style="font:60px Wingdings">&%23xF022;</span>
>   data:text/html,<span style="font:60px Webdings">&%23xF022;</span>
> 
> All this will not work across platforms, of course, but that doesn't prevent
> people writing such things - perhaps for limited, internal use where they
> don't care about wider compatibility - and being unhappy if we break them.

OK but isn't this the kind of cross-platform incompatibility we need to stamp out?

We could whitelist the popular Windows fonts if you think that's necessary.

> There's also the use-case where people write code that will use a local font
> (e.g. for a well-known icon collection) if installed, and download it
> otherwise:
> 
>   @font-face {
>     font-family: OcticonsWeb;
>     src: url(.....);
>   }
> 
>   .icon { font-family: Octicons, OcticonsWeb; }
> 
> If we disable the use of PUA characters with local fonts, we'd regress
> performance in a case like this by forcing it to download the font even
> though the user already had it installed locally.

That seems a very obscure case to optimize for. I wouldn't want to expend energy to support that without actual examples where it matters. Even then, it's probably rare enough to ignore.

	Jonathan Kew [:jfkthame] Assignee
	Comment 11 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> (In reply to Jonathan Kew (:jfkthame) from comment #9)
> > Yes, it would be simpler, 

...though on second thoughts, it wouldn't be *that* much simpler, because we'd still need to pass a flag indicating whether we're running certified-app code all the way down to the font-matching algorithm, as gfxFontGroup::FindFontForChar would need to know.

> > but I suspect it would break too many people's
> > pages. I'm confident there'll be existing usage of PUA characters with local
> > fonts, primarily aimed at Windows fonts such as Symbol, Wingdings and
> > Webdings:
> > 
> >   data:text/html,<span style="font:60px Symbol">&%23xF022;</span>
> >   data:text/html,<span style="font:60px Wingdings">&%23xF022;</span>
> >   data:text/html,<span style="font:60px Webdings">&%23xF022;</span>
> > 
> > All this will not work across platforms, of course, but that doesn't prevent
> > people writing such things - perhaps for limited, internal use where they
> > don't care about wider compatibility - and being unhappy if we break them.
> 
> OK but isn't this the kind of cross-platform incompatibility we need to
> stamp out?

I don't think we'll get far by disabling PUA/local-fonts in Firefox; we'll simply convince the people using such things that Firefox is broken and they'll switch to a browser that "works". To effectively "stamp out" such practices, we'd need to get agreement from the other major browser vendors to do the same thing.

> We could whitelist the popular Windows fonts if you think that's necessary.

It'll apply not only to "popular Windows fonts" but also to fonts used among enthusiasts for Elvish scripts, Dwarvish runes, Klingon, and others that are often handled using the PUA range; see the ConScript registry.[1] Perhaps more seriously, it'll affect Medievalist usage of fonts that follow the MUFI recommendations.[2]

[1] http://www.evertype.com/standards/csur/conscript-table.html
[2] http://folk.uib.no/hnooh/mufi/specs/index.html

I think maintaining or dropping our long-standing support for existing use patterns - however regrettable we may think them in some cases - is a very different issue from whether we introduce a new, non-portable/interoperable scheme as part of the FirefoxOS platform.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 12 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #11)
> I don't think we'll get far by disabling PUA/local-fonts in Firefox; we'll
> simply convince the people using such things that Firefox is broken and
> they'll switch to a browser that "works". To effectively "stamp out" such
> practices, we'd need to get agreement from the other major browser vendors
> to do the same thing.

TBH I don't understand why you take this position here but took the opposite position in the discussion about displaying hexboxes for control characters. But OK...

> I think maintaining or dropping our long-standing support for existing use
> patterns - however regrettable we may think them in some cases - is a very
> different issue from whether we introduce a new, non-portable/interoperable
> scheme as part of the FirefoxOS platform.

How about doing it just on FirefoxOS for now, then? There is currently no easy way to install your own local fonts AFAIK so these potential issues are minimal and we can solve the PUA-with-local-fonts problem before it arises. And it solves our icon-font problem at the same time.

	Jonathan Kew [:jfkthame] Assignee
	Comment 13 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #12)
> TBH I don't understand why you take this position here but took the opposite
> position in the discussion about displaying hexboxes for control characters.
> But OK...

ISTM there are significant differences between the two cases, but this isn't the place to launch into that discussion....

> How about doing it just on FirefoxOS for now, then? There is currently no
> easy way to install your own local fonts AFAIK so these potential issues are
> minimal and we can solve the PUA-with-local-fonts problem before it arises.
> And it solves our icon-font problem at the same time.

So the gfxFontGroup::mAllowPrivateFonts flag from patch 1 here would be renamed mAllowInstalledFontsForPUA, or something like that?

We'll still need essentially the same plumbing to pass that down from the pres-context that can determine whether we're running a certified app, via the device context and font-metrics, into gfx where the font-matching process can use it to decide what to do when it encounters a PUA codepoint. Do you want all that plumbing to be within "#ifdef GONK", so that it's not present on other platforms?

TBH, I don't see the attraction of this over the existing patches here. But if you really prefer it, I guess I could rework things that way.

Oh, another thing: if there's a local font that includes both PUA and non-PUA characters,[1] this results in the rather weird situation that the font is available to all apps, but behaves differently in certified vs non-certified. I think that's much more confusing to developers than a rule that certified-app fonts are only available to certified apps, and simply don't exist as far as other code is concerned.


[1] We may well decide never to create/ship such a font ourselves, just because it'd be confusing, but we don't fully control what fonts end up on the devices that various partners ship.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 14 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #13)
> So the gfxFontGroup::mAllowPrivateFonts flag from patch 1 here would be
> renamed mAllowInstalledFontsForPUA, or something like that?

Something like that. How about adding disablePUAForLocalFonts to gfxFontStyle? Seems like that would simplify the changes a bit.

> We'll still need essentially the same plumbing to pass that down from the
> pres-context that can determine whether we're running a certified app, via
> the device context and font-metrics, into gfx where the font-matching
> process can use it to decide what to do when it encounters a PUA codepoint.

Yes.

> Do you want all that plumbing to be within "#ifdef GONK", so that it's not
> present on other platforms?

No, just the nsPresContext code, similar to what you have now.

> TBH, I don't see the attraction of this over the existing patches here. But
> if you really prefer it, I guess I could rework things that way.

There would be no equivalent to part 3, and I think most of part 4 would go away too. It would also be simpler on the FirefoxOS side since we wouldn't need a special location for fonts for certified apps. It's also easily extended to other platforms/situations if we decide we can get away with that.

> Oh, another thing: if there's a local font that includes both PUA and
> non-PUA characters,[1] this results in the rather weird situation that the
> font is available to all apps, but behaves differently in certified vs
> non-certified. I think that's much more confusing to developers than a rule
> that certified-app fonts are only available to certified apps, and simply
> don't exist as far as other code is concerned.
> 
> [1] We may well decide never to create/ship such a font ourselves, just
> because it'd be confusing, but we don't fully control what fonts end up on
> the devices that various partners ship.

This cuts both ways. It's quite likely that if an OEM puts a PUA-using font on the device, they won't know to put it in the certified-apps-only directory (or they just won't care), in which case they'll create exactly the problem we're trying to avoid here ... whereas my proposed approach will continue to work.

	Jonathan Kew [:jfkthame] Assignee
	Comment 15 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #14)

If we do take your approach of disallowing PUA characters from locally-installed fonts (except in certified apps), how should we treat fonts loaded via @font-face with src:local()? Is such a font still "local" (so PUA characters are still blocked), or is it now a "user font" that allows them?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 16 • 10 years ago

It's still local.

	Jonathan Kew [:jfkthame] Assignee
	Comment 17 • 10 years ago

Won't that interfere with a fairly common pattern of @font-face usage?

@font-face {
  font-family: MyFontThatIncludesPUAIcons;
  src: local(MyFont-Regular),
       url(fonts/myfont-regular.woff);
}

The "local" copy of the font will mean that the downloadable one is never used -- which is the idea of this idiom: users who have the font locally get optimal performance and minimize bandwidth use by avoiding the download -- but it will then block any access to the PUA characters. Only users who *don't* have the font locally will see them, as then they'll come from the remote font.

Sorry to be a pain, but to me this doesn't feel nearly as "clean" a design as the private-fonts-directory proposal. :(

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 18 • 10 years ago

Treat a @font-face that contains any url() as non-local.

	Jonathan Kew [:jfkthame] Assignee
	Comment 19 • 10 years ago

In that case,

  @font-face {
    font-family:gaia-icons;
    src:local("Gaia-icons"),url(dummy.ttf);
  }

would work around the certified-app restriction. This still seems like an awkward, confusing approach to the issue we're trying to solve here, and it solves it less cleanly than the private-fonts model.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 20 • 10 years ago

If people want to write content that only works on FirefoxOS, we can't stop them. So I don't feel we have to block "workarounds" like that.

In fact, I think we could probably achieve the goal of your patch set here just by renaming the font to "Gaia Icons For Certified FirefoxOS Apps Only" and be done with it, letting people shoot themselves in the foot if they insist. I'd r+ a patch for that :-).

My proposal has a number of practical advantages. I think it's going to be less code overall. It's robust to anyone installing fonts with PUA glyphs anywhere. It lets non-certified apps use the Gaia icon font for icons with non-PUA characters. It lets FirefoxOS non-certified-app developers use the optimization you describe in comment #17 for Gaia icons. It keeps FirefoxOS configuration simple since there's only one place to install fonts.

As for cleanliness, AFAICT the actual problem we're trying to solve here is to prevent apps from depending on PUA glyphs in local fonts. My proposal tackles that directly, with a loophole for certified apps. The private-fonts approach tackles it indirectly. There is no obvious connection between PUA glyphs and the existence of certified-app-only fonts. A symptom of this indirection is that it adds two additional failure modes: fonts with PUA glyphs can be installed in the normal font directory, in which case the problem we were trying to prevent reappears; and fonts without PUA glyphs can be installed in the private-fonts directory, in which case they're needlessly blocked from being used by non-certified apps. So I think private-fonts is the confusing and awkward approach!

I don't really want to argue about this. If you can convince another reviewer that the private-fonts approach is best, that's fine with me.

	Jonathan Kew [:jfkthame] Assignee
	Comment 21 • 10 years ago

> So I think private-fonts is the confusing and awkward approach!

...whereas I think it's confusing for FirefoxOS to have a font that behaves differently in certified vs non-certified apps: "I copied such-and-such code from another FirefoxOS app; it works fine there, but in my project only half the icons show up!" I think it's much easier to understand and remember "the Gaia icons font is only available in certified apps" than "some of the Gaia icons work in all apps, and others in certified apps only".


I think to some extent we've been looking at this from different perspectives: is it about making it possible for Gaia to have a font that is visible only to certified apps, and thus not really part of the Web platform (and therefore we'll be OK with it using PUA codepoints); or is it about restricting how people use PUA characters, to avoid inadvertent dependencies on their local system's font configuration (such as the presence of the Gaia-icons font)?

- - - -

Let's ask a couple of others for opinions - I'll needinfo? jdaggett as a font guy, and sicking, who I know has commented on this in the related bugs.

To summarize, the motivating issue here is that we want to ship a custom Gaia-icons font that uses PUA characters; we want it installed as a "system" font to avoid the performance hit of loading via @font-face in specific apps; but we don't want to expose it as part of the public FirefoxOS platform.

We have two suggested approaches:

(a) a separate "system fonts" directory for fonts that are visible only to certified apps. This would initially be used for the Gaia-icons font, though in principle it could be used for other things if the need arises - e.g. if we have a Gaia user interface (text) font that we don't want to expose to general web pages.

(b) prevent the use of PUA characters in installed system fonts (on FirefoxOS initially, though in principle we might want to extend it to other platforms), with an exception for certified apps so that they can use PUA characters in the Gaia-icons font.

The current patches here implement approach (a), but if there's a general preference for approach (b), I'll work on an alternative set of patches to implement this option.

	John Daggett (:jtd)
	Comment 22 • 10 years ago

Hmmm, I think one possible middle road approach would be to create an icon font that *only* exposes the icon glyphs via 'dlig', and not via PUA codepoints, and ship it such that any app or site can use it.

  .icon {
    font-family: -moz-icon;
    font-feature-settings: "dlig" on;
  }

  <div class=icon>arrow-left arrow-right</div>

This has the advantage of being easy for authors to understand while keeping lots of PUA codepoints out of webpages.

I think we could easily construct a copy of FontAwesome, with substitution rules added and PUA codepoints removed, as part of the build:

  http://fortawesome.github.io/Font-Awesome/cheatsheet/

	John Daggett (:jtd)
	Comment 23 • 10 years ago

One other nice feature of using a 'dlig' only approach is that it can be localized very cleanly:

default home icon:

  <div class=icon>home</div>

Mongolian home icon, showing a yurt instead of a house:

  <div class=icon lang="mn">home</div>

Brian comments "why not vertical variants..." but that may be a bridge too far...

	Jonathan Kew [:jfkthame] Assignee
	Comment 24 • 10 years ago

(In reply to John Daggett (:jtd) from comment #22)
> Hmmm, I think one possible middle road approach would be to create an icon
> font that *only* exposes the icon glyphs via 'dlig', and not via PUA
> codepoints, and ship it such that any app or site can use it.
> 
>   .icon {
>     font-family: -moz-icon;
>     font-feature-settings: "dlig" on;
>   }
> 
>   <div class=icon>arrow-left arrow-right</div>
> 
> This has the advantage of being easy for authors to understand while keeping
> lots of PUA codepoints out of webpages.

I don't think this is a good idea. It still encourages authors to write pages/apps that depend on a specific font shipped with FxOS, and their pages will render very poorly in any generic Web platform environment that lacks this specific font. They'd fall back to rendering the textual names of the icons, which is perhaps marginally better than falling back to a hexbox, but not much; it'll still be broken and essentially unusable in most cases.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 25 • 10 years ago

I agree that using fonts here is a hack. But getting acceptable performance has a higher priority than completely avoiding any hacks.

I'd love it if we could get the same performance using <img src="icon.svg">. But how quickly can we get that to happen?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 26 • 10 years ago

Sorry, I didn't read comment 21 thoroughly enough.

I don't really have an opinion about (a) vs. (b). My only goal is to make sure that the hacks that we'll use in gaia doesn't leak to 3rd party apps and the web.

	Jonathan Kew [:jfkthame] Assignee
	Comment 27 • 10 years ago

jdaggett, of the alternatives described here, which would you prefer to review? The existing patch set here (a), or a version that implements Roc's suggested approach (b)?

	John Daggett (:jtd)
	Comment 28 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #24)
> (In reply to John Daggett (:jtd) from comment #22)
> > Hmmm, I think one possible middle road approach would be to create an icon
> > font that *only* exposes the icon glyphs via 'dlig', and not via PUA
> > codepoints, and ship it such that any app or site can use it.
> > 
> >   .icon {
> >     font-family: -moz-icon;
> >     font-feature-settings: "dlig" on;
> >   }
> > 
> >   <div class=icon>arrow-left arrow-right</div>
> > 
> > This has the advantage of being easy for authors to understand while keeping
> > lots of PUA codepoints out of webpages.
> 
> I don't think this is a good idea. It still encourages authors to write
> pages/apps that depend on a specific font shipped with FxOS, and their pages
> will render very poorly in any generic Web platform environment that lacks
> this specific font. They'd fall back to rendering the textual names of the
> icons, which is perhaps marginally better than falling back to a hexbox, but
> not much; it'll still be broken and essentially unusable in most cases.

Hmm, authors can easily set up pages to fallback to webfont use for situations where the font is not available locally. This allows anybody, certified or not, to use the same icons as the system uses, in a way that doesn't clutter up their code with PUA codepoints.  There are all sorts of examples floating around the web of folks using fonts in strange and unusual ways where the fallback will be gibberish (e.g. chart fonts).  I don't see a strong reason to put restrictions on this as long as it doesn't involve PUA codepoint usage.

For B2G UI code, using a dlig feature approach also produces much more readable, maintainable code. Using a restricted PUA codepoint font means UI code filled with gibberish entities that doesn't provide *any* clue to someone looking at it or reviewing UI changes as what the heck it is. Using a dlig feature approach makes the code *much* clearer.

	John Daggett (:jtd)
	Comment 29 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #27)
> jdaggett, of the alternatives described here, which would you prefer to
> review? The existing patch set here (a), or a version that implements Roc's
> suggested approach (b)?

Sorry but I really don't like either. I think the distinction between certified/privledged/general has no place in font selection decisions. Looking over the patches here I really think it complicates the font code unnecessarily.

If we really want to restrict the use of system icons to only certified apps then I would say, hmmm, ok, can't be helped. But the motivation here is simply to prevent the use of PUA codepoints in public webpages.  As such, I think we should just not use PUA codepoints and provide a way authors can access system icons without using PUA codepoints.  I think using a dlig feature approach is a better way of doing this and represents a better workflow for B2G code itself.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 30 • 10 years ago

The motivation isn't just to avoid PUA codepoints in 3rd party content. The motivation is to not have people write content that works great in FirefoxOS, but breaks elsewhere.

Of course "breaks" isn't a clearly defined thing. But if something renders as a "edit" icon in FirefoxOS, but the text "edit" elsewhere, then that will likely look pretty crappy.

Another way to look at it, anything that we expose to 3rd party content is something that we should expect to support for a very long time. So if something renders as an "edit" icon now, we should count on having to make sure that it renders as such for a long time forward. Even once we get SVG rendering fast enough that we have switched to it internally.

	Jonathan Kew [:jfkthame] Assignee
	Comment 31 • 10 years ago

(In reply to Jonas Sicking (:sicking) from comment #30)
> Another way to look at it, anything that we expose to 3rd party content is
> something that we should expect to support for a very long time. So if
> something renders as an "edit" icon now, we should count on having to make
> sure that it renders as such for a long time forward.

Even that's not sufficient. If we expose something that renders as an "edit" icon in FirefoxOS to web/app authors in general, we can expect that they'll make use of it. And if that "something" is dependent on a particular font - regardless of exact implementation details, whether it uses a PUA codepoint or the string "edit" with a ligature feature - such that it looks pretty crappy in a non-FirefoxOS environment, then we've forked the web platform. It's essentially like iOS exposing -webkit-... properties, resulting in "web" sites that look awful or simply don't work on non-Apple devices. We should be striving to avoid anything remotely like that.

Anything we expose to 3rd party content should be considered part of the Web platform. I don't think the "Gaia icons" font qualifies as that, except in as far as any of its icons have standardized Unicode codepoints. Beyond that, it is a private app-provided resource, and so should be available only within the app that provides it.

Purely as a performance optimization for the basic FirefoxOS apps, we're being asked to allow it to be a shared, preloaded resource instead of making each Gaia app load it via @font-face as needed. But we should avoid allowing that private optimization to pollute the web platform we expose publicly.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 32 • 10 years ago

I've got a fourth suggestion: publish the Gaia-icon font somewhere at mozilla.org. Have all apps refer to that font via its mozilla.org URL. But in FirefoxOS, have Gecko special-case that font URL to refer to a hidden local font that is not otherwise exposed.

Maybe we could even do this remapping in Necko. This would let us safely expose shared resources of any type without polluting the Web platform.

	John Daggett (:jtd)
	Comment 33 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #32)
> I've got a fourth suggestion: publish the Gaia-icon font somewhere at
> mozilla.org. Have all apps refer to that font via its mozilla.org URL. But
> in FirefoxOS, have Gecko special-case that font URL to refer to a hidden
> local font that is not otherwise exposed.

So the idea would be to have apps, both internal and external always use:

  @font-face {
    font-family: gaia-icon;
    src: local(gaia-icon), url(www.mozilla.org/fonts/gaia-icon.ttf);
  }

And the local() lookup would only succeed for certified apps? We don't want to do the mapping within Necko because we'd end up with multiple activations of the same font for different apps.

If we serve the font at a publicly available address, I don't see the need to impose the certified restriction.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 34 • 10 years ago

No, the idea would be to have all apps use

  @font-face {
    font-family: gaia-icon;
    src: url(www.mozilla.org/fonts/gaia-icon.ttf);
  }

And internally, on FirefoxOS, url(www.mozilla.org/fonts/gaia-icon.ttf) is redirected to a local resource that is otherwise completely hidden. @font-face { src:local(<anything>); } would *not* work.

	John Daggett (:jtd)
	Comment 35 • 10 years ago

Unless you (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #34)
> No, the idea would be to have all apps use
> 
>   @font-face {
>     font-family: gaia-icon;
>     src: url(www.mozilla.org/fonts/gaia-icon.ttf);
>   }
> 
> And internally, on FirefoxOS, url(www.mozilla.org/fonts/gaia-icon.ttf) is
> redirected to a local resource that is otherwise completely hidden.
> @font-face { src:local(<anything>); } would *not* work.

Hmmm, if you do this at this level then you'll be doing a lot of extra work to sanitize and activate the font each time it's used. I'm pretty sure that even with the existing activated font caching that you'd end up with lots of activated fonts sitting in memory across apps. Whereas, using local() simply utilizes a *single*, unsanitized font across all apps, same as other system fonts.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 36 • 10 years ago

Good point, so we don't want to do this at the Necko level. But we can still do it efficiently with a little bit more work.

	Jonathan Kew [:jfkthame] Assignee
	Comment 37 • 10 years ago

ISTM this would create a maintenance and versioning burden that we really don't want to take on. If Gaia-icons is exposed and used via a public URL, we're pretty much obligated to maintain the behavior of that URL in perpetuity, to avoid breaking people's apps/pages. And whenever the Gaia team wants to modify their icon collection (which I imagine will be an ongoing process), we'll need to create a new URL for the new version so that we don't break things that are using an old one.

(How about just adding new codepoints to the font - keeping the same URL - without ever changing or removing old ones? That sort-of-works, but it'll create a problem for FxOS devices whose local, hidden font is older than the current published one: if pages/apps try to use the new icons, the device will use its local font and they'll be missing. We could add code to fall back to downloading the remote font in that situation, but it's yet more complication.... and in any case I'm not keen on the scenario where we don't have the liberty to remove old stuff from the font when Gaia no longer wants it.)

In the original "private font" model here, the Gaia team keep the freedom to manage the font however they like, extending and updating it to suit their needs, without needing to manage versioning of a public resource. Third parties who want to use the icons are of course free to take (any version of) the resource and use it (and fork it) however they like, but this doesn't create a dependency on mozilla maintaining compatibility of a specific public URL forever.

IMO, that's a much better place for us to be in, overall.

	Arnau March [:arnau] ( not working in Firefox OS anymore :( )
	Comment 38 • 10 years ago

If we include the font in a repo e.g https://github.com/mozilla-b2g/moztt were our other fonts live, we could point 3rd party developers to that repo in case they want to get the icon font we use.
Will be their responsibility going there and check for updates.
No extra maintenance effort from our side.

	Arnau March [:arnau] ( not working in Firefox OS anymore :( )
	Comment 39 • 10 years ago

I maintain buildingfirefoxos.com, so I could also link there to were the font is located.

	Jonathan Kew [:jfkthame] Assignee
	Comment 40 • 10 years ago

(In reply to Arnau March  [:arnau] from comment #38)
> If we include the font in a repo e.g https://github.com/mozilla-b2g/moztt
> were our other fonts live, we could point 3rd party developers to that repo
> in case they want to get the icon font we use.
> Will be their responsibility going there and check for updates.
> No extra maintenance effort from our side.

Sure, that's fine. Of course the font will be available - whether in the moztt repo, or the gaia repo, or wherever - as part of the source of FxOS, and people can take it and use in their own projects. And we can evolve and revise that source at will, and people can use whatever version of it they wish. When we make changes, it's up to them whether and when they grab a new copy and adjust their content accordingly - or keep using their existing version forever.

Just to emphasize: That's entirely separate from the idea in comment 32 and following, that FxOS/Gaia would refer to the font at runtime via a public URL. That's the part that would create a maintenance and stability obligation that I think we should avoid.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 41 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #37)
> (How about just adding new codepoints to the font - keeping the same URL -
> without ever changing or removing old ones? That sort-of-works, but it'll
> create a problem for FxOS devices whose local, hidden font is older than the
> current published one: if pages/apps try to use the new icons, the device
> will use its local font and they'll be missing. We could add code to fall
> back to downloading the remote font in that situation, but it's yet more
> complication....

Maybe it's not that complicated? When we see a family name for the @font-face rule with the special URL, we can expand that to two fonts in the font-group, one for the local font followed by one for the downloadable font. After that, everything would work automatically AFAIK.

The private fonts patches add complexity too, and in more places since the private-fonts-enabled flag has to be plumbed all the way through to layout.

> and in any case I'm not keen on the scenario where we don't
> have the liberty to remove old stuff from the font when Gaia no longer wants
> it.)

I don't think that will be a problem in practice since feature sets, and hence icon usage, tend to expand over time rather than contract. "Semantics-preserving" icon changes can reuse the same codepoints; using a completely different icon to represent the same feature is not likely to happen often.

The cost of unused glyphs in a font is small, anyway.

With the private-fonts approach, it would still be hard to remove glyphs from the font because there could be non-Gaia certified apps using it.

In comment #21 you wrote:
> ...whereas I think it's confusing for FirefoxOS to have a font that behaves differently in certified
> vs non-certified apps: "I copied such-and-such code from another FirefoxOS app; it works fine there,
> but in my project only half the icons show up!"

That remains an issue for the private-fonts approach, but my latest proposal solves it completely; don't you think that's worth something?

	Jonathan Kew [:jfkthame] Assignee
	Comment 42 • 10 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #41)

> Maybe it's not that complicated? When we see a family name for the
> @font-face rule with the special URL, we can expand that to two fonts in the
> font-group, one for the local font followed by one for the downloadable
> font. After that, everything would work automatically AFAIK.

Currently, that implementation approach would cause us to download the resource in all cases, even though we wouldn't use it. (Bug 754215.)


> With the private-fonts approach, it would still be hard to remove glyphs
> from the font because there could be non-Gaia certified apps using it.

I don't think that's much of an issue. Certified apps (IIUC) are a strictly limited group of apps from a known group of developers (in Mozilla and partners) who can reasonably be expected to know the status of the icon font(s) and whether it's appropriate for them to use. Random 3rd-party authors are a different matter, but they won't be producing certified apps.


> In comment #21 you wrote:
> > ...whereas I think it's confusing for FirefoxOS to have a font that behaves differently in certified
> > vs non-certified apps: "I copied such-and-such code from another FirefoxOS app; it works fine there,
> > but in my project only half the icons show up!"
> 
> That remains an issue for the private-fonts approach, 

Not so much; in general, *none* of the icons will show up (or for those that are standard Unicode characters, they'll fall back to some other font, and look different). I think it's pretty easy for an author who encounters this to understand that the Gaia icons font referred to in that CSS is private to Gaia, and doesn't work for other apps. Much easier to grasp this than a situation where bits of it continue to work, and bits fail (the PUA-restriction approach).

> but my latest proposal
> solves it completely; don't you think that's worth something?

Perhaps, but I still feel that it creates much more of a long-term maintenance/management burden, and IMO that's a more important consideration.

Ideally, we wouldn't be using icon fonts like this at all; icons in Gaia would be PNG or SVG resources. We're only doing this because performance is so critical here, and currently using glyphs from a system-installed font gives us the best perf. But we'd like to get to the point where alternatives like SVG images have good enough performance that we can stop using the icon font at all, and no longer need to maintain or ship it. But if we've exposed it at a public URL for all the world's web apps/pages to use, we're stuck with maintaining it there "forever", no matter how we choose to evolve FxOS.

	Jonathan Kew [:jfkthame] Assignee
	Comment 43 • 10 years ago

An additional benefit of the private fonts approach, IMO, is that it's much easier for others to follow it when appropriate. E.g. if a device manufacturer or network partner wants to use a custom icon font for certified apps they're adding, they can benefit from the perf optimization we're after here in exactly the same way: just drop their font into the certified-app-fonts directory. With your new alternative, they'd need to configure an additional "magic URL" for Gecko to recognize (presumably we'd have a list of these URL-to-local-font mappings somewhere, so they can add an entry), and they'd also be taking on the same maintenance/updating issues. ISTM much less likely that this would actually be managed correctly by everyone.

	Jonathan Kew [:jfkthame] Assignee
	Comment 44 • 10 years ago

We've decided against doing this at this point.

Instead, bug 1030829 is providing a means to "preload" local fonts that are hidden from the main font list into the user-font cache, so that apps can use CSS with standard @font-face rules using corresponding data: URIs and get these transparently satisfied by the preloaded local font instead of having to decode, sanitize and load the font separately. On a system that doesn't have the preloaded copy of the font, the data: URI will be used as normal, so nothing should break - it just won't get the optimization.