# Outline indent malfunction with docx files

In the latest production release of LibreOffice 6.2.7.1 (x64) Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf, I believe that I may have come across more than one bug.

1. When I edit a .docx document that was generated and downloaded from Google Docs (Drive), and the document has a bullet outline, when I add a new item on the outline and then indent it, the bullet icon changes, but the indent does not.

1. I have noticed that when editing a .docx document that was generated and downloaded from Google Docs, when I hit the space bar in a table cell, the space does not show on the screen until after I type a non-space character. In other words, the cursor does not move to the next position.

Issue number 2 is annoying but manageable. Issue number 1 is a show stopper.

EDIT:

Upon further examination, I opened the docx file with notepad++ and I noticed that the first two characters were PK, which indicates a .zip file. So I unpacked it with 7-zip and got a whole bunch of other files and directories. In exploring these files, I found document.xml which contains the actual document text. I open it and scroll down to where the issue is and I find this:

"none"/></w:rPr></w:pPr><w:r><w:rPr></w:rPr><w:t>js
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="1"/><w:numId w:val="1"/></w:numPr><w:ind w:left="1440" w:hanging="360"/><w:rPr><w:u w:val="none"/></w:rPr></w:pPr><w:r><w:rPr></w:rPr><w:t>application
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="1"/><w:numId w:val="1"/></w:numPr><w:ind w:left="1440" w:hanging="360"/><w:rPr><w:u w:val="none"/></w:rPr></w:pPr><w:r><w:rPr></w:rPr><w:t>baseline
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="1"/><w:numId w:val="1"/></w:numPr><w:ind w:left="1440" w:hanging="360"/><w:rPr><w:u w:val="none"/></w:rPr></w:pPr><w:r><w:rPr></w:rPr><w:t>module
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="0"/><w:numId w:val="1"/></w:numPr><w:ind w:left="720" w:hanging="360"/><w:rPr></w:rPr></w:pPr><w:r><w:rPr></w:rPr><w:t>libs
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="0"/><w:numId w:val="1"/></w:numPr><w:ind w:left="720" w:hanging="360"/><w:rPr></w:rPr></w:pPr><w:r><w:rPr><w:u w:val="none"/></w:rPr><w:t>misc
</w:t></w:r></w:p><w:p><w:pPr><w:pStyle w:val="LOnormal"/><w:numPr><w:ilvl w:val="1"/><w:numId w:val="1"/></w:numPr><w:ind w:left="720" w:hanging="360 ...
edit retag close merge delete

How do you indent the list item? With a Tab character in front of it or by acting on the margin cursors in the ruler?

Issu #2: what do you see with View>Formatting Marks enabled?

( 2019-09-14 12:11:57 +0200 )edit

@ajlittoz Neither. I use increase indent on the toolbar. It's always worked in the past. As for the second issue, it shows a blue arrow after the bullet mark and then the paragraph marker.

( 2019-09-14 17:09:26 +0200 )edit

Lists are complex objects (a combination of a paragraph style and a "list" style) and should not be acted upon with tools other than dedicated ones. When cursor is in a list item, a special toolbar appears at the bottom of the window. Buttons to change item level are called "Demote one level" and "Promote one level". I don't trust the "Increase Indent" button in the upper main toolbar because it modifies other parameters in the style(s) and this could cause problems.

One part of them is the much poorer style features in M\$ Word and this explains the tortured XML you see. Writer has a more straightforward way of encoding list items, thanks to its style machinery. Also playing with toolbar buttons (direct formatting) is the surest way of heading into formatting difficulties later. Here you cumulate .docx encoding + direct formatting. Good luck to tidy things.

The ...(more)

( 2019-09-14 18:02:31 +0200 )edit

Everything is default style. Arial 12 pt. Besides, I also discovered that if you download it in odt format, the same thing happens, so I am thinking the problem is with how Google is translating the document from their own internal, proprietary format into these other external formats.

Besides, I also discovered a workaround: If you do CTRL-A then CTRL-C to select all and copy the entire document in Google Docs, and then CTRL-V to paste it into a blank odt file, the resulting file does not have the problems. The formatting will be a little bit off, but that is easily corrected.

Note to self: Do not use Google Docs anymore for documents that have the potential to be used in other programs.

( 2019-09-15 06:54:34 +0200 )edit

That might be related to tdf#64222 (which had just got some fixes, which will be available in the future 6.4 version). Cannot tell for sure, because of no file to test.

( 2019-09-17 11:15:39 +0200 )edit