You can easily minimize the ICU footprint by tweaking the ICU build options. See <a href="http://userguide.icu-project.org/packaging">http://userguide.icu-project.org/packaging</a><div><a href="http://userguide.icu-project.org/packaging"></a>The result will be like this - <a href="http://site.icu-project.org/charts/icu4c-footprint">http://site.icu-project.org/charts/icu4c-footprint</a></div> <div><a href="http://site.icu-project.org/charts/icu4c-footprint"></a> <div class="gmail_quote">On Fri, Jan 14, 2011 at 7:27 PM, Michael Meeks <<a href="mailto:michael.meeks@novell.com">michael.meeks@novell.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi there, On Fri, 2011-01-07 at 12:22 -0600, Norbert Thiebaud wrote: > > Which makes me wonder: do we really need everything that is in that > > beast ? pmap seems to suggest we use 84K out of the 13Mb on Linux: > > Michael: icudata contains, among other things all the supported > utf16<->other-codepage convertion. If your locale is utf8 or iso8859-1/15 > (which is most likely in your case) then sure you just need one or two > of these conversion table... if any at all (some convertion like > utf8<->utf16 are algorithmic) Sure. We have a patch for sal: <a href="http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/size-sal-textenc.diff" target="_blank">http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/size-sal-textenc.diff</a> sadly still not merged, since it needs re-testing on win32 - that chops a megabyte of this off of sal (exactly the same text encoding conversion tables). > libicudata also contains stuff about collation and locales... Right - but it also seems that some (much?) of this data is not actually used :-) AFAICS we don't use the charset conversion data at all, preferring the sal stuff. There are whole fields of API that are simply not touched from ICU: 'ucnv_' (char set conversion !?) 'ures_' 'unorm_' 'utrans_' 'u_shapeArabic' So - I suspect we could hack some big chunks of code, and data out of this: the data is the biggest evil size-wise from a distribution perspective I suspect: 5.5Mb compressed of our win32 download is data we don't use [ one of the bigger lumps of pointlessness there ]. > either way libicudata is big, but there is not that much redundancy in > it. it just covert and insanely large number of code page ( sure sure :-) and we don't need that AFAICS, since we don't use the relevant APIs; and our internal ICU does not have to be a generic useful resource for abstract programs (particularly on Win32). So I added an easy hack here: <a href="http://wiki.documentfoundation.org/Development/Easy_Hacks#de-bloat_internal_ICU" target="_blank">http://wiki.documentfoundation.org/Development/Easy_Hacks#de-bloat_internal_ICU</a> Thanks, Michael. -- <a href="mailto:michael.meeks@novell.com">michael.meeks@novell.com</a> <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list <a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </blockquote></div> -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, <a href="http://www.osdev.co.th/">http://www.osdev.co.th/</a> </div>