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 (the default level 6 is around 1MB to decode I believe). A fairly easy way to use it would be to add support for a custom compression format for our version of libjar. Andreas On Feb 26, 2014, at 8:38 PM, Brendan Dahl <bd...@mozilla.com> wrote: > 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, Rik Cabanier <caban...@gmail.com> wrote: > >> >> >> >> On Mon, Feb 24, 2014 at 5:01 PM, Andreas Gal <andreas....@gmail.com> 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 install the Korean CMaps if the language is Korean? >> The problem with that is that if a user might install a English version of >> Firefox but still open Korean PDFs (which will then display as junk) >> >> >> The fact that we don’t do this yet doesn’t seem like a good criteria. There >> is a lot of good things we aren’t doing yet. You can be the first to change >> that on this particular topic, if it technically makes sense. >> >> Load-on-demand (with an option to download all of them) seems like a nice >> solution. A large majority of users will never need CMaps or only a very >> small subset. >> >> On Feb 25, 2014, at 1:27 AM, Brendan Dahl <bd...@mozilla.com> wrote: >> >>> 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 Feb 24, 2014, at 3:01 PM, Andreas Gal <andreas....@gmail.com> wrote: >>> >>>> Is this something we could load dynamically and offline cache? >>>> >>>> Andreas >>>> >>>> Sent from Mobile. >>>> >>>>> On Feb 24, 2014, at 23:41, Brendan Dahl <bd...@mozilla.com> 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 to unicode values. This will fix a number of bugs in PDF.js and >>>>> will improve our support for Chinese, Korean, and Japanese(CJK) documents. >>>>> >>>>> I wanted to inform dev-platform because there are quite a few files and >>>>> they are large. The files are loaded lazily as needed so they shouldn't >>>>> affect the size of Firefox when running, but they will affect the >>>>> installation size. There are 168 files with an average size of ~40KB, and >>>>> all of the files together are roughly: >>>>> 6.9M >>>>> 2.2M when gzipped >>>>> >>>>> http://sourceforge.net/adobe/cmap/wiki/Home/ >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > 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
