Description: File rendering has changed in LibO 5.3 compared to older versions Steps to Reproduce: 1.Open attachment 57526 [details] (bug 46441) 2.Compare rendering between 5.3.0.0 and a older version for example 5.2.2.1 Actual Results: Rendering is different Expected Results: File should always render the same Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.4.0.0.alpha0+ Build ID: 84f2ff67a7e404febf710b1dc7f66d06745c503f CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-09_23:20:01 Locale: nl-NL (nl_NL); Calc: CL and in Versie: 5.3.0.0.beta1 (x64) Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL but not in Versie: 5.2.2.1 Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 129539 [details] Rendering LO5221
Created attachment 129540 [details] Rendering LO5400
Hi Telesco, The only difference I see is the text colour in the first page, is it what you mean? Regarding the word spacing it has slightly changed with harfbuzz but it's acceptable.
Pag 1 one at the bottom right: "the JOC on 0861 571" is missing in LibO5300, but not in 5.2.2.1. Same at the bottom right on page 2 '082 911' isn't 'visible' It could be Harfbuzz, but shouldn't happen in this way
Someone needs to test this with 5.3 with/without the new layout engine to see if it is related to it or not. But anyway some change is expected, in both layout (new engine) and line spacing.
Hi all, In attachment 57526 [details], there's no rendering issue. Text frames have a reduced area which do not allow the same layout than before. Spacings with content are the real cause of that. See Bug 104612. Jacques
It isn't Harfbuzz. Also found in Version: 5.3.0.0.alpha1+ Build ID: 43b5ca69aa545cf93eded55258d92d651917815f CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: old; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-18_05:27:05 Locale: nl-NL (nl_NL); Calc: CL
*** Bug 104612 has been marked as a duplicate of this bug. ***
No repro with: Versie: 5.3.0.0.alpha1 Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Locale: nl-NL (nl_NL); Calc: CL Pure speculation, but could this be the cause: https://cgit.freedesktop.org/libreoffice/core/commit/?id=098f7a4ac2b6f309a45d29f1b68bea18418b9ee7
Without testing myself, "rendering of document" is not a proper bug report nor a title. Bugzilla is "issue based". I'm writing this because I see Telesto opening a large number of bugs, which are not quite proper and precise. It's highly unlikely that any bugs of type "multiple problems/bad rendering", will ever be fixed. Each issue (section break, paragraph break, text box, picture...) should be reported separately, only after a search for already reported bugs, with clear issue in the title. FILEOPEN problems are different from FILESAVE, and DOC is different filter from DOCX. Only if bugs don't exist, they should be reported separately, even if they happen with the same file. Until bugs are triaged and confirmed, they shouldn't be marked with bibisectRequest, regression. I removed this from a couple of invalid and duplicate Telesto's bugs. But still in Bug 104612 which is a duplicate of Bug 104613. I kindly ask you to refrain from opening bugs without proper testing.
Hello Telesto, I've bisected the "the JOC on 0861 571" problem and it was introduced by author Justin Luth <justin_luth@sil.org> 2016-11-02 12:15:55 (GMT) committer Justin Luth <justin_luth@sil.org> 2016-11-03 19:02:41 (GMT) commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 (patch) tree 5fec72a40be7dbf15f208498494213cd6f59c114 parent 2a818a0aafac218ca09bb079d7f2cf0879385e4a (diff) there is a function for that: CalcLineSpace(xx, bEvenIfNoLine) Adding Cc: to Justin Luth Could you please update the summary to be more accurate? 'Rendering has changed in LibO5.3 compared to previous versions' doesn't say much about the problem.
This will be a bit complicated. First, thanks for reporting this problem. There was a logic error in replacing the function. Proposed fix: https://gerrit.libreoffice.org/#/c/32112/ However, the following day, m_bBorderDist is marked as always being true so this patch will not "fix" Newsletter_February2012.odt. ODF specifies that if the border-distance is defined, that it should be honoured, even without a border being present (see bug 41542). So the fact that LO hasn't done that is really a bug. This should only affect older documents, since from at least LO3.6, removing borders zero's out the padding. (So the work around to fix the document is to define borders, apply, and then remove borders.) I'm trying to see if there is a way to identify an older document and set m_bBorderDist to false in that compatibility case.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1427817a944f3cf1020b2f06a2ca934847b56ba8 tdf#104613 fix logic error in code replacement: CalcLineSpace It will be available in 5.4.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d253963f460e5600eb886480306b01a6fbc27ee6&h=libreoffice-5-2 tdf#104613 revert there is a function for that: CalcLineSpace It will be available in 5.2.5. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7382c06de7a2c78055279e1a1e7c377f490cccd1&h=libreoffice-5-3 tdf#104613 fix logic error in code replacement: CalcLineSpace It will be available in 5.3.0.1. 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.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
(In reply to Xisco Faulí from comment #16) > Is this bug fixed? > If so, could you please close it as RESOLVED FIXED? Marking as NOTABUG as discussed in comment 12