Fixed in Raring by updating QPDF to 4.0.1.
** Changed in: qpdf (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923955
Title:
pdftopdf filter fails to
The attachment "patch to fix this problem" of this bug report has been
identified as being a patch. The ubuntu-reviewers team has been
subscribed to the bug report so that they can review the patch. In the
event that this is in fact not a patch you can resolve this situation by
removing the tag '
This patch is relative to 4.0.1. I suspect that it will apply cleanly
to 3.whatever-you-have with at most offsets. The change is very
localized. If you run into any problems, you can post here. I'm
subscribed to this bug.
** Patch added: "patch to fix this problem"
https://bugs.launchpad.n
Jay, thanks for the info, I have found out this now, too by building the
experimental package on Raring. Can you attach the patch here or post a
link to it, so that I can apply it to the Quantal package? Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
For anyone watching, qpdf_4.0.1-2 in debian has had a fix for this
problem since February 25. The patch should be easy to backport to the
version in 12.10.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
** Package changed: cups (Ubuntu) => qpdf (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923955
Title:
pdftopdf filter fails to output form field values
To manage notifications about this b
Sorry, I forgot to subscribe and did not get your comment by mail...
I think a recent evince will directly send pdf (and not ps) to cups. But it
will 'rewrite' quite heavily.
And yes, PDF is the new internal default format in the linux printing chain.
This has more to do with having the appropri
It's true that the example form has the Acrobat Professional extensions
enabled. They're not required for basic form-filling, but they are for
certain features such as comments and digital signatures. It's possible
that doing pdf-pdf conversion will fail in this circumstance...
Printing these form
Concerning printing with Evince: I think it converts the PDF to
PostScript before sending it to CUPS for printing hence "flattening" the
interactive features. The problem manifests only if one tries to use
"lp" (or similar commmands) directly or if the application (like
qpdfview) tries to take adva
Form values are also lost with the old pdftopdf implementation (used in
cups-filters before 1.0.21).
Probably only the pdf->ps workflow ever worked.
The form values are also lost by just using qpdf to 'non-destructively' rewrite
the pdf. Therefore the problem is already present in the underlying
An Ubuntu and qpdfview user seems to have had the same problem trying to
print
"https://service.rundfunkbeitrag.de/e360/e364/e1685/e1699/resources1700/Buergerinnen_und_Buerger_Wohnungsabmeldung_0106.pdf";.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cups (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923955
Title:
pdftop
** Attachment added: "PDF form filled with values for reproducing issue"
https://bugs.launchpad.net/bugs/923955/+attachment/2701810/+files/interactiveform_enabled_filled.pdf
** Description changed:
Running the provided form through the pdftopdf filter results in an
empty PDF form: all fie
13 matches
Mail list logo