[Libreoffice] [PATCH] Make numbering more flexible by custom separator

[Eike Rathke]

Hi Mohammad,

On Saturday, 2011-08-27 04:09:34 +0430, Mohammad Elahi wrote:

> By this patch suffix and prefix in number styles are used
> only for specified level number not on the whole number. So the
> hardcoded "." separator was removed.

While replacing the hardcoded '.' may be a good thing, I'm not convinced
of the changes to the prefix/suffix handling.


> @@ -715,6 +715,7 @@ String SwNumRule::MakeNumString( const SwNumberTree::tNumberVector & rNumVector,
>                      continue;
>                  }
>  
> +                aStr+=rNFmt.GetPrefix();
>                  if( rNumVector[ i ] )
>                  {
>                      if( bOnlyArabic )
> @@ -724,18 +725,7 @@ String SwNumRule::MakeNumString( const SwNumberTree::tNumberVector & rNumVector,
>                  }
>                  else
>                      aStr += '0';		// alle 0-Level sind eine 0
> -                if( i != nLevel && aStr.Len() )
> -                    aStr += aDotStr;
> -            }
> -
> -            //JP 14.12.99: the type dont have any number, so dont append
> -            //				the Post-/Prefix String
> -            if( bInclStrings && !bOnlyArabic &&
> -                SVX_NUM_CHAR_SPECIAL != rMyNFmt.GetNumberingType() &&
> -                SVX_NUM_BITMAP != rMyNFmt.GetNumberingType() )
> -            {
> -                aStr.Insert( rMyNFmt.GetPrefix(), 0 );
> -                aStr += rMyNFmt.GetSuffix();
> +                aStr+=rNFmt.GetSuffix();
>              }

Removing the entire block and unconditionally appending the suffix
ignores the bInclStrings parameter, and furthermore and maybe more
important ignores the previously present condition of not having
a special character and not having a bitmap in that level. A bitmap or
special character most certainly is not followed by any suffix. I don't
know when bInclStrings is exactly passed, but it looks like a switch for
prepending/appending prefix and suffix to the entire string. bOnlyArabic
seems to specify whether only Arabic digits are to be used and then the
entire string is not surrounded by prefix/suffix. Stuffing in prefix AND
suffix on each level seem to be wrong to me, and I don't think prefix
was meant to be used like a suffix or replacement for '.' dot.

This probably will also have to be inspected in various locales where
prefix and suffix values may differ and suffix may or may not be
a replacement for '.' dot.


> @@ -810,6 +810,7 @@ String 	SvxNumRule::MakeNumString( const SvxNodeNum& rNum, sal_Bool bInclStrings
>                  }
>  
>                  sal_Bool bDot = sal_True;
> +                aStr += rNFmt.GetPrefix();
>                  if( rNum.GetLevelVal()[ i ] )
>                  {
>                      if(SVX_NUM_BITMAP != rNFmt.GetNumberingType())
> @@ -819,15 +820,9 @@ String 	SvxNumRule::MakeNumString( const SvxNodeNum& rNum, sal_Bool bInclStrings
>                  }
>                  else
>                      aStr += sal_Unicode('0');		// all 0-levels are a 0
> -                if( i != rNum.GetLevel() && bDot)
> -                    aStr += sal_Unicode('.');
> -            }
> -        }
>  
> -        if( bInclStrings )
> -        {
> -            aStr.Insert( rMyNFmt.GetPrefix(), 0 );
> -            aStr += rMyNFmt.GetSuffix();
> +                aStr += rNFmt.GetSuffix();
> +            }
>          }

Same here, modulo bitmap and special character.


  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110827/979cb088/attachment.pgp>