Created attachment 199733 [details] Gradient is jagged and broken in LibreOffice Draw for WordArt objects from Google Drawings Google Drawing: https://docs.google.com/drawings/d/1mRAwxQOKKfVsKHHVIlOJWNRlSVg9i15o0ctoD5Me04E/edit?usp=sharing When I open an exported PDF file from Google Drawings in LibreOffice Draw I see broken gradient for WordArt letters with gradients like on the attached screenshot.
Created attachment 199739 [details] pixel perfect rendering with the pdfium based insert filter
Wrong filter. LibreOffice is not a PDF editor. And, no issue with the pdfium based 'Insert as image' workflow, pixel perfect. And that seems more appropriate for a WordArt object. Taking a PDF graphic object through poppler and then converting with cairo to LibreOffice sd draw shape objects is not able to provide high fidelity. Wrong work flow.
@Dave, as an aside, do you have any perspective on poppler's ability to clip to a glyph path over a gradient? Or put another way, is there any chance something meaningful could be passed out to cairo to generate a draw shape. The pdfium work flow seems functional for getting the graphic to LO canvas with fidelity otherwise.
(In reply to Emily Grace Seville from comment #0) > When I open an exported PDF file from Google Drawings in LibreOffice Draw I > see broken gradient for WordArt letters with gradients like on the attached > screenshot. I've just opened the exported PDF with an LO Draw 25.8 nightly, and did not see anything broken or jagged. Will attach the PDF and a screenshot soon. Can you try it with a recent nightly build? https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb99-TDF/current/ (In reply to V Stuart Foote from comment #2) Stuart, stop it. It's bad enough that you keep discouraging people from editing PDFs with LO - now you're even closing bug reports filed against the import filter because you'd rather it not be used. That's inappropriate.
Created attachment 199743 [details] PDF exported from the Google Docs link - open this in LO Draw
Created attachment 199744 [details] Screenshot of attachment 199743 [details] in Draw 25.8 nightly - looks mostly-ok at 100% So, this screenshot is what I see. Build info: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 894563ee0e4032019623a97c313af3d833863b1f CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US I will say that, as I zoon in, I think I see the "jaggedness" you refer to - I believe there is some sort of a scaling artifact creating a pattern in the error which repeats at a visible frequency at some zoom levels. Please check this yourself and verify. In that case, it's not clear that the problem is with the import filter, and it might be the VCL or somewhere else in the code.
Created attachment 199745 [details] Screenshot of attachment 199743 [details] in Draw 25.8 nightly - jaggedness at 180% Increasing the zoom level, we see the jaggedness - but at some other zoom levels it disappears, then reappears etc. Looks like "sampling artifacts" in video recording.
Right, so there's a few things going on a) Stuart: I agree with Eyal - please stop with that! Something gentler along the lines of 'Libreoffices PDF editing is still a bit limited, you might like to try the Pdfium based image insert flow, but thanks for reporting it.' would be nicer! b) The actual clipping I fixed a lot of back in ~August - see b416c5b8e32632a63e1e791c34896e17d89f7982 c) The 1st problem is that the input filter doesn't implement any shaded fills; so it falls back to Poppler's internal code which chops it up into thin poloygons. c1) These appears to be PDF 'axial fill's - i.e. what we would call a gradient fill - that's actually fixable, I just haven't implemented it yet; I've also not checked if all PDF axial fills are representable in LO d) There's something else going on - I think somewhere in the rendering stack but I'm not sure where; I don't understand why it looks worse as you zoom in; sure I expect to see the individual polygons - so I expect to see jaggyness - but when you zoom in you see the colour of each polygon being non-uniform (like dark-light) which makes the jaggies look even worse. So I think this is a valid bug and is 'implement axial fills' for (c) - if you know anyone with an idea about what's going on in the jaggyness who can point to (d) that would be good.
(In reply to Eyal Rozenberg from comment #4) (In reply to Dave Gilbert from comment #8) It is a question of reputation and UX, managing user expectation. I do it because the other side of the issue is UX complaint that PDF they've "edited" (i.e. opened into Draw) has been corrupted when they overwrite it, or worse completely lost! So if we tell folks they can edit PDF with LibreOffice, they expect they'll have something at the end of their workflow that resembles their source PDF. We can not, so suggesting that LibreOffice can edit their PDFs is just wrong.
(In reply to V Stuart Foote from comment #9) > (In reply to Eyal Rozenberg from comment #4) > (In reply to Dave Gilbert from comment #8) > > It is a question of reputation and UX, managing user expectation. > > I do it because the other side of the issue is UX complaint that PDF they've > "edited" (i.e. opened into Draw) has been corrupted when they overwrite it, > or worse completely lost! > > So if we tell folks they can edit PDF with LibreOffice, they expect they'll > have something at the end of their workflow that resembles their source PDF. > > We can not, so suggesting that LibreOffice can edit their PDFs is just wrong. That's why I suggested the 'is still a bit limited' - it gives a balance of expectations.
(In reply to Dave Gilbert from comment #8) > ... > c) The 1st problem is that the input filter doesn't implement any shaded > fills; so it falls back to Poppler's internal code which chops it up into > thin poloygons. > c1) These appears to be PDF 'axial fill's - i.e. what we would call a > gradient fill - that's actually fixable, I just haven't implemented it yet; > I've also not checked if all PDF axial fills are representable in LO > > d) There's something else going on - I think somewhere in the rendering > stack but I'm not sure where; I don't understand why it looks worse as you > zoom in; sure I expect to see the individual polygons - so I expect to see > jaggyness - but when you zoom in you see the colour of each polygon being > non-uniform (like dark-light) which makes the jaggies look even worse. > > So I think this is a valid bug and is 'implement axial fills' for (c) - if > you know anyone with an idea about what's going on in the jaggyness who can > point to (d) that would be good. You might check with Armin W. for a hand with the primitives used in bcolormodifier.hxx
@Emily, sorry for the sidebar noise. Believe the NEEDINFO is to you, please retest with updated install of LibreOffice where the masking/clipping for filter imported and opened PDF has been improved. Please could test with 25.2.1 [1], the pending 25.2.2 prerelease [2], or a nightly of master against 25.8.0 [3] to see if you get what you need working with the WordArt. Otherwise the insertion of the PDF page as an image remains an option if you are not looking to further edit the drawing objects in Draw. =-ref-= [1] https://www.libreoffice.org/download/download-libreoffice/ [2] https://www.libreoffice.org/download/download-libreoffice/?type=win-x86_64&version=25.2.2&lang=en-US [3] https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/ but install it "In parallel" with a Windows /a administrative installation, some notes here: https://wiki.documentfoundation.org/Installing_in_parallel/Windows