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: 7.4.0.0.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 Calc: threaded 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: 7.3.0.3 (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 Calc: CL Paragraphs above and below table don't have "hidden" as charafter effects. Additional informations: 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? Thanks bdd0a608f23b1c4e54e3ec396e888cd40e2afa6f is the first bad commit commit bdd0a608f23b1c4e54e3ec396e888cd40e2afa6f Author: Matthew Francis <mjay.francis@gmail.com> Date: Sun Mar 15 03:02:50 2015 +0800 source-hash-705a8c226aee3e68db492083b7cf8b704335328b commit 705a8c226aee3e68db492083b7cf8b704335328b Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Tue Sep 23 20:35:50 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.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 around here. Change-Id: I5a72e462db2fff60f52b12c2125ea6ac363de695
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.