Download it now!
Bug 49856 - FILESAVE FILEOPEN EDITING Shift+Tab indented bullet indents further
Summary: FILESAVE FILEOPEN EDITING Shift+Tab indented bullet indents further
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA target:7.1.0
Depends on:
Blocks: Impress-Bullet-Number
  Show dependency treegraph
Reported: 2012-05-12 17:46 UTC by Dave Gilbert
Modified: 2020-09-14 08:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Dave Gilbert 2012-05-12 17:46:19 UTC
Problem description: 
  When trying to edit a .ppt presentation (even one which was produced by libre) shift-tab on a second level bulleted list indents and switches to an odd bullet.

  This corresponds to Ubuntu bug:
  and OpenOffice bug :

Steps to reproduce:
1) Open a shell, type libreoffice
2) You see a libreoffice window asking you what type of document you want, click 'presentation'
3) You now see an empty document with 'Click to add title' and a centred 'Click to add text', on the right there isa series of sections, Master Pages, Layouts, table Design. If 'layouts' isn't already open, click on the >Layouts to open it,
4) Click on the left most layout on the 2nd row - if you hover over it it says 'Title, Content'. When you click the empty document changes so that the 'Click to add text' is now at the top left with a round bullet.
5) Click on 'Click to add title', type 'This is a title'
6) Now click on the 'Click to add text' and  and type 'Level 1' hit return
7) Now hit tab and type Level 2 hit return (as you hit tab the bullet changes to a -)
8) type More level 2 and hit return and then Yet more level 2
9) Now go to File->Save as, select a Filter: of Microsoft Powerpoint 97/2000/XP/2003 (.ppt), type a filename (say broken2.ppt) and hit save
10) Convert the 'use Microsoft Powerpoint 97/2000/xp/2003 format' prompt
11) Exit libreoffice (File->Exit, click Discard when it prompts)
12) Now reopen libreoffice (e.g. at the terminal)
13) Use File->Open to open broken2.ppt
14) Click on the L of the 1st line that says Level 2 and then double click, the 'Level 2' is now inverted to show it's highlighted.
15) Hit shift-tab

step 15 now shows the bug - 

Current behavior:
the text incorrectly moves to the right and a bullet >> is shown. 

Expected behavior:
   it should be moving to the left and the bullet should match the 1st level bullet. Note this happens if you don't go through a .ppt format at any stage.

Platform (if different from the browser): 
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19
Comment 1 A (Andy) 2013-04-27 09:15:58 UTC
I am not sure if this is a misunderstanding.  For me it seemed to behave as normal (with LO [Win7 Home, 64bit]).  If I press the tabulator key it should move to the right, to the next level with a bullet.  Why should it therefore move to the left?  Is this maybe a misunderstanding from side?
Comment 2 Dave Gilbert 2013-04-27 15:57:47 UTC
Note step 15 is asking for 'shift tab' - not plain tab
  Plain tab goes to the right,
  Shift-tab should go to the left

Indeed shift-tab works fine in most cases, but this case it doesn't work and goes the wrong way.
Comment 3 A (Andy) 2013-04-27 16:38:24 UTC
@Dave: Thank you very much for your hint.

I never used this shortcut key and was not aware of it.  But I tested it in other presentations and I can confirm if you use Shift Key + Tabulator Key then it moves left, but in this specific case here it moves right.

reproducible with LO (Win7 Home, 64bit)
Comment 4 Itamar Carvalho 2013-04-29 13:39:41 UTC
I just tested it in LibreOffice Version (Version ID: 2ef5aff) in Windows, and I can confirm this version and platform is also affected by this bug. My version is in Portuguese (Brazil) language.

I know this is not the latest version, there is already the 3.6.6 version in 3.6 branch and that 4.0.2 is already available. I'm downloading the 4.0.2 version and I will test again, but AFAIK this bug was not addressed by this release.
Comment 5 Itamar Carvalho 2013-04-29 13:52:03 UTC
Just installed version 4.0.2 for Windows and confirmed that the bug is still there.

Version (Version ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)
Comment 6 QA Administrators 2015-03-04 02:18:44 UTC Comment hidden (obsolete)
Comment 7 Dave Gilbert 2015-03-07 20:10:08 UTC
Still present on:

(Tested on fedora 21)
Comment 8 tommy27 2016-04-16 07:26:08 UTC Comment hidden (obsolete)
Comment 9 Dave Gilbert 2016-04-16 11:53:05 UTC
Still present in on Ubuntu Xenial (build ID 1:5.1.2-0ubuntu 1)

(This isn't a regression - it goes back at least as far as 3.0.1 if you follow into the OOo bug)
Comment 10 QA Administrators 2017-05-22 13:22:02 UTC Comment hidden (obsolete)
Comment 11 Dave Gilbert 2017-05-28 00:29:02 UTC
still present on (Fedora 26)
Comment 12 Regina Henschel 2017-10-02 14:23:30 UTC
That is a problem with the old ppt format. For pptx the behavior is correct. Not sure whether developers should repair import/export filter for legacy file formats.
Comment 13 QA Administrators 2018-10-03 02:53:47 UTC Comment hidden (obsolete)
Comment 14 Dave Gilbert 2018-11-08 03:20:04 UTC
still present in:
Build ID:

(Note this was originally reported in OpenOffice in 2009 - it would be great to get it fixed by it's 10th birthday)
Comment 15 QA Administrators 2019-11-09 03:52:53 UTC Comment hidden (obsolete)
Comment 16 Dave Gilbert 2019-11-11 00:45:13 UTC
Still present in, build on Fedora 31
Comment 17 Dave Gilbert 2019-11-11 00:47:42 UTC
As requested; setting to 'inherited from OOo' based on which reported it on 3.0.1
Comment 18 Dave Gilbert 2020-09-03 20:56:07 UTC
I've been chasing this backwards through the filters and I can make the bug go away by commenting out:


                if ( eNumRuleType == SvxNumRuleType::PRESENTATION_NUMBERING )
                    aRule.SetLevel( 0, aNumberFormat );

but it's confusing.

What I'm seeing is that in the m_pDefaultSheet the mpNuMBuulletItem[Page] ends up having:

      <aFmts i="0" ptr="0x3709290">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="bb" 
      <aFmts i="1" ptr="0x3709580">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="f02d" 
      <aFmts i="2" ptr="0x3709620">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="2022" 
      <aFmts i="3" ptr="0x37096c0">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="2013" 
      <aFmts i="4" ptr="0x3709760">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="bb"
      <aFmts i="5" ptr="0x3709800">
        <SvxNumberFormat sPrefix="" sSuffix="" nStart="1" cBullet="bb" 
      (Same up to 9)

so that rule overwrites the 0th number format with the last one loaded; but there's no comment to say why.

Note this isn't apparently happening from a file generated from ppt - but I'm not sure why.
Comment 19 Dave Gilbert 2020-09-06 15:35:16 UTC
I'm now pretty convinced that those two lines are outdated by commit 8a64144fddde61dd050da4cb93b4a7242a495bb2 from 2008 from bz  which changed how outlining worked, so that slot 0 now meant something different.
Comment 20 Dave Gilbert 2020-09-06 16:12:40 UTC
(And the SetLevel(0 two lines have been there all the way back to 638c)
Comment 21 Commit Notification 2020-09-14 08:10:18 UTC
Dr. David Alan Gilbert committed a patch related to this issue.
It has been pushed to "master":

tdf#49856 Fix level 0 bullet/style on ppt import

It will be available in 7.1.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 22 Commit Notification 2020-09-14 08:10:28 UTC
Dr. David Alan Gilbert committed a patch related to this issue.
It has been pushed to "master":

tdf#49856 Add a test

It will be available in 7.1.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.