A Printer that can print PDF directly...
Winnie the Pooh
In another words, at DOS prompt "copy /b filename.PDF prn" can work...
Some one Know this kind of printer??
If you know, please Post here the "model name" of that printer
Thank you for reading :)
Waldo
controllers. In Windows:
lpr -S servername -P printername filename.PDF
Waldo
"Winnie the Pooh" <ksh...@hotmail.com> wrote in message
news:dc37a8a6.03042...@posting.google.com...
Rob Daykin
on what you want to print:
mono/colour.
pages per minute
duplexing
paper size
number of trays
etc, etc, etc...
try looking at Xerox, Canon, Kyocera, QMS/minolta, HP, Oce for starters
Rob Daykin
software developer
Pindar Technologies
Alex Cherepanov
PDF format requires random access to the file.
PDF printer has to copy the file from stdin to disk before starting
to read it from the end -- from xref table.
There is a chance to find PDF printing capapilities if the
printer has a hard disk.
Mark Carroll
Rob Daykin <rDOTda...@pindarDOT.com> wrote:
>in theory any level 3 printer should print PDF natively. Model depends
Really - how do you figure that? Your "in theory" intrigues me, given
that I can see no mention of being able to print PDF natively in my
Level 3 literature. "In practice" I could understand. (-:
-- Mark
Winnie the Pooh
http://www.adobe.com/products/postscript/capabilities.html
I found some articles about this question...
Direct PDF printing - An optional capability of the Adobe PostScript 3
interpreter that improves workflow productivity by allowing the RIP to
accept and print Portable Document Format (PDF) files without printing
through an application.
It's only optional capability.
but in practice, nearly all postscript level3 printes can print pdf
directly..
Ken Sharp
@hotmail.com says...
> I found some articles about this question...
>
>
> Direct PDF printing - An optional capability of the Adobe PostScript 3
> interpreter that improves workflow productivity by allowing the RIP to
> accept and print Portable Document Format (PDF) files without printing
> through an application.
>
>
> It's only optional capability.
> but in practice, nearly all postscript level3 printes can print pdf
> directly..
I'm sorry, but I think you are mistaken. Firstly you have confused
'PostScript language level 3' with 'PostScript 3 (TM)' systems. While
anyone can claim language level 3 compatability, only Adobe can call
their systems 'PostScript 3'.
The ability to print PDF directly is not a part of the language spec,
its an *optional* part of the PostScript 3 system. Given that, as posted
elsewhere in this thread, a printer requires a hard disk to be able to
guarantee printing a PDF file (not all PDFs are linearized), a *very*
large proportion of PostScript language level 3 printers cannot print
PDF directly, since they have no hard disk.
Additionally, the capability is a cost option from Adobe, unlike the
clone vendors who mostly seem to bundle the capability. As it costs
money, and ordinary printers are cost sensitive, a number of
manufacturers who might otherwise be able to support direct PDF printing
have chosen not to.
I'm not aware of any 'printer' which supports direct PDF printing,
though I'm sure they exist. Most wide format inkjets, imagesetters and
some 'group' printers have the capability.
Ken
Alex Cherepanov
> Given that, as posted
> elsewhere in this thread, a printer requires a hard disk to be able to
> guarantee printing a PDF file (not all PDFs are linearized),
Even linearized PDF requires direct access. Only the 1st page is
self-contained. Other pages can have shared objects, which are normally
placed at the end of the file.
> Additionally, the capability is a cost option from Adobe,
I don't think so. ABS (Adobe Brilliant Screens) and
in-RIP trapping are. PDF option just takes more resources
on the printer.
IMHO PDF option doesn't add much value to the printer because
PDF spec is evolving but it is almost impossible to upgrade
the build-in RIP.
Winnie the Pooh
Oh, you are right..
Thank you for your indication!
Most printers ( around me ) have "Adobe PostScript RIP", So I confused them.
Kyler Laird
>Direct PDF printing - An optional capability of the Adobe PostScript 3
>interpreter that improves workflow productivity [...]
I'm still trying to figure out how this improves anything. Why the
aversion to letting a cheaper, more powerful computer handle some
of the tasks of printing?
--kyler
Rob Daykin
> that I can see no mention of being able to print PDF natively in my
> Level 3 literature. "In practice" I could understand. (-:
>
> -- Mark
Level 3 introduces the necessary features for PDF printing, things like the
ReusableStream filters. It becomes relatively easy to extend L3
interpreters to handle PDF, though I haven't done this personally I can see
how it could be done. So 'in theory' everything you need to handle PDF is
in the box, you just need to string it together, and for ease all 3 main
rip library 'vendors', Adobe, Global Graphics(Harlequin and Jaws) and
GhostScript (Aladdin, GNU, etc) supply PDF read functionality as part of
their products. fait accompli...?
I know not all rip vendors implement all of L3, things like Idiom
Recognition, colourspaces and stream filters tend to suffer, which means
you could implement a rip which is L3 compliant, but incapable of doing the
necessary to process a PDF.
As for practise, well I've been evaluating printers for work recently, and
everything I've looked at does PDF direct. Curses, looks like I don't get
to write a ProcSet for printing PDFs....
In the marketplace you'd have to have a really good reason not to include
PDF printing direct. If you can name me another L3 RIP library 'vendor'
who does not supply PDF functionality I'll be amazed. I don't count HP by
the way, since last HP 'PS' printer I looked at didn't even claim a level,
let alone Adobe compatible. <grin/>
Rob Daykin
>
> IMHO PDF option doesn't add much value to the printer because
> PDF spec is evolving but it is almost impossible to upgrade
> the build-in RIP.
Relatively easy if you have a RIP sat next to the printer, and unless
you're in desktop laser territory, most big prepress systems have a box sat
next to them.
Besides most advances in PDF1.4 and 1.5 are 'unprintable' things like
transparency, links, forms and javascript support are not prepress
features, so upgrades are probably not necesssary. Certainly for prepress
work we're standardised on sending PDF1.3 out the door when asked for PDFs.
In addition you've got specs like PDF/X for prepress work which are still
largely based on PDF1.3. (I'm sure I'm about to get corrected on this, but
PDFX1a predates PDF1.4 to my sure knowledge).
It makes our life easy at work 'cos when we sent a CD of PDFs to a printer,
we can send a stack of paper produced direct from the CD as a reference.
Rob Daykin
> PDF format requires random access to the file.
> PDF printer has to copy the file from stdin to disk before starting
> to read it from the end -- from xref table.
> There is a chance to find PDF printing capapilities if the
> printer has a hard disk.
You sure you have to have a disk? Can't you just whack the whole thing
into memory in a structured way, just like XML DOM. I'm pretty sure that's
how PDFlib works amongst others. So a disk would be an implementation
consideration on a smaller desktop type laser, but not on a big beastie
RIPs with a Gig of RAM, where memory usage is kind of academic. And I've
seen a few of those around in the last 5 years.
Alex Cherepanov
> Can't you just whack the whole thing into memory in a structured way, just like XML DOM.
desktop type laser,
> but not on a big beastie RIPs with a Gig of RAM
The original poster was asking about a "printer" and a "DOS prompt",
which indicates the low end. I agree that host-based RIPs have
plenty of RAM and disk space. The structured representation won't
help much on the low end. Sampled images have few control structures
to optimize out.
Regarding PDF printing, it introduces one more step that can fail.
Adobe and Ghostscript both convert PDF to PS before rendering.
Most artists check their work using Adobe Acrobat. PDF to PS
conversion on the RIP is different from the DS generation
in Acrobat. I've seen many cases when files look different when
printed from Acrobat and printed directly.
PDF/X or CMYK only PDF files produce more consistent results.
Regarding PDF interpreter implementation in PostScript, it is not
straightforward.
(1) PDF 1.3 has ICC based color spaces but PS 3 doesn't.
(2) PS CFF ProcSet doesn't have a documented function to read
from a stream.
(3) PDF graphic state is different from PS graphic state.
(4) PDF 1.4 transparency cannot be done on PostScript level at all.
PDF interpreter in Ghostscript takes 160K of PS code with
many things coded on C level.
François Robert
news:3EABED9E...@pindarDOT.com...
...
> Besides most advances in PDF1.4 and 1.5
> are not prepress features....
Can you educate me and tell why PDF blends are "unprintable" ? (Just because
it has no PS equivament does not mean you cannot print it... It's the PS
graphic model which is insufficient).
Also, I do understand that interactive features can be considered outside
the prepress realm (although I have seen some nice demo of a still,
"printable" newspaper page that embedded a video clip, activated when
clickig a photo). But I am not sure that blending is also off limit.
_______________________________________________________
François Robert
(to mail me, reverse character order in reply address)
Tony Butka
>I'm still trying to figure out how this improves anything.
Well, actually this is a feature (direct to printer pdf printing capability)
I'm very interested in. Most of my work is done on OS/2, where printer
driver issues are a very serious problem, as is Adobe's abandonment of the
platform with PS Level 3. For those of us using those 'other' operating
systems, this feature could be a godsend, just like .ps file printing is.
BTW, I've had a number of vendors say their printers will do this, but have
not personally verified the ability. When I can take my pdf file on a floppy
and print it on their machine from a command prompt, I'll believe :-)
Tony Butka
Kyler Laird
>On Sat, 26 Apr 2003 15:22:10 GMT, Kyler Laird wrote:
>>I'm still trying to figure out how this improves anything.
>Well, actually this is a feature (direct to printer pdf printing capability)
>I'm very interested in. Most of my work is done on OS/2, where printer
>driver issues are a very serious problem, as is Adobe's abandonment of the
>platform with PS Level 3. For those of us using those 'other' operating
>systems, this feature could be a godsend, just like .ps file printing is.
O.k., so why don't you just install Ghostscript and *pretend*
that your printer handles PDF directly? None of my cheap
printers handle PostScript, but that doesn't keep me from
sending PS files to them (by way of an automatic filter I do
not usually think about).
>BTW, I've had a number of vendors say their printers will do this, but have
>not personally verified the ability. When I can take my pdf file on a floppy
>and print it on their machine from a command prompt, I'll believe :-)
So do it tonight. Why wait on hardware?
--kyler
Ken Sharp
alex...@quadnet.net says...
> Ken Sharp wrote:
> > Additionally, the capability is a cost option from Adobe,
> I don't think so. ABS (Adobe Brilliant Screens) and
> in-RIP trapping are. PDF option just takes more resources
> on the printer.
Well, I can only go by what I hear. I was told that direct PDF printing
was a cost option from Adobe by an Adobe OEM. However, that was some
time ago, things may have changed.
> IMHO PDF option doesn't add much value to the printer because
> PDF spec is evolving but it is almost impossible to upgrade
> the build-in RIP.
Well, that does depend on whether there's a hard disk, but the point is
well made.
Ken Sharp
says...
> Alex Cherepanov wrote:
>
> >
> > IMHO PDF option doesn't add much value to the printer because
> > PDF spec is evolving but it is almost impossible to upgrade
> > the build-in RIP.
>
> Relatively easy if you have a RIP sat next to the printer, and unless
> you're in desktop laser territory, most big prepress systems have a box sat
> next to them.
Yes, but Alex and I were both drawing a distinction between 'prepress
systems' and 'printers'. When people talk about a 'printer' they usually
do mean a dersktop laser or similar.
I suggested that imagesetters, wide format proofers and similar
'prepress systems' do often accept direct PDF (having a hard disk) while
desktop printers (not having a hard disk) don't. 'Workgroup' printers
fall somewhere in the middle in trems of capabilities and hardware and
might go either way.
> Besides most advances in PDF1.4 and 1.5 are 'unprintable' things like
> transparency, links,
I think you'll find that transparency is quite printable actaully.
> features, so upgrades are probably not necesssary. Certainly for prepress
> work we're standardised on sending PDF1.3 out the door when asked for PDFs.
Fine, that's your workflow. The original poster wanted to 'print PDF',
he didn't sound to me like he was saying he wanted to set up a prepress
workflow, he just wanted to print some PDF files.
Rob Daykin
>
> The original poster was asking about a "printer" and a "DOS prompt",
> which indicates the low end.
fair enough
> Most artists check their work using Adobe Acrobat. PDF to PS
> conversion on the RIP is different from the DS generation
> in Acrobat. I've seen many cases when files look different when
> printed from Acrobat and printed directly.
>
tell me about it.
>
> PDF/X or CMYK only PDF files produce more consistent results.
>
mostly
>
> Regarding PDF interpreter implementation in PostScript, it is not
> straightforward.
> (1) PDF 1.3 has ICC based color spaces but PS 3 doesn't.
>
the hooks are there for it in the CIELabBased conversion though
> (2) PS CFF ProcSet doesn't have a documented function to read
> from a stream.
>
? I'm sure it did
> (3) PDF graphic state is different from PS graphic state.
Didn't know that
>
> (4) PDF 1.4 transparency cannot be done on PostScript level at all.
>
true. Hands up who believes in transparent PS.... (it's gone all quiet out there)
> PDF interpreter in Ghostscript takes 160K of PS code with
> many things coded on C level.
Really, that much? I'm surprised.
Rob
Rob Daykin
> "Rob Daykin" <rDOTda...@pindarDOT.com> wrote in message
> news:3EABED9E...@pindarDOT.com...
> ...
> > Besides most advances in PDF1.4 and 1.5
> > are 'unprintable' things like transparency, [...]
> > are not prepress features....
> Can you educate me and tell why PDF blends are "unprintable" ? (Just because
> it has no PS equivament does not mean you cannot print it... It's the PS
> graphic model which is insufficient).
>
'transparency' can be printed but it has to be flattened first. Unless you're
printing using transparent inks, which is possible in something like packaging
work I suppose. What generally happens is that the rendering system has an
implementation specific interpretation of this and in my experience the results
are inconsistent across systems. Regardless of whether it renders to PS or a
bitmap format like TIFF, which can support an alpha channel.
It's not something I want to mess with if I can avoid it.
If you look at the printplanet (www.printplanet.com) archives about the time
Acrobat 5 came out, there's reams on people getting upset over transparency in
PDF1.4.
Rob
Rob Daykin
> Yes, but Alex and I were both drawing a distinction between 'prepress
> systems' and 'printers'. When people talk about a 'printer' they usually
> do mean a dersktop laser or similar.
>
> I suggested that imagesetters, wide format proofers and similar
> 'prepress systems' do often accept direct PDF (having a hard disk) while
> desktop printers (not having a hard disk) don't. 'Workgroup' printers
> fall somewhere in the middle in trems of capabilities and hardware and
> might go either way.
>
OK
>
> > Besides most advances in PDF1.4 and 1.5 are 'unprintable' things like
> > transparency, links,
>
> I think you'll find that transparency is quite printable actaully.
>
not in my experience. Agree to differ on this one?
>
> > features, so upgrades are probably not necesssary. Certainly for prepress
> > work we're standardised on sending PDF1.3 out the door when asked for PDFs.
>
> Fine, that's your workflow. The original poster wanted to 'print PDF',
> he didn't sound to me like he was saying he wanted to set up a prepress
> workflow, he just wanted to print some PDF files.
only an observation, since PDF 1.4 support is relatively recent on many prepress
devices let alone desktops, and PDF1.5 is a way off.
I can only offer information based on my experience, and when it comes to
printing PDFs there isn't a desktop machine in my office that does it. Besides,
I ended up relearning how to use DOS/'doze lpr recently doing printer tests in
test suites where UNIX just don't happen.
Rob
Aandi Inston
>'transparency' can be printed but it has to be flattened first. Unless you're
>printing using transparent inks, which is possible in something like packaging
>work I suppose. What generally happens is that the rendering system has an
>implementation specific interpretation of this and in my experience the results
>are inconsistent across systems.
I'd have to disagree a little with this. The PDF specification (with
specific exceptions) rigorously and mathematically defines how
transparency is implemented (unlike most transparency definitions, I
suspect). Therefore, at any given pixel or abstract point in a
figure, there is an unambigious correct colour space and colour value
after flattening transparency.
That is not to say that PDF flattening implementations perfectly
achieve this or even that it can reasonably be achieved at any level
other than rendering to device-specific bitmap (an option in Acrobat,
the slowest).
>If you look at the printplanet (www.printplanet.com) archives about the time
>Acrobat 5 came out, there's reams on people getting upset over transparency in
>PDF1.4.
Yes, but ambiguity is not the reason. It is because this was
introduced as a "do not break existing viewers" incompatible change.
Therefore, transparency can be lost in output if people have not
upgraded at every point, and without any error.
This may be no big deal on a hand-out, but on a magazine advert the
cost could be in the hundreds of thousands of dollars (i.e. the client
won't pay if their transparent design becomes opaque because someone
is using Acrobat 4).
----------------------------------------
Aandi Inston qu...@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.
frank
with. Past a certain simple level, the mathematics becomes
quite hard.
Somewhat sadly, I have been working on various prepress blend/
smooth shading/ fill/ fountain/vingette/degradee issues for about
15 years now.
The human eye is quite good at picking up color breaks; one
has to work extra hard to defeat our built-in hardware. Techniques
to do the job are closely tied to the actual halftone pattern being
used. If you cannot control halftone generation, you cannot do
a good job.
For a few years now I have considered writing a few technical
articles on this subject, and patenting a bunch of work. But the
truth is the market for good work is thinner than ever. I have
been working steadily with one of the major RIP vendors for
five years on this issue, but nobody wants to spend the money to
do a REALLY GOOD JOB.
"François Robert" <moc.s...@trebor.siocnarf> wrote in message
news:b8hap7$isv$1...@si05.rsvl.unisys.com...> "Rob Daykin"
Ken Sharp
says...
> Ken Sharp wrote:
> > I think you'll find that transparency is quite printable actaully.
> >
>
> not in my experience. Agree to differ on this one?
Not really. I'm with Aandi, you can do transparency, particularly when
*printing* transparency as opposed to trying to maintain the opacity in
other formats. There is a pretty good definition in the PDF Reference,
Adobe went to some considerable trouble to ensure that this would be
printable.
Since I'm pretty heavily involved in making sure that PDF transparency
is printable, I do have a bias though.
> I can only offer information based on my experience, and when it comes to
> printing PDFs there isn't a desktop machine in my office that does it.
Which is more or less what I said. Big systems with big rips (and larger
margins) do direct PDF printing, little printers don't....
Ken
Lee Sau Dan
Ken> Which is more or less what I said. Big systems with big rips
Ken> (and larger margins) do direct PDF printing, little printers
Ken> don't....
"Big systems". That can be a powerful computer attached to a printer.
E.g. a modern PC running Linux accepts print jobs from the Ethernet
adapter using the 'lpd' protocol, rendering the PDF/PS into PCL and
sending the result to a printer that accepts PCL, perhaps connected
with solely a low-end parallel port cable.
In that sense of "systems", there does exist "PDF printers". ;)
--
Lee Sau Dan 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: dan...@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Alex Cherepanov
>>in Acrobat. I've seen many cases when files look different when
>>printed from Acrobat and printed directly.
> tell me about it.
Acrobat can simulate overprint feature but PS printers can not.
Example: rose.ai from Illustrator samples.
Acrobat seems to ignore setflat parameter. Many printers honor it
producing ugly pictures when is is set too high.
Selection of media and bounding boxes is left to OEM and is likely
to be done wrong. Acrobat can scale the image up or down to fit
the page; printers don't.
There's no way to select device-specific features. Default settings
may be undesirable.
PDF 1.4 was introduced only in Adobe PS v. 3015 and it still doesn't
work well. Ghostscript is even worse. Just try to print the Illuatrator
samples.
>>Regarding PDF interpreter implementation in PostScript, it is not
>>straightforward.
>>(1) PDF 1.3 has ICC based color spaces but PS 3 doesn't.
> the hooks are there for it in the CIELabBased conversion though
Reading ICC profiles in PostScript is inconvenient.
Ghostscript uses extension operators here.
ICC color space in PDF can be used as an alternative color space.
This is not possible in PostScript.
>>(2) PS CFF ProcSet doesn't have a documented function to read
>> from a stream.
> ? I'm sure it did
PLRM 5.8.1 reads:
Note: StartData is the only operator in the FontSetInit procedure set
that is documented as part of the PostScript language. Other entries in
this procedure set are private to the implementation of font sets and
should not be accessed by a PostScript program.
StartData expects CFF in the current file. PDF interpreter has to read
from an external stream.
>>(3) PDF graphic state is different from PS graphic state.
>
> Didn't know that
This is the easiest one to work around.
PDF adds a few new graphic state parameters and removes the current
path. So GS uses an external stack to save-restore them and
uses the user path to preserve current path across grestore calls.
>>(4) PDF 1.4 transparency cannot be done on PostScript level at all.
>>
> true. Hands up who believes in transparent PS.... (it's gone all quiet out there)
Ghostscipt uses extension operators to pass transparency
information to the rasterizer. So it is possible to have all PDF 1.4
graphic features in Ghostscript-only PostScript.
>>PDF interpreter in Ghostscript takes 160K of PS code with
>>many things coded on C level.
> Really, that much? I'm surprised.
And growing. PDF 1.5 support will add more.
Regards,
Alex
Aandi Inston
>>>(3) PDF graphic state is different from PS graphic state.
>>
>> Didn't know that
>This is the easiest one to work around.
>PDF adds a few new graphic state parameters and removes the current
>path. So GS uses an external stack to save-restore them and
>uses the user path to preserve current path across grestore calls.
This is easy to work around with save/restore but unfortunately this
has a bad side effect. save/restore is limited to a stack of 15 in
many interpreters. gsave/grestore has a higher limit. Many products
add q/Q to PDF files with no respect for a finite limit - a classic
example was Adobe InProduct which could potentially add q/Q every time
a page was edited.
Limitcheck is therefore a common symptom when printing a PDF from
Acrobat. I have heard, but not confirmed, that Acrobat 5 no longer
uses save/restore to manage this. It is a convenience, but hardly a
necessity, and in level 3, with clipsave, there is no longer even a
need for gsave/grestore.