Created attachment 177951 [details]
Example doc file with hidden paragraphs
This is split from bug 102330
attachment 127583 [details] contains the same example in various formats, attached doc example is from this archive.
The doc file has a table with hidden text and two paragraphs before and after the table.
When opened in Writer the paragraph preceding the table (Start of Hidden Text) is not marked as hidden.
This does not happen with the DOCX or RTF examples in the above bundle.
Version: 188.8.131.52.alpha0+ (x64) / LibreOffice Community
Build ID: eb69767d7c1bb8e6e780fd9503f08c9d7f5ecb45
CPU threads: 13; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Also in 7.0, 6.0, 5.0, 4.4
Not yet in 4.3
Created attachment 177952 [details]
The example file in Word 2013 and Writer master
I confirm it with
Version: 184.108.40.206 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Paragraphs above and below table don't have "hidden" as charafter effects.
If you set "Hidden" as font effect of "Start of hidden text" tabel becomes visible and paragraph below text appears as hidden text.
Created attachment 178362 [details]
from bibisect 44
Printscreen from bibisect_44max linux repo. Bisected where first started this, not equal how it looks in 7.4.
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara; Could you possibly take a look at this one?
bdd0a608f23b1c4e54e3ec396e888cd40e2afa6f is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Sun Mar 15 03:02:50 2015 +0800
Author: Caolán McNamara <firstname.lastname@example.org>
AuthorDate: Tue Sep 23 20:35:50 2014 +0100
Commit: Caolán McNamara <email@example.com>
CommitDate: Wed Sep 24 10:04:48 2014 +0100
WW8PLCFMan::AdjustEnds deeply flawed concept wrt change tracking
The whole idea of clipping the char attributes to before the cr that word uses
as the end of para marker is flawed from especially the perspective of
redlining which is a char property in word.
If the redline encompasses the newline in order to state that it is deleted,
then if the prop is clipped to before that newline then the end-of-para doesn't
get marked as deleted
For now just remove the character attributes clipping from here to be as
conservative as possible.
Hopefully the ordering of processing start pap before start chp and end chp
before end pap and the other million improvements in the parser that came about
after AdjustEnds was created avoids whatever problems were trying to be worked
unfortunately bisecting to a 7 year old commit isn't massively useful vs a regular bug. Justin might have an insight if it makes sense to try and revert that old change or if that just brings up as much problems in another direction.
(In reply to Caolán McNamara from comment #5)
> Justin might have an insight if it makes sense to try and
> revert that old change or if that just brings up as much problems
My answer is bug 125905 comment 4. I don't expect anyone to dare to touch this.