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

Reply via email to