 |
| Photo credit: Wikipedia) |
Once great thing about Linux is that it's components work good together. Even when they don't, you can always use how they work together to get what you want, at least in some part.
My toddler was asking for a coloring picture for Elmo, the Sesame Street muppet. The official site at www.sesamestreet.org didn't have a picture so I went to the Sesame Street section on the PBS site at kids.pbs.org. Both of them were basically Flash programs. Not pages with Flash elements but a page with probably one big Flash element. There were linked to other pages with the same structure. I think this is sort of a workaround to getting Shockwave-like experience without actually using the memory drain that Shockwave is on Windows. There is no Shockwave for Linux for whatever reason.
Anyway, so I found what I was looking for and clicked on the Flash control to print the picture. A CUPS pop-up came up. Now here is another interesting component. Acquired by Apple, CUPS was the elixir that solved so many problems with printing over lpr for inkjet and non-Postscript, non-PCL printers. I credit CUPS and HPLIP to ending any printer setup and printing issues on Linux, essentially taking the drama away. Really smart on HP's part. By keeping old HP printers printing, means more ink cartridges being sold. And Linux guys keep thing running for a long time.
The thing about CUPS is that it prefers to work in the background. It lets the user facing part be handled by the OS. So when I clicked on the icon to print the picture, Mandriva popped up a different print dialog than I would normally get. This dialog did not offer the "print to file" option. I wasn't concerned initially because I wanted to print to my inkjet. But after clicking on the inkjet and Print, the printer did not print out Elmo. I suspected that there was a problem between the hand-off between Flash and CUPS/Mandriva. I looked at the print queue and there was large job just waiting.
My go-to strategy for jobs being stuck, which is usually a driver problem, is to use the print to file option. This would create a postscript output in a text file which I would convert to PDF. I would then print it again on a another PC in the house or somewhere else. Since postscript is a printer language and PDF is based on postscript, all of the kinks related to printing would have been worked out and the printer driver would just focus on printing an image basically.
But the dialog didn't offer me the print to file option. I looked on the Internet and discovered that there was a separate Print to File printer definition, called CUPS-PDF. It still used the postscript printer driver on the back-. It just deposited the resulting file on the Desktop. I installed the driver from urpmi and printed Elmo again. I checked on the Desktop and the file was there. Or what I thought it was. True enough, it was Elmo in a postscript format. I converted it to PDF and printed it in no time. Total fault to solution time: 10 minutes.
Upon further inspection, the file on the Desktop wasn't really finished. But it was enough for me to create the PDF and get what I want. It seems that the code in Flash to print the picture passed enough info to the printer driver to print the first page. But it didn't send the code to say that the document was done. It assumed that the printer driver would just take the end-of-page marker and send it off to the printer. But CUPS being a good print system dutifully waited for the end-of-document marker in vain.
So not all things in Linux work well together. But even when they don't, Linux stuff offers other ways of getting what you want. And that is all I need.
My go-to strategy for jobs being stuck, which is usually a driver problem, is to use the print to file option. This would create a postscript output in a text file which I would convert to PDF. I would then print it again on a another PC in the house or somewhere else. Since postscript is a printer language and PDF is based on postscript, all of the kinks related to printing would have been worked out and the printer driver would just focus on printing an image basically.
But the dialog didn't offer me the print to file option. I looked on the Internet and discovered that there was a separate Print to File printer definition, called CUPS-PDF. It still used the postscript printer driver on the back-. It just deposited the resulting file on the Desktop. I installed the driver from urpmi and printed Elmo again. I checked on the Desktop and the file was there. Or what I thought it was. True enough, it was Elmo in a postscript format. I converted it to PDF and printed it in no time. Total fault to solution time: 10 minutes.
Upon further inspection, the file on the Desktop wasn't really finished. But it was enough for me to create the PDF and get what I want. It seems that the code in Flash to print the picture passed enough info to the printer driver to print the first page. But it didn't send the code to say that the document was done. It assumed that the printer driver would just take the end-of-page marker and send it off to the printer. But CUPS being a good print system dutifully waited for the end-of-document marker in vain.
So not all things in Linux work well together. But even when they don't, Linux stuff offers other ways of getting what you want. And that is all I need.
