Re: Intent to implement: WOFF2 webfont format
> OK. So it can work if every browser that supports the format puts in in > Accept: as soon as it begins support. That may be true of WebP; I don't > believe it's true of WOFF. Is it? > > you need to opt-in to the transcoding, yes. But you make it sound like you can't use woff at all without transcoding, and that's not true. Doing the right http thing doesn't interfere with also doing the right css thing. Indeed we've been using woff with that crazy text/xml header - just changing it to reflect our true preferences enables both scenarios. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Tue, Oct 7, 2014 at 4:53 PM, Patrick McManus wrote: > content format negotiation is what accept is meant to do. I'm aware, but I think format negotiation on the HTTP layer is a misfeature that we shouldn't keep treating as if it was a good feature (for reasons given in https://wiki.whatwg.org/wiki/Why_not_conneg ; I used to believe in Accept a decade ago, but back then I believed in XML, too). On Wed, Oct 8, 2014 at 7:17 PM, Patrick McManus wrote: > accelerators like cloudflare and mod_pagespeed/mod_proxy exist to do this > kind of general thing as reverse proxies for specific origins.. they can > cache the transcoding locally. I can see how *in theory* it seems attractive to cater to the idea of the origin server serving bloated files and a drop-in reverse-proxy magically doing things right thanks to HTTP headers. But (in no specific order): * The process for minting MIME types for fonts is so broken that it's not worth bothering. * The idea only works if other WOFF2-supporting browsers consistently sent the MIME type (that's too hard to mint) in the Accept header, too. * It would seem more worthwhile to think this is a real use case if there was ample evidence of optimizer software existing from TrueType to WOFF1. Is there such evidence? * If you really want to do this optimization and get to rewrite responses with the origin server's permission, why not rewrite the CSS to list various formats such that they get generated URLs (appended query strings) and then make the font converter look at the query string? (That is, if Cloudflare/mod_pagespeed truly want to do this, the lack of Accept is not stopping them.) > Obviously that's a lot harder for forward proxies to do. Reverse proxies are > often > the termination of https:// as well - so this transformation remains relevant > in the > https world we want. Yeah, considering the https world we want, we should treat forward proxies as adversaries and not something to cater to. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 08/10/14 15:44, Patrick McManus wrote: > I'm not aware of font negotiation - but negotiation is most useful when > introducing new types (such as woff2). The google compression proxy already > does exactly that for images and people are successfully using the AWS > cloudfront proxy in environments where the same thing is done. Accept is > used to opt-in to webp on those services and that allows them to avoid > doing UA sniffing. OK. So it can work if every browser that supports the format puts in in Accept: as soon as it begins support. That may be true of WebP; I don't believe it's true of WOFF. Is it? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 2:15 PM, Robert Kaiser wrote: > Jonathan Kew schrieb: >> >> But the model for webfonts is explicitly *not* to have a single URL that >> may be delivered in any of several formats, but rather to offer several >> distinct resources with different URLs, and let the browser decide which >> of them to request. >> >> So the "negotiation" is handled within the browser > > > Right. And if I remember correctly, we also just invented the > element for HTML5 to do the same for images as it's actually *better* in > many regards to the dilemma we have with all the Accept: negotiation. Or am > I wrong there? Sometimes client side negotiation is the better solution, sometimes server side is. It can be a pain in the ass to try to get your hosting provider to install modules that handles content negotiation based on accept. Or to switch service provider to one that lets you run server side script. Or learn your server infrastructure to figure out how to add negotiation. In those cases it's great that developers can handle it on the client. But there are also cases when it's a pain to figure out the client side code to modify it to pass through the right parameters to do negotiation on the client. Or to ask all your customers to rewrite their apps to handle content negotiation. Or find all the places where your referring to a given resource and replace it with logic to do client side negotiation. In those cases it's good if the server has access to all the information needed to serve the most appropriate resource. When we design the platform such that we require people to use a particular solution we better be really sure that that solution will work in all the (common) situations that people need the problem solved. When we get it wrong, which so far happens a lot, people end up with horrible workarounds, buggy apps, slower productivity and more resource usage. In short, with a worse user experience. We far too often close our eyes to the realities of web development in an effort to keep the platform simple. However simple doesn't always mean fewer features. When developers have to work around the lack of features that doesn't make their jobs simpler. That said, adding all the features isn't always the answer either of course. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
Jonathan Kew schrieb: But the model for webfonts is explicitly *not* to have a single URL that may be delivered in any of several formats, but rather to offer several distinct resources with different URLs, and let the browser decide which of them to request. So the "negotiation" is handled within the browser Right. And if I remember correctly, we also just invented the element for HTML5 to do the same for images as it's actually *better* in many regards to the dilemma we have with all the Accept: negotiation. Or am I wrong there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 12:03 PM, Jonathan Kew wrote: > Possible in theory, I guess; unlikely in practice. The compression > algorithm used in WOFF2 is extremely asymmetrical, offering fast decoding > but at the cost of slow encoding. The intent is that a large library like > Google Fonts can pre-compress their fonts offline, and then benefit from > serving smaller files; it's not expected to be suitable for on-the-fly > compression. > accelerators like cloudflare and mod_pagespeed/mod_proxy exist to do this kind of general thing as reverse proxies for specific origins.. they can cache the transcoding locally. Obviously that's a lot harder for forward proxies to do. Reverse proxies are often the termination of https:// as well - so this transformation remains relevant in the https world we want. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 8/10/14 16:48, Patrick McManus wrote: On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote: On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus mailto:mcma...@ducksong.com>> wrote: > intermediaries, as I mentioned before, are a big reason. It provides an > opt-in opportunity for transcoding where appropriate (and I'm not claiming > I'm up to speed on the ins and outs of font coding). If the format is negotiated client-side before a URL is fetched, that's not going to help, is it? scenario - origin only enumerates ttf in the css, client requests ttf (accept: woff2, */*), intermediary transcodes to woff2 assuming such a transcoding is a meaningful operation. Possible in theory, I guess; unlikely in practice. The compression algorithm used in WOFF2 is extremely asymmetrical, offering fast decoding but at the cost of slow encoding. The intent is that a large library like Google Fonts can pre-compress their fonts offline, and then benefit from serving smaller files; it's not expected to be suitable for on-the-fly compression. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren wrote: > On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus > wrote: > > intermediaries, as I mentioned before, are a big reason. It provides an > > opt-in opportunity for transcoding where appropriate (and I'm not > claiming > > I'm up to speed on the ins and outs of font coding). > > If the format is negotiated client-side before a URL is fetched, > that's not going to help, is it? > > scenario - origin only enumerates ttf in the css, client requests ttf (accept: woff2, */*), intermediary transcodes to woff2 assuming such a transcoding is a meaningful operation. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus wrote: > intermediaries, as I mentioned before, are a big reason. It provides an > opt-in opportunity for transcoding where appropriate (and I'm not claiming > I'm up to speed on the ins and outs of font coding). If the format is negotiated client-side before a URL is fetched, that's not going to help, is it? -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 11:18 AM, Jonathan Kew wrote: > > So the "negotiation" is handled within the browser, on the basis of the > information provided in the CSS stylesheet, *prior* to sending any request > for an actual font resource. > > I'm not advocating that we don't do the css bits too. That's all cool. Jonas's suggestion was also adding an appropriate accept bit. > Given that this is the established model, defined in the spec for > @font-face and implemented all over the place, I don't see much value in > adding things to the Accept header for the actual font resource request. > intermediaries, as I mentioned before, are a big reason. It provides an opt-in opportunity for transcoding where appropriate (and I'm not claiming I'm up to speed on the ins and outs of font coding). y'all can do what you want - but using protocol negotiation in addition to the css negotiation is imo a good thing for the web. > FWIW, when DNT was being created HTTP request header byte count seemed to > be a pretty strong concern, which (AIUI) was why we ended up with DNT: 1 > rather than something clearer like DoNotTrack: true. > > I know - but I disagree pretty strongly with the analysis there. The impact is extremely marginal... and trust me, I'm very interested in HTTP performance :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 8/10/14 15:44, Patrick McManus wrote: On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham mailto:g...@mozilla.org>> wrote: On 07/10/14 14:53, Patrick McManus wrote: > content format negotiation is what accept is meant to do. Protocol level > negotiation also allows designated intermediaries to potentially transcode > between formats. Do you know of any software which transcodes font formats on the fly as they move across the network? I'm not aware of font negotiation - but negotiation is most useful when introducing new types (such as woff2). The google compression proxy already does exactly that for images and people are successfully using the AWS cloudfront proxy in environments where the same thing is done. Accept is used to opt-in to webp on those services and that allows them to avoid doing UA sniffing. They don't normally give firefox webp, but if you make an add-on that changes the accept header to include webp they will serve firefox that format. That's what we want to encourage instead of UA sniffing. But the model for webfonts is explicitly *not* to have a single URL that may be delivered in any of several formats, but rather to offer several distinct resources with different URLs, and let the browser decide which of them to request. So the "negotiation" is handled within the browser, on the basis of the information provided in the CSS stylesheet, *prior* to sending any request for an actual font resource. Given that this is the established model, defined in the spec for @font-face and implemented all over the place, I don't see much value in adding things to the Accept header for the actual font resource request. Even where a service (like Google fonts, AIUI) is currently sniffing UA versions and varying its behavior, it wouldn't help to advertise WOFF2 support via the Accept header for the font request, because that won't result in them serving the appropriate WOFF2-supporting CSS to Firefox. We need to get them to serve the right CSS; and once they do that (either universally, or based on UA sniffing) the existing @font-face mechanism will let us choose the best of the available resource formats for our use. > imo you should add woff2 to the accept header. as with webp, this is particularly useful to opt-in to a new format. I agree that as a list of legacy formats and q-values is all rather useless, but as a signal that you want something new that might not be widely implemented its a pretty good thing. In this case its certainly better than the txt/html based header being used. Do you know of any software which pays attention to this header? above. http request header byte counts aren't something to be super concerned with within reason (uris, cookies, and congestion control pretty much determine your performance fate on the request side). And it sounds like wrt fonts the accept header could be made more relevant and actually smaller as well. FWIW, when DNT was being created HTTP request header byte count seemed to be a pretty strong concern, which (AIUI) was why we ended up with DNT: 1 rather than something clearer like DoNotTrack: true. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham wrote: > On 07/10/14 14:53, Patrick McManus wrote: > > content format negotiation is what accept is meant to do. Protocol level > > negotiation also allows designated intermediaries to potentially > transcode > > between formats. > > Do you know of any software which transcodes font formats on the fly as > they move across the network? > I'm not aware of font negotiation - but negotiation is most useful when introducing new types (such as woff2). The google compression proxy already does exactly that for images and people are successfully using the AWS cloudfront proxy in environments where the same thing is done. Accept is used to opt-in to webp on those services and that allows them to avoid doing UA sniffing. They don't normally give firefox webp, but if you make an add-on that changes the accept header to include webp they will serve firefox that format. That's what we want to encourage instead of UA sniffing. > > > imo you should add woff2 to the accept header. > > as with webp, this is particularly useful to opt-in to a new format. I agree that as a list of legacy formats and q-values is all rather useless, but as a signal that you want something new that might not be widely implemented its a pretty good thing. In this case its certainly better than the txt/html based header being used. > Do you know of any software which pays attention to this header? > > above. http request header byte counts aren't something to be super concerned with within reason (uris, cookies, and congestion control pretty much determine your performance fate on the request side). And it sounds like wrt fonts the accept header could be made more relevant and actually smaller as well. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Wed, Oct 8, 2014 at 12:10 PM, Gervase Markham wrote: > (This situation is basically "the Accept: problem".) There's a bit more elaboration here for those new to it: https://wiki.whatwg.org/wiki/Why_not_conneg -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 07/10/14 14:53, Patrick McManus wrote: > content format negotiation is what accept is meant to do. Protocol level > negotiation also allows designated intermediaries to potentially transcode > between formats. Do you know of any software which transcodes font formats on the fly as they move across the network? > imo you should add woff2 to the accept header. Do you know of any software which pays attention to this header? Given that other browsers don't set it, why would anyone else write such software? (This situation is basically "the Accept: problem".) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
content format negotiation is what accept is meant to do. Protocol level
negotiation also allows designated intermediaries to potentially transcode
between formats. imo you should add woff2 to the accept header.
On Tue, Oct 7, 2014 at 9:39 AM, Henri Sivonen wrote:
> On Fri, Oct 3, 2014 at 3:11 AM, Jonas Sicking wrote:
> >> @font-face {
> >> font-family: MyFont;
> >> src: url(myfont.woff2) format("woff2"),
> >> url(myfont.woff) format("woff"),
> >> url(myfont.eot) format("embedded-opentype"),
> >> url(myfont.ttf) format("truetype");
> >> }
> >
> > Could we at least add woff2 to the Accept header when fetching fonts?
>
> Why? The CSS-level negotiation feature shown above works great and
> doesn't involve any HTTP-level varying. (Also, like Anne says, fonts
> MIME types are a sad story.)
>
> I think we should treat Accept in general as a legacy mistake and not
> try to make it do new tricks.
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Fri, Oct 3, 2014 at 3:11 AM, Jonas Sicking wrote:
>> @font-face {
>> font-family: MyFont;
>> src: url(myfont.woff2) format("woff2"),
>> url(myfont.woff) format("woff"),
>> url(myfont.eot) format("embedded-opentype"),
>> url(myfont.ttf) format("truetype");
>> }
>
> Could we at least add woff2 to the Accept header when fetching fonts?
Why? The CSS-level negotiation feature shown above works great and
doesn't involve any HTTP-level varying. (Also, like Anne says, fonts
MIME types are a sad story.)
I think we should treat Accept in general as a legacy mistake and not
try to make it do new tricks.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Mon, Oct 6, 2014 at 11:07 PM, Zack Weinberg wrote: > https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011. I tried fixing this together with Håkon back in 2008: https://annevankesteren.nl/2008/08/font-mime-types We couldn't get agreement with the IETF fast enough so instead browsers ignore MIME types for fonts as Safari was already doing: http://www.alvestrand.no/pipermail/ietf-types/2008-August/002066.html It was all rather sad. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-03 4:37 AM, Jonathan Kew wrote: it seems we fetch fonts using Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 which doesn't look even remotely sensible. Agree, but note that there are no official MIME types for most font formats. (I *think* application/font-woff did get registered for WOFF1.) Lots of people have just made up MIME types, including e.g. application/x-ttf, application/ttf, font/ttf (inventing a whole category!) and so on. I'm not aware of any significant changes in this area since I wrote https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011. As described in that post, I continue to think that "Accept: application/font" plus client-side selection of URL based on format() is the Right Thing. I just filed bug 1077312. However, I don't think this needs to actually block the implementation of WOFF2 support. Also agree here. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Friday, 3 October 2014 02:12:22 UTC+2, Jonas Sicking wrote: > Could we at least add woff2 to the Accept header when fetching fonts? If Internet Media Types for fonts were widely and consistently deployed, then that sort of server-mediated content negotiation (client sends list of accepted formats and q factors, sever decides what is best and sends it) would probably work. However, they are not and never have been; also early attempts to creat a font/* top level type were blocked. Which is why @font-face uses a format hint instead. This is client-mediated content negotiation (content provides list of avbailable formats and a link to each, client decides what is best and asks for it). This works well in practice. Thus, an ordered list of urls and formats in a scr descriptor remains the recommended deployment method; it needs no web server config changes and no ua detection, and is resilient to fonts in the wild being served as text/plain or application/octet-stream or whatever the sever defaults to for "no idea what this is". Which is not to argue against sending sensible accept headers, but cleaning that up is orthogonal to woff2 deployment. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 3/10/14 01:11, Jonas Sicking wrote:
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew wrote:
Or do people need to hardcode
UA versions to know what UAs support it?
I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
widely-supported) formats, using the @font-face src descriptor's "format
hint" to let the browser choose the optimal resource depending on what it
supports:
@font-face {
font-family: MyFont;
src: url(myfont.woff2) format("woff2"),
url(myfont.woff) format("woff"),
url(myfont.eot) format("embedded-opentype"),
url(myfont.ttf) format("truetype");
}
Could we at least add woff2 to the Accept header when fetching fonts?
Sounds like a good suggestion in principle.
Wondering what we currently send in that header, I looked at some font
requests in the DevTools Network panel... it seems we fetch fonts using
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
which doesn't look even remotely sensible. If we're going to adjust
this, we should probably not simply add woff2 to this but do a more
thorough cleanup job.
For comparison, Chrome appears to use simply
Accept:*/*
and Safari, at least according to its inspector, doesn't send an Accept
header at all when fetching fonts. (Or images, for that matter.)
I just filed bug 1077312. However, I don't think this needs to actually
block the implementation of WOFF2 support.
JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew wrote:
>> Or do people need to hardcode
>> UA versions to know what UAs support it?
>
>
> I believe that's what Google Fonts currently does, though IMO a better
> approach is to serve CSS that offers both WOFF2 and older (more
> widely-supported) formats, using the @font-face src descriptor's "format
> hint" to let the browser choose the optimal resource depending on what it
> supports:
>
> @font-face {
> font-family: MyFont;
> src: url(myfont.woff2) format("woff2"),
> url(myfont.woff) format("woff"),
> url(myfont.eot) format("embedded-opentype"),
> url(myfont.ttf) format("truetype");
> }
Could we at least add woff2 to the Accept header when fetching fonts?
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2/10/14 17:17, Ehsan Akhgari wrote:
Is support for WOFF2 feature detectible?
Not directly, but it would be fairly easy for a site that really wants
to detect it via CSS+JS hackery to do so. There'd be some overhead to
such detection, though.
Or do people need to hardcode
UA versions to know what UAs support it?
I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
widely-supported) formats, using the @font-face src descriptor's "format
hint" to let the browser choose the optimal resource depending on what
it supports:
@font-face {
font-family: MyFont;
src: url(myfont.woff2) format("woff2"),
url(myfont.woff) format("woff"),
url(myfont.eot) format("embedded-opentype"),
url(myfont.ttf) format("truetype");
}
etc.
JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Thursday, October 2, 2014 9:17:38 AM UTC-7, Ehsan Akhgari wrote: > On 2014-10-02, 7:03 AM, Jonathan Kew wrote: > > > > WOFF2 is currently supported by Chrome and Opera,[4] and the Google > > webfonts service is serving WOFF2-compressed fonts to browser versions > > that are known to support it.[5] > > Is support for WOFF2 feature detectible? Or do people need to hardcode > UA versions to know what UAs support it? You don't need UA detection, @fontface with format() hint does the trick: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#defining-font-family-with-font-face ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-02, 7:03 AM, Jonathan Kew wrote: The W3C WebFonts Working Group[1] has been working on designing and specifying a new compressed font format for the web, aiming to give significantly smaller file sizes than the existing WOFF format (to reduce bandwidth requirements), while remaining cheap to decode (for low-power devices). The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. For more information about the WOFF2 format, see the FPWD spec[2] and current Editors' Draft.[3] WOFF2 is currently supported by Chrome and Opera,[4] and the Google webfonts service is serving WOFF2-compressed fonts to browser versions that are known to support it.[5] Is support for WOFF2 feature detectible? Or do people need to hardcode UA versions to know what UAs support it? I'm proposing to add WOFF2 support to Gecko, based on the "reference implementation" code from the Google font and compression teams, found at [6]. Support for WOFF2 will be controlled by a new boolean pref "gfx.downloadable_fonts.woff2.enabled". Initially this defaults to false for release builds, and true for nightlies; when we're ready to ship the feature on-by-default, we can simply flip the pref to true for all channels. This work is happening in bugs [7] and [8], which I hope to land "real soon now" (in time for Gecko 35, if all goes well). - JK [1] http://www.w3.org/Fonts/WG/ [2] http://www.w3.org/TR/WOFF2/ [3] http://dev.w3.org/webfonts/WOFF2/spec/ [4] http://caniuse.com/#feat=woff2 [5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2 [6] https://code.google.com/p/font-compression-reference/ [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2/10/14 16:20, Ralph Giles wrote: On 2014-10-02 4:03 AM, Jonathan Kew wrote: The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. What kind of filesize reductions do you see over ttf and woff1? Results will vary considerably depending on the specific fonts involved, but a compressed size that is around 25-30% smaller than WOFF 1.0 would be typical for TrueType fonts. See Appendix B of http://www.w3.org/TR/WOFF20ER/. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-02 4:03 AM, Jonathan Kew wrote: > The format is primarily based on earlier TrueType compression work > (MicroType Express) by Monotype, and a new entropy coder (Brotli) > developed by Google's data compression team in Zurich. What kind of filesize reductions do you see over ttf and woff1? -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: WOFF2 webfont format
The W3C WebFonts Working Group[1] has been working on designing and specifying a new compressed font format for the web, aiming to give significantly smaller file sizes than the existing WOFF format (to reduce bandwidth requirements), while remaining cheap to decode (for low-power devices). The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. For more information about the WOFF2 format, see the FPWD spec[2] and current Editors' Draft.[3] WOFF2 is currently supported by Chrome and Opera,[4] and the Google webfonts service is serving WOFF2-compressed fonts to browser versions that are known to support it.[5] I'm proposing to add WOFF2 support to Gecko, based on the "reference implementation" code from the Google font and compression teams, found at [6]. Support for WOFF2 will be controlled by a new boolean pref "gfx.downloadable_fonts.woff2.enabled". Initially this defaults to false for release builds, and true for nightlies; when we're ready to ship the feature on-by-default, we can simply flip the pref to true for all channels. This work is happening in bugs [7] and [8], which I hope to land "real soon now" (in time for Gecko 35, if all goes well). - JK [1] http://www.w3.org/Fonts/WG/ [2] http://www.w3.org/TR/WOFF2/ [3] http://dev.w3.org/webfonts/WOFF2/spec/ [4] http://caniuse.com/#feat=woff2 [5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2 [6] https://code.google.com/p/font-compression-reference/ [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
