[Libreoffice-bugs] [Bug 108726] PDF insertion regressions in 5.4

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=108726

--- Comment #10 from Miklos Vajna  ---
(In reply to V Stuart Foote from comment #7)
> @Miklos?

Transparent PDF looks doable.

"break" -- as you said -- still possible with manually opening in Draw and
copying the draw page. Out-of-the-box break is possible, but a rather large
work. It would require LO providing a skia interface, also pdfium's skia output
(the only vector one) is not yet ready.

So I guess let's keep this bug open for the transparency part.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 108726] PDF insertion regressions in 5.4

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=108726

--- Comment #9 from V Stuart Foote  ---
(In reply to sergio.callegari from comment #8)
> > I think return of break would requires enhancement as in bug 106581 to use 
> > Skia graphics with the pdfium filtered PDF.
> 
> 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?
> 

As in your original posting in bug 104648, _no_. 

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.

> > A PDF file filter import opened into into Draw still support the "break".
> 
> 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.
> 

Yes that is correct, but the PDF structure is lost losing fidelity when
printing or reexporting out of the saved ODF drawing.

> 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.
> Another workaround is to open in inkscape, save as emf and insert the emf
> that supports the break action. 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.

There are better ghostscript based PDF conversions than Inkscape--but that is
one approach.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 108726] PDF insertion regressions in 5.4

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=108726

--- Comment #8 from sergio.calleg...@gmail.com ---
> I think return of break would requires enhancement as in bug 106581 to use 
> Skia graphics with the pdfium filtered PDF.

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?

> A PDF file filter import opened into into Draw still support the "break".

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.

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. Another workaround
is to open in inkscape, save as emf and insert the emf that supports the break
action. 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 108726] PDF insertion regressions in 5.4

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=108726

V Stuart Foote  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW
 CC||vmik...@collabora.co.uk,
   ||vstuart.fo...@utsa.edu
   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=10
   ||6581
 Blocks||99746
Summary|PDF import regressions in   |PDF insertion regressions
   |5.4 |in 5.4

--- Comment #7 from V Stuart Foote  ---
Confirming both aspects on Windows 10 Pro 64-bit en-US with
Version: 5.4.0.3 (x64)
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 8; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: group

But I think the loss of the "break" was expected with adoption of the pdfium
based insertion. I think return of break would requires enhancement as in bug
106581 to use Skia graphics with the pdfium filtered PDF.

A PDF file filter import opened into Draw still support the "break".

@Miklos?


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=99746
[Bug 99746] [META] Improve PDF filter handling
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs