Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
Moving to PDF as a future print job spooling format
Share
Print
CommentsThis switch was agreed upon at last week's Linux Desktop Printing Summit. Open Source Development Labs (OSDL) and Linuxprinting.org organized the meeting, which was hosted by Lanier (a Ricoh corporation) at its Lanier Education Center in Atlanta.
At the meeting there was virtually no disagreement about the change. The fine details will have to be thrashed out over the coming months, but representatives from CUPS, Ghostscript, Linuxprinting.org, KDE, GNOME, hardware vendors (present were people from Epson, HP, IBM, Lanier, Lexmark, Ricoh, Sharp, and Xerox), and developers of free drivers all agreed that PDF will give them more power, more reliability, and more control over the printing process.
Why is this? After all, isn't PDF a (partially) binary format? Isn't there a disadvantage with PDF compared to PostScript, which you can open and modify with a standard text editor? As it turns out, PDF has much to recommend it.
The professional and commercial digital printing world has moved to PDF already. More and more printer models are able to consume and interpret PDF files directly. A number of international industry standards, such as PDF/X3, PDF/A, and others, make PDF processing more reliable.
We see a number of efforts underway to establish a standard way to embed "job tickets" into an actual print file. Job tickets carry the exact print settings the user asked for and are read -- and hopefully honored -- by all job processing programs, including the ones at the destination printer.
It makes a lot of sense to go into the same direction for Linux printing.
PDF, as a specification, is owned by Adobe, which developed it based on PostScript, which Adobe also owns. Like PostScript, PDF is an open and fully documented file format. PDF is not patent-encumbered; while Adobe owns a few PDF-related patents, it has guaranteed royalty-free usage of the PDF specifications to anybody, including the freedom to implement the standards for PDF generating and PDF consuming software to everyone who uses the specs.
PDF is better suited as a page description format than PostScript on various fronts. It supports transparencies and color profiles in an advanced way that PostScript can't compete with. PDF is now universally accepted as one of the best document exchange formats, even for non-printing purposes, and it is far better than PostScript for online publication and viewing. PostScript also has some known cumbersome aspects to it when it comes to printing, which are easier to solve with PDF.
Though many people are not aware of it, PostScript is a fully-fledged programming language, which means PostScript could be used with malicious code embedded in PostScript files, and it can cause incompatibilities, failures, and undesired output more often than printing professionals would like. PostScript files also are not easy to lay out as "n-up" or "book" signatures unless they meet the strict Document Structuring Conventions.
While PDF is derived from PostScript and its imaging model, its page description code cannot contain malicious pieces. In the original PDF file format specification the page description constructs no longer make up a fully-fledged programming language. The problematic PostScript instructions were removed from PDF 1.0, though some new "weird" capabilities were added by Adobe in later versions -- such as the ability to embed multimedia files or attach other document formats, which in turn necessitated the creation of industry standards such as PDF/X3 and PDF/A that prohibit usage of such extensions for digital printfiles and prepress purposes.
PDF lends itself more readily to imposition processing, file merging, page extraction, and other manipulations that may be appropriate for a print file format. Font problems which are present in PostScript are less frequent with PDF, and more easy to solve if they occur.
In addition, PDF files tend to be smaller than equivalent PostScript files thanks to the format's built-in compression. Searching for text strings, and copying and pasting them to other files, is almost impossible in PostScript, but easy in PDF. To use PostScript for Internet publishing in general is not a good idea, but PDF already has a major presence on the World Wide Web.
PDF, by default, enables direct random access to every page inside a file; PostScript files require linear processing of the first N pages before page N+1 can be displayed, and often it is impossible to go back to page N-1 once you see page N in a viewer.
Existing PDF support in Linux
While we're looking at a change of direction, it's not as if the summit's decision forces us to move into a completely new and unexplored field.
CUPS is already "PDF-ready" in a basic sense. Though there is not yet any job ticketing or overwhelming color profile support, CUPS does automatically process PDF files thrown at it. Its internal MIME-typing and filtering system auto-detects the format and converts it into any filetype the target printer may desire. A spooling system running CUPS being used as a pre-processor and PDF interpreter turns every inkjet, deskjet, impact, label, or laser printer into one that is ready for use in a PDF-only environment.
Ghostscript is PDF-ready in an even broader sense. It works in both directions -- converting into as well as converting from PDF. Since Ghostscript can convert PDF into PostScript it can act as stepping stone to further convert into other output formats, such as PCL3, PNM, JPEG, PNG, BMP, or display raster.
Even the venerable gv viewer is able to display PDF; it calls Ghostscript internally for the rendering into the on-screen format. It can also create PDF files with the help of its -sDEVICE=pdfwrite parameter. The pdfwrite device is rather sophisticated, albeit hard to handle on the command line, like all of Ghostscript. It accepts setdistillerparams commands, can produce PDF 1.4 output, is able to honor embedded pdfmark operators that may come within the to-be-processed PostScript input, can handle color profiles, can change various bitmap resolution settings, can embed fonts completely or subsets thereof, can downsample black and white or color images, and much more.
Easy-to-use wrapper scripts for Ghostscript such as ps2pdf convert PostScript files into PDF. Ghostscript can even convert multiple PS files into one single merged PDF document. Recent versions of AFPL Ghostscript have added basic support for PDF/X3 output and processing of embedded color profiles. Support for DeviceN color spaces has been a welcome improvement in the 8.5x series of Ghostscript.
And we have the luxury of another good, free PDF processing application: Xpdf. The CUPS pdftops filter is derived from it; the Poppler library project is forked from Xpdf and improved by a group of desktop environment developers at Freedesktop.org.
OpenOffice.org has a reliable PDF exporting function. KDEPrint has been able to print to PDF for five years, functioning as a virtual printer that writes any document as a PDF file to disk.
KWord can even import PDF files and edit them. Scribus has a world-class and standard-compliant PDF export capability. PDF files generated by Scribus pass even the most sophisticated professional prepress checks.
KPDF, a top-notch PDF viewer, replaces Adobe Acrobat Reader for most KDE users. KPDF may be missing a few features required by prepress professionals -- such as displaying layers in PDF-1.6, handling transparencies well, the ability to add notes, and JavaScript scripting support -- but Kpdf development is still in full swing.
More importantly, both KDE and GNOME are about to gain good PDF-writing back ends, which will be different from current virtual printers that "write to PDF" by converting PostScript input. The new back ends will work by writing to PDF directly, without a detour via a temporary PostScript file, with the help of their low-level libraries. This will enable all apps to export directly to PDF. GNOME will get it with its switch to the Cairo graphics libraries; KDE4 will be founded on Qt-4.2 or later, which contains an excellent PDF-writing back end via a component called Arthur.
What needs to be done
Of course, the FOSS software stack for handling PDF is far from complete, but summit participants hope that the pro-PDF message coming from the Desktop Linux Printing Summit will inspire more activity in this area by application developers. Soon we may see new Linux-based professional PDF utilities, such as pre-flight checkers, imposition software, and PDF file manipulating tools, either free or commercial. Yes, we already have the PDF Toolkit (pdftk), but some people think pdftk is too resource-intensive, and do not like it because it depends heavily on Java.
Overall, the move to PDF will guarantee that Linux will be taken more seriously in the printing industry. After all, representatives from seven printer vendors were already participating in the summit, and even more gave their apologies for not being able to make it.
There is still one thing that the open source community should be asking Adobe: When will it start to support its full product range on Linux? Adobe provides only Acrobat Reader 7 on Linux -- nothing else from its rich set of other applications. Adobe is in danger of losing out on several fronts: Microsoft is trying to crash PDF support in the market by pushing to get its own XML Paper Specification (XPS) format, formerly known as "Metro," accepted, while the free software community is about to bypass Adobe's unattractive Reader with its own software. Due to Adobe's long delay with Acrobat Reader, the free software community has come up with KPDF, oKular, and Evince.
Comments
on Moving to PDF as a future print job spooling formatNote: Comments are owned by the poster. We are not responsible for their content.
Now you suggest using PDF as the intermediate format instead of Postscript further adding to the madness. But, I look around at the more than 50 printers within view and I don't see a single one that speaks PDF! The vast majority of them speak PCL and a few speak Postscript as well as PCL but, none speak PDF. Why on earth would you choose a format that is completely unsupported by any printer? Why not, instead, implement a supported printer language that can eliminate some of the conversions presently required to print a simple page? We already have a few languages that are supported by the printer manufacturers, Linux needs to use those languages and PDF is not one of them. Besides everything else, Ghostscript is a crappy PDF implementation!
Why must Linux continue to be a mutant fish swimming upstream?
Try <tt>less<nobr> <wbr></nobr>/var/log/cups/error_log</tt> on your machine to see what a mess printing is, even if it isn't giving you trouble. The fact that scanners are also a mess does not negate the fact that CUPS is problematic.
Finally, how many of the printers that you listed support PDF directly? How many support PCL? Can you find a printer that supports PDF directly?
Would you really prefer the Linux print system be reworked to support PDF or would you not prefer PCL? Finally, would you not rather leave it at Postscript and fix CUPS?
-Computer:~] dad%cat<nobr> <wbr></nobr>/var/log/cups/error_log
<nobr> <wbr></nobr>/PrintJobMgr/Contents/MacOS/PrintJobMgr (PID 3955) for job 415.
I [15/Apr/2006:13:32:35 -0400] Adding start banner page "none" to job 416.
I [15/Apr/2006:13:32:35 -0400] Job 416 queued on 'deskjet_5550' by 'mel'.
I [15/Apr/2006:13:32:35 -0400] Started filter<nobr> <wbr></nobr>/System/Library/Printers/Libraries/PrintJobMgr/Co<nobr>n<wbr></nobr> tents/MacOS/PrintJobMgr (PID 4617) for job 416.
I [15/Apr/2006:13:41:51 -0400] Adding start banner page "none" to job 417.
Doesn't look like a mess to me. As I posted before the printing systems are almost identical. As you can see:
s-Computer:~] dad% which lpr
<nobr> <wbr></nobr>/usr/bin/lpr
No, switching to PDF will not fix these problems - better integration and testing by distributions will, however. The switch to PDF will solve a different set of problems and allow us to migrate to a *simpler* filter chain that produces higher quality output and is less prone to errors.
As for "PCL" being a common printer language, life is not so simple - "PCL" refers to any of over 2 dozen different language variants that are in common use, and most inkjet and impact printers do not understand it. It isn't suitable for use as a general print file format...
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.c<nobr>o<wbr></nobr> m] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/pa<nobr>i<wbr></nobr> nrelief.htm] Nerve pain relief [/URL]</tt>
----
I'm sorry to hear about your printing griefs. But I can't help you if you only point to other people having issues. Nor can someone else. You need to specifically describe where and when your own printing mis-behaviour occurs. Otherwise you just look like someone liking to troll...<nobr> <wbr></nobr>:-)
I've also followed your link. But this, on its first page lists only 10 postings of people with problems; the newest of these was written 17 months ago, the oldest nearly four and a half years ago. Given that there are several millions of people using CUPS, I conclude that this link hardly proofs what you are trying to proof<nobr> <wbr></nobr>:-)
However, there are still many people encountering problems using CUPS. The right place to see them dealt with (even very current ones), to report them yourself, and politely seek help, is in the <a href="http://www.cups.org/" title="cups.org">CUPS.org</a cups.org> web <a href="http://www.cups.org/newsgroups.php" title="cups.org">forums</a cups.org>, not here.
Try <tt>less<nobr> <wbr></nobr>/var/log/cups/error_log</tt> on your machine to see what a mess printing is, even if it isn't giving you trouble.
----
I did it. I can't see what you mean. Can you be more specific? Or was really just trolling this time?
Would you really prefer the Linux print system be reworked to support PDF?
----
Oh yes, I do for sure!
Your arrogance is incomprehensible! No one asked for your help!
He provided a link to 156,000 articles describing problems with CUPS as supporting evidence to his assertion that CUPS was a mess. Far more supporting evidence than you offered. Furthermore, the fact that you chose to look only at the first page does not negate the existence or relevance of the remaining 156,000 listed postings.
I did it. I can't see what you mean. Can you be more specific? Or was really just trolling this time?
It seems that you are the one that is trolling!
He provided a link to 156,000 articles describing problems with CUPS
I can do something similar for Windows:
<a href="http://groups.google.com/groups/search?q=%22printing%22+%22problems%22+%22windows%22&qt_s=Search" title="google.com">http://groups.google.com/groups/search?q=%22print<nobr>i<wbr></nobr> ng%22+%22problems%22+%22windows%22&qt_s=Search</a google.com>
This returns 194,000 results. Your point is? Variations in printing in different environments, with different drivers and printers is a problem on any platform. Has nothing to do with CUPS.
Oh my. You must be new to this whole Google thing. You get 200,000 hits for ANYTHING you search for! Try this URL: <a href="http://www.google.com/search?hl=en&lr=&safe=off&q=problem+with+anonymous+trolls&btnG=Search" title="google.com">http://www.google.com/search?hl=en&lr=&safe=off&q<nobr>=<wbr></nobr> problem+with+anonymous+trolls&btnG=Search</a google.com> (3,600,000 hits)
I fail to see any arrogance in his words, even if no one asked for his help.
--> "He provided a link to 156,000 articles describing problems with CUPS"
Hmmm... so you trust these Google figures? OK, I'll provide you an as valid link (but to 6,630,000 articles) supporting evidence to my assertion that CUPS is about perfect: <a href="http://www.google.com/search?q=no+problem+with+perfect+cups+printing&ie=UTF-8&oe=UTF-8" title="google.com">"no problem with perfect CUPS printing"</a google.com>. Far more supporting evidence than you offered.
Find the flaw in my "evidence", and you found the flaw in yours too<nobr> <wbr></nobr>;-)
The hint of grandparent still is valid: if you have problems, name them. The right place to report them are the CUPS.org user forums. What you do here is frequently called <a href="http://en.wikipedia.org/wiki/Internet_troll" title="wikipedia.org">"trolling"</a wikipedia.org> elsewhere...
Better now?
would you not rather leave it at Postscript and fix CUPS?
I don't consider a PDF based printing backend and an improved CUPS to be mutually exclusive.
Let's take a look at PDF again:
PDF is one of the prefered document interexcange formats.
Most programs that are interested in printing are also able to produce PDF files, and you can get virtual printer drivers that produce PDFs, meaning that it is generally easy to produce PDFs.
Many printers, especially the more professional ones, can read PDF directly, and if not, their driver or the printing subsystem could convert it as has been done with PostScript; the printer down the hall here even has a build in webserver that allows me to upload PDF files and have the printed that way.
PDF is as mentioned in the article, a safe exchange format.
PDF is a better format for print than PostScript.
So PDF can generally be considered superior to PostScript, and if PostScript were to be replaced, PDF would be a good candidate.
But is it worth it to rip out PostScript from the printing subsystems and replace it with PDF?
Well, you mention that CUPS is a mess, but could it be that retrofitting it with PDF could provoke the amount refactoring that would make CUPS streamlined?
If we consider that the printers talk PDF natively, and the user space applications talk PDF natively, wouldn't it make everything cleaner if the printing subsystem also talked PDF natively?
The risc of bugs are generally lower with a clean architecture, and also consider that whenever you convert data from one format to another, a dataloss is generally to be expected and keeping everything in PDF will prevent this too.
So all in all, PDF has my backing.
The first page is all over a year old, and there are five in the next three pages that are under a year. One of them was a problem with Samba, not cups.
Hear! hear!
IMHO, CUPS is an atrocity. The end-user configuration is nearly impossible to comprehend. There's no explanation in the config tools to help explain what the various options are even for so you have little to no clue which one too choose.
I have a workstation which I successfully (after taking way too much time, BTW; driver issue mainly) got a locally-connected photo printer to work. Then it was time to configure a connection to the B/W laser printer downstairs which was to be the default printer for this system. The CUPS configuration tool couldn't seem to comprehend such a setup. It was almost as though, having set up the first printer, CUPS was of the attitude "How many printers do you need, pal?" Nevertheless, I decide to add another printer and am faced with the question "Do I want to create a new queue?" Seemed reasonable to me. Until following that path eventually resulted in an announcement that this would blow away existing printer configurations. Trying a different tack, I was presented with a radio-button menu of a dozen or so different printer communication protocols that I should select from. Hardly user-friendly even to someone like myself that's been setting up network printers on UNIX systems for the better part of twenty years.
I have to agree with you, the CUPS project needs (and badly) to clean up their software to make it easier to use before jumping on to the next "gee whiz this is cool and fun to work on" glitzy feature that leave most users wondering why they still can't get a printer set up on their Linux network. But, instead of fixing this glaring deficiency in CUPS, the developers and their fans get all defensive and fire back that you should RTFM. Now that not a bad idea if, of course, there was an FM to read that actually helped. Since the major distributions are adopting CUPS as the standard printing system -- to the extent that they've largely omitted LPD and LPRng off their CDs and if they're still present, they clash with other tools that have been made dependent on CUPS -- this junk has got to be made to work more smoothly. And it's got to be configurable by someone who doesn't have CVS check-in access to the CUPS project.
And PDF as a printer format? Yah. That'll work just ducky. Imagine all the filters that are going to have to work perfectly in conjunction with one another for this to produce uncorrupted output. (I especially like the fact the CUPS insists on passing Postscript through some sort of PS-to-PS filter before printing to a printer that accepts Psotscript natively. The need for that filter isn't in any CUPS documentation that I've run across.)
"...myself that's been setting up network printers on UNIX systems for the better part of twenty years."
Makes me really wonder how you did that, if you are even confused by a selection of network protocols... If you had said that you came from a Windows background, I'd sympathize with you and even understand you complaining...
But a dyed-in-the-wool Unix stalemate of 20 years standing?!? C'mon!
###
"CUPS insists on passing Postscript through some sort of PS-to-PS filter"
Your application usually doesn't know about the device-specific printer options, and sends "device-independent" PostScript. (It would print, single-sided, loose-collection-of-sheets).
Some applications do even generated buggy PostScript, which does not print on every device.
If the device is expected to duplex, staple, fold, punch, use different paper for front and back covers, or deliver the output to a certain sorter bin, the commands to make the device do that need to be inserted into the PostScript job, making the file a "device dependent" one. (Different PS printers use different commands to do the same thing, such as tray selection, etc).
The pstops filter does both: sanitize and normalize buggy PostScript as good as it can. And insert device specific commands into the original PostScript, according to the targetted ouput device...
That filter does even more: assume you have a 40 page document, but you only want pages 5,11-16 and 34 printed -- pstops extracts those. Or it puts to logical pages on one sheet of paper, if you want this.
And in case the output target is a non-PS device: the downstream PS-to-something filter needs a normalized PS too...
Feeling better now?
###
"The need for that filter isn't in any CUPS documentation that I've run across.)"
Honestly, you do not sound like you've run across much documentation in your 20 years of Unix, CUPS or not, and you do not sound like you're much interested either. I suspect my effort is likely to be very much in vain...
But have a look for instance here:
--> <a href="http://localhost:631/documentation.html" title="localhost">http://localhost:631/documentation.html</a localhost> (on any system that has CUPS installed...)
--> <a href="http://www.cups.org/cups-help.html" title="cups.org">http://www.cups.org/cups-help.html</a cups.org>
--> <a href="http://localhost:631/sum.html" title="localhost">http://localhost:631/sum.html</a localhost> (on any system that has CUPS installed...)
--> <a href="http://localhost:631/sam.html" title="localhost">http://localhost:631/sam.html</a localhost> (on any system that has CUPS installed...)
--> <a href="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html#id2603263" title="samba.org">http://www.samba.org/samba/docs/man/Samba-HOWTO-C<nobr>o<wbr></nobr> llection/CUPS-printing.html#id2603263</a samba.org>
Methinks the grandparent poster is on the mark and you sound like one of those defensive folks he was writing about. I hate to resort to fisking but here goes:
"Makes me really wonder how you did that, if you are even confused by a selection of network protocols<nobr> <wbr></nobr>..."
I, too, have wondered what the heck the proper selection of protocol options is when configuring CUPS. You can have a printer attached to another system, know exactly how you'd normally configure the printcap entry to send jobs to that printer and find yourself trying things at random in the CUPS config programs, never sure where the next dead end is going to appear. I've worked on collections network printers ranging from small workgroups to large systems with a few hundred print queues sending jobs to remote printers. Those were far easier than working with CUPS.
"dyed-in-the-wool Unix stalemate"
Heh, I hope you meant "stalwart".
"assume you have a 40 page document, but you only want pages 5,11-16 and 34 printed"
Most users I know would prefer to merely pull the PostScript file into gvv and select the pages to be printed. Not wrestle with printer driver switches.
"--> <a href="http://localhost:631/documentation.html" title="localhost">http://localhost:631/documentation.html</a localhost> (on any system that has CUPS installed...)"
You mean that self-serving piece of crud? I especially love the "The Printing Problem" Yes, for years UNIX was "plagued" by having two disparate printing systems. It was awful that these two printing systems, um, actually worked. Thank goodness the CUPS project came along to save the day. Give us a break.
CUPS was a solution to a problem that the vast, vast majority of UNIX and Linux users do not have. How many people actually own or have the opportunity to even use some huge printer that does all your book creation for you that the CUPS advocates are so quick to use as an example. Most of us are dealing with desktop printers or modest departmental devices. I suspect that most of us users don't get very excited about and couldn't care less about printers that fold, sort, and staple our documents. If CUPS is what we have to deal with, we'd sure like some documentation with some meaningful examples showing how to configure CUPS to solve the most common problems. As of now, their documentation doesn't even come close to providing anything like that. Maybe someday, eh?
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr> pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr> ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr> es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr> lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr> nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr> ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr> -Pain-Relief.html] Natural pain relief [/URL]
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
Simply accusing anyone who doesn't agree with CUPS flawed methodology of being incappable and unexperienced.
I myself have been working as a systems admin for major fortune 500 companies for 20 years now and I have to say that trying to configure CUPS is like finding a black bag in a dark room with the lights off.
E.g. I have been googling the web in vain so far trying to get a decent/any explanation for the settings in the cups-config file.
And those flimsy man pages are no FM!
20 years later and Linux is still a geek operating system with lofty promises and configuration nightmares like CUPS.
You can rant about Windoze all you want, but there I can set up any printer in under 60 seconds - with no need to read any FM!
With CUPS I can't even get through the flimsy man pages in that time, much less figure out all the options to be specified.
Let's have some cites please! Hewlett Packard, arguably one of the world's largest printer manufacturers, sells more than 50 different printer models. Of all those printers, only the DesignJet series has direct PDF support. Epson offers none. Xerox offers none.
We're not talking about the ability to print PDF files through a driver that converts it to PCL, they can all do that, we're talking about the printer being able to directly interpret the PDF format.
so if they/we are ahead of the curve we'll have it made with the manufactures catch up.
Are you really so delusional as to think that Linux will make manufacturers follow?
Ricoh printers do support PDF direct printing
Posted by: Anonymous Coward on April 20, 2006 11:29 PM-----
Yesterday I send PDF to a Xerox which does exactly that: consume PDF.
You better research your facts....
<nobr> <wbr></nobr>...and use CUPS and PDF instead. Oh wait...
1) Application converts from its own format to Postscript;
2) Printing system converts from Postscript to the printer language (or massages the Postscript according to the printer's requirement);
It the printer understands the same Postscript level as produced by the application, step 2) may not be necessary at all.
This doesn't look complicated at all... And all the problems related to printing in Linux are usually in the applications themselves.
If you set up a print server using CUPS, for instance, you will see that printing in Linux is actually quite capable (and efficient, and non problematic). You can have a bunch of printers connected to it and use CUPS' filtering to make them all appear to understand the same language. This makes client management _A_LOT_ more efficient (only one driver to maintain on them).
Some (not most) printers speak PCL (various versions), others speak PostScript (various levels), others speak RPCS (Ricoh), and others speak a variety of languages specific to the model or manufacturer (ESC/P, HPGL, etc.), or even a combination of languages (or no language at all - many home inkjet printers). The point is PDF seems to be the future, with the professional printing business already commited to it and home/office printers starting to have support for it, and looks like a better "unification" language.
So, why not? The Postscript advantage right now is the availability of client drivers bundled with every OS, but that can happen with PDF too (and isn't that important, provided drivers exist, have good quality and are fairly simple to install and configure).
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]
Does pdftk offer the same capabilities? Any scripts available?
For example, here are some nice scripts for psutils:
<a href="http://wiki.scribus.net/index.php/How_to_make_impositions_with_pstops" title="scribus.net">http://wiki.scribus.net/index.php/How_to_make_imp<nobr>o<wbr></nobr> sitions_with_pstops</a scribus.net>
----
Yes, I know. But I want something even better.
Does pdftk offer the same capabilities?
----
You can look it up yourself on their website. The author thankfully provided a working link in his article, despite even mildly criticizing pdftk. Did you read the article at all?<nobr> <wbr></nobr>:-)
Write it yourself. So you support Open Software? If you do,
then after writing it, give it away.
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr> pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr> ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr> es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr> lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr> nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr> ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr> -Pain-Relief.html] Natural pain relief [/URL]
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.c<nobr>o<wbr></nobr> m] Pain relief [/URL]
</tt>
ishmal
----
Another one hyping XML...
Color me unimpressed. I prefer to live in the Real World (TM), not in Dreamland. Or can you offer one of the following: proof-of-concept code? example applications? industry adoption? a working toolchain? -- That would change my level of attention considerably.
PDF however, is being used all over the world for many different applications, and is a well designed format. And although the documentation is sometimes a bit difficult to decipher, once you've deciphered it it does make a lot of sense.
What about them? Are you suggesting that the printer might be filling them out?
Interactive forms are applications on the PC, they are not printer spoolings. The issue at hand is whether or not to change from the present Postscript spooling format to a PDF spooling format or better yet some other format like PCL.
PDF seems a little too heavy-weight compared to PS.
If you reread the article you will notice where it states that Postscript is featureful enough to be considered a programming language that is capable of far more than what it is presently used for, including malicious uses. Postscript is also more mature and stable than PDF and, most importantly, Postscript is unencumbered by Adobe's patents. PDF on the other hand is heavily patented and I am left with a hollow feeling from Adobe's "promises" to not enforce the patents.
Those stinking $20-50 printers cost so much more in consumables (ink for you morons) than a real printer anyway.
A laser costs about 0.1-0.3 cents per page. where inkjets are 4-50 cents per page. A colour postscript laser can cost as little as 1-3 cents per page.
Also a good laser will outlast an inkjet anyway.
A good compromise is a B/W laser and a supported colour inkjet for the times you actually really need colour.
Also, if you think LInux printing is a mess, maybe you just have made as poor a choice in Linux Distributions as you have in printers.
I have found the printing in my Linux distro to be not only easy to setup and use, but in some ways, more powerful than Windows printing. CUPS is especially cool in it's discovery and use of other CUPS systems on the network. After all, CUPS is good enough for Mac users.
Throw out that HP Deskjet, and shabby distro and install SuSE 10.1 and get a good PS laser and an Epson or Canon inkjet if you need colour.
Tachyon
I only hope that PDF printing will not suddenly mean that Linux will also honor PDF-"don't print this"-marks and the like (variants of DRM).
That would be a big drawback.
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]
Please don't use descriptions like that. People unfamiliar with kde and linux will see that, some might think ok I'll try it, see that it's still a work in progress and think 'Dang, if that's what they call top-notch this people are a lost cause.'
If you want a good pdf viewer, really, look at acroread. It works and works well. even the linux version. I want kpdf to get better and hopefully with the release of kde 4, it will be but it has a LONG way to go.
From what I rememberd about KPDF, my first reaction was to agree with you. But then I decided to have a fresh look at KPDF, something I haven't done for a long time. I am truly impressed! The text selection works even better than for acroread (Adobe's Acrobat Reader for Linux). I am now replacing acroread with KPDF for my daily use.
else, KPDF is great. (And note that I deal with pdf's very (!)
frequently.)
Bobby
I find it more lightweight, yet better usable than acroread7 for most of my own requirements. And I can copy and pasted pictures and text from it. I can even let the "KDE Text To Speeach" (KTTS) engine read the document to me. I can use it to directly open remote PDF files via ftp, http, webdav, smb, fish, nfs...
Yes, I know there can be many more improvements made. But I don't feel guilty for still calling it "top-notch". (I even outlined the areas where Acrobat Reader 7 currently is superior.)
Cheers,
Kurt Pfeifle
KPDF 3.4 and later is much better. Other than filling in PDF forms, there's very little that (if anything) that Acroread does better than KPDF.
That feature request has been rejected by the joint OSDL/LSB/Gnome/KDE Grand Unification Committee on the grounds that it would add even more bloat to the GUI. They ruled that it is entirely unnecessary. After all, you can rotate your monitor quite easily!
I have to agree with the parent. KPDF is a steaming pile! Look at all the responses in its defense; 'it's great, except for...' Pathetic.
Back on topic, CUPS blows chunks and it has nothing to do with whether you use postscript or PDF.
When was the last time you used kpdf? Two years ago? If you posted this back then, you would have been correct. Today, kpdf is excellent, and even handles huge 200+ page documents I throw at it with ease. Much faster and nicer than acroread.
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr> pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr> ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr> es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr> lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr> nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr> ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr> -Pain-Relief.html] Natural pain relief [/URL]
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
Kevin (www.eurfa.org.uk)
regarda eMPe
last paragraph calls for a response. It invites the "open source
community" to beg Adobe to grant us additional non-free software to
run on GNU/Linux--and suggests that the only reason we developed free
software to handle PDF is that Adobe hadn't given us non-free software.
I can't speak for the supporters of open source, but that's not how we
do things in the free software movement. We have a decades-long
campaign of developing free replacements for non-free software, just
for freedom's sake.
Non-free BSD Unix was already available in 1983, when we began
developing the GNU system to replace it. Non-free Java was already
available when we developed GCJ and GNU Classpath to replace it. Qt
was already available--though not free software yet--when we began
developing GNOME to replace it (Evince, mentioned in your story, is
part of GNOME). Those non-free packages were available, but they did
not respect our freedom--so we replaced them.
Open source cites only practical values, such as powerful and reliable
software. Some proponents of the open source might willingly use
Adobe's non-free software. A few (not most, I trust) might even beg
for it. But the free software movement will only ask Adobe what we
ask of all proprietary software companies: to respect users' freedom
by making their software free. And if they don't, we'll develop a
free replacement, for freedom's sake.
Free porn password archive - PornPassPlanet.com
Posted by: Anonymous Coward on May 11, 2006 08:56 AM#