https://bugs.documentfoundation.org/show_bug.cgi?id=97991
--- Comment #9 from Michael Meeks <michael.me...@collabora.com> --- 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. * reduce update size ? + not an explicit goal thus far, but clearly after the initial download the size of the incremental updates is prolly by far more important than the download size itself. This is an area where TDF could invest in improving things for the vast majority of users. * 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 * improve performance + there is some level of cost from having all languages installed, I don't think this has been characterized recently - but it might be interesting to do that again in eg. cachegrind to get a hard number of eg. startup cost with more langs installed. + this should have some technical fix of course. * 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. * 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. + somewhat increases our releng burden - 5x builds to push -> more B/W -> a relatively small effect though + download page simplification / complexity - this will need re-engineering / tweaking - will need to be different for Windows. - 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. + some engineering to the packaging perl scripts - some man days of work; no need to move to Wix. + I guess we would want to have roughly 20 languages in each of say five piece. + against this: + would obsolete the on-line help for Windows users. + what %age of users actually use the on-line help ? Previous studies I've seen suggest a surprisingly small number; and clearly an even smaller number of them are off-line at the time. ie. what is the benefit ? =) + confusion wrt. "what is LibreOffice" - mine is not the same as yours etc. "yours does not have my language" etc. * Anyway - all things are possible; I imagine if someone has done the engineering work already; and has a real proposal that might be more interesting. My general suggestion would be to optimize our size and packaging instead; I imagine investing in reducing and compacting and/or better arrangement in the MSI so that the compression works better (it is IIRC per-file based not global so it can't see commonality between eg pt_BR and pt if they are in different streams) would be a better use of time. Other things like moving our clipart to SVG from PNG might help too (it compresses better usually). And/or if we want to include more things, upping the target file-size limit might be a good idea. Just my 2 cents. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise