[Libreoffice-bugs] [Bug 134743] Table of Contents - "Tab position relative to paragraph style format" stops working

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Jul 29 02:18:56 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=134743

--- Comment #4 from Frank Zimmerman <fz1844 at gmail.com> ---
Thanks for looking at it. This evening I got out the Meld program, and
extracted the contents of both ODT's. There were a few differences, but nothing
that stood out to me.

So I started swapping over various elements. I tried the Styles.xml from the
working doc to the non-working doc. Zipped up, renamed to ODT, but it didn't
change. I tried it the other way around, didn't break the good one.

Next I tried the Contents.xml and went both ways with that. Again, same
results. Did not break the working doc, and did not fix the broken one.

Next I tried both Contents and Styles XML. Same results.

Finally I tried the Settings.xml and this made all the difference. If I take
the Settings.xml from the broken doc and put it in the good one, it breaks it.
If I take the Settings.xml from the good doc and put it in the broken one, it
fixes it.

There are some interesting differences between the two. Some of the differences
seem to come from the import of Word Docs, which I used to create the original
non-working ODT (whereas the working ODT was created by copy/paste of text from
the non-working ODT.

In the Properties for the non-working ODT, the Template (in the General tab)
shows as "Normal.dotm". In the working ODT, it shows my LibreOffice template
"PP Book Template".

More interesting, there were some "Custom Properties" defined in the
non-working ODT, which I guess were imported from the Microsoft Word files. I
deleted all these custom properties, but the TOC still does not format
correctly. And other than those Custom Properties, I can't see any other
differences in the Properties dialog itself.

Next I did a MELD on the two Settings.xml files (after running XML Tidy on them
first!). Here are the properties that are different, between the two docs. This
first set have different integer values. I'm not listing the values for these,
as I'm not sure they are relevant.

ViewAreaTop
ViewAreaLeft
ViewAreaWidth
ViewAreaHeight
ViewLeft
ViewTop
VisibleTop
VisibleRight
VisibleBottom

This next structure is only in the non-working doc:

ForbiddenCharacters
- Language: en
- Country: US
- Variant:
- BeginLine: 
- EndLine: 

These next properties are in both docs, but in the non-working one, they have
the following values (and in the working one, the opposite values):

FloattableNomargins: true
UnbreakableNumberings: true
AddVerticalFrameOffsets: true
BackgroundParaOverDrawings: true
DoNotJustifyLinesWithManualBreak: true
DoNotCaptureDrawObjsOnPage: true
EmbedSystemFonts: true
AddFrameOffsets: true
ConsiderTextWrapOnObjPos: true
TableRowKeep: true
TabsRelativeToIndent: false
IgnoreTabsAndBlanksForLineCalculation: true
InvertBorderSpacing: true
ClippedPictures: true
TabOverMargin: true
TreatSingleColumnBreakAsPageBreak: true
SurroundTextWrapSmall: true
ApplyParagraphMarkFormatToNumbering: true

There was also an "Rsid" property that had a different value between the two
docs, but this is just a long integer, so I don't think it will affect the
formatting of the TOC.

I'm pretty sure it is one of the boolean properties that is causing the
mess-up. I could now test each one to find out which it is (or it may be a
combination of more than one) but it would be nice if we could get someone
involved who has more knowledge about the Settings.XML file, who might be able
to hone in on just which of these is the culprit.

I believe that these properties got set from the import of Word DOC (or DOCX)
files, into the original (non-working) ODT. So it could potentially affect
other people's documents as well, and this import process needs to be looked
at, so a property is not carried over that breaks indenting in the Table of
Contents.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200729/208acb67/attachment.htm>


More information about the Libreoffice-bugs mailing list