Bug 117923 - FILEOPEN Numbering in a specific DOC is huge
Summary: FILEOPEN Numbering in a specific DOC is huge
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.7.2 release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.2.0
Keywords: bibisected, filter:doc, regression
Depends on:
Blocks: DOC-Lists-Direct-Formatting
  Show dependency treegraph
 
Reported: 2018-05-31 01:52 UTC by Aron Budea
Modified: 2018-07-23 04:32 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOC (29.00 KB, application/msword)
2018-05-31 01:52 UTC, Aron Budea
Details
PDF exported in Word (81.16 KB, application/pdf)
2018-05-31 01:52 UTC, Aron Budea
Details
Sample from bug 108630 saved as DOC (33.50 KB, application/msword)
2018-07-02 16:25 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-05-31 01:52:06 UTC
Created attachment 142429 [details]
Sample DOC

Open the attached DOC, created in Word.

The numbering before the second entry is of very large size, while in Word it isn't.

Observed using LO 6.1 alpha1 & 4.0.0.3 / Windows 7.
Size is fine in 3.5.0.3.
=> regression
Comment 1 Aron Budea 2018-05-31 01:52:37 UTC
Created attachment 142430 [details]
PDF exported in Word
Comment 2 Aron Budea 2018-05-31 04:41:04 UTC
Bibisected to the following range:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=934e051b16349a1ab6d2bdd9f03e60aaafcb2ec8..75df7739309ccc5342084e668d9d869620cb3233

I wonder if this commit could be the culprit (wild guess):
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9eb05aa6883ea41fb1d1dad2f7f1870e8e63ce32
author		Miklos Vajna <vmiklos@suse.cz>	2012-08-08 18:07:03 +0200
committer	Miklos Vajna <vmiklos@suse.cz>	2012-08-08 18:12:06 +0200

"n#774681 SwFltControlStack::NewAttr don't extend font name / size attributes"

It's also possible that the behavior was correct by accident.
Comment 3 Xisco Faulí 2018-05-31 08:41:46 UTC
Reproduced in

Version: 6.1.0.0.beta1+
Build ID: 2a0d8106a558845357d39648656e08ec6f091cf8
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Comment 4 Jacques Guilleron 2018-05-31 08:53:43 UTC
Hi Aron,

I reproduce with
LO 6.1.0.0.alpha1+ Build ID: 23c5125148a8110d88385b29570bf0b7d4400458
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-05-12_00:15:25
Locale: fr-FR (fr_FR); Calc: CL
and
LO 3.6.7.2 (Build ID: e183d5b)
but not with
LO 3.5.3.2 Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80
Comment 5 Jacques Guilleron 2018-06-04 12:47:39 UTC
Hi all,

I observed that Text Body Paragraph Style and depending styles are defined as: Arial + 48pt...
Comment 6 Aron Budea 2018-06-04 15:56:26 UTC
Thanks for the observation, Jacques!

I checked what happens with a DOCX file, which opens fine, and in that case the feature was added in the following commit. It's probably not relevant, as previously this part of the specs simply wasn't supported, but I guess knowing about it can't hurt.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=df07d6cb9f62c0a2c4b29bd850d4efb4fcd4790b
author		Luboš Luňák <l.lunak@collabora.com>	2014-05-29 14:31:20 +0200
committer	Luboš Luňák <l.lunak@collabora.com>	2014-05-29 14:34:50 +0200

handle direct formatting for numbering in .docx (bnc#875717)
Comment 7 Mike Kaganski 2018-07-02 08:09:29 UTC
Reverting commit 9eb05aa6883ea41fb1d1dad2f7f1870e8e63ce32 does not fix the issue.

The other suspect is https://cgit.freedesktop.org/libreoffice/core/commit/?id=e70df84352d3670508a4666c97df44f82c1ce934.
Comment 8 Mike Kaganski 2018-07-02 13:04:29 UTC
https://gerrit.libreoffice.org/56812
Comment 9 Mike Kaganski 2018-07-02 13:05:03 UTC
Aron: thank you especially for the comment 6!
Comment 10 Xisco Faulí 2018-07-02 14:15:26 UTC
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=df07d6cb9f62c0a2c4b29bd850d4efb4fcd4790b
> author		Luboš Luňák <l.lunak@collabora.com>	2014-05-29 14:31:20 +0200
> committer	Luboš Luňák <l.lunak@collabora.com>	2014-05-29 14:34:50 +0200
> 
> handle direct formatting for numbering in .docx (bnc#875717)

Bug 108630 is also affected by that commit. Adding it to See also as well...
Comment 11 Commit Notification 2018-07-02 15:15:39 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=942f1056b51e53358d42ff8da8a1bbdce9ba5303

tdf#117923: handle direct formatting for numbering in .doc

It will be available in 6.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 12 Mike Kaganski 2018-07-02 15:15:57 UTC
(In reply to Xisco Faulí from comment #10)

So, now there should appear a similar regression for DOC. Sigh! undocumented features of Word...
Comment 13 Aron Budea 2018-07-02 16:25:01 UTC
Created attachment 143269 [details]
Sample from bug 108630 saved as DOC

(In reply to Mike Kaganski from comment #12)
> (In reply to Xisco Faulí from comment #10)
> 
> So, now there should appear a similar regression for DOC. Sigh! undocumented
> features of Word...
Attaching that sample saved as DOC. I haven't checked with the change, yet.
Comment 14 Mike Kaganski 2018-07-03 00:06:59 UTC
(In reply to Aron Budea from comment #13)

Thanks; as expected, now DOCX and DOC are treated ... consistently. :-)
Comment 15 Xisco Faulí 2018-07-03 00:11:53 UTC
Issue verified in

Version: 6.2.0.0.alpha0+
Build ID: 5fce97a58b8f764e35bf98128591c9a89537da05
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

@Mike, Thanks for fixing this!!
Comment 16 Xisco Faulí 2018-07-03 00:16:01 UTC
(In reply to Mike Kaganski from comment #14)
> (In reply to Aron Budea from comment #13)
> 
> Thanks; as expected, now DOCX and DOC are treated ... consistently. :-)

Indeed, the problem is happening with DOC now, but yeah, at least it's consistent  :D