support for repeating format code in calc

Noel Power nopower at suse.com
Wed Apr 25 02:37:29 PDT 2012


Hi Eike
On 24/04/12 20:31, Eike Rathke wrote:
> Hi Noel,
>
> Sorry, this took too long..
No problem, thanks for taking the time and having a look
>
> On Wednesday, 2012-04-18 21:01:41 +0100, Noel Power wrote:
>
>> I've been looking at providing support for the repeating character
>> in number formats. I've been playing abit with the code and what I
>> have sofar seems to work reasonably well ( no doubt there are plenty
>> of edge cases still to be discovered )  But.. life would be simpler
>> I think if we had just stored a plain format code like docx seems to
>> rather than the fancy pants xml that's there now :/
> Well, try to exactly specify that format code syntax for an open
> standard, with all it's quirks MS may have hidden.. ironically even
> OOXML didn't attempt that. Yes, _they_ got away with that..
;-) ahh my gripe is the xml seems a little over the top where a plain 
string format would do ( and be possibly be easier to change )  also 
would be closer or same as what's actually used in the formatter. The 
fact the format may not be well specified by MS is another matter ( and 
yes, their specification(s) to do with that are fuzzy ) :-) But really I 
am only complaining because I can't figure out a way not to have to 
incur an odf change and all the 'fun' that might bring :-)
[...]
>
> Note that Excel's '*' definition is a bit "unsharp":
>
> http://office.microsoft.com/en-us/excel-help/number-format-codes-HP005198679.aspx
> Text and spacing, Repeating characters:
>
> | To repeat the next character in the format to fill the column width,
> | include an asterisk (*) in the number format. For example, type 0*- to
> | include enough dashes after a number to fill the cell, or type *0 before
> | any format to include leading zeros.
>
> So "fill the column width" actually knows (I guess?) three conditions:
> * start of text: fill from left border to text
> * in text: split text in two, left justify first part, right justify
>    second part, fill with character in between
> * end of text: fill from text to right border
>    (this I only guess, does Excel do that?)
maybe I am naive, isn't this complicating things ( right/left justified 
? ) doesn't it just fill to available width ( granted with assumed 
knowledge of column width border size etc. ) with 0 or more of the 
character to repeat ? I would expect an existing left/center/right 
justification on the cell to be ignored when this 'special' format code 
is specified ( admittedly I haven't tried this... )
>
> Whatever Excel does nowadays if more than one * are present, I hope it
> still bails out with an error.
you will think I am very lazy, I think trying to report errors in those 
formats would be more complex than it's worth  ( e.g  you need to 
generate messages ( where? ) with  "[ specific type of format err ] at 
position x" type information )
Afaics  with mso (xp at least) and libreoffice  the formatter fails 
silently, I mean generally I suppose people just rely on the preview 
and/or applying the format to show you if the format worked. With that 
in mind I would specify ( in whatever specification blurb we might 
provide ) that we expect only one '*[char]' in the format but in the 
event of more that one occurrence we take ( to be decided ) either the 
first or last one and ignore the others.
>   And what if it occurs in date/time format
> codes?
I am completely ignoring those for the moment, should work the same 
though, that would be the intention :-)
>
> I assume also left/centered/right justification affects things for
> leading/trailing fills.
unless Excel does this I would avoid such complication like the plague ( 
especially given my complete ignorance in such matters ;-) ) Saying that 
I didn't test even what would happen on the calc side with same :-/
>
> Given that I think we'd need a number:fill-character or some such
> attribute to go with
> 16.27 Data Styles
> http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#__RefHeading__1416346_253892949
> with the limitation that it can be present only once (if that is what
> Excel does) and specyfing what happens in these three conditions.
>
> Your number:repeated does fine, but may not survive ODF-speak (neither
> may my number:fill-character ;-) as someone might ask "how many times to
> be repeated".
I really hope no question like that comes up, surely the concept of a 
code/directive that is implemented by the view/layout ( there must be 
other types of fill to width/height etc. concepts in writer/calc ) is 
not alien.
So basically we are talking about changing 'repeated' to 
'fill-character' and using it in the same way? ( /me thinks +1 for 
'number:fill-character' which imo better describes things anyway )
[...]
>    Also I worry a little that there seemed to be at one
> point support for the '*' format code, I wonder what the history was
> or is it just a case of unfinished business?
> That is a remainder of old times.. the format code scanner is able to
> handle that (and it should)
definitely seems to handle it :-)

[...]

> we could use
>
>      String aFill;
>      aFill.Expand( nNumCharsToInsert, mnChar);
>      aTmpStr.Insert( aFill, mnPos);
>
> to avoid multiple reallocations with character-based Insert.
we just should use that, I will change it thanks!
>> +    SfxObjectShell* pDocSh  = SfxObjectShell::Current();
>> +    if ( pDocSh )
>> +    {
>> +        // is this a calc document
>> +        Reference<  XServiceInfo>  xSI( pDocSh->GetModel(), UNO_QUERY );
>> +        if ( xSI.is() )
>> +            bUseStarFormat = xSI->supportsService( rtl::OUString( "com.sun.star.sheet.SpreadsheetDocument" ) );
>> +    }
> Heh, that's clever :-)
no no, not clever, this just relects my the fact I haven't looked at or 
really thought about writer much yet, since those formats can be used in 
writer tables it *might* make sense to use them in that context too ( 
the same odf elements apply right ? ) but then again a table column 
doesn't have to exclusively contain the number formatted item so it's 
not quite the same and its not clear to me where what width you might 
fill to ( we might be better off just avoiding that altogether )

So, assuming there is nothing controversial about my thoughts above ( 
and I guess I need to do some more investigation wrt justification ) the 
question is where to go next?, what's the standard way of moving 
forward?, in the meantime can we use some experimental name space, can 
we assume 'number:fill-character' can be used?

thanks again
Noel


More information about the LibreOffice mailing list