Utlimate slow printing solution











up vote
4
down vote

favorite












I've been under ubuntu for nearly 10 years now, there are some problems that have thick skin! One of them, the slow printing delay problem, I never could solve! Today I start printing 20 copies of a 1 page pdf document, after half an hour nothing happened! I search for solutions on the net since years, but found any. I'm sure that it is not brand or model related problem, since I tested many printers from different brands, it seems that the raw file generated for the printer is very big, takes long time to be generated and to be transmitted to the printer.



I wonder if we could find some workarounds in this post, in cmdline, or at least, identify what's wrong, at which process it stucks, I know almost nothing in cmdline printing, can you please give some cmd lines to test and debug printing process.



Edit:



It seems that printing a single page one time give no delays, but if I try to print say, 20 copies of the same page, it seems that it's generating the whole 20 pages, thus giving a very long delay.



Edit 2:
Here is my debug info: http://pastebin.com/yZFgP66v



Edit 3:
Always after rebooting, the printing starts at boot process (I understand thus that it is a CPU issue!)










share|improve this question
























  • I personally haven't experienced this.
    – Android Dev
    Oct 22 '16 at 11:35










  • This seems like a CUPS issue not really Ubuntu.
    – LnxSlck
    Oct 22 '16 at 11:44










  • I agree with @LnxSlck
    – ubugnu
    Oct 22 '16 at 11:48















up vote
4
down vote

favorite












I've been under ubuntu for nearly 10 years now, there are some problems that have thick skin! One of them, the slow printing delay problem, I never could solve! Today I start printing 20 copies of a 1 page pdf document, after half an hour nothing happened! I search for solutions on the net since years, but found any. I'm sure that it is not brand or model related problem, since I tested many printers from different brands, it seems that the raw file generated for the printer is very big, takes long time to be generated and to be transmitted to the printer.



I wonder if we could find some workarounds in this post, in cmdline, or at least, identify what's wrong, at which process it stucks, I know almost nothing in cmdline printing, can you please give some cmd lines to test and debug printing process.



Edit:



It seems that printing a single page one time give no delays, but if I try to print say, 20 copies of the same page, it seems that it's generating the whole 20 pages, thus giving a very long delay.



Edit 2:
Here is my debug info: http://pastebin.com/yZFgP66v



Edit 3:
Always after rebooting, the printing starts at boot process (I understand thus that it is a CPU issue!)










share|improve this question
























  • I personally haven't experienced this.
    – Android Dev
    Oct 22 '16 at 11:35










  • This seems like a CUPS issue not really Ubuntu.
    – LnxSlck
    Oct 22 '16 at 11:44










  • I agree with @LnxSlck
    – ubugnu
    Oct 22 '16 at 11:48













up vote
4
down vote

favorite









up vote
4
down vote

favorite











I've been under ubuntu for nearly 10 years now, there are some problems that have thick skin! One of them, the slow printing delay problem, I never could solve! Today I start printing 20 copies of a 1 page pdf document, after half an hour nothing happened! I search for solutions on the net since years, but found any. I'm sure that it is not brand or model related problem, since I tested many printers from different brands, it seems that the raw file generated for the printer is very big, takes long time to be generated and to be transmitted to the printer.



I wonder if we could find some workarounds in this post, in cmdline, or at least, identify what's wrong, at which process it stucks, I know almost nothing in cmdline printing, can you please give some cmd lines to test and debug printing process.



Edit:



It seems that printing a single page one time give no delays, but if I try to print say, 20 copies of the same page, it seems that it's generating the whole 20 pages, thus giving a very long delay.



Edit 2:
Here is my debug info: http://pastebin.com/yZFgP66v



Edit 3:
Always after rebooting, the printing starts at boot process (I understand thus that it is a CPU issue!)










share|improve this question















I've been under ubuntu for nearly 10 years now, there are some problems that have thick skin! One of them, the slow printing delay problem, I never could solve! Today I start printing 20 copies of a 1 page pdf document, after half an hour nothing happened! I search for solutions on the net since years, but found any. I'm sure that it is not brand or model related problem, since I tested many printers from different brands, it seems that the raw file generated for the printer is very big, takes long time to be generated and to be transmitted to the printer.



I wonder if we could find some workarounds in this post, in cmdline, or at least, identify what's wrong, at which process it stucks, I know almost nothing in cmdline printing, can you please give some cmd lines to test and debug printing process.



Edit:



It seems that printing a single page one time give no delays, but if I try to print say, 20 copies of the same page, it seems that it's generating the whole 20 pages, thus giving a very long delay.



Edit 2:
Here is my debug info: http://pastebin.com/yZFgP66v



Edit 3:
Always after rebooting, the printing starts at boot process (I understand thus that it is a CPU issue!)







printing cups-lpd






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 31 '16 at 13:49

























asked Oct 22 '16 at 11:32









ubugnu

12627




12627












  • I personally haven't experienced this.
    – Android Dev
    Oct 22 '16 at 11:35










  • This seems like a CUPS issue not really Ubuntu.
    – LnxSlck
    Oct 22 '16 at 11:44










  • I agree with @LnxSlck
    – ubugnu
    Oct 22 '16 at 11:48


















  • I personally haven't experienced this.
    – Android Dev
    Oct 22 '16 at 11:35










  • This seems like a CUPS issue not really Ubuntu.
    – LnxSlck
    Oct 22 '16 at 11:44










  • I agree with @LnxSlck
    – ubugnu
    Oct 22 '16 at 11:48
















I personally haven't experienced this.
– Android Dev
Oct 22 '16 at 11:35




I personally haven't experienced this.
– Android Dev
Oct 22 '16 at 11:35












This seems like a CUPS issue not really Ubuntu.
– LnxSlck
Oct 22 '16 at 11:44




This seems like a CUPS issue not really Ubuntu.
– LnxSlck
Oct 22 '16 at 11:44












I agree with @LnxSlck
– ubugnu
Oct 22 '16 at 11:48




I agree with @LnxSlck
– ubugnu
Oct 22 '16 at 11:48










1 Answer
1






active

oldest

votes

















up vote
0
down vote













Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups



# /etc/init.d/cups restart


or for Ubuntu



$ sudo /etc/init.d/cupsys restart


then enter this command to view the log




tail -f /var/log/cups/error_log




With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.



Generally there are two data paths taken during a print job;



1) HPIJS driver path



2) Postscript driver path. Both data paths will use the "hp" backend.



For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.



For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.



Reference



If that doesn't work stop by our great Wiki page DebuggingPrintingProblems






share|improve this answer





















  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
    – ubugnu
    Oct 22 '16 at 12:22










  • Can you try and install/reinstall qpdf
    – LnxSlck
    Oct 22 '16 at 14:01










  • I got the same error
    – ubugnu
    Oct 22 '16 at 19:38










  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
    – ubugnu
    Oct 22 '16 at 19:49












  • It seems that pdftocairo work even better
    – ubugnu
    Oct 22 '16 at 20:19











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f840415%2futlimate-slow-printing-solution%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups



# /etc/init.d/cups restart


or for Ubuntu



$ sudo /etc/init.d/cupsys restart


then enter this command to view the log




tail -f /var/log/cups/error_log




With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.



Generally there are two data paths taken during a print job;



1) HPIJS driver path



2) Postscript driver path. Both data paths will use the "hp" backend.



For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.



For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.



Reference



If that doesn't work stop by our great Wiki page DebuggingPrintingProblems






share|improve this answer





















  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
    – ubugnu
    Oct 22 '16 at 12:22










  • Can you try and install/reinstall qpdf
    – LnxSlck
    Oct 22 '16 at 14:01










  • I got the same error
    – ubugnu
    Oct 22 '16 at 19:38










  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
    – ubugnu
    Oct 22 '16 at 19:49












  • It seems that pdftocairo work even better
    – ubugnu
    Oct 22 '16 at 20:19















up vote
0
down vote













Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups



# /etc/init.d/cups restart


or for Ubuntu



$ sudo /etc/init.d/cupsys restart


then enter this command to view the log




tail -f /var/log/cups/error_log




With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.



Generally there are two data paths taken during a print job;



1) HPIJS driver path



2) Postscript driver path. Both data paths will use the "hp" backend.



For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.



For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.



Reference



If that doesn't work stop by our great Wiki page DebuggingPrintingProblems






share|improve this answer





















  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
    – ubugnu
    Oct 22 '16 at 12:22










  • Can you try and install/reinstall qpdf
    – LnxSlck
    Oct 22 '16 at 14:01










  • I got the same error
    – ubugnu
    Oct 22 '16 at 19:38










  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
    – ubugnu
    Oct 22 '16 at 19:49












  • It seems that pdftocairo work even better
    – ubugnu
    Oct 22 '16 at 20:19













up vote
0
down vote










up vote
0
down vote









Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups



# /etc/init.d/cups restart


or for Ubuntu



$ sudo /etc/init.d/cupsys restart


then enter this command to view the log




tail -f /var/log/cups/error_log




With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.



Generally there are two data paths taken during a print job;



1) HPIJS driver path



2) Postscript driver path. Both data paths will use the "hp" backend.



For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.



For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.



Reference



If that doesn't work stop by our great Wiki page DebuggingPrintingProblems






share|improve this answer












Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups



# /etc/init.d/cups restart


or for Ubuntu



$ sudo /etc/init.d/cupsys restart


then enter this command to view the log




tail -f /var/log/cups/error_log




With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.



Generally there are two data paths taken during a print job;



1) HPIJS driver path



2) Postscript driver path. Both data paths will use the "hp" backend.



For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.



For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.



Reference



If that doesn't work stop by our great Wiki page DebuggingPrintingProblems







share|improve this answer












share|improve this answer



share|improve this answer










answered Oct 22 '16 at 11:49









LnxSlck

10.2k12949




10.2k12949












  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
    – ubugnu
    Oct 22 '16 at 12:22










  • Can you try and install/reinstall qpdf
    – LnxSlck
    Oct 22 '16 at 14:01










  • I got the same error
    – ubugnu
    Oct 22 '16 at 19:38










  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
    – ubugnu
    Oct 22 '16 at 19:49












  • It seems that pdftocairo work even better
    – ubugnu
    Oct 22 '16 at 20:19


















  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
    – ubugnu
    Oct 22 '16 at 12:22










  • Can you try and install/reinstall qpdf
    – LnxSlck
    Oct 22 '16 at 14:01










  • I got the same error
    – ubugnu
    Oct 22 '16 at 19:38










  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
    – ubugnu
    Oct 22 '16 at 19:49












  • It seems that pdftocairo work even better
    – ubugnu
    Oct 22 '16 at 20:19
















I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
– ubugnu
Oct 22 '16 at 12:22




I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
– ubugnu
Oct 22 '16 at 12:22












Can you try and install/reinstall qpdf
– LnxSlck
Oct 22 '16 at 14:01




Can you try and install/reinstall qpdf
– LnxSlck
Oct 22 '16 at 14:01












I got the same error
– ubugnu
Oct 22 '16 at 19:38




I got the same error
– ubugnu
Oct 22 '16 at 19:38












I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
– ubugnu
Oct 22 '16 at 19:49






I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages
– ubugnu
Oct 22 '16 at 19:49














It seems that pdftocairo work even better
– ubugnu
Oct 22 '16 at 20:19




It seems that pdftocairo work even better
– ubugnu
Oct 22 '16 at 20:19


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f840415%2futlimate-slow-printing-solution%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?