Description: Page count is terribly off on file open with a large table; ultimately it will work (but seems slower) Steps to Reproduce: 1. Open attachment 107266 [details] (bug 84635) 2. Wait until the document appears 3. look at the page count - 43 4. Wait rather long time -> Drops to 26 (expected) Actual Results: Opens with 43 pages Expected Results: 26 pages straight forward, not first 43 and trimming down to 26 Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in 6.2 also in (opening fast, but number of spurious pages on file open (not being trimmed down). Exactly: 43 pages 6.1 fine with 6.0
My bibisect attempt lands here. author Jan-Marek Glogowski <glogow@fbihome.de> 2018-07-09 09:06:55 +0200 committer Khaled Hosny <khaledhosny@eglug.org> 2018-07-09 22:11:35 +0200 commit fad862e290d727fc9fefe206f6e4b807482c4175 (patch) tree 5195c1277fce198e5b69d552e9209665d8007faf parent 9d754a59154c40235c240bb0e7f47a2006fa85bd (diff) tdf#118555 fix HFONT fallback handing / lifecycle Instead of storing the never changing DC in the WinFontInstance store the HFONT, which is Windows logical font instance. Then set the correct HFONT instance from the layout when rendering its text. This also changes the HFONT ownership and lifecycle. The HFONT is moved from the mhFonts to the WinFontInstance, if available, so it has a proper referenced lifecycle. The mhFonts is still needed, as embedded font just supply an HFONT and no WinFontInstance. https://cgit.freedesktop.org/libreoffice/core/commit/?id=fad862e290d727fc9fefe206f6e4b807482c4175 However coming without warranties, as there is also sorts of quirky behavior in the 6.2 bibisect repro. Note 2: The 43 to 26 is also in 6.1, but is simply fast disappearing. So maybe i'm looking in the wrong bibisect repro?
@Buovjaga, 4 eyes so more than 2.. Any idea how to approach this?
(In reply to Telesto from comment #0) > Description: > Page count is terribly off on file open with a large table; ultimately it > will work (but seems slower) > > Steps to Reproduce: > 1. Open attachment 107266 [details] (bug 84635) > 2. Wait until the document appears > 3. look at the page count - 43 > 4. Wait rather long time -> Drops to 26 (expected) Goes from 41 to 26, took maybe 10 secs. Version: 7.1.0.0.alpha0+ (x64) Build ID: a486fd929d4b3e915f928ef495b6cb2b96d74a3a CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded The bug is also still present in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Goes from 43 to 26, roughly about 2 to 3 seconds for me for both versions.