Version: (using KDE KDE 3.1.1) Installed from: Mandrake RPMs OS: Linux > Sure...but note that this 'faulty' PDF printed fine before the upgrade ;-) > > You are going to have to 'lead me by the nose' as I am not a programmer and > don't have any experience/depth with the print system. > > If you want the other Four 'problem one' let me know. Sorry for the long delay. I checked the PDF you sent me. I'm able to print it normally with kprinter, however kghostview is unable to view it (and print it). But this is a problem in kghostview (the KDE PS/PDF viewer) and not in kdeprint. You should report the problem to the application maintainer (see http://bugs.kde.org) Bye. Michael. -- ------------------------------------------------------------------ Michael Goffioul IMEC-DESICS-MIRA e-mail: goffioul@imec.be
Moved from Crash to normal as not displaying a PDF file is not a program crash. Also could you try that pdf file with the CVS head version of KGhostView (if not attach the files that are not displayed correctly)? The new version of KGhostView handles better PDF files.
Subject: Re: Some PDF files fail to print On Thursday 31 July 2003 02:03 pm, you wrote: > ------- Additional Comments From tsdgeos@terra.es 2003-07-31 20:03 ------- > Moved from Crash to normal as not displaying a PDF file is not a program crash. > Also could you try that pdf file with the CVS head version of KGhostView (if not > attach the files that are not displayed correctly)? The new version of KGhostView > handles better PDF files. I don't use CVS or beta, just release software. Sorry. The problem occurred when I upgraded from mandrake v9.0 to v9.1. ie. I didn't have a problem before. At least one of the files I had printed out before and I was printing it out again for someone else after the upgrade. Here are 4 files. They print fine under xpdf using kprinter. Regards...Martin Created an attachment (id=2120) diet.pdf Created an attachment (id=2121) HPRA.pdf Created an attachment (id=2122) kavanaugh.pdf Created an attachment (id=2123) talk.pdf Created an attachment (id=2124) ltsp-3.0-4-en.pdf
Strange, I am also running Mandrake 9.1 as my stable desktop and I can view all that files with KGhostView. You say you are not able to view them? Maybe you have KGhostview misconfigured, try going to the Configure KGhostview dialog, Ghostscript section and clicking the Configure button These are my versions $ rpm -q kdegraphics kdegraphics-3.1-9.1mdk $ rpm -q ghostscript ghostscript-7.05-53.2mdk
Subject: Re: Some PDF files fail to print On Thursday 31 July 2003 02:34 pm, you wrote: > ------- Additional Comments From tsdgeos@terra.es 2003-07-31 20:34 ------- > Strange, I am also running Mandrake 9.1 as my stable desktop and I can view all > that files with KGhostView. > > You say you are not able to view them? Maybe you have KGhostview misconfigured, No, that was the other guys (Michael) statement. I can view but but they hang when printing. This problem started following my upgrade from v9.0 to v9.1 in late May, early June and initially I hit several lists for advice to try and locate where the problem. Here is an earlier mail to Michael as he was the only person to respond. I'm not sure why he couldn't open them with KGhostview whereas I can. It seems like it may be an unusual and quirky problem. ---------------------------one of my original list mails with Michael's response > > > This was following an upgrade from Mandrake v9.0 to v9.1. > > > > > > With some help, I found they would print when using xPDF and kprinter. > > > > > > HP OfficeJet R40xi. > > > > > > kde 3.1.0 > > > > > > Anyone else seen this ? > > > > > > What other info do you need ? > > > > > > How do I track the problem down ? > > > > In which circumstances does the failure occur? Could you provide a > > sample of "faulty" PDF? > > > > Michael > > Sure...but note that this 'faulty' PDF printed fine before the upgrade ;-) > > You are going to have to 'lead me by the nose' as I am not a programmer and > don't have any experience/depth with the print system. > > If you want the other Four 'problem one' let me know. In which circumstances can't you print the file? I tried to view it with gv, it works. However it fails with kghostview. If your problem occurs within kghostview, then you should contact kghostview developer. Michael recently came back to me again, so I thought I had better follow-up to KGhostview, even though it is late. Also note, I have since upgraded to kde 3.1.2 (texstar RPM's) but the problem remains. > try going to the Configure KGhostview dialog, Ghostscript section and clicking the > Configure button > > These are my versions > > $ rpm -q kdegraphics > kdegraphics-3.1-9.1mdk > > $ rpm -q ghostscript > ghostscript-7.05-53.2mdk If I go to applications|publishing|Kghostview|settings|configure Kghostview select ghostscript then click configure, nothing happens. kdegraphics-3.1.2-3tex ghostscript-7.05-53.2mdk I'd be interested if you can print them. Sorry I am not more help. Spoonfeed me commands etc. and I'll try and get you all the info I can. Regards...Martin
I can print correctly both HPRA.pdf and kavanaugh.pdf using Mandrake 9.1 and KGhostView (won't try the others as they are too many pages, sorry), also i've looked a bit at the printing code of KGhostview and i think it basically calls kprinter to do the job. Are you sure the settings of the print dialog (printing system and such) are both the same when using xpdf and KGhostview.
Subject: Re: Some PDF files fail to print On Thursday 31 July 2003 03:37 pm, you wrote: > ------- Additional Comments From tsdgeos@terra.es 2003-07-31 21:37 ------- > I can print correctly both HPRA.pdf and kavanaugh.pdf using Mandrake 9.1 and > KGhostView (won't try the others as they are too many pages, sorry), also i've > looked a bit at the printing code of KGhostview and i think it basically calls kprinter > to do the job. > > Are you sure the settings of the print dialog (printing system and such) are both the > same when using xpdf and KGhostview. Let me check again. Ref the larger ones. Why don't you just try and print page 1 ? Regards...Martin
Subject: Re: Some PDF files fail to print On Thursday 31 July 2003 03:37 pm, you wrote: > > Are you sure the settings of the print dialog (printing system and such) are both the > same when using xpdf and KGhostview. Yes. What happens is that with Kghostview. it loads the paper then pauses, finally kicking out a blank piece of paper. With xpf and kprinter, it prints fine. Anything else I can check ? Regards...Martin
Can this be a duplicate of Bug 57976 which is also about being unable to print with Mandrake 9.1? Anyone else seeing problems with this files (outside mandrake 9.1)? BTW, i don't have a printer right now, so I can't test. luis
Some recent Astrophysical Journal PDF files fail to print from KGhostView. Other PDF files from the same site do print. By printing to a PostScript file and comparing, I've found the problem: $ diff print.ps noprint.ps 3,4c3,4 < %%BoundingBox: 0 0 569 758 < %%HiResBoundingBox: 0.000000 0.000000 568.300000 757.192017 --- > %%BoundingBox: 0 0 572 766 > %%HiResBoundingBox: 0.000000 0.000000 571.700000 765.200000 7c7 < %%CreationDate: 2004/03/22 11:36:19 --- > %%CreationDate: 2004/03/22 10:56:46 63c63 < 612 792 /letter setpagesize --- > 612 810 null setpagesize ... The file that does not print sets the page size to null whereas the one that does work it is /letter (correct for the US of course). I have edited the PostScript file changing the "null" to "/letter" and the resulting file now prints. A sample file that has shows the problem is at ftp://xanth.msfc.nasa.gov/pub/tennaaf/kde/57640.web.pdf I'm using the CUPS print system. Note, different printers handle this differently. An HP LaserJet 4000 flashes "Tray 1 load plain custom" and then prints on whatever you feed it. Whereas our Lanier printer sends the file to the bit bucket. So to confirm the bug you should print to a PostScript file and then "grep setpagesize". You only need to print the first page. (kpdf will print the file, but (currently) does a poor job at selecting fonts. xpdf displays and prints the file with no problems.) I'm adding this as a comment to 61922 since I downloaded diet.pdf and verified that I'm seeing "null setpagesize" in the PostScript output. I'm on a RedHat 9.0 running KDE 3.2.1.
This bug is still present in kde-3.2.2 (debian unstable, kghostview 0.20). The pagesize looks like "621 801 null setpagesize". But some pdf's are working (in my case pdf's containing only scanned documents). Our HP LaserJet 2200DTN just ignores these print jobs...
I have to correct myself: gs generates the "null setpagesize" entry. kghostview, gv and pdf2ps are generating the same output, so it is not a bug in kghostview (debian unstable, gs-gpl 8.01-4, gs-common 0.3.6)
I agree that Kghostview print to file and pdf2ps generate identical output. This fails with gs v7.05 (from RedHat 9), v7.07 (from Fedora 2) and v8.01 (compiled from source under Fedora 2). I've sent an email to bug-ghostscript@gnu.org
So far, I've heard nothing back from bug-ghostscript@gnu.org I reported the bug and a workaround to Redhat, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126446 For the benefit of people who don't track RedHat bug reports, here is the key information: The problem is in a loop in gdevpsu.c (in the ghostscript source tree) where it looks up the width and height in a table. If the current width and height don't *exactly* match a value in a table, then the code falls though the loop and generates the "null setpagesize" PostScript ("null" is the last entry in the table). I have no idea why anyone would think that the width and height always be found in the table for *all* files. So the real problem may be deeper... Below I show the context diff of a very simple (and very dirty) fix that I put in which works for us. If the code falls though the loop (without finding a match) I decrement the pointer, which causes p->size_name to point to "/letter" instead of "null". This is not really intended to be a general fix, but it works fine for us (in the USA) and clearly demostrates the nature of the problem. Allyn ---------------------------------------------------------------------- *** gdevpsu.orig 2003-01-16 18:49:01.000000000 -0600 --- gdevpsu.c 2004-06-03 15:31:44.024345004 -0500 *************** *** 273,278 **** --- 273,280 ---- while (p->size_name[0] == '/' && (p->width != width || p->height != height)) ++p; + /* If size_name is "null" then decrement pointer back to /letter */ + if ( p->size_name[0] == 'n' ) --p; pprintd2(s, "%d %d ", width, height); pprints1(s, "%s setpagesizen", p->size_name); }
The patch (and analysis) is incorrect. Some printers don't support setting the page using numeric values but a small set of special purpose operators. The table look-up checks whether there is a predefined page size operatot to set this page size. When there is no such operator, "null" indicates that the page size should be set using numeric method. The patch makes Ghostscript ignore the page size of the document and use US Letter size for any non-standard document. This is clearly wrong. Probably, most users would prefer to fit non-standard pages to the paper size. However, for the printers with expensive media, a PostScript error is preferable.
Can anyone confirm whether or not this bug is present in Okular?
No answer from reporter in a long time, closing down the bug. If you can provide the information we ask for please reopen the bug.