Bug Hunting Session
Bug 99474 - FILESAVE as doc: bullet point character format wrongly taken from following paragraph
Summary: FILESAVE as doc: bullet point character format wrongly taken from following p...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: All All
: medium major
Assignee: Luke Deller
URL:
Whiteboard: target:5.2.0 target:5.1.4
Keywords: regression
Depends on:
Blocks:
 
Reported: 2016-04-24 05:25 UTC by Luke Deller
Modified: 2018-07-02 15:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test case document (9.16 KB, application/vnd.oasis.opendocument.text)
2016-04-24 05:25 UTC, Luke Deller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Deller 2016-04-24 05:25:31 UTC
Created attachment 124593 [details]
Test case document

When saving to DOC format a file which contains a bullet point list or a numbered list, any direct character formatting applied to the text immediately following the list will be applied to the bullet point or list number preceding it.

Steps to reproduce:
1) Open the attached testcase.odt in LibreOffice.  Note that the bullet points are black.
2) Save as .doc format
3) File -> Close
4) Re-open .doc file.  See that the bullet points are now red.
5) (optional) Open the .doc file in Microsoft Word.  See that the last bullet point is red.

Expected behaviour:
at steps 4 and 5, the bullet points should still be black.

I have reproduced this with LibreOffice 5.2.0.0alpha and with 5.0.3.2.
Comment 1 raal 2016-04-24 06:27:19 UTC
I can confirm with Version: 5.2.0.0.alpha0+
Build ID: 170a473597534cf59887b1d817538322e7039862
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-04-19_00:41:06
and Version: 4.5.0.0.alpha0+

Works in 3.5, regression
Comment 2 Julien Nabet 2016-04-24 09:20:05 UTC
Luke: I noticed you assigned yourself, do you want to work on it to fix this? If yes, please change the status to ASSIGNED. If not, unassign yourself.
Comment 3 Julien Nabet 2016-04-24 09:27:40 UTC
On pc Debian x86-64 with master sources updated today, the 2 bullets are red when exporting in doc.
During export, I just had this on console:
warn:sfx.doc:16451:1:sfx2/source/doc/docfile.cxx:692: Physical name not convertible!

I noticed, that bullets were ok (black) with docx export.

Miklos: thought you might be interested in this one.
Comment 4 Luke Deller 2016-04-24 10:39:02 UTC
Yes I would enjoy having a look at this one; changing it to "assigned".

I think what is happening here is that when emitting direct character formatting upon a run of text, LibreOffice inadvertently includes the end-of-paragraph marker within the run of text.  It is this direct character formatting upon the end-of-paragraph marker which overrides the character style of the bullet point for that paragraph.

- in the DOC format, direct character formatting upon a run of text is stored in a data structure where each run implicitly begins where the previous run ended

(Reference:
https://msdn.microsoft.com/en-us/library/dd909669.aspx
https://msdn.microsoft.com/en-us/library/dd910989.aspx
)

- in the DOC format, the end-of-paragraph marker is actually a character within the document, consuming a character position.  This means that direct character formatting over a run of text can possibly include the end-of-paragraph marker.

- LibreOffice emits direct character formatting on runs of text corresponding to ODT text nodes

- The run of text corresponding to the first ODT text node in a paragraph will implicitly start from where the previous text node ended, which means it will span across the end of paragraph marker
Comment 5 Luke Deller 2016-04-26 16:19:46 UTC
BTW I suspect this is not a regression, though I have only tested as far back as 4.0.1.

Beware that in older versions of LibreOffice (such as 4.0.1 but not 4.0.3), the red bullet point in the doc file is not correctly imported, so at step #4 of my "steps to reproduce" it deceptively looks fine.  Using a newer version of LibreOffice at step #4 shows that the problem does indeed exist in the doc file generated by the old version of LibreOffice.
Comment 6 Commit Notification 2016-04-27 15:20:02 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=817c3b17fa57a7c4c4f80569bc00a21001fb6807

tdf#99474 close direct char fmt at end of para

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2016-05-03 15:59:32 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e5e155ddf467cdce2312fa16d0392900afc7355&h=libreoffice-5-1

tdf#99474 close direct char fmt at end of para

It will be available in 5.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

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