Re: PATCH (tweaking the fill in character support in Calc Number Format Strings)
On 27/08/12 15:29, Johann Messner wrote: Now, I am wound up to a high pitch ... I am looking forward to a binary LO release in the future featuring the fill in character Cell format specifier ;-))) thanks once again for your nice patches, you can see them http://cgit.freedesktop.org/libreoffice/core/commit/?id=f727644ad18838a78525256623a33f864fe13fb2 http://cgit.freedesktop.org/libreoffice/core/commit/?id=84c54990c0dbd3385a4a653afe63d0fa7b1c435b thanks again also to Eike who reviewed also. also I added your details ( and license attribution ) here https://wiki.documentfoundation.org/Development/Developers#First_name_from_G_to_N Look forward to the next patch from you ( please see details https://wiki.documentfoundation.org/Development#Preparing_patches on the preferred methods of sharing patches with us ) thanks again, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PATCH (tweaking the fill in character support in Calc Number Format Strings)
Hi On 26/08/12 21:47, Johann Messner wrote: Hello Noel, [dear valued libreoffice developers and hackers], please check out on https://linux.jku.at/messner/LibreOffice/ the patch file patchInfo-26-Aug-2012__against_libreoffice_Master.txt thank you for making those changes against master, I appreciate it, it is much easier to see the changes now, I cc. Eike here who also has ( I hope ) also some interest in your patch ( but more importantly knows stuff ) it proposes some codes adaptions in order to tweak the fill in character support in Calc's Cell Formtat Strings as introduced in http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/28410ose changes too :-) So, in summary the changes are a) to change the how the formatter marks the repeating character, it looks like now 0x1b is 'before' the char to repeat, previously it was after ( makes more sense to me to have the marker preceding the repeat char ) Eike, was there any reason for the original scheme that you recall or any objections to changing b) in cellform.cxx let cells with type CELLTYPE_STRING apply the format with the repeating code also. Hmmm now I did see this previously but I didn't see why the a string type cell would need to apply the numeric format, so I left it out, I presume this change is necessary for some types of non numberic cell content, I would guess maybe dates or something? is that correct ? ( or if not I'd be interested in the scenario that requires it ) c) same as above except for CELLTYPE_FORMULA, so yes, this was oversight by me, formulas can have numeric results for sure that could use the repeating character format support so that part is needed. I guess the change to the format for the else leg of the 'if ( pFCell-IsValue() )' test probably has some similar rational as in the string case. d) some additional checks to prevent potential div/0 which are fine e) the new built-in formats, Eike are they ok for you? if they are I also not sure what ( if any ) additional effort is required to internationalise those formats :/ ps. did you already state you licence intentions for your patches, the usual is to post some blanket statement All my contributions, past and future, to LibreOffice are licensed under the terms of the MPL / LGPLv3+. to the list, if you haven't done so already would/could you do that please, thanks again Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PATCH (tweaking the fill in character support in Calc Number Format Strings)
hi Noel, prologue: All my contributions, past and future, to LibreOffice are licensed under the terms of the MPL / LGPLv3+. Am Mo, 27.Aug.12, KW35 (15:54:57 Uhr) schrieb Noel Power nopo...@suse.com: So, in summary the changes are b) in cellform.cxx let cells with type CELLTYPE_STRING apply the format with the repeating code also. Hmmm now I did see this previously but I didn't see why the a string type cell would need to apply the numeric format, so I left it out, I presume this change is necessary for some types of non numberic cell content, I would guess maybe dates or something? is that correct ? ( or if not I'd be interested in the scenario that requires it ) According to the related ODF Specification (or is it an extension?) all of the cell types (including Number, Date, Text, user defined, and so on) should support the fill in character format specifier ... [pls see https://tools.oasis-open.org/issues/browse/OFFICE-3765 ] c) same as above except for CELLTYPE_FORMULA, so yes, this was oversight by me, formulas can have numeric results for sure that could use the repeating character format support so that part is needed. I guess the change to the format for the else leg of the 'if ( pFCell-IsValue() )' test probably has some similar rational as in the string case. Yes, you are absolutely right. d) some additional checks to prevent potential div/0 which are fine OK e) the new built-in formats, Eike are they ok for you? if they are I also not sure what ( if any ) additional effort is required to internationalise those formats :/ ps. did you already state you licence intentions for your patches, the usual is to post some blanket statement All my contributions, past and future, to LibreOffice are licensed under the terms of the MPL / LGPLv3+. to the list, if you haven't done so already would/could you do that please, ... of course (please see the prologue of this eMail) thanks again Noel Now, I am wound up to a high pitch ... I am looking forward to a binary LO release in the future featuring the fill in character Cell format specifier ;-))) Many thanks to all of you in the LibreOffice Project for the good work (german..insbesondere gilt Eike Rathke bzw. den Leuten vom =STARCALCTEAM() unsere Anerkennung und unser aller Dank!!/german) best regards, hans ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PATCH (tweaking the fill in character support in Calc Number Format Strings)
Hi Noel, On Monday, 2012-08-27 14:54:57 +0100, Noel Power wrote: a) to change the how the formatter marks the repeating character, it looks like now 0x1b is 'before' the char to repeat, previously it was after ( makes more sense to me to have the marker preceding the repeat char ) Eike, was there any reason for the original scheme that you recall or any objections to changing I don't recall anything special there, we just had it wrong ;-) in fact Excel puts the '*' before the character to repeat, so that's what we should do as well. b) in cellform.cxx let cells with type CELLTYPE_STRING apply the format with the repeating code also. Hmmm now I did see this previously but I didn't see why the a string type cell would need to apply the numeric format, so I left it out, I presume this change is necessary for some types of non numberic cell content, I would guess maybe dates or something? is that correct ? ( or if not I'd be interested in the scenario that requires it ) The text format may have embedded characters, so a cell containing foo displayed with a format code of 'bar @ baz' shows as bar foo baz. Each number format may also have a text subformat (the 4th subformat) in case the cell content is text and not number, e.g. 0;-0;;text:* @ in Excel works as expected. c) same as above except for CELLTYPE_FORMULA, so yes, this was oversight by me, formulas can have numeric results for sure that could use the repeating character format support so that part is needed. I guess the change to the format for the else leg of the 'if ( pFCell-IsValue() )' test probably has some similar rational as in the string case. d) some additional checks to prevent potential div/0 which are fine e) the new built-in formats, Eike are they ok for you? In general yes, there just should be no gaps in the formatindex=... values, so continue with whatever each locale's last index is. if they are I also not sure what ( if any ) additional effort is required to internationalise those formats :/ I'd leave that to localizers. There are 16 possibilities to display a negative currency amount (with/without blanks between symbol and amount, symbol preceding or following amount, minus before or after amount or before or after symbol, or no minus but parentheses, ...) plus variants whether some character's width gap is included or not. Excel's default en-US accounting format code is _($* #,##0.00_);_($* (#,##0.00);_($* -??_);_(@_) while for de-DE it is _-* #.##0,00 €_-;-* #.##0,00 €_-;_-* -?? €_-;_-@_- ... Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgp82JyaPyEZt.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PATCH (tweaking the fill in character support in Calc Number Format Strings)
Hi Johann, On Monday, 2012-08-27 16:29:06 +0200, Johann Messner wrote: Many thanks to all of you in the LibreOffice Project for the good work (german..insbesondere gilt Eike Rathke bzw. den Leuten vom =STARCALCTEAM() unsere Anerkennung und unser aller Dank!!/german) Lol, thanks :-) The easter-egg police wiped all traces of history.. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgp5bjkVXzgbT.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
