Re: Icon fonts in FxOS
On 06/17/2014 09:18 PM, James Burke wrote: On 6/17/14, 10:08 AM, Vivien Nicolas wrote: That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now. So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there. I appreciate there are always tradeoffs, but I also want to caution against just proceeding because there is an escape value via certified. We have a train model, and if it takes another train to avoid certified-only, all apps benefit. It is already disconcerting that just switching the type value in the manifest from certified to privileged, we see a 20ms slowdown[1]. TBH I'm not surpised. We (re)discovered last september/october that the CSP in JS was consuming a lot of startup time. Not because the JS code was slow, but because of 1 xpconnect call per file, and apps loads a lot of files. So for certified app, we landed a fast path. It would be good to investigate if this is purely related to the CSP or not, by simply disabling it (security.csp.enable = false), and if yes, investigate if reducing the number of files by aggregating them helps. The greater concern is these certified escapes build up, and then taking the time to undo them later eats into the next certified escape that is wanted, so the gap will continue to grow. A good way to start fighting the issue is to stop adding to the pile. It's true that this is a big concern. The greater concern is that the web platform is not competitive / successful. So in order to mitigate some of the issues, that are always solvable but takes time, we adding to the pile. We know that at some point we have to pay the cost, and we always try to not take this path - sadly sometimes there is no other choice for a given release, and then we need to add to the pile. On icon fonts, it would be good to make sure there implemented with accessibility in mind. This document[1] talks about that, and mentions a Firefox bug[2] about aria-hidden that may need some attention if icon fonts are used in buttons. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005 [2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540 James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Jun 18, 2014, at 2:03 AM, Vivien Nicolas vnico...@mozilla.com wrote: On 06/17/2014 09:18 PM, James Burke wrote: On 6/17/14, 10:08 AM, Vivien Nicolas wrote: That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now. So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there. I appreciate there are always tradeoffs, but I also want to caution against just proceeding because there is an escape value via certified. We have a train model, and if it takes another train to avoid certified-only, all apps benefit. It is already disconcerting that just switching the type value in the manifest from certified to privileged, we see a 20ms slowdown[1]. TBH I'm not surpised. We (re)discovered last september/october that the CSP in JS was consuming a lot of startup time. Not because the JS code was slow, but because of 1 xpconnect call per file, and apps loads a lot of files. So for certified app, we landed a fast path. It would be good to investigate if this is purely related to the CSP or not, by simply disabling it (security.csp.enable = false), and if yes, investigate if reducing the number of files by aggregating them helps. Please profile this. I am sure this can be optimized. We likely don’t need to involve xpconnect here for starters. Thanks, Andreas The greater concern is these certified escapes build up, and then taking the time to undo them later eats into the next certified escape that is wanted, so the gap will continue to grow. A good way to start fighting the issue is to stop adding to the pile. It's true that this is a big concern. The greater concern is that the web platform is not competitive / successful. So in order to mitigate some of the issues, that are always solvable but takes time, we adding to the pile. We know that at some point we have to pay the cost, and we always try to not take this path - sadly sometimes there is no other choice for a given release, and then we need to add to the pile. On icon fonts, it would be good to make sure there implemented with accessibility in mind. This document[1] talks about that, and mentions a Firefox bug[2] about aria-hidden that may need some attention if icon fonts are used in buttons. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005 [2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540 James ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Tue, Jun 17, 2014 at 5:09 AM, James Burke jbu...@mozilla.com wrote: On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. I agree that it's great when we can move to a privileged app. Though if it comes at the cost of a 500ms or 150ms slowdown then that might not be worth it. Another thing that will likely force us to use certified apps for now is Web Components. We are only enabling those for certified apps for now since we want to have freedom to make changes to the spec and the implementation without worrying about breaking other apps or webpages. Can the email app work without Web Components? Either way, I definitely agree that, we should certainly look at reducing those 150ms. But do people really feel comfortable with making that the only plan? Can we make that happen for Gecko 34 (September 1st)? At what point do we start working on a backup plan such as the ones discussed in this thread? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/18/14 8:25 AM, Jonas Sicking wrote: Another thing that will likely force us to use certified apps for now is Web Components. We are only enabling those for certified apps for now since we want to have freedom to make changes to the spec and the implementation without worrying about breaking other apps or webpages. Can the email app work without Web Components? Either way, I definitely agree that, we should certainly look at reducing those 150ms. But do people really feel comfortable with making that the only plan? Can we make that happen for Gecko 34 (September 1st)? At what point do we start working on a backup plan such as the ones discussed in this thread? So this is the heart of the matter (at least for email/gaia apps and the idea of privileged): certified is being used as an implementation pref switch. There will always be new things we will want to try, and it helps if Gecko has a well-constrained set of web apps to try it out, to work out any issues in the Gecko implementation, maybe help give early feedback on specs. We need a controlled space that also gets some real world use, but where we can hopefully update as the Gecko implementation changes. I am particularly interested in service workers because I am hopeful it will eliminate the need for email's cookie cache that is used for fast startup. I expect that will also only be enabled for certified apps in the beginning. This comes at a cost: Gaia apps will not be able to do installs/updates via the Marketplace, which also makes it hard to use them on Android via the web runtime, but the hope is that by having this early testing we have better APIs and implementations for the web platform in the long run. So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be privileged, because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. In the short term this creates a bit of an issue for email. The privileged setting helped with the new CSP policy desires (bug 1012652) but since email is part of gaia, and email uses some of the shared resources, I filed bug 1027185 to switch email back to certified, and we'll have to use another approach for bug 1012652. I will confirm the cause of the slowdown for bug 1024005 before switching email back to certified. That should end the privileged diversion for this thread. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Wed, Jun 18, 2014 at 6:59 PM, James Burke jbu...@mozilla.com wrote: So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be privileged, because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. We said that a year or two ago. There will always be new features to test, and with a current total of 34 apps in the gaia/apps directory we have no shortage of certified apps to test them out with. The risk of inadvertently building another proprietary app platform that isn't the web and of crippling the pace of Firefox OS updates because we're forcing 34 apps through an arduous certification process they don't need (a mistake Android already made for us) seems greater than the risk of taking the brave step of making some Gaia apps a step closer to being web apps. The longer that each Gaia app is not a web app, the less credible our mantra of the web is the platform becomes. If we can't figure out how to build our own apps using the web, how can we can expect third party app developers to do so? Maybe we haven't yet figured out all the details of how to put the Email app in the Firefox Marketplace, let alone how to make it run cross-platform, but if we resign ourselves to the idea that all Gaia apps are going to have to be certified for the foreseeable future then we're not doing our mission justice IMHO. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/18/14 12:20 PM, Ben Francis wrote: On Wed, Jun 18, 2014 at 6:59 PM, James Burke jbu...@mozilla.com mailto:jbu...@mozilla.com wrote: So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be privileged, because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. We said that a year or two ago. There will always be new features to test, and with a current total of 34 apps in the gaia/apps directory we have no shortage of certified apps to test them out with. The risk of inadvertently building another proprietary app platform that isn't the web and of crippling the pace of Firefox OS updates because we're forcing 34 apps through an arduous certification process they don't need (a mistake Android already made for us) seems greater than the risk of taking the brave step of making some Gaia apps a step closer to being web apps. The longer that each Gaia app is not a web app, the less credible our mantra of the web is the platform becomes. If we can't figure out how to build our own apps using the web, how can we can expect third party app developers to do so? Maybe we haven't yet figured out all the details of how to put the Email app in the Firefox Marketplace, let alone how to make it run cross-platform, but if we resign ourselves to the idea that all Gaia apps are going to have to be certified for the foreseeable future then we're not doing our mission justice IMHO. It is a matter of degree: at least with Gaia apps we get the use of web tech in the construction, just not the network delivery and addressability, and by proving out the web APIs in Gaia first, we ensure a better dev experience with those APIs later for all. That is how I would frame the larger picture, in the effort of cooperation and moving forward. For me personally, I would absolutely not put a performance fix that is only available for certified apps. See the use of the cookie cache in email: it is ugly, but it is standard. Sometimes we need to do the uglier things or have less ideal dev experience in the interests of working on the common platform, file bugs for the platform, then switch to something better when it is properly sorted out, available to all apps. For email's cookie cache, I'm hopeful the proper answer will be Service Workers. But, I am not working on that platform code affected by the icon font request, so it is easier for me to be harder philosophically in that case. I would endorse that harder line though for performance changes tied to certified. New features only in certified apps is a harder one to sort out. I personally want to avoid features that are only available to certified apps in email. However, since email depends on /shared, some of that choice is out of email's control. Maybe instead of using certified as the marker, we use app signing instead, with a list of signatures that are allowed getting pushed as part of device flashing, and a dev experience that overrides that, so that we do not have to sign for our local dev-debug-deploy cycles. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Thu, Jun 19, 2014 at 3:20 AM, Ben Francis bfran...@mozilla.com wrote: On Wed, Jun 18, 2014 at 6:59 PM, James Burke jbu...@mozilla.com wrote: So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be privileged, because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. Maybe we haven't yet figured out all the details of how to put the Email app in the Firefox Marketplace, let alone how to make it run cross-platform, but if we resign ourselves to the idea that all Gaia apps are going to have to be certified for the foreseeable future then we're not doing our mission justice IMHO. I'm all for making Gaia apps be privileged apps. It both enables us to put it in the marketplace and puts more pressure on us to move the privileged apps platform forward. The work to make Loop and the homescreen only use privileged APIs has brought many advantages to the privileged apps ecosystem. Even better is to make Gaia apps be non-privileged normal hosted apps as that does the same thing to the web. Calculator, if we shipped it, could likely fall into this category already today. But we have to realize that it comes at a cost. Right now it would mean not using Web Components and (until we speed up Gecko) a 150ms startup cost. 6 months from now the costs would likely not be zero, as you point out, but they would hopefully be different. So the question is when do we make this transition? I.e. when are the above costs acceptable? I'm happy to leave that decision up to the teams working on the individual apps. But just because the answer is not now, doesn't mean that the answer is never. In the meantime, trying to stick to privileged permissions, or to normal permissions, gives some of the benefit while making it possible to avoid some of the costs. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`. Is this what you were referring to? W. - Original Message - From: Jet Villegas j...@mozilla.com To: Wilson Page wilsonp...@mozilla.com Cc: Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, Jonathan Kew j...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 12:54:57 AM Subject: Re: Icon fonts in FxOS Wilson: How difficult would it be to have your grunt script add a dlig table to your font? https://www.microsoft.com/typography/otspec/features_ae.htm#dlig https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 --Jet - Original Message - From: Wilson Page wilsonp...@mozilla.com We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is 12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts. I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue? IMO we should just treat icon assets in the same way we do images assets. Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains. At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform. W. - Original Message - From: Jonathan Kew j...@mozilla.com To: Wilson Page wilsonp...@mozilla.com, Jet Villegas j...@mozilla.com Cc: Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 11:31:18 AM Subject: Re: Icon fonts in FxOS On 17/6/14 11:10, Wilson Page wrote: The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`. Is this what you were referring to? OK, so if you're using ligatures to access the icon glyphs, can you modify the script that generates this font so that it does NOT assign PUA codepoints to the glyphs at all? It should be possible to leave them unencoded (i.e. with no entry in the font's cmap), so that the only way they can be accessed is via the ligature sequence. I see you're embedding the generated font directly in a CSS file as a data-URL. How's the performance of this approach? It won't be quite as efficient as installing the font in the base OS, because each app that uses it will be instantiating its own separate copy, so there must be a memory and perf cost. But maybe it's good enough? JK blockquote - Original Message - From: Jet Villegas j...@mozilla.com To: Wilson Page wilsonp...@mozilla.com Cc: Patryk Adamczyk padamc...@mozilla.com , John Daggett jdagg...@mozilla.com , b2g-internal b2g-inter...@mozilla.org , Cameron McCormack hey...@gmail.com , Jonathan Watt jw...@mozilla.com , L. David Baron dba...@mozilla.com , Jaime Chen jac...@mozilla.com , Vivien vnico...@mozilla.com , sicking sick...@mozilla.com , Robert O'Callahan rocalla...@mozilla.com , Jonathan Kew j...@mozilla.com , mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 12:54:57 AM Subject: Re: Icon fonts in FxOS Wilson: How difficult would it be to have your grunt script add a dlig table to your font? https://www.microsoft.com/typography/otspec/features_ae.htm#dlig https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 --Jet - Original Message - From: Wilson Page wilsonp...@mozilla.com We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. /blockquote ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page wilsonp...@mozilla.com wrote: Maybe I'm late to the party, but I don't know what the PUA issue is? Code points carry semantics. If you assign meaning to unassigned code points through fonts, you have created a portability problem. That is, the font is required to make sense out of the code points. This was a problem with Emoji until it was standardized by Unicode. It would be good to avoid doing that again. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block. - Original Message - From: Anne van Kesteren ann...@annevk.nl To: Wilson Page wilsonp...@mozilla.com Cc: Jonathan Kew j...@mozilla.com, Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Jonathan Watt jw...@mozilla.com, Jet Villegas j...@mozilla.com, Cameron McCormack hey...@gmail.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 12:26:19 PM Subject: Re: Icon fonts in FxOS On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page wilsonp...@mozilla.com wrote: Maybe I'm late to the party, but I don't know what the PUA issue is? Code points carry semantics. If you assign meaning to unassigned code points through fonts, you have created a portability problem. That is, the font is required to make sense out of the code points. This was a problem with Emoji until it was standardized by Unicode. It would be good to avoid doing that again. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
grunt-webfont is where the magic lives :) - Original Message - From: Jonathan Kew j...@mozilla.com To: Wilson Page wilsonp...@mozilla.com, Anne van Kesteren ann...@annevk.nl Cc: Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Jonathan Watt jw...@mozilla.com, Jet Villegas j...@mozilla.com, Cameron McCormack hey...@gmail.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 2:22:03 PM Subject: Re: Icon fonts in FxOS On 17/6/14 13:17, Wilson Page wrote: If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block. Right, if we're embedding the font in our apps rather than installing it in the OS, then the PUA codepoints it includes aren't likely to be exposed to the world in general. Still, it'd be cleaner to eliminate them - especially if we expect this may be adopted by other authors as well. Where is the script that generates this font maintained? JK blockquote - Original Message - From: Anne van Kesteren ann...@annevk.nl To: Wilson Page wilsonp...@mozilla.com Cc: Jonathan Kew j...@mozilla.com , Patryk Adamczyk padamc...@mozilla.com , John Daggett jdagg...@mozilla.com , b2g-internal b2g-inter...@mozilla.org , L. David Baron dba...@mozilla.com , Jaime Chen jac...@mozilla.com , Jonathan Watt jw...@mozilla.com , Jet Villegas j...@mozilla.com , Cameron McCormack hey...@gmail.com , Vivien vnico...@mozilla.com , sicking sick...@mozilla.com , Robert O'Callahan rocalla...@mozilla.com , mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Tuesday, June 17, 2014 12:26:19 PM Subject: Re: Icon fonts in FxOS On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page wilsonp...@mozilla.com wrote: Maybe I'm late to the party, but I don't know what the PUA issue is? Code points carry semantics. If you assign meaning to unassigned code points through fonts, you have created a portability problem. That is, the font is required to make sense out of the code points. This was a problem with Emoji until it was standardized by Unicode. It would be good to avoid doing that again. -- http://annevankesteren.nl/ /blockquote ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 17/6/14 13:17, Wilson Page wrote: If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block. Right, if we're embedding the font in our apps rather than installing it in the OS, then the PUA codepoints it includes aren't likely to be exposed to the world in general. Still, it'd be cleaner to eliminate them - especially if we expect this may be adopted by other authors as well. Where is the script that generates this font maintained? JK *From: *Anne van Kesteren ann...@annevk.nl *To: *Wilson Page wilsonp...@mozilla.com *Cc: *Jonathan Kew j...@mozilla.com, Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Jonathan Watt jw...@mozilla.com, Jet Villegas j...@mozilla.com, Cameron McCormack hey...@gmail.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org *Sent: *Tuesday, June 17, 2014 12:26:19 PM *Subject: *Re: Icon fonts in FxOS On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page wilsonp...@mozilla.com wrote: Maybe I'm late to the party, but I don't know what the PUA issue is? Code points carry semantics. If you assign meaning to unassigned code points through fonts, you have created a portability problem. That is, the font is required to make sense out of the code points. This was a problem with Emoji until it was standardized by Unicode. It would be good to avoid doing that again. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 17/6/14 11:52, Wilson Page wrote: I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is 12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts. I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue? I looked at the embedded font in your CSS file, and it has the icons encoded at PUA character codes U+E001..E01D. If we could avoid exposing PUA codes at all, that would be helpful, as it eliminates any risk that authors actually use (non-portable) PUA codes to render the icons. AFAIK, it should be possible to do this. In fontforge, the glyphs are referenced by name; they shouldn't need codepoints assigned. IMO we should just treat icon assets in the same way we do images assets. Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains. At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform. If this works acceptably, can we close bug 951593 (and 1008458) as WontFix? That'd be awesome, IMO, as none of the proposed strategies there are really satisfactory. Where are we at w.r.t. the launch regression that was filed as bug 1002904? Has the data-URL version of the embedded font been tried there? One other optimization you might want to consider - especially as the icon collection grows - is to have your build scripts generate a custom font subset for each app that's using them, instead of having all the apps (separately) load the complete set of icons even if they only need a few. So the original collection of graphics would be a shared building block resource, but the actual CSS that embeds the font would be individually generated for each app depending on its needs. (Presumably it'd be simple to scan the app's files and determine exactly which icons it needs.) JK W. *From: *Jonathan Kew j...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com, Jet Villegas j...@mozilla.com *Cc: *Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org *Sent: *Tuesday, June 17, 2014 11:31:18 AM *Subject: *Re: Icon fonts in FxOS On 17/6/14 11:10, Wilson Page wrote: The gaia-icons font currently uses ligatures to place icons, see here https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32. The ligature character sequence is derived from the original filename of the SVG source file in `images/`. Is this what you were referring to? OK, so if you're using ligatures to access the icon glyphs, can you modify the script that generates this font so that it does NOT assign PUA codepoints to the glyphs at all? It should be possible to leave them unencoded (i.e. with no entry in the font's cmap), so that the only way they can be accessed is via the ligature sequence. I see you're embedding the generated font directly in a CSS file as a data-URL. How's the performance of this approach? It won't be quite as efficient as installing the font in the base OS, because each app that uses it will be instantiating its own separate copy, so there must be a memory and perf cost. But maybe it's good enough? JK *From: *Jet Villegas j...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com *Cc: *Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, Jonathan Kew j...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org *Sent: *Tuesday, June 17, 2014 12:54:57 AM *Subject: *Re: Icon fonts in FxOS Wilson: How difficult would it be to have your grunt script add a dlig table to your font? https://www.microsoft.com/typography/otspec/features_ae.htm#dlig https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 --Jet - Original Message - From: Wilson Page wilsonp...@mozilla.com We
Re: Icon fonts in FxOS
On 16/06/14 21:34, Jet Villegas wrote: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) For 1.4, a 5th option is that we don't use icon fonts. Which apps are currently using them in 1.4? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 06/16/2014 09:34 PM, Jet Villegas wrote: Hi All: We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team understandably wants to squeeze every bit of performance on their apps in v1.4: https://bugzilla.mozilla.org/show_bug.cgi?id=951593 We are concerned about leaking these fonts into Open Web content, so we want to restrict it to certified Gaia apps: https://bugzilla.mozilla.org/show_bug.cgi?id=1008458 The approach we take to restrict icon fonts to certified Gaia apps is under some debate, and we've got 4 possibilities: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 release, so I'm inclined to let the Gaia team use the icon font as-is (option 1) with the promise that they won't use it in uncertified non-system apps. I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) Ideally we would like to use SVG instead of Icon Fonts in Gaia for many use cases. But I believe the SVG performance won't be as good an Icon Font baked into the platform in the 2.1 timeframe. 3 seems agressive. PUA has always worked on the web AFAIK and it's unclear to me why we want to changed this. 4 seems like an obfuscation mechanism, which is smart, but won't prevent what 2 and 3 try to prevent, which is leaking our glyphs on the web. I'm not saying I like 2 - it always sad when we have to do a certified-only hack - but it seems the cleaner approach as it draw a clear line between regular and this private font without regressing things that already works, or trying to hide the feature even if it works. Then once SVG would be good enough, yes I believe we will use it. Vivien. Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 06/17/2014 06:01 PM, Wilson Page wrote: Just to clarify: I am in favor of icon-fonts, but less baking them into the system. Do we have perf figures comparing normal @font-face loading (external or inlined) compared to the baked in solution? Yeah, looked at comment 37 of bug 948856. Between not baking it, and baking it, there is a 500ms diff :/ *From: *Vivien Nicolas vnico...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com, Jonathan Kew j...@mozilla.com *Cc: *Jet Villegas j...@mozilla.com, Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org *Sent: *Tuesday, June 17, 2014 4:48:19 PM *Subject: *Re: Icon fonts in FxOS Just want to make sure that there is no misunderstanding here: based on the data from https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37, some experience with loading icon fonts versus images versus svg that has been described on dev-gaia, *preloading the font is needed*. On 06/17/2014 12:52 PM, Wilson Page wrote: I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is 12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts. Performance is not always related to the size of the asset. For example last time I found that we consume 2.4mb of memory all the time in the System app because we were loading 4 times an image asset of 3k. Every time this asset was rendered it was consuming 600k of memory. This asset was a gradient and it was expensive to render it. When you consider the size of the asset in this case, you should also consider at which time it is read, if is it going to trigger some invalidations because the image will arrive after the app is rendered, how long will it take for the font subsystem to render those glyphs, can we save some memory by using some system features, instead of having a local copy in all apps, etc... I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue? IMO we should just treat icon assets in the same way we do images assets. Image assets may be slow. We run into this issue multiple times in the Settings app. Replacing our current image assets icons with an icon font baked into the platform shave ~300ms of load time. Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains. Obviously 300ms is not negligible :) Also in terms of memory there is an impact too, and since we're targeting very low end devices, I expect this to be useful too. The current mechanism used by Gecko to discard images help us to reduce the memory overhead here for background apps, but it has the side effect that the image needs to be re-decoded when the app goes to foreground and it takes time (you see images flashes when the images are re-decoded / repainted). So icon font would make some apps to load faster, consume less memory, and avoid some glitches when the app goes from background to foreground. Definitively not negligible. At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform. What you say here is true. And we would all like to use only simple web features, and that's definitively the goal. But while we are heading up to this goal, we sometimes needs to do some trade-offs, and using icon fonts is one of them. It does not mean there is more distance from the real web platform, as I believe that while Gaia use icon fonts, a lot of efforts will be done on the svg side in order to replace the icon font with SVG when it will be time to do so. So you should see that as: it makes us more competitive in this extremely competitive area, and offers us a bit more time to fix the real issue, which is that SVG does not fit yet, and beside that, to fix the web platform to make it becomes reals on mobile. Vivien. W. *From: *Jonathan Kew j...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com, Jet Villegas j...@mozilla.com *Cc: *Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan
Re: Icon fonts in FxOS
On 06/17/2014 06:51 PM, Jonathan Kew wrote: On 17/6/14 17:02, Vivien Nicolas wrote: On 06/17/2014 06:01 PM, Wilson Page wrote: Just to clarify: I am in favor of icon-fonts, but less baking them into the system. Do we have perf figures comparing normal @font-face loading (external or inlined) compared to the baked in solution? Yeah, looked at comment 37 of bug 948856. Between not baking it, and baking it, there is a 500ms diff :/ If I'm reading bug 948856 correctly, the difference may have been somewhat less (150ms? comment 17) when the font was inlined in the CSS using a data URI, rather than loaded from a separate file. The 150ms is going from gif - icon font if I read correctly too. And moving it into moztt was 10 ms better. It seems somewhat different than what is state in comment 37, which says: 3- Replacing gif with icon font with the font in shared/style (median: 1595) 4- Replacing gif with icon font with the font in system/fonts (median: 1010) It worth double checking the time here. If we can't afford that, then we still need some other solution here. But jburke said that we're generally downgrading apps from certified to privileged as much as possible. If the system-installed icon font were available only to certified apps, would this adequately address the issue? Any Gaia apps that go from certified to privileged would need to adopt a separate (lower-perf) approach at that point. That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now. So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there. This could be solved by roc's suggestion of providing the font through @font-face with a public mozilla URL, which the platform then recognizes and special-cases to use a locally preinstalled copy instead, but I'm not really comfortable with making all this dependent on a public URL (which we're then obligated to maintain forever, so as not to break other people's apps that may start to depend on it). I'd prefer a solution that is purely an internal optimization in the FxOS device, and not exposed to the Web at all. For certified apps, we could do that; but if it needs to be available to non-certified Gaia apps as well, it's less clear how we can handle this. We could extend use of the private font to privileged as well as certified apps, but does that make it too public to be healthy? It still wouldn't be leaking to the general Web, but we might find that a lot of 3rd-party apps start to depend on it, and thus risk breaking any time we want to revise it for Gaia (or switch Gaia to some completely different solution such as SVG images). For the moment, I think we should just consider |certified| app. JK *From: *Vivien Nicolas vnico...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com, Jonathan Kew j...@mozilla.com *Cc: *Jet Villegas j...@mozilla.com, Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org *Sent: *Tuesday, June 17, 2014 4:48:19 PM *Subject: *Re: Icon fonts in FxOS Just want to make sure that there is no misunderstanding here: based on the data from https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37, some experience with loading icon fonts versus images versus svg that has been described on dev-gaia, *preloading the font is needed*. On 06/17/2014 12:52 PM, Wilson Page wrote: I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is 12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts. Performance is not always related to the size of the asset. For example last time I found that we consume 2.4mb of memory all the time in the System app because we were loading 4 times an image asset of 3k. Every time this asset was rendered it was consuming 600k of memory. This asset was a gradient and it was expensive to render it. When you consider
Re: Icon fonts in FxOS
On 6/17/14, 10:08 AM, Vivien Nicolas wrote: That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now. So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there. I appreciate there are always tradeoffs, but I also want to caution against just proceeding because there is an escape value via certified. We have a train model, and if it takes another train to avoid certified-only, all apps benefit. It is already disconcerting that just switching the type value in the manifest from certified to privileged, we see a 20ms slowdown[1]. The greater concern is these certified escapes build up, and then taking the time to undo them later eats into the next certified escape that is wanted, so the gap will continue to grow. A good way to start fighting the issue is to stop adding to the pile. On icon fonts, it would be good to make sure there implemented with accessibility in mind. This document[1] talks about that, and mentions a Firefox bug[2] about aria-hidden that may need some attention if icon fonts are used in buttons. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005 [2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540 James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On Wed, Jun 18, 2014 at 4:51 AM, Jonathan Kew j...@mozilla.com wrote: If I'm reading bug 948856 correctly, the difference may have been somewhat less (150ms? comment 17) when the font was inlined in the CSS using a data URI, rather than loaded from a separate file If we can't afford that, then we still need some other solution here. Maybe we should investigate that 150ms performance difference further, and try to reduce it? Seems to me it wouldn't be hard to build a toy page that uses some fonts with embedded data: URIs, measure its load performance, and identify chunks of the profile related to font loading/rendering. AFAIK no-one's really tried to optimize this case and there's probably some low-hanging fruit. Jonathan, B2G doesn't share user font instances across apps (assuming 1 app per process) in any way, right? And it doesn't share rasterized glyphs across processes either? I'm wondering what extra costs there are of using a user data: URL font are vs referencing a system font. I guess usually the system font gets mmaped so it's already in memory without having to do any loading, conversion or decompression. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Icon fonts in FxOS
Hi All: We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team understandably wants to squeeze every bit of performance on their apps in v1.4: https://bugzilla.mozilla.org/show_bug.cgi?id=951593 We are concerned about leaking these fonts into Open Web content, so we want to restrict it to certified Gaia apps: https://bugzilla.mozilla.org/show_bug.cgi?id=1008458 The approach we take to restrict icon fonts to certified Gaia apps is under some debate, and we've got 4 possibilities: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 release, so I'm inclined to let the Gaia team use the icon font as-is (option 1) with the promise that they won't use it in uncertified non-system apps. I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. In general, I prefer solutions that do not require certified status, as I hope more apps for gaia can move to privileged and even be delivered through the Marketplace and for Android devices that can use Marketplace apps. I can appreciate there are other factors involved, just mentioning a general desire to move more to apps out of the certified embrace. For email, I will likely look for any alternatives that allow us to stay privileged instead of reverting to certified. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
Comments inline. 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain. It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings. 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG. I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better. --- Patryk Adamczyk, R.G.D. Design Manager - Visual Design, Firefox OS Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 16/6/14 22:09, James Burke wrote: On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. In general, I prefer solutions that do not require certified status, as I hope more apps for gaia can move to privileged and even be delivered through the Marketplace and for Android devices that can use Marketplace apps. I can appreciate there are other factors involved, just mentioning a general desire to move more to apps out of the certified embrace. For email, I will likely look for any alternatives that allow us to stay privileged instead of reverting to certified. OK, that's useful info, thanks! And it significantly changes the picture, as it means that implementing a platform-level solution targeting certified apps may be less useful than expected. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. Icon fonts are perfect for our themeability requirements as they can easily by styled with CSS. AFAIK SVGs cannot be colored/styled with CSS alone (but I don't know that much about SVG). We've been using icon-fonts in Camera for a while now and so far it's been great. I plan to move Camera to pull its icon-font from gaia-icons so that we can begin to move to toward a central icons store. IMO SVG and icon-fonts will always serve slightly difference use cases. But for simple icons, icon-fonts have always got the job done; allowing me to focus on the more important stuff :p W. - Original Message - From: Patryk Adamczyk padamc...@mozilla.com To: Jet Villegas j...@mozilla.com Cc: John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, Jonathan Kew j...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Monday, June 16, 2014 10:14:19 PM Subject: Re: Icon fonts in FxOS Comments inline. 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain. It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings. blockquote 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) /blockquote To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG. blockquote I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) /blockquote We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better. --- Patryk Adamczyk, R.G.D. Design Manager - Visual Design, Firefox OS Mozilla Corporation ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
(2014/06/17 4:34), Jet Villegas wrote: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) Actually WingDings can NOT be used at least on desktop Firefox because it does not have a unicode cmap. Does Firefox OS have an option to relax this restriction? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
Wilson: How difficult would it be to have your grunt script add a dlig table to your font? https://www.microsoft.com/typography/otspec/features_ae.htm#dlig https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 --Jet - Original Message - From: Wilson Page wilsonp...@mozilla.com We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
