Description: . Steps to Reproduce: open file http://bugs.documentfoundation.org/attachment.cgi?id=144865 from bug 119880 Actual Results: chart not rendered correctly Expected Results: render as in previous versions Reproducible: Always User Profile Reset: No Additional Info: regression
This seems to have begun at the below commit. Adding Cc: to XXXX ; Could you possibly take a look at this one? Thanks 4ceb12ed5c1df70be8d1ed104f3ddd252c58baa1 is the first bad commit commit 4ceb12ed5c1df70be8d1ed104f3ddd252c58baa1 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Nov 29 03:33:01 2018 -0800 source ec11c1aee04eacb00d94a6359f959b990ddb6923 author Miklos Vajna <vmiklos@collabora.com> 2018-11-19 09:03:40 +0100 committer Miklos Vajna <vmiklos@collabora.com> 2018-11-19 10:52:21 +0100 commit ec11c1aee04eacb00d94a6359f959b990ddb6923 (patch) tree 635b155d36c56f79565aa6e6f82dbe942e95e8b1 parent d0ecdcf4a563adfcff4aae511723488961ae259e (diff) external: update pdfium to 3613
On pc Debian x86-64 with master sources updated today, I don't reproduce this. I tried gtk3, gtk, gen and kde5 renderings. Did you notice some specific console logs?
(In reply to Julien Nabet from comment #2) > On pc Debian x86-64 with master sources updated today, I don't reproduce > this. > Confirm, it works on linux (tested current master 6.3)- windows only bug.
Could you plase check if PDF images are broken in general or if the problem is specific to this single PDF only? Thanks. (I don't have a Windows system at hand right now to check.)
(In reply to Miklos Vajna from comment #4) > Could you plase check if PDF images are broken in general or if the problem > is specific to this single PDF only? Thanks. > > (I don't have a Windows system at hand right now to check.) Hello Miklos, broken in general. In file explorer I copied PDF file and pasted to Writer. I see preview image in 6.1.4.2, but nothing in 6.3.0.0.alpha0+.
Created attachment 149732 [details] Second PDF sample. Sorry, I was not clear enough: I wonder if the problem is specific to this PDF in your bugdoc or no inserted PDF is visible at all. See the attached random sample -- is insertion of this second sample also broken on Windows? Thanks.
(In reply to Miklos Vajna from comment #6) > Created attachment 149732 [details] > Second PDF sample. > > Sorry, I was not clear enough: I wonder if the problem is specific to this > PDF in your bugdoc or no inserted PDF is visible at all. See the attached > random sample -- is insertion of this second sample also broken on Windows? > Thanks. This file is OK, but I have another one which doesn't work. I'll send it to you privately, because I cannot attach files here. It looks like PDFs created with PDFcreator doesn't works now.
OK. So if PDFs in general work, but not some specific one, then I guess this will be a pdfium upstream bug. https://bugs.chromium.org/p/pdfium/issues/list is where these can be reported. Should we close this one as resolved/notourbug?
(In reply to Miklos Vajna from comment #8) > OK. So if PDFs in general work, but not some specific one, then I guess this > will be a pdfium upstream bug. > https://bugs.chromium.org/p/pdfium/issues/list is where these can be > reported. Should we close this one as resolved/notourbug? I see PDFs in Chrome correctly (chrome version 72.0.3626.121, but I don't know which version pdfium it uses). Maybe we need update pdfium in LO?
Makes sense, I'll update pdfium to latest in 1-2 weeks and then let's see if an update solves the problems.
don't repro in Version: 6.3.0.0.alpha0+ Build ID: d81a11220d76eeecac80b27b25a4576b6e78210b CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
(In reply to Miklos Vajna from comment #10) > Makes sense, I'll update pdfium to latest in 1-2 weeks and then let's see if > an update solves the problems. Pdfium was updated today in https://cgit.freedesktop.org/libreoffice/core/commit/?id=8743247493ba90098e3e32cf30de0e8995569852. @Raal, could you please recheck ?
Created attachment 149970 [details] test file Still doesn't work with Version: 6.3.0.0.alpha0+ Build ID: 2f83055cdbd915d5036a7b4374b4ad10e6efc65f CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win Preview is correct in 6.1.4.2 and I can see PDF in Chrome
That's annoying. :-( Could you please try your luck with reporting this to pdfium upstream? See <https://pdfium.googlesource.com/pdfium/#Bugs>. (You can mention that we know the good..bad range is 3550..3613.) It's additional pain that this is Windows-only, as I haven't ever built pdfium on Windows with the upstream build system, so it's tricky for me to debug this. Thanks!
Created attachment 149993 [details] screenshot on Win10 + master sources updated yesterday On Win10 + master sources updated yesterday (UI Render GL), I made a screenshot of rendering http://bugs.documentfoundation.org/attachment.cgi?id=144865 On console logs, I only noticed this: warn:vcl.gdi:1132:4080:vcl/source/graphic/Manager.cxx:135: Calculated size mismatch. Variable size is '400624' but calculated size is '200824' About debug information in pdfium, I don't see any equivalent to https://cgit.freedesktop.org/libreoffice/core/commit/?id=8976e546909be0e523dbaf6581c53c1d5b44a1d0 in external/pdfium (or perhaps missed it).
(In reply to Miklos Vajna from comment #14) > That's annoying. :-( > > Could you please try your luck with reporting this to pdfium upstream? See > <https://pdfium.googlesource.com/pdfium/#Bugs>. (You can mention that we > know the good..bad range is 3550..3613.) > But it works in Chrome.. Does it makes sense report pdfium bug which occurs only in LO to upstream? Tested on another computer and it works with Version: 6.3.0.0.alpha0+ (x64) Build ID: 3c964980da07892a02d5ac721d80558c459532d0 CPU threads: 1; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-12_03:38:09 and W10 with same build. So it doesn't works for me only on win7 computer and LO from bibisect repository bibisect-win32-6.3 Closing.
You're right, the ideal upstream bug is when it doesn't work in Chrome, either. :-)