Summary: | XPDF crash with encrypted pdf | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | boozo <gagnmat> |
Component: | Current packages | Assignee: | Printing Team <printing> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | strace |
Description
boozo
2006-03-30 13:49:58 UTC
Step to reproduce: 1: pdftk 1.pdf output 1.128.pdf owner_pw foo user_pw baz 2: xpdf 1.128.pdf nb: nothing similar with kpdf or acroread (I've made some test with the binary and a source compiled version of xpdf-3.01-r7 without probem) Created attachment 83460 [details]
strace
*** Bug 128168 has been marked as a duplicate of this bug. *** so this bug is only in -r8 of xpdf? Can you please test a bit more and maybe provide a patch if you see the reason? :) (In reply to comment #4) > so this bug is only in -r8 of xpdf? > Can you please test a bit more and maybe provide a patch if you see the reason? > :) > same problem with the xpdf-3.01-r8 version and using the "nodrm" USEflag do not change anything for me I'll do my best to provide a patch if I found an issue ;-) ps: can you confirmed this bug ? >(I've made some test with the binary and a source compiled version of
xpdf-3.01-r7 without probem)
erf! I made a mistake... the pb is on : xpdf-3.01-r7 and -r8 version form portage
in fact, what I wanted to says : if I use the binary (-3.01pl2) version or compile it from the tarball (xpdf-3.01) of project's homepage everything is right
$ xpdf 1.128.pdf Error: Incorrect password $ xpdf -opw foo 1.128.pdf (works) looks perfectly good to me? Cany ouplease attach the failing pdf and give more info? Maybe it is a gcc-3.4 or a stable-x86 problem? Try upgrading poppler please (In reply to comment #7) > $ xpdf -opw foo 1.128.pdf thanks, it's good for me too... but, dialog box isn't used to ask the password from now on with poppler ? ...maybe the difference with kpdf ? |