Re: Integrating ICU into Mozilla build
This thread has got off-topic (reasonably; the new issues are important) but back on the original point, if we do add ICU then: On 03/12/12 11:32, Norbert Lindenberg wrote: - Add the required set of ICU source files as separate files to the Mozilla repository. The current version of ICU (50.1, C/C++ version) has about 5350 source files; stripping out files that aren't needed for the internationalization API (but might be needed later) brings this to about 3250 files. The complete Mozilla tree before this addition has about 70,000 files. This, - Add the source bundles (zip/tar) to the Mozilla repository, and then extract the source files as part of the build. Not this. Having source bundled up like this makes code search and license compliance, to name but two things, much harder. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
Neil writes: > Ah, so that explains the fallback flash I experience on a site I > frequent that makes heavy use of a downloaded symbol font. It is > irksome because the fallback content is ASCII text ;-) Just in case others read and want to copy this behaviour, sites should not be encoding symbols at Unicode points preassigned with another meaning. Imagine what screen readers think of this, for example. The Private Use Area range of code points exists for this purpose. Having said that, the existing behaviour is probably to show hexboxes until the font is downloaded, which is not an obvious visual improvement. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On 12/5/2012 8:07 AM, Benjamin Smedberg wrote: On 12/3/2012 5:39 PM, Norbert Lindenberg wrote: OK, just as an introduction, why we're doing this: The ECMAScript Internationalization API (which has been approved by Ecma TC 39 and is on track to become an Ecma standard next week) provides web applications with the ability to format numbers, dates, and times and sort strings according to the rules of the language that the application is using, not the one that browser and OS default to. Many users are multilingual and go to web sites in different languages, and even users who aren't sometimes have to use browsers that don't support their language. The API in addition lets applications tailor the results to their specific needs, e.g., specify the currency with which numbers are displayed, select the date-time components used in a date format, or ignore punctuation in sorting. To implement that, we need good library support, and ICU fits the bill. If I may be a skeptic: Is this feature really worth the costs? Right now xul.dll is about 18MB on Windows, and the entire install size of Firefox on disk is 91MB. Just an FYI: I suspect that you have a staged update since the size on Windows is actually around 45 MB. Robert Assuming that the weight is roughly similar to mac, we'd be talking a 15% increase in on-disk size for a feature which seems on the surface to be relatively obscure. Maybe it would be better to just not implement this EMCA specification? What does this feature really buy us in terms of strategic importance? How well do the data files compress? Even more important than the installed size, a 15% increase in download size could have a noticeable impact on our install conversion rates. --BDS ___ 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: Integrating ICU into Mozilla build
On 05.12.12 17:07, Benjamin Smedberg wrote: On 12/3/2012 5:39 PM, Norbert Lindenberg wrote: OK, just as an introduction, why we're doing this: The ECMAScript Internationalization API (which has been approved by Ecma TC 39 and is on track to become an Ecma standard next week) provides web applications with the ability to format numbers, dates, and times and sort strings according to the rules of the language that the application is using, not the one that browser and OS default to. Many users are multilingual and go to web sites in different languages, and even users who aren't sometimes have to use browsers that don't support their language. The API in addition lets applications tailor the results to their specific needs, e.g., specify the currency with which numbers are displayed, select the date-time components used in a date format, or ignore punctuation in sorting. To implement that, we need good library support, and ICU fits the bill. If I may be a skeptic: Is this feature really worth the costs? Right now xul.dll is about 18MB on Windows, and the entire install size of Firefox on disk is 91MB. Assuming that the weight is roughly similar to mac, we'd be talking a 15% increase in on-disk size for a feature which seems on the surface to be relatively obscure. Maybe it would be better to just not implement this EMCA specification? What does this feature really buy us in terms of strategic importance? How well do the data files compress? Even more important than the installed size, a 15% increase in download size could have a noticeable impact on our install conversion rates. I think we're having a more general issue with intl data right now. Hyphenation dicts are in a similar bucket as collation data, I think. Like, if chinese isn't hyphenated great, or sorted perfectly, I wouldn't be able to tell. I can't read the script. I'd love if we had a way to be sub-optimal the first time someone hits the problem and then on-demand, download language-specific data later. Which raises the question, how large would ICU be with mostly-no data? Or, say, just the data for Chinese, assuming we could actually build just the UI locale, and chinese was said to be big earlier in this thread. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On 12/3/2012 5:39 PM, Norbert Lindenberg wrote: OK, just as an introduction, why we're doing this: The ECMAScript Internationalization API (which has been approved by Ecma TC 39 and is on track to become an Ecma standard next week) provides web applications with the ability to format numbers, dates, and times and sort strings according to the rules of the language that the application is using, not the one that browser and OS default to. Many users are multilingual and go to web sites in different languages, and even users who aren't sometimes have to use browsers that don't support their language. The API in addition lets applications tailor the results to their specific needs, e.g., specify the currency with which numbers are displayed, select the date-time components used in a date format, or ignore punctuation in sorting. To implement that, we need good library support, and ICU fits the bill. If I may be a skeptic: Is this feature really worth the costs? Right now xul.dll is about 18MB on Windows, and the entire install size of Firefox on disk is 91MB. Assuming that the weight is roughly similar to mac, we'd be talking a 15% increase in on-disk size for a feature which seems on the surface to be relatively obscure. Maybe it would be better to just not implement this EMCA specification? What does this feature really buy us in terms of strategic importance? How well do the data files compress? Even more important than the installed size, a 15% increase in download size could have a noticeable impact on our install conversion rates. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
Mike Hommey wrote: > On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote: >> Rafael Ávila de Espíndola wrote: Actually, ICU has several options for how its data is packaged. One option is libraries (which are not sharable between architectures, AFAIK), but another possibility is to use data package (.dat) files, which I believe *could* be shared between the 32- and 64-bit builds. >>> >>> getting a bit off topic, but since we don't support 10.5 anymore, can't we >>> build just a 32 bit plugin container instead of the full browser as a >>> universal binary? Would the plugin container need to link with ICU too? >>> >> >> Not yet, there are supported Hardware models using 10.6 that *do not* >> have 64 bit avaiable. Granted they are on the older end of stuff, but it >> does exist. > > Note that apparently, this is even worse than that. 10.6 didn't enable > 64 bits by default on 64 bits capable hardware. (I just figured while > looking at something unrelated on my wife's mac running 10.6.8) Yes, I meant that as well, since some of these older machines are by default set like that, and no UI way to change it. I noticed this as well on the x64 mini's SeaMonkey has that are 10.6 but my research showed that x64 was unstable on that version of mini we have so I didn't turn it on :-) -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote: > Rafael Ávila de Espíndola wrote: > >> > >> Actually, ICU has several options for how its data is packaged. One option > >> is libraries (which are not sharable between architectures, AFAIK), but > >> another possibility is to use data package (.dat) files, which I believe > >> *could* be shared between the 32- and 64-bit builds. > > > > getting a bit off topic, but since we don't support 10.5 anymore, can't we > > build just a 32 bit plugin container instead of the full browser as a > > universal binary? Would the plugin container need to link with ICU too? > > > > Not yet, there are supported Hardware models using 10.6 that *do not* > have 64 bit avaiable. Granted they are on the older end of stuff, but it > does exist. Note that apparently, this is even worse than that. 10.6 didn't enable 64 bits by default on 64 bits capable hardware. (I just figured while looking at something unrelated on my wife's mac running 10.6.8) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
On Tue, Nov 27, 2012 at 10:49 AM, Henri Sivonen wrote: > Therefore, I propose that we adopt the following policy: > 1) APIs that are shipped on the release channel shall be shipped > without a prefix. > 2) If we ship APIs that don't have specs already, we'll write specs. In yesterday’s platform meeting, it turned out that I had misunderstood Randell’s position on prefixing WebRTC. Even though in general, it might be bad for a policy to have seemingly ad hoc exceptions, I think making an exception for WebRTC is reasonable, because: * WebRTC is already in the implementation pipeline and the policy was meant for new features and not for abruptly removing existing prefixes, so it seems reasonable to stretch the notion of “existing feature” to an in-the-pipeline feature in the case of a huge feature like WebRTC where making changes right now might be too disruptive. * It appears that there’s some kind of commitment made in the WG involved as in the case of WebGL. * WebRTC is a uniquely huge feature (or set of features) and it needs special rollout (unusual iteration after release). * Even if WebRTC and WebGL were excluded, I think it would be a big win to stop prefixing other APIs that are introduced. Also, a clarification was asked about whether the policy was proposed to apply to new features only or also to existing features. (I intended it to apply to new features.) Therefore, I propose that we adopt the following policy: 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the release channel shall be shipped without a prefix. 2) If APIs that don’t already have specs are shipped, we’ll get specs written. (For clarity, the above formulation does not require WebGL or WebRTC to have prefixes.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On 5/12/12 10:54, Neil wrote: John Daggett wrote: Last time I looked, Webkit caches activated fonts, so the second time the UA loads the same font (e.g. in a different document) it will be shown immediately without fallback content first. Ah, so that explains the fallback flash I experience on a site I frequent that makes heavy use of a downloaded symbol font. It is irksome because the fallback content is ASCII text ;-) It's not so bad for other downloaded fonts as usually the only problem is that the aspect ratio is wrong so the line wrapping changes once the font loads. You shouldn't normally see a flash of fallback text unless the font is particularly slow to load; the text should be invisible until the font is available. We aim to hide the text until the font is ready, unless it takes more than a few seconds to load. (The timeout is configurable - see gfx.downloadable_fonts.fallback_delay - so if you've set it lower than the default of 3000ms, you'll see visible fallback more frequently.) Could you point us to the irksome site? If you're often seeing ASCII fallback, I wonder if there's something unusual about how it's specifying/loading the symbol font. BTW, in bug 816483 I'm proposing to cache/share the activated fonts across pages, so that when you visit successive pages that use the same fonts, they'll be available immediately. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
John Daggett wrote: Last time I looked, Webkit caches activated fonts, so the second time the UA loads the same font (e.g. in a different document) it will be shown immediately without fallback content first. Ah, so that explains the fallback flash I experience on a site I frequent that makes heavy use of a downloaded symbol font. It is irksome because the fallback content is ASCII text ;-) It's not so bad for other downloaded fonts as usually the only problem is that the aspect ratio is wrong so the line wrapping changes once the font loads. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
