I lost an inkscape drawing pdf#

> option when inserting the pdf image in an existing drawing/presentation. > the pdf document in draw is a useful workaround for the lack of 'break' > Indeed, the possibility of getting this behavior through the 'opening' of Yes that is correct, but the PDF structure is lost losing fidelity when printing or reexporting out of the saved ODF drawing. > the 'break' action remains supported, I think. > automatic (opposed to showing the image rendered by pdfium), which is why > an existing draw document, then the conversion into native LibO objects is > If you 'open' the pdf file with draw, in opposition to 'inserting' it into Miklos' work on an 'insert as image' capability (resolving bug 89727) and then moving it to a pdfium based filter simply does not support it. > to use Skia graphics with the pdfium filtered PDF?Īs in your original posting in bug 104648, _no_. > leveraging the 5.3 codepath for the 'break', until it is possible to switch > Wouldn't it be possible, at least for the time being, leaving in place and (In reply to sergio.callegari from comment #8)

Still, it seems a bit more complex than desirable and a bit inconsistent to have break on all vector formats (svg, emf, wmf, native metafile), but PDF. Another workaround is to open in inkscape, save as emf and insert the emf that supports the break action. Indeed, the possibility of getting this behavior through the 'opening' of the pdf document in draw is a useful workaround for the lack of 'break' option when inserting the pdf image in an existing drawing/presentation. If you 'open' the pdf file with draw, in opposition to 'inserting' it into an existing draw document, then the conversion into native LibO objects is automatic (opposed to showing the image rendered by pdfium), which is why the 'break' action remains supported, I think. > A PDF file filter import opened into into Draw still support the 'break'. Wouldn't it be possible, at least for the time being, leaving in place and leveraging the 5.3 codepath for the 'break', until it is possible to switch to use Skia graphics with the pdfium filtered PDF? > I think return of break would requires enhancement as in bug 106581 to use Skia graphics with the pdfium filtered PDF.

I hope that this can be fixed before the 5.4 final release. Notably, LibO already includes a codepath for doing so, since PDF images are converted in LibO drawing primitives when /opened/ rather than imported.

I lost an inkscape drawing windows#

Ideally, this should still be present and transform the image in elementary LibO drawing primitives (even not perfectly), as it happens for windows metafiles. This is extremely critical in some workflows.Ģ) The 'break' action is now missing for PDF images in draw and impress. I see a very nice and commendable effort at providing a faithful and fast rendering of PDF images inserted in documents, drawing and presentations, thanks!Īt the same time, I also see some quite notable regressions:ġ) PDF images with a transparent background are always rendered with a white solid background, which makes the PDF import completely useless when the imported image needs to appear on a colored or otherwise non-white background. Just tested LibO 5.4 RC, with interest in the new management of PDF files during import.