[Libreoffice] License for my patches
All my patches to LibreOffice project are under LGPLv3+/MPL1.1 dual license and future versions of the licenses. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] problems in number format dialog
On Fri, Jul 29, 2011 at 5:54 AM, Markus Mohrhard markus.mohrh...@googlemail.com wrote: can someone from the Thai community check whether these two patches cause any problems. We're reading this discussion and patches. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Please take a look at Bug 38293 – Format Cell dialog doesn't accept number format with locale specifier
This bug render LibreOffice 3.4 useless in Thailand. I still found it in LibreOffice 3.4.1 RC1. https://bugs.freedesktop.org/show_bug.cgi?id=38293 Anybody has any idea what cause the problem? -- _/|\_ /Samphan Raruenrom./ Osdev - Open Source Development Co., Ltd. /สัมพันธ์ ระรื่นรมย์./ โอเอสเด็บ - บริษัท โอเพนซอร์สดิเวลอปเมนต์ จำกัด tel: +66 2 269 9889 web: osdev.co.th http://www.osdev.co.th/ twitter: @osdev http://twitter.com/osdev facebook: facebook.com/osdev http://www.facebook.com/osdev ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help with the Bug 33092 – Autocomplete display double character for this word [CTL / Thai]
On Tue, May 31, 2011 at 5:56 PM, Cedric Bosdonnat cedric.bosdonnat@free.fr wrote: Hello Samphan, On Tue, 2011-05-31 at 12:32 +0700, Samphan Raruenrom wrote: Any idea about my experimental fix? i.e. remove the auto-style that switch to the very same locale. It doesn't look bad to me but I could go into deeper investigation as I couldn't type that word using any of the thai layouts from scim. Could you give us some more hints to type this on scim? Here are the steps to reproduced the bug: 1. open a blank Writer document. Switch LibO to Thai locale. Tools Options Language Settings Locale Setting = Thai 2.Switch keyboard to Thai. I know nothing about skim but I've just tried and found that you only need to add support for Thai (e.g. on Ubuntu). Then you switch the keyboard to Thai using Alt+Shift+L. 3.Type text “มิถุ” by press “,b56”. (I miss the last character in the previous message, sorry :'( ) When you've switched the keyboard to Thai, simply type *,* (comma) -- to get -* ม* *b* -- to get -* ิ* *5* -- to get - *ถ* *6* -- to get - * ุ* 4.The function autocomplete will display the full word มิถุนายน (June in Thai) 5. Press enter to accept the suggestion, and another enter for readability 6. Repeat the step 3-5 once Expect result: There should be two lines of “มิถุนายน”. Real result: There are two lines of “มิถุนายน” but the first one has a doubled/overlapped cluster. See below. Did you try to type some text in another language (and trigger autocorrection too) between those two iterations of the steps to see if your patch didn't alterate anything there? Not yet. But I'll try it, ASAP. I think this case is very specific, i.e. the 3rd and the 4th characters happen to be in the same cluster (the first 3 chars tricker the autocompletion). I think we can always artificially create such case in any language with non-spacing, composing characters. For Thai, it happen that we have such case in the default autocompletion list which is the month name (มิถุนายน = June). So people have to fight with it all the time. My last question is how do it come that this language setting alters the first word but not the second one? I completely have no idea. On Tue, May 24, 2011 at 9:22 PM, Samphan Raruenrom samp...@osdev.co.th wrote: Hi, We've been trying to fix this bug https://bugs.freedesktop.org/show_bug.cgi?id=33092 However, we don't know whether the approach that we've tried is the right thing, so can you please review the following idea. Step to reproduced the bug: 1.Use Thai locale, open a blank Writer document 2.Switch keyboard to Thai. 3.Type text “มิถุ” by press “,b5”. 4.The function autocomplete will display the full word มิถุนายน (June in Thai) 5. Press enter to accept the suggestion, and another enter for readability 6. Repeat the step 3-5 once Expect result: There should be two lines of “มิถุนายน”. Real result: There are two lines of “มิถุนายน” but the first one has a doubled/overlapped cluster. See below. It is strange that the second (and later) autocompletion of the same word doesn't trigger the same bug. Look at the content.xml style:style style:name=T1 style:family=text style:text-properties style:language-complex=th style:country-complex=TH/ /style:style snip. text:p text:style-name=P1มิถtext:span text:style-name=T1ุนายน/text:span/text:p text:p text:style-name=P1text:span text:style-name=T1มิถุนายน/text:span/text:p There is an auto-style T1 which switch the locale to th. In the 2nd paragraph, the auto-style is placed around the autocompleted word. However, in the first line, the auto-style is placed just before the suggestion. Moreover, for the word มิถุนายน, the auto-style happen to be placed inside a cluster ถ+ ุ , which result in ugly display of the cluster. Because the display function still cannot handle this case well. We've tried removing the whole auto-style T1 from the ODT and everything is fine again. Then we couldn't find a reason why LO need to put the auto-style while autocomplete in the first place. Because the user is typing in a locale, then autocompletion of the same locale is fired. So the whole text must be in the same locale. Why put and auto-style to switch to the same locale? So we've try an experimental patch (https://bugs.freedesktop.org/attachment.cgi?id=45511 ) that get rid of the auto-style when autocomplete altogether. We've tried it with no side-effect as of now
Re: [Libreoffice] Need help with the Bug 33092 – Autocomplete display double character for this word [CTL / Thai]
Hi, Any idea about my experimental fix? i.e. remove the auto-style that switch to the very same locale. On Tue, May 24, 2011 at 9:22 PM, Samphan Raruenrom samp...@osdev.co.thwrote: Hi, We've been trying to fix this bug https://bugs.freedesktop.org/show_bug.cgi?id=33092 However, we don't know whether the approach that we've tried is the right thing, so can you please review the following idea. Step to reproduced the bug: 1.Use Thai locale, open a blank Writer document 2.Switch keyboard to Thai. 3.Type text “มิถุ” by press “,b5”. 4.The function autocomplete will display the full word มิถุนายน (June in Thai) 5. Press enter to accept the suggestion, and another enter for readability 6. Repeat the step 3-5 once Expect result: There should be two lines of “มิถุนายน”. Real result: There are two lines of “มิถุนายน” but the first one has a doubled/overlapped cluster. See below. It is strange that the second (and later) autocompletion of the same word doesn't trigger the same bug. Look at the content.xml style:style style:name=T1 style:family=text style:text-properties style:language-complex=th style:country-complex=TH/ /style:style snip. text:p text:style-name=P1มิถtext:span text:style-name=T1ุนายน/text:span/text:p text:p text:style-name=P1text:span text:style-name=T1มิถุนายน/text:span/text:p There is an auto-style T1 which switch the locale to th. In the 2nd paragraph, the auto-style is placed around the autocompleted word. However, in the first line, the auto-style is placed just before the suggestion. Moreover, for the word มิถุนายน, the auto-style happen to be placed inside a cluster ถ+ ุ , which result in ugly display of the cluster. Because the display function still cannot handle this case well. We've tried removing the whole auto-style T1 from the ODT and everything is fine again. Then we couldn't find a reason why LO need to put the auto-style while autocomplete in the first place. Because the user is typing in a locale, then autocompletion of the same locale is fired. So the whole text must be in the same locale. Why put and auto-style to switch to the same locale? So we've try an experimental patch ( https://bugs.freedesktop.org/attachment.cgi?id=45511 ) that get rid of the auto-style when autocomplete altogether. We've tried it with no side-effect as of now. But I don't know whether actually the auto-style is needed for a reason we don't understand. Any idea? Thanks, Samphan. -- _/|\_ *Samphan Raruenrom.* Osdev - Open Source Development Co., Ltd. *สัมพันธ์ ระรื่นรมย์.* โอเอสเด็บ - บริษัท โอเพนซอร์สดิเวลอปเมนต์ จำกัด tel: +66 2 269 9889 web: osdev.co.th http://www.osdev.co.th/ twitter: @osdev http://twitter.com/osdev facebook: facebook.com/osdevhttp://www.facebook.com/osdev -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ moz-screenshot-9.png___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Need help with the Bug 33092 – Autocomplete display double character for this word [CTL / Thai]
Hi, We've been trying to fix this bug https://bugs.freedesktop.org/show_bug.cgi?id=33092 However, we don't know whether the approach that we've tried is the right thing, so can you please review the following idea. Step to reproduced the bug: 1.Use Thai locale, open a blank Writer document 2.Switch keyboard to Thai. 3.Type text “มิถุ” by press “,b5”. 4.The function autocomplete will display the full word "มิถุนายน" (June in Thai) 5. Press enter to accept the suggestion, and another enter for readability 6. Repeat the step 3-5 once Expect result: There should be two lines of “มิถุนายน”. Real result: There are two lines of “มิถุนายน” but the first one has a doubled/overlapped cluster. See below. It is strange that the second (and later) autocompletion of the same word doesn't trigger the same bug. Look at the content.xml style:style style:name="T1" style:family="text" style:text-properties style:language-complex="th" style:country-complex="TH"/ /style:style snip. text:p text:style-name="P1"มิถtext:span text:style-name="T1"ุนายน/text:span/text:p text:p text:style-name="P1"text:span text:style-name="T1"มิถุนายน/text:span/text:p There is an auto-style T1 which switch the locale to th. In the 2nd paragraph, the auto-style is placed around the autocompleted word. However, in the first line, the auto-style is placed just before the suggestion. Moreover, for the word มิถุนายน, the auto-style happen to be placed inside a cluster ถ+ ุ , which result in ugly display of the cluster. Because the display function still cannot handle this case well. We've tried removing the whole auto-style T1 from the ODT and everything is fine again. Then we couldn't find a reason why LO need to put the auto-style while autocomplete in the first place. Because the user is typing in a locale, then autocompletion of the same locale is fired. So the whole text must be in the same locale. Why put and auto-style to switch to the same locale? So we've try an experimental patch (https://bugs.freedesktop.org/attachment.cgi?id=45511 ) that get rid of the auto-style when autocomplete altogether. We've tried it with no side-effect as of now. But I don't know whether actually the auto-style is needed for a reason we don't understand. Any idea? Thanks, Samphan. -- _/|\_ Samphan Raruenrom. Osdev - Open Source Development Co., Ltd. สัมพันธ์ ระรื่นรมย์. โอเอสเด็บ - บริษัท โอเพนซอร์สดิเวลอปเมนต์ จำกัด tel: +66 2 269 9889 web: osdev.co.th twitter: @osdev facebook: facebook.com/osdev ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] change default fall-back font lists for Thai locale in vcl.xcu
I've done a small research on preferred fonts for Thai in Windows/Linux/MacOSX by consulting several communities, font developers and authority. Here is the modification that the Thai community decide that best for Thai locale. It will help users when exchanging documents between these platforms with different installed fonts and also promote the use of the new government sponsored free fonts (TH_Sarabun) as the standard cross-platform fonts. Please review it and make comments if anything wrong or need to be improved before committing. Thanks, Samphan. -- _/|\_ /Samphan Raruenrom./ Osdev - Open Source Development Co., Ltd. /สัมพันธ์ ระรื่นรมย์./ โอเอสเด็บ - บริษัท โอเพนซอร์สดิเวลอปเมนต์ จำกัด tel: +66 2 269 9889 web: osdev.co.th http://www.osdev.co.th/ twitter: @osdev http://twitter.com/osdev facebook: facebook.com/osdev http://www.facebook.com/osdev diff --git a/officecfg/registry/data/org/openoffice/VCL.xcu b/officecfg/registry/data/org/openoffice/VCL.xcu index 0967543..fb9e3d2 100644 --- a/officecfg/registry/data/org/openoffice/VCL.xcu +++ b/officecfg/registry/data/org/openoffice/VCL.xcu @@ -495,22 +495,22 @@ /node node oor:name=th oor:op=replace prop oor:name=UI_SANS oor:op=replace oor:type=xs:string -valueAngsana New;OONaksit;Tahoma;Lucidasans;Arial Unicode MS;clearlyU/value +valueTahoma;Arial Unicode MS;Waree;Loma;Thonburi;Lucidasans;Lucida Sans;clearlyU/value /prop prop oor:name=CTL_DISPLAY oor:type=xs:string oor:op=replace -valueAngsana New;OONaksit;Tahoma;Lucidasans;Lucida Sans;Arial Unicode MS/value +valueTahoma;Arial Unicode MS;Waree;Loma;Thonburi;Lucidasans;Lucida Sans;Angsana New/value /prop prop oor:name=CTL_HEADING oor:type=xs:string oor:op=replace -valueAngsana New;OONaksit;Tahoma;Lucidasans;Lucida Sans;Arial Unicode MS/value +valueCordia New;CordiaUPC;Browallia New;BrowalliaUPC;Bromlila;Corada;Umpush;Thonburi;TH SarabunPSK;TH SarabunNew;Angsana New;AngsanaUPC;Tahoma;Arial Unicode MS;Lucidasans;Lucida Sans/value /prop prop oor:name=CTL_PRESENTATION oor:type=xs:string oor:op=replace -valueCordia New;CordiaUPC;Angsana New;OONaksit;Tahoma;Lucidasans;Lucida Sans;Arial Unicode MS/value +valueCordia New;CordiaUPC;Browallia New;BrowalliaUPC;Bromlila;Corada;Umpush;Thonburi;TH SarabunPSK;TH SarabunNew;Angsana New;AngsanaUPC;Tahoma;Arial Unicode MS;Lucidasans;Lucida Sans/value /prop prop oor:name=CTL_SPREADSHEET oor:type=xs:string oor:op=replace -valueTahoma;Angsana New;OONaksit;Lucidasans;Lucida Sans;Arial Unicode MS/value +valueTahoma;Arial Unicode MS;Waree;Loma;Thonburi;TH SarabunPSK;TH SarabunNew;Angsana New;AngsanaUPC;Lucidasans;Lucida Sans/value /prop prop oor:name=CTL_TEXT oor:type=xs:string oor:op=replace -valueAngsana New;OONaksit;Tahoma;Lucidasans;Lucida Sans;Arial Unicode MS/value +valueAngsana New;AngsanaUPC;Angsima;Kinnari;Norasi;Thonburi;TH SarabunPSK;TH SarabunNew;Tahoma;Arial Unicode MS;Lucidasans;Lucida Sans/value /prop /node node oor:name=ja oor:op=replace ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] change default fall-back font lists for Thai locale in vcl.xcu
On Mon, May 23, 2011 at 9:21 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: Hi Sampha, *, On Mon, May 23, 2011 at 2:36 PM, Samphan Raruenrom samp...@osdev.co.th wrote: I've done a small research on preferred fonts for Thai in Windows/Linux/MacOSX by consulting several communities, font developers and authority. Cood to hear, as most of us will not really know Thai fonts and their difference and won't know what fonts are available on the various systems. Here is the modification that the Thai community decide that best for Thai locale. [...] Please review it and make comments if anything wrong or need to be improved before committing. No complaints, sounds reasonable enough, so go ahead and commit. Just noticed that you removed OONaksit completely, although it was ranking second or third in the previous lists. But as indicated above: I cannot judge the font-choice, I can only comment on the technical part of it, and that is OK from my side. Seems to have a StarOffice/variant-thereof only font if I interpret http://openoffice.org/bugzilla/show_bug.cgi?id=42738#c7 correctly. For the record, OONaksit is the font that is bundled with a fork of OpenOffice.org 1.x (actually we have TWO forks of OpenOffice.org 1.x to enable Thai CTL while OOo didn't support i18n yet). However, the two forks were ended to promote single OpenOffice when OOo 2.0 CTL support was good enough. Some patches from both forks went into OOo and that's why OONaksit is there. But no one get OONaksit installed anymore so we decide to remove it. We add some famous Thai fonts which are included in several Linux distros. And for Thai fonts bundled in MacOSX only Thonburi is voted as good enough. We decide to add TH_Sarabun which is not bundled in any platform but is mandated as THE official font in government sector. And it is also the only font that look good across the 3 platforms so including it help users in mixed environment to exchange documents across platform easier, using the same font. Thank for reviewing the patch :) Samphan. _/|\_ Choice of fonts is left to Thai community, so again: Go ahead :-) (can also use it for 3-4 branch) ciao Christian -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice Tinderbox?
On Wed, Apr 20, 2011 at 5:07 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: On Wed, Apr 20, 2011 at 7:09 AM, Samphan Raruenrom samp...@osdev.co.th wrote: Firefox - Tinderboxpushlog : http://tbpl.mozilla.org/ Doing it this was is near impossible, as the repository is split into multiple ones. Building LibreOffice from master or 3.4 branch is hard for beginners because we don't know which point in time that the branch are buildable on one's platform. http://tinderbox.libreoffice.org/libreoffice-3-4/status.html (note that the build did break because of errors in the translation files) http://tinderbox.libreoffice.org/MASTER/status.html (bah, all red or old) Cool! I should add the above URLs to build LO wiki page, agree? -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice Tinderbox?
Firefox - Tinderboxpushlog : http://tbpl.mozilla.org/ Building LibreOffice from master or 3.4 branch is hard for beginners because we don't know which point in time that the branch are buildable on one's platform. So I'm wondering whether it is possible to setup Tinderbox for LibreOffice project? So that more developers can work on the source. -- _/|\_ /Samphan Raruenrom./ Osdev - Open Source Development Co., Ltd. /สัมพันธ์ ระรื่นรมย์./ โอเอสเด็บ - บริษัท โอเพนซอร์สดิเวลอปเมนต์ จำกัด tel: +66 2 269 9889 web: osdev.co.th http://www.osdev.co.th/ twitter: @osdev http://twitter.com/osdev facebook: facebook.com/osdev http://www.facebook.com/osdev ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Build current master, stuck in odk, configmgr, more_fonts, sw
I have the following error when building the current master (just g pull) ERROR: error 65280 occurred while making /cygdrive/f/git/libo/odk/pack/copying ERROR: error 65280 occurred while making /cygdrive/f/git/libo/configmgr/source ERROR: error 65280 occurred while making /cygdrive/f/git/libo/more_fonts/fonts/ttf_amt ERROR: error 65280 occurred while making /cygdrive/f/git/libo/sw/prj Any idea what went wrong? Thanks, -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] when switch to libreoffice-3-3-2 branch, why the g script disappear
On Tue, Mar 29, 2011 at 2:50 PM, Tor Lillqvist tlillqv...@novell.comwrote: Is this perhaps on Windows? Anybody working on the source on Windows? git has problems replacing files that are in use on Windows, so if a git command attempts to replace the very g script that is being run, it will fail silently, the end result being that g disappears. Just do a git reset --hard HEAD in the bootstrap clone to get it back. I've tried git reset --hard HEAD and I still don't get g back. I have to git checkout master to get g back. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix obvious bug in VCL that prevent glyph-fallback for one glyph-missing character at the end of string
While working on other bugs, we found this bug in
vcl/win/source/gdi/salgdi3.cxx b/vcl/win/source/gdi/salgdi3.cxx . When
there is only one character at the end of the string that require
glyph-fallback, the bug prevent glyph-fallbacking. Because the code will
not detect that the last character need glyph-fallback. It is an obvious
bug because of wrong loop's terminating condition checking.
Please take a look.
Samphan.
--
_/|\_ /Samphan Raruenrom./ Osdev - Open Source Development Co., Ltd.
/ ??./ ? - ?? ?? ?
tel: +66 2 269 9889 web: osdev.co.th http://www.osdev.co.th/
twitter: @osdev http://twitter.com/osdev facebook: facebook.com/osdev
http://www.facebook.com/osdev
diff --git a/vcl/win/source/gdi/salgdi3.cxx b/vcl/win/source/gdi/salgdi3.cxx
index ae62c6e..343f39f 100644
--- a/vcl/win/source/gdi/salgdi3.cxx
+++ b/vcl/win/source/gdi/salgdi3.cxx
@@ -555,13 +555,14 @@ bool WinGlyphFallbackSubstititution::FindFontSubstitute( ImplFontSelectData rFo
{
// guess a locale matching to the missing chars
com::sun::star::lang::Locale aLocale;
+LanguageType eLang = LANGUAGE_DONTKNOW;
sal_Int32 nStrIdx = 0;
const sal_Int32 nStrLen = rMissingChars.getLength();
while( nStrIdx nStrLen )
{
const sal_UCS4 uChar = rMissingChars.iterateCodePoints( nStrIdx );
-const LanguageType eLang = MapCharToLanguage( uChar );
+eLang = MapCharToLanguage( uChar );
if( eLang == LANGUAGE_DONTKNOW )
continue;
MsLangId::convertLanguageToLocale( eLang, aLocale );
@@ -569,7 +570,7 @@ bool WinGlyphFallbackSubstititution::FindFontSubstitute( ImplFontSelectData rFo
}
// fall back to default UI locale if the missing characters are inconclusive
-if( nStrIdx = nStrLen )
+if( eLang == LANGUAGE_DONTKNOW )
aLocale = Application::GetSettings().GetUILocale();
// first level fallback:
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [patch] (draft) remove Andale Sans UI from the LO default font lists
On Fri, Mar 18, 2011 at 9:18 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: Hi Samphan, On Fri, Mar 18, 2011 at 1:05 AM, Samphan Raruenrom samp...@osdev.co.th wrote: On Thu, Mar 17, 2011 at 9:26 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: On Thu, Mar 17, 2011 at 9:02 AM, Samphan Raruenrom samp...@osdev.co.th wrote: [...] Since Andale Sans UI is only available for PC that have installed StarOffice 7 (or newer), I suggest we remove the font from LO default font fallback lists because not many people will have the font installed anyway. You forgot the discussion from February already? Sorry. My English is not very good so I may not understand your message fully. You proposed to remove Andale Sans UI already at the beginning of February, and back then it was explained why this is not a good idea/why this is not necessary. And back then it was also explained that of course bugfixes and extensions of the list for locales that aren't covered properly yet are of course welcome. You just must not make changes carelessly, as chaning the list might have impact on the display of existing documents. (I did consider your post now as bad style. It is like you would ask your father whether you can take a cookie now. Your father says no, thus you ask your mother the same question, hoping that she will answer differently.) ciao Christian Sorry again. But that's not my intention. I mean my English is not good so I misunderstood your Feb reply. I thought that you'd like me to send a patch instead so I do it now. That's my fault to misunderstood your message and I'm sorry for that. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [patch] (draft) remove Andale Sans UI from the LO default font lists
On Thu, Mar 17, 2011 at 9:04 PM, Petr Mladek pmla...@suse.cz wrote: Hi Samphan, first, thanks for your patch. I am not expert on fonts, so please excuse my potentially ignorant questions. Samphan Raruenrom píše v Čt 17. 03. 2011 v 15:02 +0700: See http://www.wazu.jp/gallery/views/View_AndaleSansUI.html Andale Sans UI (soui.ttf) Source: Supplied with StarOffice 7.0, which is free for education and research purposes. Stats: Version 1.10 has 668 glyphs and 3,400 kerning pairs Support: Cyrillic (Russian), Greek, Latin Since Andale Sans UI is only available for PC that have installed StarOffice 7 (or newer), I suggest we remove the font from LO default font fallback lists because not many people will have the font installed anyway. Hmm, I think that it does not cause any harm if Andale Sans UI is in the fallback list. It is ignored if it is not installed. Former StarOffice users might want to use it for backward compatibility. This is what the patch does: 1) remove all instance of Andale Sans UI Could you please explain what it the advantage of this change? I think that I have missed something. OK. I see the point. 2) for UI_SANS, if Andale Sans UI is the first-priority font, use Tahoma instead because it has better glyph coverage than Arial Unicode MS It seems to me that Arial Unicode MS supports more unicode ranges and code pages, see http://www.microsoft.com/typography/fonts/font.aspx?fmid=1081 http://www.microsoft.com/typography/fonts/font.aspx?FMID=1805 Or is Tahoma better for a particular language? I've just found after I've sent the email that Arial Unicode MS has much better glyph coverage. Sorry for not having done the homework enough :P And for that reson, I think we should prefer Arial Unicode MS to Andale Sans UI in UI_SANS case. I'll discuss the rationale in the next reply (to Christian). 3) for th locale, the Thai community are coming with better default font lists that work cross-platform Sounds great. Best Regards, Petr -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [patch] (draft) remove Andale Sans UI from the LO default font lists
On Thu, Mar 17, 2011 at 9:26 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: Hi Samphan, *, On Thu, Mar 17, 2011 at 9:02 AM, Samphan Raruenrom samp...@osdev.co.th wrote: [...] Since Andale Sans UI is only available for PC that have installed StarOffice 7 (or newer), I suggest we remove the font from LO default font fallback lists because not many people will have the font installed anyway. You forgot the discussion from February already? Sorry. My English is not very good so I may not understand your message fully. Please explain the why I definitely say -1 to removing Andale Sans UI unless you refer to the thread in earyl February and explain why you still think it is a good thing to do. From Petr's reply, I agree that we should retaion Andale Sans UI for compatibility with StarOffice 7 users. 2) for UI_SANS, if Andale Sans UI is the first-priority font, use Tahoma instead because it has better glyph coverage than Arial Unicode MS This is a bogus argument, as the there is a font-list especially for the purpose of finding a font that covers the glyph-area. And I kind of doubt that Arial Unicode has less glyphs than Tahoma. Do you have an example? Sorry. I've just found after I sent the email that Arial Unicode MS have very good glyph coverage. 3) for th locale, the Thai community are coming with better default font lists that work cross-platform This is fine with me. I'll send a patch for the th locale after the Thai community reach a conclusion on this. But again: Please take a look and make comments. You had those comments in February already. And now you come with the very same proposal of removing Andale Sans UI without even referring to the previous thread. Sorry again for that. I misunderstand the thread and thought that you'd like to see the patch. I'll read your Feb comments again. ciao Christian -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Approaches to enable international number format import/export in Calc
OK. Let me propose a better patch (attached) using the first approach. Also attach to the bug : https://bugs.freedesktop.org/show_bug.cgi?id=33089 This only to enable the conversion of Thai buddhist calendar and Thai native numeral between Excel and Calc. I wish I could add more support for other locale's but we need inputs from developers in each locale that define their own calendars and native numerals. So please share your locale specific details or reference materials. (sorry for cross-posting) On Tue, Mar 8, 2011 at 12:47 PM, Kohei Yoshida kyosh...@novell.com wrote: On Tue, 2011-03-08 at 00:04 -0500, Kohei Yoshida wrote: So what do you think? Given the above, to me the choice is clear. The only issue is that, we may already have lost an window of opportunity to do it the right way for 3.4. So, we may have to take your patch for 3.4, and work on my proposed solution post-3.4. I can't say for sure which direction we are going for 3.4 at the moment. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ i33089.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Approaches to enable international number format import/export in Calc
Surprisingly, Calc doesn't support or even handle import/export from/to Excel international number format, result in lost of information from dates in non-western locale when convert. For example, these dates in Excel (see i18ndate.xls file) When import to Calc will become The reason is that Excel international number format (LCID) is completely different from Calc's. See https://office.microsoft.com/en-us/excel-help/creating-international-number-formats-HA001034635.aspx The correct import would generate the following in Calc (see manually-fixed i18ndate.ods) (note: still see difference in how Excel and Calc interpret Hijri calendar) See LibO bug https://bugs.freedesktop.org/show_bug.cgi?id=33089 and the original OOo issue http://openoffice.org/bugzilla/show_bug.cgi?id=93503 In bugzilla, I and Kohei have made a discussion about the approaches to fix this problem :- 1) When import from Excel, convert Excel LCID (4-8 hex digits) to Calc's natnum and calendar specifier. When export reverse the process to generate the appropriate Excel LCID. 2) When import form Excel, maintain Excel LCID as-is in Calc number format. When export use the LCID already there. Since this is a feature that effect many non-western locales. Each with specific details in how they handle local calendars and natnums. I think we should make this important decision first, before we start to implement it. This will benefit every non-western locales with natnums and/or local calendars. I know because this is the top-priority bug in Thai, to convert date in buddhist calendar from Excel. Other non-western locales must have faced similar problems. So what do you think? -- _/|\_ Samphan Raruenrom.? Osdev - Open Source Development Co., Ltd. ??.? ? - ?? ?? ? tel: +66 2 269 9889? web: osdev.co.th twitter: @osdev? facebook: facebook.com/osdev ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Please review our patch for Bug 33089 – Calc export of non-gregorian date to Excel loses format
Thanks! See my long description on the bugzilla. On Tue, Feb 22, 2011 at 4:59 AM, Kohei Yoshida kyosh...@novell.com wrote: On Mon, 2011-02-21 at 12:02 +0700, Samphan Raruenrom wrote: https://bugs.freedesktop.org/show_bug.cgi?id=33089 This is the no.1 most serious bug that effect many Thai users esp. organization users. The patch is our work on fixing the bug. Please review it to see if it could be commit to LibreOffice or is there any change that is needed. As I wrote in the bugzilla, I need a summary and a brief explanation of the change that the patch makes in order to understand the issue. Right now there is only a code change with no explanation, which makes it harder for me to review. Could you provide a little more context to the patch? Thanks! Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Please help us fix this Writer autocorrect bug
I'm going to work on this bug. Anyone have any idea about the problematic auto-style T1 in the bug report? Bug 33092 Autocomplete display double character for this word [CTL / Thai] https://bugs.freedesktop.org/show_bug.cgi?id=33092 Step to reproduced: 1.Open a blank Writer document. 2.Switch keyboard to Thai. 3.Type text by press ,b5. 4.The function autocomplete will display the full word. Expect result: This function should display the text as . Real result: It displays the text with the second character doubled and overlapped. (See the pictures) This problem occurs when some text is splitted into 2 runs. if a non-spacing vowel mark (e.g. ?) is placed at the first character of the second run, the text will be displayed overlap. But the problem will occur in the first (regarding position in the document) autocompleted word in a document. I've pasted 2 snipplets of content.xml to show examples:- A: Western autocomplete case: text:p text:style-name="Standard"January/text:ptext:p text:style-name="Standard"february/text:p B1: Thai autocomplete case with overlapped text: text:p text:style-name="Standard"???text:span text:style-name="T1" ?/text:span/text:ptext:p text:style-name="Standard"text:span text:style-name="T1"/text:span/text:p B2: Thai autocomplete case without problem: text:p text:style-name="Standard"???text:span text:style-name="T1" /text:span/text:ptext:p text:style-name="Standard"text:span text:style-name="T1"???/text:span/text:p You will see that, in case B1 and B2, the first autocompleted word (e.g. "") is splitted before the vowel mark (?). But in the second autocompleted word (e.g. ""), the entire autocompleted word is placed in the text:span element. OOo seems not to be able to display non-spacing mark at the begining of a text run so that's why the text is displayed overlapped. Note that the splitted autocompleted word always happend if you insert the word before any other autocompleted word. That is, it happend only for the first occurance of such autocompleted words. -- _/|\_ Samphan Raruenrom.? Osdev - Open Source Development Co., Ltd. ??.? ? - ?? ?? ? tel: +66 2 269 9889? web: osdev.co.th twitter: @osdev? facebook: facebook.com/osdev ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help to debug with Visual C++ 2008
FYI: We simply rename soffice.bin to soffice.bin.exe and open in it Visual C++. Then add those path you mentioned in Project Properties. Thanks. On Mon, Feb 7, 2011 at 4:56 PM, Tantai Tanakanok tan...@osdev.co.th wrote: Thanks Tor, It's work. On Mon, Feb 7, 2011 at 3:33 PM, Tor Lillqvist tlillqv...@novell.comwrote: I success debug with Attach to process solution but I want to debug the code that execute when LibO start. Ah. That is always hard for me because 1) I never remember which source file it is that actually contains the main program of soffice.bin. There are half a dozen or so files with promising names and/or promising directory names... of course none of them has any comment giving a short descreiption of its purpose. 2) Once you figure out which file actually is the real main, you then need to build that stuff with debug=t, open the soffice.bin in VS (does VS like that, does it understand that it is a normal executable even if called .bin, don't know), and I guess set in the project's properties PATH so that it includes the URE/bin and Basis/program directories, and then just start it under the debugger. Occasionally I have found it easier to just add a volatile int hang=1; while (hang); loop in the main program or some other low-level enough function, once I find it, and start it normally and just attach soffice.bin in the debugger, break it, set breakpoints, set hang to zero, and continue... --tml -- _/|\_ Tantai Thanakanok. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice default UI font need to be changed
Christian, I agree completely with you and learn a lot from you detail explanation. Next I'd need a bit of advice to fix the bug I've mentioned. On Sun, Feb 6, 2011 at 1:40 AM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: On Sat, Feb 5, 2011 at 9:59 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: On Sat, Feb 5, 2011 at 6:38 PM, Nguyen Vu Hung vuhung16p...@gmail.com wrote: [VCL.xcu / list of default fonts and fallback] When there are issues cross-locale, then raise them. It is not that the list didn't change since the beginning of the OOo project. If I understand the OP correctly, he wants LibO to 1. Handle different languages on different locales. This is already done. I'd like to explain a bit about our (Thai) situation. Thai users may use en_US or th_TH for UI locale to get English menu and translated menu respectively. Normally, en_US are used for most users. The UI font replacement list based on locale seem to assume that for en_US UI locale, only Western characters will be in the UI. However, UI font isn't only used for static text in menu and dialog box. But also for user text in File Property Description text boxes, File Recent Documents filename list, and Calc formula bar. For user/editable text like these, they could be in any languages - Western, CTL, CJK. So with this (user text) in mind, the higher-priority font in UI font list should have good glyph coverage. For example (I know little about fonts), Tahoma or Microsoft Sans Serif in Windows. So I imagine replacing Andale UI with Tahoma (or better default) in the list. Having default with good glyph coverage is a good thing. However, LibO itself should display any multi-lingual text correctly if glyph fallback work correctly. But as you can see in the bug we've submitted : https://bugs.freedesktop.org/show_bug.cgi?id=33090 Glyph fallback for *CTL* text in *Windows* is currently broken but *only*for UI text rendering, not for text in the document. It used to work in older versions. This is the part that we'd like to fix. Can you give as a clue about where should we look in the VCL source? Thanks. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] A patch need review Re: Who do I know when a patch will make it to a release
Can someone review the patch to go to libreoffce-3-3, please. On Sat, Feb 5, 2011 at 2:09 AM, Caolán McNamara caol...@redhat.com wrote: On Fri, 2011-02-04 at 09:44 +, Michael Meeks wrote: Caolan - are you happy for this: commit 6c01edfe66d6e350b20178d9ab367806d956cb46 Author: Caolán McNamara caol...@redhat.com Date: Thu Nov 11 13:31:33 2010 + Resolves: #i25247#, #i25561#, #i48064#, #i92341# CTL/Other Default Font to go to libreoffice-3-3 ? if so, I guess that's fine without further review; at least it looks like an Oracle patch to me - 'ftcAsci' eg. ;-) Its my patch, so I'm happy with it by definition, and someone else probably needs to do a quick review of it. ftcAsci is the spelling used in the MS docs for this (IIRC), not mine. C. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice default UI font is StarOffice Andale Sans UI ?
Anyone agree that we should change the LibreOffice default UI font list?
On Fri, Feb 4, 2011 at 2:54 PM, Samphan Raruenrom samp...@osdev.co.thwrote:
Look at
http://opengrok.go-oo.org./xref/libs-core/officecfg/registry/data/org/openoffice/VCL.xcu#129
prop oor:name=UI_SANS oor:type=xs:string oor:op=replace
valueAndale Sans UI;Arial Unicode MS;Lucida Sans Unicode;Tahoma;DejaVu
Sans;Albany AMT;Albany;Arial;Nimbus Sans L;Interface
User;WarpSans;Geneva;Tahoma;MS Sans
Serif;Helv;Dialog;Lucida;Helvetica;Charcoal;Chicago;Helmet;Interface
System;Sans Serif/value
/prop
You can see that the first-priority default UI font of every LibreOffice
applications are, Andale Sans UI. However, Andale Sans UI is not
available on all system. I guess Andale Sans UI will be installed with
StarOffice. So it's not logical to be used as the first-priority default UI
font.
Look at
http://opengrok.go-oo.org./xref/libs-gui/vcl/source/window/window.cxx#287
if ( ! aUserInterfaceFont.Len() )
{
String aFallbackFont (RTL_CONSTASCII_USTRINGPARAM( Andale Sans UI
));
if ( mpWindowImpl-mpFrameData-mpFontList-FindFontFamily(
aFallbackFont ) )
aUserInterfaceFont = aFallbackFont;
}
The font also is used as the last-resort fallback font. I suggest we
reconsider the use of this font and create a better font list that works
more cross-platform and cross-locale.
As a side-effect, this would help us fix a Thai locale-sensitive bug :
https://bugs.freedesktop.org/show_bug.cgi?id=33090
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Who do I know when a patch will make it to a release
I found that the patch to fix this bug https://bugs.freedesktop.org/show_bug.cgi?id=33044 was submitted in master. However, I still see the bug in LibO 3.3 so the patch must landed somewhere outside the libreoffice-3-3 branch. I don't understand much about LibreOffice git branches. However, the bug is important for Thai. How can we know when the patch will make it to which release? -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Who do I know when a patch will make it to a release
On Sat, Feb 5, 2011 at 2:09 AM, Caolán McNamara caol...@redhat.com wrote: On Fri, 2011-02-04 at 09:44 +, Michael Meeks wrote: Caolan - are you happy for this: commit 6c01edfe66d6e350b20178d9ab367806d956cb46 Author: Caolán McNamara caol...@redhat.com Date: Thu Nov 11 13:31:33 2010 + Resolves: #i25247#, #i25561#, #i48064#, #i92341# CTL/Other Default Font to go to libreoffice-3-3 ? if so, I guess that's fine without further review; at least it looks like an Oracle patch to me - 'ftcAsci' eg. ;-) Its my patch, so I'm happy with it by definition, and someone else probably needs to do a quick review of it. ftcAsci is the spelling used in the MS docs for this (IIRC), not mine. The intention for my original post is two fold:- 1) I'd like to know when/which-version will this fix land in. 2) I'd like to understand the policy for development vs. release branches. For example, which committed patches will be in the 3.3.1 or 3.4 release. How things like this are planned/decided (which used to be group by child workspaces before). -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice default UI font need to be changed
Look at
http://opengrok.go-oo.org./xref/libs-core/officecfg/registry/data/org/openoffice/VCL.xcu#129
prop oor:name=UI_SANS oor:type=xs:string oor:op=replace
valueAndale Sans UI;Arial Unicode MS;Lucida Sans Unicode;Tahoma;DejaVu
Sans;Albany AMT;Albany;Arial;Nimbus Sans L;Interface
User;WarpSans;Geneva;Tahoma;MS Sans
Serif;Helv;Dialog;Lucida;Helvetica;Charcoal;Chicago;Helmet;Interface
System;Sans Serif/value
/prop
You can see that the first-priority default UI font of every LibreOffice
applications are, Andale Sans UI. However, Andale Sans UI is not
available on all system. I guess Andale Sans UI will be installed with
StarOffice. So it's not logical to be used as the first-priority default UI
font.
Look at
http://opengrok.go-oo.org./xref/libs-gui/vcl/source/window/window.cxx#287
if ( ! aUserInterfaceFont.Len() )
{
String aFallbackFont (RTL_CONSTASCII_USTRINGPARAM( Andale Sans UI ));
if ( mpWindowImpl-mpFrameData-mpFontList-FindFontFamily(
aFallbackFont ) )
aUserInterfaceFont = aFallbackFont;
}
The font also is used as the last-resort fallback font. I suggest we
reconsider the use of this font and create a better font list that works
more cross-platform and cross-locale.
As a side-effect, this would help us fix a Thai locale-sensitive bug :
https://bugs.freedesktop.org/show_bug.cgi?id=33090
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] web based libre office
Another idea for a shorter-term solution for this is, instead of web-based LibO, someone make a synchronization software that relay changes between off-line ODF and online Google Docs, a la Google Cloud Connect for MS Office. Working with Google Docs is somewhat painful because it still lacks many familiar features. An ideal solution would be to use a fat client that store the ODF in the cloud. Many users can use the fat client to edit the document at the same time while the synchronization software relay the changes made by different users. Google Docs would be nice as the cloud storage except that ODF lost a lot of formatting when convert to Google Docs. On Mon, Jan 24, 2011 at 10:03 PM, Michael Meeks michael.me...@novell.comwrote: Hi Ged, On Mon, 2011-01-24 at 15:06 +0100, Ged Wed wrote: whats the support for doing a web based open office ? Ajax based with a restful JSON or XML model. Well, it is not an impossibly bad idea :-) I am asking because this seems like such a good move. Libre Office would then have a very compelling solution that neither google Docs or MS Office can really compete against. Riight; except they are already in the market place - which makes us at least two years away from there, even if we had a product now :-) - what is important is that both the fat client and the thin client are both adapted towards the client / server model together. This makes both version easy to maintain, change control, testing etc Well - since we have a fat client; I would personally focus on two things: a) feature parity between fat and web client + no-one else does this. + fat client for off-line, web for (who? ;-) b) abandon hope of off-line web editing: that's why you have the fat client right ? :-) which means, we have to re-use the fat client on the web server; that means all sorts of good things: we need to make it smaller, more reliable, faster to start, etc. etc. and it also makes some things a lot easier; IMHO doing remote rendering by cutting at VCL and proxying rendering (wherever possible) to a remote canvas, -might- work in semi-linear time. I'm thinking a re-hash of: http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ Though of course VCL's rendering APIs are (now) substantially less pleasant than gtk+'s. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ICU bloat ...
You can easily minimize the ICU footprint by tweaking the ICU build options. See http://userguide.icu-project.org/packaging http://userguide.icu-project.org/packagingThe result will be like this - http://site.icu-project.org/charts/icu4c-footprint http://site.icu-project.org/charts/icu4c-footprint On Fri, Jan 14, 2011 at 7:27 PM, Michael Meeks michael.me...@novell.comwrote: 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: http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/size-sal-textenc.diff 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: http://wiki.documentfoundation.org/Development/Easy_Hacks#de-bloat_internal_ICU Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
