Boris Zbarsky schrieb:
On 2/26/14 3:58 PM, Wesley Hardman wrote:
Personally, I would prefer to have it already available.
We have several deployment targets with different tradeoffs. Broadly
speaking:
Phones: expensive data, limited storage. Want to not use up the
storage, so download lazil
On 28/02/14 12:37, Jonathan Kew wrote:
> Presumably we always want the complete PSL available. So it really
> should be part of the base product, not a [try-to-]load-on-demand resource.
I was proposing it be part of the base product, but updated on demand.
> Isn't it sufficient to update that wit
On 28/2/14 11:44, Gervase Markham wrote:
On 26/02/14 20:21, Jonathan Kew wrote:
Lets turn this question around. If we had an on-demand way to load
stuff like this, what else would we want to load on demand?
A few examples:
Spell-checking dictionaries
Hyphenation tables
Fonts for additional sc
On 26/02/14 20:21, Jonathan Kew wrote:
>> Lets turn this question around. If we had an on-demand way to load
>> stuff like this, what else would we want to load on demand?
>
> A few examples:
>
> Spell-checking dictionaries
> Hyphenation tables
> Fonts for additional scripts
If this came with an
On Thu, Feb 27, 2014 at 07:33:39PM +0900, Mike Hommey wrote:
> On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
> >
> > Could we compress major parts of omni.ja en block? We could for
> > example stick all JS we load at startup into a zip with zero
> > compression and then compress tha
On 2/27/2014, 12:30 AM, Axel Hecht wrote:
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything abo
On Thu, Feb 27, 2014 at 6:27 AM, Benjamin Smedberg wrote:
> On 2/26/2014 4:36 PM, Bobby Holley wrote:
>
>> On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman > >wrote:
>>
>> It seems like it would be trivial to add a button in the Preferences UI to
>> let people precache all dynamically-loaded data.
On 2/26/2014 4:36 PM, Bobby Holley wrote:
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman wrote:
It seems like it would be trivial to add a button in the Preferences UI to
let people precache all dynamically-loaded data.
I don't think that would be trivial. In particular, which spellchecking
Andreas Gal wrote:
Could we compress major parts of omni.ja en block? We could for example stick
all JS we load at startup into a zip with zero compression and then compress
that into an outer zip. I think we already support nested containers like that.
Assuming your math is correct even with
On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
>
> Could we compress major parts of omni.ja en block? We could for
> example stick all JS we load at startup into a zip with zero
> compression and then compress that into an outer zip. I think we
> already support nested containers lik
On Thu, Feb 27, 2014 at 09:30:22AM +0100, Axel Hecht wrote:
> The feature of zip we want is the index, that let's us seek to a
> position in the bundle and start unpacking, just given the filename.
>
> How hard is to actually create a datastructure for the same purpose
> for a tar.xz or so? I don'
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything about the uncompression
algorithms to know
Could we compress major parts of omni.ja en block? We could for example stick
all JS we load at startup into a zip with zero compression and then compress
that into an outer zip. I think we already support nested containers like that.
Assuming your math is correct even without adding LZMA2 just
On Thu, Feb 27, 2014 at 08:25:00AM +0900, Mike Hommey wrote:
> On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
> >
> > This randomly reminds me that it might be time to review zip as our
> > compression format for omni.ja.
> >
> > ls -l omni.ja
> >
> > 7862939
> >
> > ls -l omni.t
On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
>
> This randomly reminds me that it might be time to review zip as our
> compression format for omni.ja.
>
> ls -l omni.ja
>
> 7862939
>
> ls -l omni.tar.xz (tar and then xz -z)
>
> 4814416
>
> LZMA2 is available as a public domai
On 2/26/14 3:58 PM, Wesley Hardman wrote:
Personally, I would prefer to have it already available.
We have several deployment targets with different tradeoffs. Broadly
speaking:
Phones: expensive data, limited storage. Want to not use up the
storage, so download lazily.
Consumer laptops
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman wrote:
> Personally, I would prefer to have it already available. I tend to live
> by "Its better to have it and not need it than to not have it and need it."
> (or have to fetch it.) This is my opinion though.
>
It seems like it would be trivial
On 2/26/2014, 11:56 AM, Andreas Gal wrote:
This randomly reminds me that it might be time to review zip as our compression
format for omni.ja.
ls -l omni.ja
7862939
ls -l omni.tar.xz (tar and then xz -z)
4814416
LZMA2 is available as a public domain implementation. It uses a bit more memor
Here are a few things to think about:
1. Not everyone will have internet access. Businesses sometimes have limited
access, or access to specific site only. There was discussion on this in the
addons file registration a little while ago.
What if you are travelling without internet and working
https://bugzilla.mozilla.org/show_bug.cgi?id=977292
Assigned to nobody.
On 2/26/2014 12:49 PM, Andreas Gal wrote:
>
> This sounds like quite an opportunity to shorten download times and reduce
> CDN load. Who wants to file the bug? :)
>
> Andreas
>
> On Feb 26, 2014, at 9:44 PM, Benjamin Smed
On 26/2/14 20:49, Andreas Gal wrote:
This sounds like quite an opportunity to shorten download times and reduce CDN
load. Who wants to file the bug? :)
Re fonts, see bug 619521 and bug 648548; there's even an old
proof-of-concept patch there, but it's been stalled for a while
If we're
This sounds like quite an opportunity to shorten download times and reduce CDN
load. Who wants to file the bug? :)
Andreas
On Feb 26, 2014, at 9:44 PM, Benjamin Smedberg wrote:
> On 2/26/2014 3:21 PM, Jonathan Kew wrote:
>> On 26/2/14 19:57, Andreas Gal wrote:
>>>
>>> Lets turn this question
On 2/26/2014 3:21 PM, Jonathan Kew wrote:
On 26/2/14 19:57, Andreas Gal wrote:
Lets turn this question around. If we had an on-demand way to load
stuff like this, what else would we want to load on demand?
A few examples:
Spell-checking dictionaries
Hyphenation tables
Fonts for additional s
On 26/2/14 19:57, Andreas Gal wrote:
Lets turn this question around. If we had an on-demand way to load stuff like
this, what else would we want to load on demand?
A few examples:
Spell-checking dictionaries
Hyphenation tables
Fonts for additional scripts
JK
Andreas
On Feb 26, 2014, at
Lets turn this question around. If we had an on-demand way to load stuff like
this, what else would we want to load on demand?
Andreas
On Feb 26, 2014, at 8:53 PM, Bobby Holley wrote:
> That's still a ton for something that most of our users will not (or will
> rarely) use. I think we absolut
This randomly reminds me that it might be time to review zip as our compression
format for omni.ja.
ls -l omni.ja
7862939
ls -l omni.tar.xz (tar and then xz -z)
4814416
LZMA2 is available as a public domain implementation. It uses a bit more memory
than zip, but its still within reason (th
That's still a ton for something that most of our users will not (or will
rarely) use. I think we absolutely need to get an on-demand story for this
kind of stuff. It isn't the first time it has come up.
bholley
On Wed, Feb 26, 2014 at 11:38 AM, Brendan Dahl wrote:
> Yury Delendik worked on re
Yury Delendik worked on reformatting the files a bit and was able to get them
down to 1.1MB binary which gzips to 990KB. This seems like a reasonable size to
me and involves a lot less work than setting up a process for distributing
these files via CDN.
Brendan
On Feb 24, 2014, at 10:14 PM, Ri
On Mon, Feb 24, 2014 at 5:01 PM, Andreas Gal wrote:
>
> My assumption is that certain users only need certain CMaps because they
> tend to read only documents in certain languages. This seems like something
> we can really optimize and avoid ahead-of-time download cost for.
>
So, you'd only inst
My assumption is that certain users only need certain CMaps because they tend
to read only documents in certain languages. This seems like something we can
really optimize and avoid ahead-of-time download cost for.
The fact that we don’t do this yet doesn’t seem like a good criteria. There is
It’s certainly possible to load dynamically. Do we currently do this for any
other Firefox resources?
>From what I’ve seen, many PDF’s use CMaps even if they don’t necessarily have
>CJK characters, so it may just be better to include them. FWIW both Popper and
>Mupdf embed the CMaps.
Brendan
On Mon, Feb 24, 2014 at 3:01 PM, Andreas Gal wrote:
> Is this something we could load dynamically and offline cache?
>
That should be possible. The CMap name is in the PDF so Firefox could
download it on demand.
Also, if the user has acrobat, the CMaps are already on their machine.
> On Feb 24,
On 2014-02-24 2:41 PM, Brendan Dahl wrote:
> There are 168 files with an average size of ~40KB, and all of the files
> together are roughly:
> 6.9M
> 2.2M when gzipped
IIRC mupdf was able to save significant space by pre-parsing the files.
Their code for that is GPL (and oriented toward compiling
On Mon, Feb 24, 2014 at 3:01 PM, Andreas Gal wrote:
> Is this something we could load dynamically and offline cache?
>
> Andreas
>
> Sent from Mobile.
>
>> On Feb 24, 2014, at 23:41, Brendan Dahl wrote:
>>
>> PDF.js plans to soon start including and using Adobe CMap files for
>> converting chara
Is this something we could load dynamically and offline cache?
Andreas
Sent from Mobile.
> On Feb 24, 2014, at 23:41, Brendan Dahl wrote:
>
> PDF.js plans to soon start including and using Adobe CMap files for
> converting character codes to character id's(CIDs) and mapping character
> codes
35 matches
Mail list logo
