| Summary: | printer instance not visisble to non-kde-apps | ||
|---|---|---|---|
| Product: | [Unmaintained] kdeprint | Reporter: | arne anka <kde-bugs> |
| Component: | general | Assignee: | KDEPrint Devel Mailinglist <kde-print-devel> |
| Status: | CLOSED NOT A BUG | ||
| Severity: | normal | CC: | jlayt |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | differences between same file printed with opera directly and with opera through kprinter | ||
|
Description
arne anka
2005-09-27 10:08:05 UTC
Printer instances are CUPS-specific. If a non-KDE application does not show them in its built-in print dialog (I'm not talking about kprinter here), then it's not kdeprint's fault. OTOH, the other "nothing to print" problem is probably related to kdeprint. hm, the first part should thus be classified as "resolved wontfix". regarding the second part ("nothing to print") i was not sure whether it is kprinter related. should i file a new bugreport?
Can determine how Opera makes use of an external program to print: 1) piping the PS data to the program 2) calling the program with a temporary PS file Some useful options to test with kprinter: --stdin: makes kprinter read PS data from its standard input (piping) -c: kprinter makes a copy of the given file, useful to avoid that the calling application removes the file to print before kprinter has sent it to CUPS both work. is it a workaround or an acceptable solution? These are *solutions* in the sense that these options are specifically there to cope with the various possibilities: case 1: the calling app pipes the PS to kprinter; in that case, when using kprinter without any option, you shouldn't see the "Files" tab in the main dialog; if it's not the case, you can force it using --stdin option case 2: the calling app calls kprinter with a temporary file; in that case, you should see the "Files" tab in the main print dialog; however, the common problem is that the temporary file gets deleted by the client before kprinter sends it to CUPS (because the sending process takes place in another process); in that case, the -c option forces kprinter to make a copy of the file, solving that problem if using -c there's no "files" tab -- but it prints anyway. The -c flag shouldn't have an effect in this case, as it looks like data is coming from stdin. If it does not work without the "-c" flag, then there's something wrong in the kprinter logical and/or a problem with how Opera calls the external print program. Cristian: there's something to check here. My reading of the comment #4 was: "using either one of --stdin or -c makes printing from work". Michael reads it as "only using both --stdin or -c at the same time works". Arne, could you please specify? kprinter --stdin -> works kprinter -c -> works kprinter --stdin -c -> does not work all clarity obfuscated? Hmm... I can't reproduce this. Do: 1) echo "hello" | kprinter --stdin -c 2) choose "Print to File (PDF)" (or PS) 3) accept conversion of mimetype text and generally say "OK" to everything kprinter requests 4) an output like [ 1 pages * 1 copy ] left in /tmp/kde-ctibirna/kdeprint_XOAckVO7 [1] Wrote 1 pages, 450398 bytes should appear 5) visualize the ~/print.pdf or ~/print.ps file that you should by now obtain Does it contain the word "hello" ? Thanks > Does it contain the word "hello" ?
yes.
but in cooperation with opera it's not functional.
i get the progress-information of opera ("printing page X") and then it's over.
i suggest you install opera (it's free available) and test yourself -- would be nice to see if it's single issue on my computer or a general issue wirh opera and kprinter.
Side note: -c and --stdin shouldn't have effect on each other. They are part of 2 separate logical paths in the kprinter process. There's something strange here. Created attachment 12775 [details]
differences between same file printed with opera directly and with opera through kprinter
Very strange! See below. Arne? Did you manage to print anything with kprinter from opera? I mean, succesfully put it in a ps file or on paper? I tried: > --stdin alone, -c alone (both make kprinter dialog appear, without the "Files" tab, as expected), > no options at all, --stdin with -c and --stdin -c -o (for any combination kprinter doesn't even appear, nothing happens, which is weird, it more looks like kprinter is never launched...) What intrigues me is that loading this very simple file: <html><body>test</body></html> and trying to print it to a ps file with opera's own print-to-file option and, alternatively, with kprinter --c, I obtain two quite similar PS files, but the one obtained from kprinter is can't be parsed at all by ghostscript (plenty of errors) and it contains slight differences that I attach here above. I start to think there is something bogus in opera and I would invite you to report this bug (give the bugs.kde.org URL too if you want) to the opera team. Strange, indeed. When printing to PS file from kprinter, it actually does nothing, it just copy the incoming PS data to the given location. Something to try is to use a script like this as print program in opera: #!/bin/sh exec cat > /tmp/test.ps With this, you should be able to at least check the PS coming from Opera and see whether it's bogus. Michael. I tried that already. It doesn't do anything. No file created. Plus: http://list.opera.com/pipermail/opera-linux/2005-April/008882.html (it basically says it doesn't work with lpr either) Sorry, as long as the printing dialog in opera says that the printing program has to read stdin and 'cat > test.ps' doesn't do anything, I will have to consider that this is a bug in opera. Since the code is closed I can't even try to begin to look further, please notify opera developers. #14
> no options at all,
surprising -- with no option at least the kprinter dialog shows up.
no problem to file a bug-report -- but what should i say? atm i lost track of the issues _you're_ experiencing (my issue is solved by using --stdin _or_ -c :-).
the behaviour reported in the link in #16 did i never experience (although i use opera since 5.x continuously).
Yes, sorry. Without options, kprinter shows up but it shows it will try to print a temporary file called "%20" (which is the url encoding for a space, like " "). I think you should report to opera that 'cat > /tmp/test.ps' given as a printing program doesn't do anything. I'm surprised that you get correct ps files with 'kprinter --stdin'. Thanks a lot. Well, it doesn't suprise me that much. From all the discussions and test, it appears to me that there's a communication problem between Opera and the child print process. This has as result to mess up the STDIN detection mechanism of kprinter: if kprinter detects something on stdin, it assumes data coming from stdin, otherwise it assumes being called with a file to print; however it's not the case, so it ends up in a state where it should read from stdin, but its internal flags are not correctly set. When using the --stdin option, this bypasses the detection mechanism and set the flags correctly, resulting in a pritn success. At leats that's my interpretation. Michael. My surprise comes from the fact that Arne seems to print correctly with kprinter --stdin while I only get corrupted postscript (see the diff). following #19 it seems to be at least partially to be a kprinter issue? regarding #20: i stopped wondering a while ago -- the network-printers they got here are really weird, albeit supposed to understand postscript (oki 20something). I've got to say that I believe the right answer here is not to use printer instances; yes you can bodge it by forcing everything through kprinter, but it seems to me that CUPS is just too broken in the way it does instances. Closing old Resolved status bug. |