[Libreoffice-ux-advise] [Bug 97991] Reducing the size of the Windows Installer

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=97991

--- Comment #11 from Yousuf (Jay) Philips <philipz85 at hotmail.com> ---
(In reply to Óvári from comment #7)
> Not sure if “en-US, de, ar, ja, ru, qtz” are a similar set of languages;
> however for testing purposes they may give a broad cross-section of use
> cases.

Yes these select languages were chosen as a means of testing a broad range of
languages. e.g. ja to test asian/cjk languages, ar to test rtl/ctl languages

> If effort is going to be expended to create separate downloads, perhaps the
> best solution for minimal downloads would be to have:
> * a core LibreOffice download (without any language pack); and

There would always have to be atleast a single language pack in it or else it
wouldnt work

> * each language as a *separate* download, not grouped at all.

Not sure how much benefit would be attained in this approach, as each language
UI pack is normally quite small in size ( < 2Mb ).

(In reply to Andras Timar from comment #8)
> Windows installer is created with help of a huge Perl script and standard
> tools from Windows SDK, such as msidb.exe.
> 
> Installer maker script is configurable in regards of languages you build in,
> and you can fine tune what go into the package in scp2. 
> 
> So, in theory, your goal can be reached.

Glad to hear.

> The situation was the same everywhere in the world 15 years ago. It is easy
> to get used to the comfort of high speed net connection, but I think 4 hours
> is not that much (maybe those users will not download LibreOffice daily for
> testing).

Yes my brother doesnt use the daily builds, but with the cost/availability of
electricity where he is, he chose not to download it.

> If TDF ever decides to split the installer for different languages
> or geographies, I hope that the decision will be based on some survey and
> calculations of cost/benefit, not on anecdotal evidence.

The main object of this issue was to save users from downloading an installer
larger than what they need, which in turn would reduce TDF's bandwidth costs.
It was also to make the installer closer in size to LO competitors like AOO
(134Mb) and WPS (78Mb). But yes i do see the ramifications of this proposal as
it would involve extra work for building as well as modification of the
website, so it would be good for someone/committee to read through the proposal
and make a decision in it.

(In reply to Michael Meeks from comment #9)
> There are several goals here that are in tension with each other:
> 
> * reduce download size
>      + I assume this is not a goal; since the help has significant size[1],
>        and by bundling lots of help files in we will rapidly become larger
>        than the existing download.
>      + IMHO our ~static 200Mb download footprint is reasonably small.
> 	  + I suspect we could even increase this;
> 	    I'd say an upped 250Mb is reasonable myself.

The proposal wasnt to include help packages as part of the installer, as that
would highly increase the size, it was about removing things currently bundled
and possibly include small useful extra items, like additional fonts, into
particular installers. The old windows daily builds which only had english
bundled were around ~120mb.

> * reduce install size
>      + IMHO our ~1Gb install size is reasonably small too.
>         + Office 2013 requires 3Gb:
> 	    +
> https://technet.microsoft.com/en-us/library/ee624351.aspx?f=255&MSPPError=-
> 2147217396

The install size of ~1Gb would be only if a user installed every single
language in the installer, but most users are likely to only install 1 to 3
languages, which means the install size for most users would be around 600mb.

> * increased font bundling
>      + seemingly we want to include more fonts for some locales
>           + in general a bit of engineering work can usually save
>             some space to free it up for more fonts without growing
>             our download footprint, if we're indeed too worried
> 	    about that.

With the CJK font mentioned in the other bug being around ~100mb uncompressed,
i would wonder how much it could be reduced in an .msi file.

> * distribute on-line help in the package
>      + this essentially requires cutting the package into several
>        pieces as suggested in order to keep the size sensible, that:
> 	   + increases our test burden
> 	     - 5x builds to test instead of one.

Is this about testing the installer or testing the languages, as if it is about
testing the languages, CJK users would only be testing the CJK version, and of
course download the extra help package to also test that.

> 	   + somewhat increases our releng burden
> 	     - 5x builds to push -> more B/W
> 	         -> a relatively small effect though

Yes there would be 5 more installers to push, but alot less B/W would be
consumed from downloaders.

>   	   + download page simplification / complexity
> 	     - this will need re-engineering / tweaking
> 	     - will need to be different for Windows.

Ideally this would also work for Mac OS as well.

> 	     - how reliably can we detect people's locales
> 	       and map that to the "click here to download"
> 	       so 99.9% don't mis-download the wrong thing ?
> 	       If we have eg. 2% downloading the wrong thing
> 	       this adds ~4Mb to our apparent download size.

Ideally we'd show them the 6 versions and let them choose the one they want. We
currently dont detect people's locales as a means of giving them the correct
help pack.

> Other things like moving our clipart to
> SVG from PNG might help too (it compresses better usually).

I think > 25% of the clipart is SVG.

> 	Just my 2 cents.

Thanks for weighing in.

-- 
You are receiving this mail because:
You are on the CC list for the bug.