Bug 113062 - Numbering > 9 appear reversed while editing a textbox in impress
Summary: Numbering > 9 appear reversed while editing a textbox in impress
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Impress-Bullet-Number RTL-Textbox
  Show dependency tree / graph
 
Reported: 2017-10-12 11:34 UTC by Lior Kaplan
Modified: 2019-05-15 09:33 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
testdoc for 113062 (13.05 KB, application/vnd.oasis.opendocument.presentation)
2017-10-12 11:36 UTC, Lior Kaplan 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Lior Kaplan 2017-10-12 11:34:25 UTC 
Description:
When you edit a textbox in LTR direction the numbering will show 01, 11, 21 and 31 instead of 10, 11, 12 and 13. Leaving the textbox edit mode with show them correctly.

While this doesn't affect the presentation itself, it makes Impress looks "half baked" while creating the presentation.

Steps to Reproduce:
1. In a text box, turn on numbering.
2. Enter more than 9 items on the list
3. Change list directionality to RTL

Actual Results:  
numbers bigger than 9 appear backwords (01, 11, 21, 31)

Expected Results:
numbers bigger than 9 appear as 10, 11, 12 and 13


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36
Comment 1 Lior Kaplan 2017-10-12 11:36:46 UTC 
Created attachment 136920 [details]
testdoc for 113062

As demonstrated during LibOCon 2017
Comment 2 Xisco Faulí 2017-10-13 22:30:02 UTC 
Reproduced in

but not in

Version: 6.0.0.0.alpha0+
Build ID: 3672cdd35985201ea87463cf032fedd02c052f4d
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

A couple of things:
1. A bug shouldn't be autoconfirmed by the reporter and someone else should triage it.
2. In case you would confirm one ( as this one because it was demonstrated during the LiboConf), please check with a master build before reporting it, otherwise it might happen it's already fixed, like in this issue.
Anyway, thanks for the great work on RTL ;-)
Closing as RESOLVED WORKSFORME
Comment 3 Xisco Faulí 2017-10-13 22:31:07 UTC 
*Reproduced in

Version: 5.4.1.2
Build ID: 1:5.4.1~rc2-0ubuntu0.17.04.1~lo0.1
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: es-ES (ca_ES.UTF-8); Calc: group
Comment 4 Lior Kaplan 2017-10-14 18:30:15 UTC 
(In reply to Xisco Faulí from comment #2)
> Reproduced in
> 
> but not in
> 
> Version: 6.0.0.0.alpha0+
> Build ID: 3672cdd35985201ea87463cf032fedd02c052f4d
> CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
> Locale: ca-ES (ca_ES.UTF-8); Calc: group
> 
> A couple of things:
> 1. A bug shouldn't be autoconfirmed by the reporter and someone else should
> triage it.

Thanks for the comment.

> 2. In case you would confirm one ( as this one because it was demonstrated
> during the LiboConf), please check with a master build before reporting it,
> otherwise it might happen it's already fixed, like in this issue.

Done. Already created a local build for testing.

> Anyway, thanks for the great work on RTL ;-)

(:
Comment 5 Lior Kaplan 2017-10-14 18:31:11 UTC 
BTW, I'm trying to figure out what commit fixed the bug, so it could be backported to 5.4 branch. Help appreciated.
Comment 6 Xisco Faulí 2017-10-15 21:00:17 UTC 
(In reply to Lior Kaplan from comment #5)
> BTW, I'm trying to figure out what commit fixed the bug, so it could be
> backported to 5.4 branch. Help appreciated.

Adding backportRequest for that ;-)
Comment 7 Lior Kaplan 2018-09-27 09:41:46 UTC 
Verified in Version: 6.1.1.2