Bug 27452 - xpdf "print to pdf" instead prints to postscript, which crashes gv
Summary: xpdf "print to pdf" instead prints to postscript, which crashes gv
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends on:
Blocks: 27445
  Show dependency treegraph
 
Reported: 2020-10-19 20:12 CEST by w unruh
Modified: 2021-09-07 14:11 CEST (History)
0 users

See Also:
Source RPM: xpdf-4.02-1.2.mga7.src.rpm
CVE:
Status comment:


Attachments

Description w unruh 2020-10-19 20:12:25 CEST
Description of problem: I have a pdf file which I tried to print to pdf with xpdf. The file (print.pdf  -- the default name xpdf gave) is not pdf, it is a postscript file. Furthermore if I look at the file it is a postscript, not a pdf, file. 

If I move the file to print.ps, and run gv print.ps, then gv throws an error


Error: /undefined in ImData_44_0
Operand stack:
   false   96   2752   1344   160
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1992   1   3   %oparray_pop   1991   1   3   %oparray_pop   1979   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %sGPL Ghostscript 9.27: Unrecoverable error, exit code 1
topped_push   --nostringval--   rectfill   (NULL)   (gs_pattern1_instance_t)   (pattern accumulator)   5   %pattern_paint_finish   --nostringval--
Dictionary stack:
   --dict:726/1123(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--   --dict:67/75(L)--   --dict:726/1123(ro)(G)--   --dict:67/75(L)--   --dict:18/25(L)--   --dict:9/15(L)--   --dict:9/15(L)--   --dict:0/15(L)--
Current allocation mode is local
Last OS error: Resource temporarily unavailabl
"



Version-Release number of selected component (if applicable):
xpdf-4.02-1.2.mga7

How reproducible: Always on that particular pdf file
Here is the definition in the ps file created by xpdf:

1 array dup /ImData_44_0 exch def
dup 0 <~LkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3TzLkpkCz+sJ3Tz~> put
pop
false pdfSetup
595 842 pdfSetupPaper
end

And here is the first instance which I think is the one that throws thatfirst error.
....
  /PaintProc {
    pop
q
0 0 32 32 re
W
[32 0 0 32 0 0] cm
ImData_44_0 0
<<
  /ImageType 1
  /Width 32
  /Height 32
  /ImageMatrix [32 0 0 -32 0 32]
  /BitsPerComponent 1
  /Decode [1 0]
  /DataSource { pdfImStr }
>>
imagemask
pop pop
Q
  }




xpdf print to PDF should produce a pdf file, not a postscript file. 
xpdf should NOT produce an invalid postscript file. 
(Unfortunately that file is a file with personal and sensitive data in it, so 
I cannot include it here.)
Comment 1 Aurelien Oudelet 2020-10-19 20:34:06 CEST
Hi, thanks for reporting this.

Does this related to https://bugs.mageia.org/show_bug.cgi?id=27445 ?

This is really similar.
So the issue here is in xpdf.

Assigning to all packagers, as no registered one.
(Please set the status to 'assigned' if you are working on it)

Assignee: bugsquad => pkg-bugs
Source RPM: xpdf => xpdf-4.02-1.2.mga7.src.rpm
Keywords: (none) => Triaged

Comment 2 w unruh 2020-10-19 21:25:19 CEST
Yes, i came across this one while having the problem printing reported in 27445, but it is a problem with xpdf. It impacts printing from  xpdf since xpdf sends out a postscript file to the printer (instead of simply the original pdf file).
Aurelien Oudelet 2020-10-20 19:46:06 CEST

Blocks: (none) => 27445

Comment 3 Aurelien Oudelet 2020-10-20 19:48:27 CEST
(In reply to w unruh from comment #2)
> Yes, i came across this one while having the problem printing reported in
> 27445, but it is a problem with xpdf. It impacts printing from  xpdf since
> xpdf sends out a postscript file to the printer (instead of simply the
> original pdf file).


Workaround: use Okular from Plasma.

Adding recent commiters on this package.
(Please set the status to 'assigned' if you are working on it)
Comment 4 w unruh 2021-06-22 08:08:00 CEST
This seems to be independent of bug 27445. I am also not sure if this is still a problem with  on Mga8-- in fact it does not seem to be.
Comment 5 Aurelien Oudelet 2021-07-06 13:17:55 CEST
Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.
Comment 6 Marja Van Waes 2021-09-07 14:11:11 CEST
Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.