The display of pencentage format (as well as many other formats, most apparent for time and date) depends on locale.  What is the "Language" setting in your cell format dialog when you change the pencentage format and leading zeroes?  If you didn't change it yourself, I believe the default language is decided by locale (so sv-SE?).

In any case, I can't reproduce the space between numbers and the percent sign %, under either English (en-US) or simplified Chinese (zh-CN) UI (both are set to zh-CN locale per OS, I believe):
Version: 6.4.7.2 (x64)
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

I can, however, see the space between numbers and % (i.e. "17.55 %") if I set the "Language" setting in cell format to "French (France)".

So please provide an example document showing the inconsistency (use the "Add an attachment" link on this page, above the comment text box), and we can see if it's indeed a bug in LibreOffice or just some locale/language setting difference on your side.

Created attachment 167075 [details]
Archive with simple ODS and four screen grabs

(In reply to Ming Hua from comment #1)
> The display of pencentage format (as well as many other formats, most
> apparent for time and date) depends on locale.  What is the "Language"
> setting in your cell format dialog when you change the pencentage format and
> leading zeroes?  If you didn't change it yourself, I believe the default
> language is decided by locale (so sv-SE?).
> 
> In any case, I can't reproduce the space between numbers and the percent
> sign %, under either English (en-US) or simplified Chinese (zh-CN) UI (both
> are set to zh-CN locale per OS, I believe):
> Version: 6.4.7.2 (x64)
> Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
> CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
> Locale: zh-CN (zh_CN); UI-Language: en-US
> Calc: threaded
> 
> I can, however, see the space between numbers and % (i.e. "17.55 %") if I
> set the "Language" setting in cell format to "French (France)".
> 
> So please provide an example document showing the inconsistency (use the
> "Add an attachment" link on this page, above the comment text box), and we
> can see if it's indeed a bug in LibreOffice or just some locale/language
> setting difference on your side.

I was really identifying the inconsistency of the "additional" space depending upon whether the integer value has one or more digits. Also, as mentioned, reformatting the cell to only one leading zero (integer digit) doesn't revert the format so the user is now left with an unchangeable undesired format with the % indicator no longer aligned in a tabular fashion - but at least the decimal is aligned if a mono spaced font is utilised ;).

Created attachment 167076 [details]
Screenshot of the example file when opened in zh-CN locale, en-US UI

(In reply to Colin from comment #3)
> I was really identifying the inconsistency of the "additional" space
> depending upon whether the integer value has one or more digits.

I understand the problem you are describing, what I was saying is that the problem is dependent on locale, as I can not reproduce the problem using your steps in comment 0.

I do see the same problem in your attached sample file, however in that file, the locale/language of the cells are not defined (or defined as default), as it is shown as "Default - Chinese (simplified)" when opened on my computer.  See screenshot.  You can also see that it's using period (.) instead of comma (,) as the decimal separator, which is also decided by locale/language.

So in order to figure out the cause of the problem, more testing under your specific Swedish locale is needed to get the exact steps to reproduce.

The issue is concerned more with the single-digit integer samples below the cell you have investigated. I can see there are numerous potential variations on the space/no space theme but looking specifically at the "smaller" values it can be seen that having decided the "two leading zeros" parameter with or without additional space characters doesn't satisfy my requirements, the formatting then malfunctions when the cell is re-formatted to only one leading zero.
It doesn't permit a fallback to a layout without "zero padding" whilst retaining the original, additional space - in fact I can only re-introduce a space between the value and the symbol if I overwrite the cell and start all over again.

If loCALC had the ability to right format with indent in the same manner as EXCEL or a decimal tab alignment format then it would never even have been noticed.
I tried to "Zero Fill" to achieve a left indent and artificial "decimal tab" which was almost satisfactory apart from the spacing of the symbol but it was the lack of "reverting" to the original format when the leading zero parameter was reset to 1 which seemed unusual.
As a member of the development squad, are you aware of any intention to facilitate right aligned indents or decimal alignment of CALC cells?
Would submitting enhancement requests be a more worthy endeavour?

(In reply to Colin from comment #5)
> It doesn't permit a fallback to a layout without "zero padding" whilst
> retaining the original, additional space - in fact I can only re-introduce a
> space between the value and the symbol if I overwrite the cell and start all
> over again.
There is no need to start all over again.  The "Format code" part in the Format dialog is editable, just add the space back, i.e. 0.00" "% (maybe it's a non-break space, I'm not sure" when you reformat it to one leading zero.

The issue, as far as I can see, is that Calc is being inconsistent when the user is using the simple UI options to format the pencentage cells, for _certain locales_.

(In reply to Colin from comment #6)
> If loCALC had the ability to right format with indent in the same manner as
> EXCEL or a decimal tab alignment format then it would never even have been
> noticed.
I have little experience in MS Excel, but from your description, I don't see anything not doable in Calc with hand-crafted format codes.  Maybe Excel provide better pre-defined formats, especially for non-English locales?  That's definitely an area LibreOffice can improve in, and enchancement requests are welcome.

> As a member of the development squad, are you aware of any intention to
> facilitate right aligned indents or decimal alignment of CALC cells?
> Would submitting enhancement requests be a more worthy endeavour?
I am merely an (somewhat) advanced user doing QA work on Bugzilla, and not a developer.  Nor do I have any insights about the intentions of developers working on this area, sorry.  However, like I said above, well-described enhancement request, especially with comparison to what MS Excel provides, should always be welcome.

Created attachment 167077 [details]
How to manually change the format code

Here is a screenshot using your example file to show how to achieve the aligned appeareance you want for two leading-zeros.

Note that for English and other locales that don't use a space between the digits and percent sign, no manual editing is needed.  The UI generates the correct format code by default.

(In reply to Ming Hua from comment #8)
> Created attachment 167077 [details]
> How to manually change the format code
> 
> Here is a screenshot using your example file to show how to achieve the
> aligned appeareance you want for two leading-zeros.
> 
> Note that for English and other locales that don't use a space between the
> digits and percent sign, no manual editing is needed.  The UI generates the
> correct format code by default.

Firstly, many thanks for your input.

During the course of our discussion I had figured out how to edit the format in the way you had demonstrated. As you mentioned, Date formats are also readily editable and I have achieved passable competency in that area which helped.

I think, to summarise, the only idiosyncracy still remaining is that if a default percentage cell with only one integer digit and a space is amended to produce 2 leading zeros and then re-amended back to the original 1 leading zero then the format without a space which is introduced by setting leading zeros to 2 doesn't revert to a format with a space when it is re-edited to 1 leading Zero.

I still perceive it as trivial and leave it in your hands to decide whether the report should be classified as not worth fixing, not a bug, or processed as a very low priority minor cosmetic change.

Going outside the box, perhaps, if the UK distribution didn't have different space defaults for single and double integer digits on percentages then one very esoteric sheet wouldn't produce a noticeable anomaly when "flipping" the format.

How are the formats originally placed in the distribution? I can identify that they "grow" as a user modifies them but have no idea where/how the underlying defaults originate.

Hi Colin, in the issue of the losing space in leading zeros: Try it in current release 7.0.3. I can confirm that space is lost in your old version. But in current it is ok.
Please, confirm that and send us information, if it is so.
Thank you wery much.

(In reply to srdosm from comment #10)
> Hi Colin, in the issue of the losing space in leading zeros: Try it in
> current release 7.0.3. I can confirm that space is lost in your old version.
> But in current it is ok.
What do you mean by "the issue of the losing space in leading zeros"?

I just re-checked with 7.1.0 alpha1+, the two values 01.75% (in cell E12) and 1.75% (E13) are still missing a space between digits and percent sign.

I don't think this problem has anything to do with LO versions, but some specific combination of locale/language settings when user is changing the format of the numbers.

(In reply to Ming Hua from comment #11)
> (In reply to srdosm from comment #10)
> > Hi Colin, in the issue of the losing space in leading zeros: Try it in
> > current release 7.0.3. I can confirm that space is lost in your old version.
> > But in current it is ok.
> What do you mean by "the issue of the losing space in leading zeros"?
> 
> I just re-checked with 7.1.0 alpha1+, the two values 01.75% (in cell E12)
> and 1.75% (E13) are still missing a space between digits and percent sign.
> 
> I don't think this problem has anything to do with LO versions, but some
> specific combination of locale/language settings when user is changing the
> format of the numbers.

Hi Hua,
I never noticed the response was from "not you" and proceeded to load 7.0.3 on top of my working version. Completely obliterated it just as your response popped up on my mail preview.
I was under the impression it always asked me if I wanted to overwrite or parallel instal. Should have picked "Custom". :(

(In reply to Colin from comment #12)
> 
> I was under the impression it always asked me if I wanted to overwrite or
> parallel instal. Should have picked "Custom". :(
Sorry to hear about that.

It wouldn't hurt for you to test 7.0.3 though.  If you don't like it, it's generally safe to un-install 7.0.3 and then re-install 6.4.6/7 later.  If you want to be extra safe, make a backup of your user profile (in %APPDATA%\Roaming\LibreOffice\4\).

Parallel installation on Windows is not trivial (not achievable from options in Installer), but not too hard either.  See https://wiki.documentfoundation.org/Installing_in_parallel/Windows for instructions.

(In reply to Ming Hua from comment #13)
> (In reply to Colin from comment #12)
> > 
> 
> It wouldn't hurt for you to test 7.0.3 though.  If you don't like it, it's
> generally safe to un-install 7.0.3 and then re-install 6.4.6/7 later.  If
> you want to be extra safe, make a backup of your user profile (in
> %APPDATA%\Roaming\LibreOffice\4\).

Time to abandon the "kiddy wheels" - I just needed the little push
See you on the other side

(In reply to Ming Hua from comment #11)

> What do you mean by "the issue of the losing space in leading zeros"?

Colin send in comment 9 that, there is still the problem when he set leading zeros. If he set it, then there is number and sign of percent with no space betweeen. In his comment No. 9 is:

"... percentage cell with only one integer digit and a space is amended to produce 2 leading zeros and then re-amended back to the original 1 leading zero then the format without a space ..."

But it happens only in the version 6.4.6.2. In current version don't.



> 
> I just re-checked with 7.1.0 alpha1+, the two values 01.75% (in cell E12)
> and 1.75% (E13) are still missing a space between digits and percent sign.
> 
> I don't think this problem has anything to do with LO versions, but some
> specific combination of locale/language settings when user is changing the
> format of the numbers.


You must first delete the wrong formatting without the space (ctrl+1 > numbers > category-percent). After you delete it then change leading zeros. There is stil space, in v7.0.3. But if you do same in version 6.4.6.2 then there start to be the nospace problem. This is how I understood what colin still has wrong.

Cells, where is existing a percent number, there will be no space between number and '%', because this is so in the formatting. It is not so, you open the document in new version and then you will see space between number and '%' in the cells E12, E13.

When Colin can't check it because he has only old version  please check it on your computer, Ming Hua.

> 
> You must first delete the wrong formatting without the space (ctrl+1 >
> numbers > category-percent). After you delete it then change leading zeros.
> There is stil space, in v7.0.3. But if you do same in version 6.4.6.2 then
> there start to be the nospace problem. This is how I understood what colin
> still has wrong.
> 

I'm becoming more accomplished under your tutelage. Now Using 7.0.3.1 and discovering that the first two format samples in the percentage parameters appear to be "fixed" with the distribution. That is to say - mouseover with these two entries does not produce the little delete parameter checkbox, whereas it permits me to delete any of the remaining entries. It also produces the label "User-defined" for the interlopers

The issue now seems to be - where did the additional removable entries originate? I don't think I could have created them by "trial and error" (accident) as I originally had no idea how to attempt to modify them and they appear to have (created?) counterparts in your locale. My best guess is that they somehow crept into the distribution and remained. Is there something in my user profile that could point me at the source of these entries?

As the effect is removable and repairable with user preferences I would be inclined to withdraw the bug report in favour of enhancement requests to the cell format permitting decimal alignment - which could negate any adverse effects of extra zeros and spaces - regardless of the numerical format, together with the right indent of any cell contents as featured in eXcel.

Will you change the status or should I? I suggest it is resolved.

Are you already aware of any "expert tips" to user format a right indent or space in a cell - besides of course simply packing a space into the end of the string  ;))

I'm gonna learn another new skill - how to file an enhancement request.
Any "good practice" tips?

(In reply to Ming Hua from comment #13)
> (In reply to Colin from comment #12)
> > 
> > I was under the impression it always asked me if I wanted to overwrite or
> > parallel instal. Should have picked "Custom". :(
> Sorry to hear about that.
> 
> It wouldn't hurt for you to test 7.0.3 though.  If you don't like it, it's
> generally safe to un-install 7.0.3 and then re-install 6.4.6/7 later.  If
> you want to be extra safe, make a backup of your user profile (in
> %APPDATA%\Roaming\LibreOffice\4\).
> 
> Parallel installation on Windows is not trivial (not achievable from options
> in Installer), but not too hard either.  See
> https://wiki.documentfoundation.org/Installing_in_parallel/Windows for
> instructions.

I ran with it and filed an enhancement request for decimal tabs - which was the primary influence of my initial report.

Mike Kaganski picked that up and sent me the totally specific method which resolves everything.
See 138306
I now have a new bug - the About LibreOffice pane doesn't permit cut & Paste on the latest release

You inspired me to investigate the formatting further and Mike was able to nail it for me.
Thanks.
Should I mark the issue as resolved or is that down to you?

Commited by Colin (bug creator)that it works good in version 7.0.3.

For me it works on dev master:
Version: 7.1.0.0.alpha1+ (x64)
Build ID: 00e5c63c35307faacf76a5e2ca7953c4208244ed
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: cs-CZ (cs_CZ); UI: en-US
Calc: CL