Problem is caused by _cairo_path_fixed_stroke_extents() returning wrong
extents.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1300659
Title:
printed pdf file lacks item boxes
To
Created attachment 125087
Debug patch
This patch shows the problem is caused by
_cairo_path_fixed_stroke_extents().
If the operation is changed to a fill (change line 259 in the PDF from
"S" to "f") the box appears in the output.
--
You received this bug notification because you are a member
Created attachment 125086
Reduced test case
Reduced test case. This PDF strokes a single path of one of the boxes in
the original PDF. The original PDF draws the boxes with the fill-stroke
operator "B". I've replaced it with a stroke "S".
To reproduce:
pdftocairo -ps reduced-test-case.pdf
Created attachment 120924
Check in ranges in ByteRange array v2
- renamed isInteger() to isIntOrInt64()
- added and use getIntOrInt64()
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
(In reply to Albert Astals Cid from comment #120)
> Ok, good, so Adrian can you commit your patch?
Pushed
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1085526
Title:
ubuntu pdf
Created attachment 120924
Check in ranges in ByteRange array v2
- renamed isInteger() to isIntOrInt64()
- added and use getIntOrInt64()
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
(In reply to Albert Astals Cid from comment #120)
> Ok, good, so Adrian can you commit your patch?
Pushed
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify
I don't think we need to check if the byte range covers the entire
document. Our job, when verifying the signature, is to use the byte
ranges provided in the signature dictionary. It is up to the pdf
producer to ensure the byte range covers the entire document (excluding
the signature value).
All
I don't think we need to check if the byte range covers the entire
document. Our job, when verifying the signature, is to use the byte
ranges provided in the signature dictionary. It is up to the pdf
producer to ensure the byte range covers the entire document (excluding
the signature value).
All
(In reply to Albert Astals Cid from comment #114)
> I'm not very convinced by the naming of
> GBool isInteger() { return type == objInt || type == objInt64; }
> what do you think of
> isIntOrInt64() ?
I prefer a single word instead of isXXXorYYY() but I can appreciate that
isInteger() could
Created attachment 120889
Check in ranges in ByteRange array
This is an alternative to the patch in comment 108. It checks all ranges
in the ByteRange array.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
(In reply to Andre Guerreiro from comment #105)
> Created attachment 120434 [details] [review]
> Improve robustness of SignatureHandler::validateCertificate
>
> This patch adds additional NULL-checking in
> SignatureHandler::validateCertificate() which avoids segfault for some
> signatures like
(In reply to Albert Astals Cid from comment #114)
> I'm not very convinced by the naming of
> GBool isInteger() { return type == objInt || type == objInt64; }
> what do you think of
> isIntOrInt64() ?
I prefer a single word instead of isXXXorYYY() but I can appreciate that
isInteger() could
(In reply to Andre Guerreiro from comment #105)
> Created attachment 120434 [details] [review]
> Improve robustness of SignatureHandler::validateCertificate
>
> This patch adds additional NULL-checking in
> SignatureHandler::validateCertificate() which avoids segfault for some
> signatures like
Created attachment 120889
Check in ranges in ByteRange array
This is an alternative to the patch in comment 108. It checks all ranges
in the ByteRange array.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
I suggest we change the pdfsig "-c" switch to "-nocert". We can easily
add a single character option if we find it is needed. But we can't get
rid of it if we later regret it.
I'm still waiting for an answer to comment 79.
--
You received this bug notification because you are a member of Ubuntu
(In reply to Andre Guerreiro from comment #97)
> Quoting from ISO 32000-1 section 12.8.1:
> "This range should be the entire file, including the signature dictionary
> but excluding the signature value itself (the Contents entry). Other ranges
> may be used but since they do not check for all
(In reply to Andre Guerreiro from comment #100)
> Created attachment 119283 [details] [review]
> Manpage improvement
Pushed
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1085526
(In reply to Albert Astals Cid from comment #96)
> As said please let's not spend too much time on arguing over switch names,
> if you really really want -nocert, just push a patch to the
> signatureHandling branch that switches to it.
Done. I've also added a man page. If any further information
(In reply to Andre Guerreiro from comment #100)
> Created attachment 119283 [details] [review]
> Manpage improvement
Pushed
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
(In reply to Andre Guerreiro from comment #97)
> Quoting from ISO 32000-1 section 12.8.1:
> "This range should be the entire file, including the signature dictionary
> but excluding the signature value itself (the Contents entry). Other ranges
> may be used but since they do not check for all
I suggest we change the pdfsig "-c" switch to "-nocert". We can easily
add a single character option if we find it is needed. But we can't get
rid of it if we later regret it.
I'm still waiting for an answer to comment 79.
--
You received this bug notification because you are a member of Ubuntu
(In reply to Albert Astals Cid from comment #96)
> As said please let's not spend too much time on arguing over switch names,
> if you really really want -nocert, just push a patch to the
> signatureHandling branch that switches to it.
Done. I've also added a man page. If any further information
(In reply to Markus Kilås from comment #88)
> I found a workaround for my build issue by creating symlinks:
> /usr/include/nspr -> /usr/include/nspr4
> /usr/inclyde/nss -> /usr/include/nss3
Are you using configure or cmake? The nss pkgconfig file should contain
the correct include path.
--
You
What is the output of "pkg-config --cflags nss"?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1085526
Title:
ubuntu pdf doc viewer will not let me sign a document
To manage
What is the output of "pkg-config --cflags nss"?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
To manage notifications about this bug go
(In reply to Markus Kilås from comment #88)
> I found a workaround for my build issue by creating symlinks:
> /usr/include/nspr -> /usr/include/nspr4
> /usr/inclyde/nss -> /usr/include/nss3
Are you using configure or cmake? The nss pkgconfig file should contain
the correct include path.
--
You
(In reply to Albert Astals Cid from comment #82)
> Honestly i don't think spending much time on discussing the option name
> makes much sense, we just need to document it properly and that's it.
I raised this issue because pdfimages uses -j for jpeg but -png, -jp2,
-jbig2, -tiff, and -ccitt for
(In reply to Albert Astals Cid from comment #82)
> Honestly i don't think spending much time on discussing the option name
> makes much sense, we just need to document it properly and that's it.
I raised this issue because pdfimages uses -j for jpeg but -png, -jp2,
-jbig2, -tiff, and -ccitt for
(In reply to Martin McDowell from comment #8)
> It has been a year since a last post of this bug but I am still getting this
> problem in October 2015. I have Ubuntu 14.04. The PDF is viewed in the
> default Evince document viewer 3.10.3
The fix is in poppler 0.28 released in Nov 2014.
--
You
(In reply to Albert Astals Cid from comment #70)
> So we have two things missing, right?
> * Enabling the use of other keystores
> * The name of the pdfsigverify tool
>
>
> I think the enabling the use of other keystores is important but maybe not
> critical for the first release.
>
> For the
(In reply to Albert Astals Cid from comment #70)
> For the pdfsigverify it seems we kind of agreeed on the compromise to call
> it pdfsig that only does verification right now but in the future may
> suppport signing?
This is the only thing left that I think needs fixing before the initial
(In reply to Adam Reichold from comment #77)
> Some minor suggestions:
>
> * The naming of BLOCK_SIZE and block_len in hashSignedDataBlock seems
> misleading to me, maybe CHUNK_SIZE and block_len?
>
> * The method hashSignedDataBlock could probably be replaced by a static
> function taking the
(In reply to Albert Astals Cid from comment #74)
> (In reply to Adrian Johnson from comment #73)
> > (In reply to Albert Astals Cid from comment #72)
> > > > Large file support.
> > >
> > > Do you think this should be a blocker for the initial release
+ r_values[0] = r2.isInt64() ? r2.getInt64() : r2.getInt();
+ r_values[1] = r3.isInt64() ? r3.getInt64() : r3.getInt();
+ r_values[2] = r4.isInt64() ? r4.getInt64() : r4.getInt();
According the PDF Reference, the ByteRange array contains pairs of
(offset,length).
Why do we ignore the first
(In reply to Albert Astals Cid from comment #72)
> > Large file support.
>
> Do you think this should be a blocker for the initial release or something
> we can improve later?
I think it should be included.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs,
(In reply to Adam Reichold from comment #77)
> Some minor suggestions:
>
> * The naming of BLOCK_SIZE and block_len in hashSignedDataBlock seems
> misleading to me, maybe CHUNK_SIZE and block_len?
>
> * The method hashSignedDataBlock could probably be replaced by a static
> function taking the
(In reply to Albert Astals Cid from comment #70)
> For the pdfsigverify it seems we kind of agreeed on the compromise to call
> it pdfsig that only does verification right now but in the future may
> suppport signing?
This is the only thing left that I think needs fixing before the initial
+ r_values[0] = r2.isInt64() ? r2.getInt64() : r2.getInt();
+ r_values[1] = r3.isInt64() ? r3.getInt64() : r3.getInt();
+ r_values[2] = r4.isInt64() ? r4.getInt64() : r4.getInt();
According the PDF Reference, the ByteRange array contains pairs of
(offset,length).
Why do we ignore the first
(In reply to Albert Astals Cid from comment #74)
> (In reply to Adrian Johnson from comment #73)
> > (In reply to Albert Astals Cid from comment #72)
> > > > Large file support.
> > >
> > > Do you think this should be a blocker for the initial release
(In reply to Albert Astals Cid from comment #72)
> > Large file support.
>
> Do you think this should be a blocker for the initial release or something
> we can improve later?
I think it should be included.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs,
(In reply to Albert Astals Cid from comment #70)
> So we have two things missing, right?
> * Enabling the use of other keystores
> * The name of the pdfsigverify tool
>
>
> I think the enabling the use of other keystores is important but maybe not
> critical for the first release.
>
> For the
(In reply to Andre Guerreiro from comment #63)
> I also thought of adding the feature to pdfinfo but it seems wrong to mix up
> something which performs various computations and relies on external state
> (NSS cert DB) to pdfinfo which just reads metadata from the file itself.
pdfinfo already
(In reply to Andre Guerreiro from comment #63)
> I also thought of adding the feature to pdfinfo but it seems wrong to mix up
> something which performs various computations and relies on external state
> (NSS cert DB) to pdfinfo which just reads metadata from the file itself.
pdfinfo already
I don't think NSS should be mandatory. It is not required for rendering
PDFs. configure/cmake should include NSS in the "building poppler with
support for" summary.
> byte_range->arrayGet(1, );
> byte_range->arrayGet(2, );
> byte_range->arrayGet(3, );
>
> unsigned int signed_data_len =
I don't think NSS should be mandatory. It is not required for rendering
PDFs. configure/cmake should include NSS in the "building poppler with
support for" summary.
> byte_range->arrayGet(1, );
> byte_range->arrayGet(2, );
> byte_range->arrayGet(3, );
>
> unsigned int signed_data_len =
I'm not sure that removing this functionality is a good idea. Can't we
just add an option to findText to enable a looser search and leave it to
the front ends to decide if/how to expose this option.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
(In reply to comment #15)
Adrian, does the PostScript part looks good to you?
Looks good.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1242678
Title:
evince cannot render some
Yes, you can replace setpagedevice with pop. It is not clear to me how
your patch is doing this. Something like /setpagedevice { pop } bind
def should work.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
Pushed.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/1243484
Title:
Incorrect handling of orientation when printing PDF files
To manage notifications about this bug go to:
Created attachment 92877
0008 ensure there is always a valid page size in the output
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/1243484
Title:
Incorrect handling of
Albert,
Any update on the review/testing of these patches?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/1243484
Title:
Incorrect handling of orientation when printing PDF files
(In reply to comment #54)
Are the patches fixing pdftocairo the same way as pdftops so that the PS
output of pdftocairo has everything fixed which was fixed in pdftops?
See the following bug report
https://bugs.linuxfoundation.org/show_bug.cgi?id=1176
The rporter tells that all is OK
(In reply to comment #51)
Is it not possible to solve our problem without ABI change?
Unfortunately not. But you don't need all the patches to fix the bug you
reported. You can omit 0002 since DSC comments don't affect printing.
0004 can be omitted since that is a cleanup that doesn't affect
Created attachment 91314
0006 - pdftocairo fixes
Apply origpagesize and crop box changes to pdftocairo to ensure it works
the same way as pdftops.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
Created attachment 91315
0007 cairo clip to crop box
Another crop box fix for cairo.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/1243484
Title:
Incorrect handling of
Created attachment 91266
0002 - fix media DSC comments
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/1243484
Title:
Incorrect handling of orientation when printing PDF files
To
(In reply to comment #45)
Are you making the qt-ps-converters do the same too?
It should work. All the changes are internal to the PSOutputDev class. I
tried qt4-demo but it doesn't seem to have a print function.
--
You received this bug notification because you are a member of Ubuntu
Desktop
Carlos, could you review the patch.
I don't see the Syntax Error messages. Maybe it depends on the font.
What does pdffonts -subst show?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in Ubuntu.
Works for me with cairo 1.12. Looks like a cairo bug that has been
fixed.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/710137
Title:
evince badly mis-renders gradients in pdf
Testing setpagedevice on my printer it seems that if setpagedevice is
called after printing one side in duplex mode, the next page will not be
on the second side but instead start on a new sheet of paper.
If you want to call setpagedevice on each page to allow pages to be
reordered you could emit
Test2.pdf is a postscript file, not pdf. So it will be rendered by
ghostscript when viewed with evince.
The problem is caused by libreoffice. The gradient is actually a
series of shaded rectangles. In fact the rectangles are not even
correctly aligned. There is a tiny gap between each one. Cairo
Created attachment 57654
align fills
Here's an experimental patch for the cairo backend. It doesn't
completely solve the problem but it does eliminate the seams in some
cases.
Some test cases I tried it with:
I started looking at what it would take to implement javascript. The
problem is all the javascript in this pdf does is check the viewer
version and if 7.0 loads the XFA plugin. The pdf contains a stream
with 600KB of XML starting with template
xmlns=http://www.xfa.org/schema/xfa-template/2.1/;.
This is caused by a pixman bug:
https://bugs.freedesktop.org/show_bug.cgi?id=46277
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/588756
Title:
doesn't render the whole
Created attachment 56143
cairo - don't render text when text matrix is not invertable
The problem is the PDF file is using a noninvertible text matrix [0 0 0
0]. The PDF specification has this to say about noninvertible matrices:
When rendering graphics objects, it is sometimes necessary for
*** This bug has been marked as a duplicate of bug 44798 ***
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/878715
Title:
Contents of the page is not displayed while it is OK with
Can you provide the PDF to reproduce the problem. I expect the bug is
probably in the PDF file. Text in PDF files is glyphs, not characters.
Text extraction only works correctly if the PDF file provides the glyph
to unicode mapping.
--
You received this bug notification because you are a member
(In reply to comment #7)
A little more info, the HP M1522 is a PS Level 2 with PS Level 3 emulation.
Does this matter?
I don't think you are reading the specifications correctly. It is PS
Level 3 emulation which means it contains a non Adobe PostScript
interpreter that implements all the Level
In comment 12 I wrote:
The best solution would be to fix pdftops to use patterns for level 2 or
higher output.
I've now fixed poppler to use patterns instead of Type 3 fonts:
https://bugs.freedesktop.org/show_bug.cgi?id=40076
** Bug watch added: freedesktop.org Bugzilla #40076
The PDF does not contain a gradient. It contains a series 2 point high
filled rectangles designed to look like a gradient. Evince has trouble
with white seams showing between adjacent fills due to antialiasing.
The best solution would be if openoffice used a PDF gradient. The bug
where evince
The problem appears to be caused by pdftops writing tiling pattern
images as Type 3 fonts. I am assuming this was done to support level 1
PS. The PLRM section 4.9 (Patterns) states The ability to paint with
patterns is a feature of LanguageLevels 2 (tiling patterns) and 3
(shading patterns). With
I don't have Oneiric installed. However I did try:
pdf2ps firefox.pdf
ps2pdf firefox.ps output.pdf
and while it looks correct the text has been converted to bitmaps and as
a result is not selectable.
I also tried printing to PostScript from firefox and running ps2pdf. The
result appears to
Something I didn't think to ask before is to check that your printer has
PS error message printing enabled.
Looking at the Lexmark T644 menus and messages manual at:
http://www.lexmark.com/publications/pdfs/t640/eng/menumess.pdf
there is a setting under the PostScript menu for enabling the
gtk+ 2.20 and later provides a function for getting the printable area
of the page:
http://library.gnome.org/devel/gtk/stable/GtkPrinter.html#gtk-printer-
get-hard-margins
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
calendar.pdf works for me on all the printers I have.
- What sort of printer do you have?
- Do you have problems printing other PDF files?
- Have you tried any of the steps in comment 95. Attaching the PS file that
does not print with lpr -o raw would be helpful
- Is your printer configured to
If it is intermittent it is not this bug. I had intermittent problems
with printing to my LaserJet 4050 after upgrading to 10.10. It turned
out to be bug 229981 which I fixed by changing the connection type to
AppSocket/HP JetDirect.
--
You received this bug notification because you are a member
*** This bug is a duplicate of bug 680628 ***
https://bugs.launchpad.net/bugs/680628
Seems like it's not a cairo problem but a poppler problem then?
Yes, definitely a problem with the pdftops utility in poppler.
--
You received this bug notification because you are a member of Ubuntu
*** This bug is a duplicate of bug 680628 ***
https://bugs.launchpad.net/bugs/680628
This is not the same as bug 680628. Bug 680628 involves a very large
number of masked images. This bug is an very simple test case containing
some text. Comment 17 indicates that printing from any application
If there are still cases of cairo causing 0a errors I will need to see
the PDF file to fix. Looking back over the comments there were a few
comments saying they still had the 0a error after the update but none
of them supplied the PDF file that reproduces the problem.
--
You received this bug
I can reproduce the failure to print on my printer. The jpeg images are
being uncompressed then recompressed with Flate in the cairo PDF output.
Cairo 1.9.6 and Poppler git master contain a fix that embeds the
original jpeg in the output so the file size will not blow up.
With cairo and poppler
Probably not. It requires the cairo 1.9.6 development snapshot which
still has a number of regressions that need to be fixed before 1.10.0
can be released. Patching cairo 1.8.10 is not feasible due to the large
number of changes required.
--
Printing from evince (and perhaps other GTK apps) to
Could someone who can reproduce this bug test the attached files.
As a first attempt at fixing this bug in poppler I'm attaching a zip
containing two files (original.ps and modified.ps). original.ps has been
created by using gedit, saving to pdf, and runing pdftops -level3.
Printing this should
Are the upstream developers of Cairo also aware that the fix does not
solve the problem in all situations?
No. Probably because it is a different bug.
If you think you've found a cairo printing bug I suggest the following:
1. First show that the PDF fails to print when cairo is part of the
The can't select orientation in printing dialog bug has already been
fixed in git:
https://bugzilla.gnome.org/show_bug.cgi?id=591551
** Bug watch added: GNOME Bug Tracker #591551
https://bugzilla.gnome.org/show_bug.cgi?id=591551
--
Cannot select orientation in printing dialog
I'm unable to reproduce the upside down problem. What are you printing
to? Can you attach the output?
--
Printing multiple slides on one pages doesn't keep aspect ratio
https://bugs.launchpad.net/bugs/472400
You received this bug notification because you are a member of Ubuntu
Desktop Bugs,
The orientation can be changed in page setup (File-Page Setup).
--
Cannot select orientation in printing dialog
https://bugs.launchpad.net/bugs/480895
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evince in ubuntu.
--
desktop-bugs
It is a bug in ghostscript
http://bugs.ghostscript.com/show_bug.cgi?id=690823
** Bug watch added: Ghostscript (AFPL) Bugzilla #690823
http://bugs.ghostscript.com/show_bug.cgi?id=690823
--
Printing produces broken PDF
https://bugs.launchpad.net/bugs/443026
You received this bug notification
There was an mistake made when the commits were backported from master
to the 2.28 branch. Fixed in this commit:
http://git.gnome.org/cgit/evince/commit/?h=gnome-2-28id=7ff0dbcf7a396eea2de03de59b8259e72908158f
--
evince prints files scaled to portrait orientation, despite needing landscape
There's a couple of recent commits to evince that should fix the
landscape printing issues:
http://git.gnome.org/cgit/evince/commit/?h=gnome-2-28id=0f09dd9fc42af289d6015aa89b2aa5e26429c942
http://git.gnome.org/cgit/evince/commit/?h=gnome-2-28id=2fec784bbc737ef20b86a925bca92424eb5261d1
--
The low quality printing in your PDF is a different bug. This bug is
about Type 3 fonts being printed as a bitmap. The PDF you attached has
no Type 3 fonts.
The reason pages 1 and 4 of your PDF are printed as a bitmap are:
- Firefox is using cairo operators that are not natively supported by
PDF
Vincenzo Ciancia wrote:
I now have all the packages that are generated by the source package poppler,
version 0.10.3-0ubuntu1, and
recompiled intrepid's evince. I checked using ldd that evince is using the
new libraries. However, the problem is still
the same.
The fix is not in 0.10.x. You
92 matches
Mail list logo
