When pdftocairo ist used with libcairo2-1.15.12-1 -- which (AFAIK)
contains the bug I linked above -- to output a pdf file (as pdftopdf
1.21 will do!), it would be no surprise have a corrupt pdf after
pdftocairo, which gs then rightly will complain about; esp. the ET
-thing is the one things such
My observations:
As changing pdftops-renderer does not seem to make a difference, probably only
one of the programs is installed and thus used in all cases?
According to Dependencies.txt, libcairo2-1.15.12-1 seems to installed, which
AFAIK is affected by the problem described e.g. here:
Object 39 is an image; but even Object 4 (the content stream of the
first page; obj 93 *is* used on that page) has such a decompression
error.
Ghostscript prints:
warning: ignoring zlib error: incorrect data check
So probably libqpdf (which is used for the very low-level pdf stuff in
pdftopdf)
For example, here some java/PDFBox-based implementation of how to flatten
simple forms:
https://gist.github.com/jribble/beddf7620536939f88db
(IIRC there are more form elements than those 2-3 handled here(?)).
Note that QPDF does not have something like the PDAcroForm class (and
its friends)
See https://bugs.linuxfoundation.org/show_bug.cgi?id=1315 why this cannot work.
And QPDF won't be able to do anything about it, either...
There might even be PDF-capable printers on the market (i.e. where the
rasterization is not done by gs / poppler on the host), where the form content
will not
According to Mike Sweet [1]:
Dec 28, 2007 by Michael Sweet:
The 1.1.x (and 1.0.x) behavior was incorrect. According to the IPP
specification, number-up is applied *first*, and page-ranges refers to the
imposed pages. Similarly, page-set is applied after imposition.
and here [2]:
Nov 16, 2008
Exception is thrown in libqpdf
** Package changed: cups-filters (Ubuntu) = qpdf (Ubuntu)
** Also affects: cups-filters (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to qpdf in Ubuntu.
/Contents is the correct spelling.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to qpdf in Ubuntu.
https://bugs.launchpad.net/bugs/1392048
Title:
File not printed Exception: unknown object type inspecting /Contents
key in page
Per PDF Spec, the /contents key in a Page dictionary is optional.
The attached pdf's page 9 has no /contents key.
But QPdfObjectHandle::getPageContents() throws an exception;
cups-filter (pdftopdf) calls it via QPDFObjectHandle::addPageContents().
--
You received this bug notification because
cups-filter's pdftopdf before around 1.0.21 was based on poppler, not
qpdf.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to qpdf in Ubuntu.
https://bugs.launchpad.net/bugs/1263784
Title:
PDF form data is blank when printed with lp
You seem to have a quite old version of cups-filters (=1.0.20 i think).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to qpdf in Ubuntu.
https://bugs.launchpad.net/bugs/1263784
Title:
PDF form data is blank when printed with lp
Fixed in bzr revision 7145.
** Changed in: cups-filters (Ubuntu)
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups-filters in Ubuntu.
https://bugs.launchpad.net/bugs/1259240
Title:
** Changed in: cups-filters (Ubuntu)
Status: New = In Progress
** Changed in: cups-filters (Ubuntu)
Assignee: (unassigned) = Tobias Hoffmann (smilingthax)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups-filters
No full analysis yet, but a first point:
The line was deleted in the commit, not added.
Therefore it is correct, that it is also missing later.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups-filters in Ubuntu.
Public bug reported:
Reproducible crash:
1) start x
2) (terminal): xinput test-xi2 10
[10 is the device id, see below]
3) use touch device on the window a bit, use more than 2 fingers, and
occassionally click into the terminal window
4) xserver segfaults after at most a few tries of 3), i.e.
** Attachment added: x server log
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1198332/+attachment/3726261/+files/Xorg.0.log
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg-server in Ubuntu.
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
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
18 matches
Mail list logo
