Description: If you open the PDF „aufschiebenfribourgpraesentation.pdf“, LO Draw freezes. The file is 1,2 MB and contains 46 pages. According to the properties the file was created by „Acrobat Distiller 6.0.1 (Windows)“ with „Acrobat PDFMaker 6.0 für PowerPoint“ and the PDF Version is 1.2. I ran the file through „GPL Ghostscipt 9.15“. GS created a new PDF with Version 1.5, but this file still freezes Draw. Steps to Reproduce: 1. Open PDF with LO Draw Actual Results: Draw shows file Expected Results: Draw freezes Reproducible: Always User Profile Reset: No Additional Info: http://web.archive.org/web/20090419034041/http://www.fu-berlin.de/studium/docs/DOC/aufschiebenfribourgpraesentation.pdf It‘s from the student counseling of the Freie Universität Berlin. http://www.fu-berlin.de/sites/studienberatung/studienberatung/ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393
Created attachment 136910 [details] Original file
Created attachment 136911 [details] PDf, that was created with Ghostscript 9.15
Version: 5.4.2.2 (x64) Build-ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU-Threads: 4; Betriebssystem:Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: group Version: 6.0.0.0.alpha0+ (x64) Build ID: 91d5cebbde2e854a73a9a7633725350df1418387 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-09_01:26:55 Locale: de-DE (de_DE); Calc: CL
I tested the attached files and it is not freezing draw only but also any LibreOffice running component (Writer, Calc…). However, I tried an other pdf file of 2.9 MB and it is working fine even it takes few time to open. Testing environment: • Operating system : Windows 8.1 Pro 64-bits. • LibreOffice : Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: en-US (en_US); Calc: group And also on : • Operating system : Ubuntu 16.04.3 64-bits. • LibreOffice :Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: ja-JP (ja_JP.UTF-8); Calc: group
Dear Xisco, I know that I cannot change the status of my own bug reports. Another member of this forum that confirmed my bug, but forgot to change the status. So I do it for him. Better than left the report as "unconfirmed", I think. :-)
Confirmed in Version: 6.0.0.0.alpha1+ Build ID: d30522e46ca884e9bc74af21711d9537e8118859 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Mike from comment #5) > Dear Xisco, > I know that I cannot change the status of my own bug reports. Another member > of this forum that confirmed my bug, but forgot to change the status. So I > do it for him. Better than left the report as "unconfirmed", I think. :-) Ok, no problem. Ideally, it's good to check with older versions to see whether it's a regression too. See: https://wiki.documentfoundation.org/QA/Triage_For_Beginners#Regression_Testing
still repro in Version: 6.2.0.0.alpha0+ (x64) Build ID: d8733e2c59f120acf9feddff04964becc3358621 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-06-26_11:09:03 Locale: ru-RU (ru_RU); Calc: CL
Dear Mike, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hello, I've recheck this bug for Version: 6.5.0.0.alpha0+ Build ID: 3e33a11d8a553a99bd5f23940a65c301924198fb CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kf5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-12-16_11:03:40 Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded Issue is still reproducible with PDF from Comment#2 and also with my test document - attached below.
Created attachment 156616 [details] test document PDF
I was able to reproduce this Writer 7.0.0.0.alpha1+, built from the latest source today. Writer froze and soffice.bin CPU usage was 96% (memory 1 GiB) , Web Content CPU 36% (and memory 1.7 GiB). I waited for a few minutes and then killed it.
Created attachment 165051 [details] 113050 - Minimum test case - PDF, 1 page, 19 kb, Crash on import I made a minimum test case from the presentation. Now it's only one page and the size is 19 kb.
Confirmed in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 465c3ad95059f0efa13c8027f7383c4d20a5b2ff CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 (cairo+xcb) Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded The original document and the GS version from comment #2 still do freeze Draw. The document in comment #11 as well as the minimum test case from #13 opened without freezing though. I was able to open the minimum test case file, add a background, save as .odg and quit the application.
Still happenining on current head using the original aufschiebenfribourgpraesentation.pdf ; I've got gdb on it and am looking. To me it seems to be stuck on page 17 in #21 0x00007faf4bdbbd24 in pdfi::DrawXmlEmitter::visit (this=0x7faf293c3240, elem=...) at /discs/fast/core/sdext/source/pdfimport/tree/drawtreevisiting.cxx:369 the loop: 367 while( this_it != elem.Children.end() && this_it->get() != &elem ) 368 { 369 (*this_it)->visitedBy( *this, this_it ); 370 ++this_it; 371 } but maybe it's being slow. Visually there's nothing odd when viewed in okular; old school presentation with shaded background, simple clipart and long German words. I'll keep digging:w
pdfseparate -f 17 -l 17 aufschiebenfribourgpraesentation.pdf page17.pdf gets a single page pdf that also fails. I'm not sure this is actually a hang, as opposed to a crazy slowness. Annotating the DrawXmlEmitter::visit( PageElement& elem, I see that for my single page test it's called once and never gets out of it's loop, so I added: std::cerr << "DrawXmlEmitter::visit loop; size: " << elem.Children.size() << " count=" << count << std::endl; with count incrementing on the loop. There are 157589 elements for some reason in that simple page, and after 12 minutes it's got through about 80000 of them, but it's slowing down quite a bit as it's adding them. I'll keep digging.
It does indeed finish loading, after somewhere more than 30mins, and with LO taking about 2.5G of RAM; the elements are mostly N4pdfi12FrameElementE's all 48x48 pixels; so something has rasterised an image as frames, sometimes using 3 elements per pixel. DrawXmlEmitter::visit loop; count=173N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,21888 DrawXmlEmitter::visit loop; count=174N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,21888 DrawXmlEmitter::visit loop; count=175N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,21888 ... DrawXmlEmitter::visit loop; count=853N4pdfi12FrameElementEw,h@x,y:48,-48@75611.1,21888 DrawXmlEmitter::visit loop; count=854N4pdfi12FrameElementEw,h@x,y:48,-48@75611.1,21888 DrawXmlEmitter::visit loop; count=855N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,22032 DrawXmlEmitter::visit loop; count=856N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,22032 DrawXmlEmitter::visit loop; count=857N4pdfi12FrameElementEw,h@x,y:48,-48@65147.1,22032 DrawXmlEmitter::visit loop; count=858N4pdfi12FrameElementEw,h@x,y:48,-48@65195.1,21984 Keeping digging.
OK, so these are 'DRAWMASK' entries; following the cookie crumbs we go out through xpdfimport and back through wrapper_gpl.cxx to a call to poppler that does the parsing. We can get our stream back by doing: ./instdir/program/xpdfimport page17.pdf </dev/null > xdpfwrapper-op 2>&1 which gives us a 67M file with 170 draw images and 157404 drawMask's! /me grabs a bigger shovel, and keeps digging.
OK, so now I understand the source of the problem. On Page 17 of the presentation is a cut-art graphic of a hand; this hand has a few half-toned patterns on it; these are represented in the pdf as images and masks (about 8 of them). They're then repeated using a tiled pattern fill; and poppler calls us back for every repetition creating thousands of copies. (That minimum test case has part of that pattern in it) #0 pdfi::PDFOutDev::drawImageMask (this=0x7fffffffdc20, pState=0x78c080, str=0x794910, width=8, height=8, invert=false) at /discs/fast/core/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:1031 #1 0x0000000000484b32 in Gfx::doImage (this=this@entry=0x760540, ref=ref@entry=0x7fffffffcef0, str=0x794910, inlineImg=inlineImg@entry=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:4300 #2 0x0000000000487dce in Gfx::opXObject (this=0x760540, args=<optimized out>, numArgs=<optimized out>) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Object.h:441 #3 0x000000000047eba3 in Gfx::go (this=this@entry=0x760540, topLevel=topLevel@entry=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:685 #4 0x000000000047f320 in Gfx::display (this=this@entry=0x760540, obj=obj@entry=0x75c708, topLevel=topLevel@entry=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:646 #5 0x000000000047f7f7 in Gfx::drawForm (this=0x760540, str=0x75c708, resDict=<optimized out>, matrix=<optimized out>, bbox=0x75c698, transpGroup=<optimized out>, softMask=false, blendingColorSpace=0x0, isolated=false, knockout=false, alpha=false, transferFunc=0x0, backdropColor=0x0) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:4836 #6 0x0000000000483338 in Gfx::doTilingPatternFill (this=0x760540, tPat=0x75c680, stroke=<optimized out>, eoFill=<optimized out>, text=<optimized out>) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:2185 #7 0x0000000000483c4d in Gfx::opEOFill (this=0x760540, args=<optimized out>, numArgs=<optimized out>) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:1775 #8 0x000000000047eba3 in Gfx::go (this=this@entry=0x760540, topLevel=topLevel@entry=true) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:685 #9 0x000000000047f320 in Gfx::display (this=this@entry=0x760540, obj=obj@entry=0x7fffffffd8c0, topLevel=topLevel@entry=true) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Gfx.cc:646 #10 0x00000000004cc330 in Page::displaySlice (this=0x75d680, out=0x7fffffffdc20, hDPI=<optimized out>, vDPI=7200, rotate=0, useMediaBox=true, crop=true, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=true, abortCheckCbk=0x0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0x0, annotDisplayDecideCbkData=0x0, copyXRef=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Page.cc:584 #11 0x00000000004cc5d8 in Page::display (this=<optimized out>, out=out@entry=0x7fffffffdda0, hDPI=hDPI@entry=2.4858339854353144e-317, vDPI=vDPI@entry=-nan(0xfffffffffffff), rotate=rotate@entry=-1, useMediaBox=useMediaBox@entry=255, crop=crop@entry=255, printing=printing@entry=true, abortCheckCbk=0x0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0x0, annotDisplayDecideCbkData=0x0, copyXRef=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/Page.cc:530 #12 0x00000000004d4e42 in PDFDoc::displayPage (this=this@entry=0x7fffffffdaa0, out=0x7fffffffdda0, out@entry=0x7fffffffdc20, page=page@entry=1, hDPI=2.4858339854353144e-317, hDPI@entry=7200, vDPI=-nan(0xfffffffffffff), vDPI@entry=7200, rotate=-1, rotate@entry=0, useMediaBox=255, useMediaBox@entry=true, crop=255, crop@entry=true, printing=<optimized out>, abortCheckCbk=<optimized out>, abortCheckCbkData=<optimized out>, annotDisplayDecideCbk=<optimized out>, annotDisplayDecideCbkData=<optimized out>, copyXRef=false) at /discs/fast/core/workdir/UnpackedTarball/poppler/poppler/PDFDoc.cc:608 #13 0x00000000004170ac in main (argc=<optimized out>, argv=<optimized out>) at /discs/fast/core/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:177 it looks like poppler has a hook to tell the output device about the whole pattern in one go (useTilingPatternFill and tilingPatternFill), so implementing that would do it. A hack would be to add an optimisatino into DrawXmlOptimizer I think - tree/drawtreevisiting.cxx I'll have a look.
(In reply to Dave Gilbert from comment #19) > > it looks like poppler has a hook to tell the output device about the whole > pattern in one go (useTilingPatternFill and tilingPatternFill), so > implementing that would do it. > Sounds like a good idea to me - just make sure that callback is available in our oldest supported version of poppler - if it is not you will need to scatter some #ifdef around and have some fallback code.
Great. So as mentioned on irc, it looks like we have to support poppler >=0.14 0.14 does indeed have the same tilingPatternFill and useTilingPatternFill hooks in the outputDev - great.....oh, the interface has changed somewhere along the line, so have to deal with that change; sigh OK, got to try a few versions then. (Falling back would be easy, poppler behaviour on this hook is already see if it's supported, try the hook and if the hook doesn't exist refuse). I'll look at implementing it.
I flipped to playing with DrawXMLOptimizer because I thought it might be easier than tilingPatternFill, but hmm. I hacked part of what was needed into /pdfimport/tree/drawtreevisiting.cxx DrawXmlOptimizer::visit (FrameElement & ... but it only gets me part way; I reckon out of the ~150k possibilities this is only hitting about 30k. The problem is that on the original image there's actually 5 or 6 overlapping patterns with different image/masks. They each get rasterised into tiles, but then the start of the optimiser performs a sort, so the neighbouring tiles of any one image aren't next to each other in the optimiser list. That sounds fixable but is now getting much messier. I'll flip back to tilingPatternFill; the pain with that is getting my head around all the different coordinate spaces and Poppler doesn't provide much helper APIs for recreating parts of the path to export the image. Right, I thought I'd just add those notes before carrying on...
Getting there slowly; I have a modified wrapper on both sides enabling the tiling call, and passing the tile to the other side. With that in place the file loads OK, but without the offending hand! Now, to build the structure from the imported data...
One thing I think I understand now is the 'minimum test case' in this bug, loads but is a strangely rectangular blob in LO, but is much smaller and subtle displayed in a PDF viewer. I don't think our code uses the clip path for anything other than polygons, so the array of images generated by the tiled fill is left square.
Created attachment 192485 [details] Current state of page17 OK, I'm finally getting somewhere; the geometry is now working, see the attached 'hand' from page17 of the original document. This is solid shaded at the moment, not with the textures. I've got the images plumbed through the wrapper to the pdfimport layer (hmm with some bodges that need fixing) so next step is to get them into the polygon.
Created attachment 192623 [details] A rendered thumb OK, I think I have this reasonably happy; this is part of the hard part of page17 which looks reasonably close. It's a bunch of ~3 overlayed transparent tiledFill's, each of which I've turned into cropped PolyPoly's with tiled image fills. Note this freaks X a bit; it's taking about ~10 seconds to render the slide; but that's a separate issue. 152680 is also working now. Now, to tidy up and get through CI....
https://gerrit.libreoffice.org/c/core/+/163575 is my current code; just working through cleaning it up. Bunch of unused in the intermediate patches, I've got those cleaned up. I need to get the QA code happy. Ewww the Windows and Mac failure looks more 'fun'
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/18a1c3d6c98348d4e3da6e6c9740d6923ab2fba1 tdf#113050 poppler: Enable splash It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8e4a351f12d777ad9102086298741d0a97e5eeb9 tdf#113050 sdext.pdfimport: Write the tiling pattern header It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8ac5f40b330c6cd248073b8686c05f566ecd7195 tdf#113050 sdext.pdfimport: Write the tiling pattern image It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7a63d26466bac7eb7b25233a5a53788bed88c81 tdf#113050 sdext.pdfimport: Flip bitmap It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ec0b9062dc8dba82509183eb865da55827bde4d5 tdf#113050 sdext.pdfimport Tiling pattern fill parser It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4a13e1890e8a0ed81e8fb17009185fa2b15ebff7 tdf#113050 sdext.pdfimport: Plumb tiling pattern fill to pdfiprocessor It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2350357d5cc2ac1787816ce887af6e9f36b8d252 tdf#113050 sdext.pdfimport: Create poly for tiling pattern It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bc5bd022a9ea8128bd5e9ba02bda48332dccbbe4 tdf#113050 sdext.pdfimport: In styles Specialise draw:fill-image It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ff160e93d32c62e09b28393979b3535e01057cdc tdf#113050 sdext.pdfimport: In styles wrap 'Contents' It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d7e5eae44e18ab89e85a0e6ed633853ede70ec71 tdf#113050 sdext.pdfimport: Add ImageContainer::asBase64EncodedString' It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2bf5664823e7ef71d917fe95a2c3d92e46d77c32 tdf#113050 sdext.pdfimport: Add FillImage field to PolyPolyElement It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f21f816a16914e06ff141a800a63f0966e387b2 tdf#113050 sdext.pdfimport: Expose the ImageContainer const It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4b295b1b77b33c9a5b5fcfab58132ca0dcb7f90b tdf#113050 sdext.pdfimport: Create the fill-image style and use it It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/784696e47c7f28dac111b95e61f06a9a1f7cdc97 tdf#113050 sdext.pdfimport: Add TileWidth and TileHeight fields It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/81fbaf4bb9ddc385d4452257d731e4097dfed079 tdf#113050 sdext.pdfimport: Set and write TileWidth/Height It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cf776a6fa697924deb7df5c0561e12bbd7cda16a tdf#113050 sdext.pdfimport: Enable tilingPatternFill It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 152680 has been marked as a duplicate of this bug. ***
*** Bug 157732 has been marked as a duplicate of this bug. ***
OK, marking this as fixed. Notes: * Still to do is fixing the ~10 seconds rendering pause that I see on page 17, but that's separate. * If you're using an old Poppler this fix wont work - we can make it work for some older versions if we throw enough ifdef's in; please file a bug if you need it. * There are other bugs with pdf import hangs; but they have different causes; this one (and the dupes) are 'tilingPatternFill' bugs.