portnoy@athena.mit.edu (Stephen L. Peters) (02/14/90)
I'm sure that this has been posted before (and probably again), but now I need the answer. How can you get a bitmap of a PostScript file? Is it possible to get a filter that can dump the print out to a file in a bitmap format? Please answer by mail, since most netters have possibly seen this already... Stephen Peters portnoy@athena
kent@wsl.dec.com (Christopher A. Kent) (02/15/90)
How do you get a bitmap of a PostScript file? You can't. If you could, you could use the PostScript engine as a font foundry, and no one, especially not Adobe, is about to let people do that, since that's where they make their money. Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
izen@amelia.nas.nasa.gov (Steven H. Izen) (02/15/90)
In article <2761@bacchus.dec.com> kent@wsl.dec.com (Christopher A. Kent) writes: >How do you get a bitmap of a PostScript file? You can't. If you could, >you could use the PostScript engine as a font foundry, and no one, >especially not Adobe, is about to let people do that, since that's where >they make their money. Maybe with Adobe's PS interpreter you can't, but Freedom of Press for the SGI Personal Iris has an output option to obtain bitmaps. -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve@izen386.math.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | Klein bottle for sale - Inquire within.
philip@Kermit.Stanford.EDU (Philip Machanick) (02/15/90)
In article <4917@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: > In article <2761@bacchus.dec.com> kent@wsl.dec.com (Christopher A. Kent) writes: > >How do you get a bitmap of a PostScript file? You can't. If you could, > >you could use the PostScript engine as a font foundry, and no one, > >especially not Adobe, is about to let people do that, since that's where > >they make their money. > > Maybe with Adobe's PS interpreter you can't, but Freedom of Press for the > SGI Personal Iris has an output option to obtain bitmaps. > > > -- > Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: > or steve@izen386.math.cwru.edu / > or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. > | Klein bottle for sale - Inquire within. OK, so how does LaserTalk get a bitmapped version of PostScript to display on a Mac screen? There must be some way of uploading the bitmap from a printer (implies you must have a PS printer, of course, but you can't have everything). Philip Machanick philip@pescadero.stanford.edu
woody@rpp386.cactus.org (Woodrow Baker) (02/15/90)
In article <1990Feb15.065013.20929@Neon.Stanford.EDU>, philip@Kermit.Stanford.EDU (Philip Machanick) writes: > In article <4917@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven > H. Izen) writes: > > In article <2761@bacchus.dec.com> kent@wsl.dec.com (Christopher A. > Kent) writes: > > >How do you get a bitmap of a PostScript file? You can't. If you could, > > >you could use the PostScript engine as a font foundry, and no one, > > >especially not Adobe, is about to let people do that, since that's where > > >they make their money. Frankly, while I understand thier motivation, I think it is a great disservice, to put it as mildly as I possible can. > > OK, so how does LaserTalk get a bitmapped version of PostScript to > display on a Mac screen? There must be some way of uploading the bitmap > There is a piece of code that they licensed from Adobe, apparently. It is an eexec routine that is a ceexec routine embedded in it. basicaly, it flushes the bands back down the appletalk link. I have not experimented much with it. What I would do, if I had a MAC, is to hook 2 of them up, run something that captures Appletalk traffic on one, and writes it to disk. Then I would start Lasertalk, and dump some code,and ask for a bitmap back. for display. I would then analyze thebus traffic. What I suspect is thatyou will find a download for a routine called flushbands. Study the invokation of it, and you can determine how to use it. I have a standalone cexec copy of it, I just have never taken it apart to see what the invocation is, or how it works. I'd *LOVE* to have a copy of the APPLETALK transactions captured by the above technique. If someone would do it, and make arrangements to transmit it to me, I'd appreciate it a BUNCH! Cheers Woody > Philip Machanick > philip@pescadero.stanford.edu
kent@wsl.dec.com (Christopher A. Kent) (02/16/90)
Woody, Could you explain to me exactly to whom Adobe is doing a disservice by not letting people use their printers as a font foundry? Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (02/17/90)
I understand why some groups have a "frequently asked questions" period mailing. I brought up this issue a few months ago, and we went round and round about it, touching upon Lasertalk, Lancaster's coding style, Adobe's Ice, and trojan horse error handlers. Lasertalk, which uses laserwriters to image bitmaps and bring them back to a Mac or PC, is pretty inexpensive for the macintosh. The more expensive PC version won't work for me, since my laptop has only 1 serial port and the program requires both mouse and laserwriter! I don't think there would be anything too wrong about PERSONAL use of a cracked or re-engineered protocol, but could see the trouble in a) cracking lasertalk and selling a new product based upon pirated code expensively licensed from Adobe, or selling adobe's fonts in either outline or bitmap form. Rather than trying to crack postscript to find the address of the rendered bitmap, or a fake postscript viewer like NeWS, I have decided to order Ultrascript PC, which looks like an authentic port of the Adobe product to the 80286. It is advertized as being able to render postscript into both PCX and TIFF, both of which are bitmap files. I get the ability to print on my deskjet as a bonus. -- Jordan Pollack Assistant Professor CIS Dept/OSU Laboratory for AI Research 2036 Neil Ave Email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890
zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) (02/17/90)
In article <2761@bacchus.dec.com> kent@wsl.dec.com (Christopher A. Kent) writes: >How do you get a bitmap of a PostScript file? You can't. Note that this is the theoretically correct answer, *regardless* of any policy on the part of Adobe. Given a PostScript program, there is no guarantee that there exists one single equivalent bitmap. Profit motive has nothing to do with it. Now, it is true that there are a lot of PostScript programs that have results that can be represented as static bitmaps, and there are ways to get those bitmaps, which differ according to what sort of machine and window system you are running. As an example of a PostScript program that does not translate to a bitmap, but does produce visible output, there is the "snowflake" program I wrote for the LaserWriter, which uses the random number generator to generate a unique snowflake every time it is printed. Given that a bitmap looks the same every time it is printed, translating this into a bitmap is not useful. As an example of a way to translate a PostScript program into a bitmap, without in any way involving a printer engine, run NeWS, preview the image, and do a screendump. Can we stop discussing the evils of Adobe now? Elizabeth
woody@rpp386.cactus.org (Woodrow Baker) (02/19/90)
In article <30006@sparkyfs.istc.sri.com>, zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) writes: > In article <2761@bacchus.dec.com> kent@wsl.dec.com (Christopher A. Kent) writes: > >How do you get a bitmap of a PostScript file? You can't. > Go tell that to EMERALD City! > Note that this is the theoretically correct answer, *regardless* of incorrect answer > no guarantee that there exists one single equivalent bitmap. Profit Hmmmmm, so how does the output get put on the page in a standard laserprinter? guess what, a bitmap is created in the printers memory, then it gets read and shifted out serialy to control the laser, such that the laser puts dots down on the drum, and thus an image. Take a magnifing glass and look carefully. > of PostScript programs that have results that can be represented as > static bitmaps, and there are ways to get those bitmaps, which differ All bitmaps are static at the time they are produced, and can be snapshotted if you have the correct code.....that is if the bitmap is held in memory like most printers are. t > As an example of a PostScript program that does not translate to a > bitmap, but does produce visible output, there is the "snowflake" > program I wrote for the LaserWriter, which uses the random number > generator to generate a unique snowflake every time it is printed. > Given that a bitmap looks the same every time it is printed, > translating this into a bitmap is not useful. This makes no sense whatsoever. The snowflake creates a bit-map in the printers ram, everytime it is printed. Now, granted, the same bit map won't be produced by the execution of the program everytime it is run, but a bitmap will still be produced. If one likes the printed bit map, and desires to print it at a later date, one would need to either, reseed the random number generator such that you could reproduce the given snowflake, or grab the bitmap..... Cheers Woody
amanda@mermaid.intercon.com (Amanda Walker) (02/20/90)
In article <17975@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > > Note that this is the theoretically correct answer, *regardless* of > incorrect answer Your prejudices are showing again, Woody :-). Of course, I'm sure mine do in the rest of this article... > > no guarantee that there exists one single equivalent bitmap. Profit > Hmmmmm, so how does the output get put on the page in a standard laserprinter? > guess what, a bitmap is created in the printers memory, [...] Take a > magnifing glass and look carefully. That has more to do with the printer than with PostScript. You could output PostScript on a plotter, or an automatic vinyl cutter, or any number of other devices that wouldn't know what a bitmap is if you threw one at them. A PostScript program is an abstract description of how to render an image. It says nothing about the actual end result of rendering that image. The fact that most PostScript renderings are done inside 300 dpi black & white printers is irrelevant. > [about Elizabeth's "snowflake" program] > This makes no sense whatsoever. The snowflake creates a bit-map in the > printers ram, everytime it is printed. All right, let's take another example. What would a bitmap of your PostScript mailing-list program look like? If what you want is to render a PostScript program into a bitmap, something like UltraScript, Freedom of Press, or LaserTalk should do the trick to one degree or another, but I agree with Elizabeth--let's stop arguing about the evils of Adobe, or at least take it to alt.religion.computers. Sigh. -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
epsilon@wet.UUCP (Eric P. Scott) (02/20/90)
In article <4917@amelia.nas.nasa.gov> steve@izen386.math.cwru.edu (Steven H. Izen) writes: >Maybe with Adobe's PS interpreter you can't With Adobe's DPS interpreter on the NeXT you can. -=EPS=-
glenn@heaven.woodside.ca.us (Glenn Reid) (02/20/90)
In article <1990Feb19.172134.12850@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >That has more to do with the printer than with PostScript. You could >output PostScript on a plotter, or an automatic vinyl cutter, or any >number of other devices that wouldn't know what a bitmap is if you threw >one at them. A PostScript program is an abstract description of how to >render an image. It says nothing about the actual end result >of rendering that image. The fact that most PostScript renderings are done >inside 300 dpi black & white printers is irrelevant. Not really, Amanda. In the red book, it states explicitly that PostScript is intended for raster devices. Raster isn't quite the same thing as a bitmap device, and that's an important distinction (see below) But you can't really do halftoning or implement even-odd fill algorithms on a vinyl cutter. At least I couldn't. The real issue, I think, is that Adobe did not "prohibit" getting at the bitmap in the political sense, they "prevented" it in the technical sense. The point that Chris Kent was trying to make, and which Woody missed, was that in the GENERAL sense, you cannot guarantee that the bitmap is there. In a printer with less than a full-page frame buffer, the image might be in a display list somewhere (there are at least 6 typesetters for which this is true). This is the "computer science" sense of the word "general", not the Saturday afternoon sense of it. Think carefully about what you might consider doing to a bitmap if you had one, and think about these raster devices for a minute, and realize that they are just as important as the laser printer hooked up to your Amiga or whatever: * 8-bit color screens * 24- or 32-bit color screens (or printers) * color devices with CMYK, black adjustment, color correction * 4-bit grayscale at 92dpi (NeXT) * 400dpi printers * continuous tone color printers * variable-resolution devices * high-resolution typesetters * FAX machines * "zoom" in any display environment I think the real point here is not that your hand will be slapped if you steal a bitmap, but that bitmaps are really pretty big, heavy, ugly, and useless things, for most purposes. Scanned images are best kept as source samples, not as halftoned bit- or byte-maps. Everything that is reduced to a bitmap becomes fixed, unwieldy, single-purpose, or otherwise boring. Adobe didn't implement any but very specialized, undocumented ways of prying the bitmap out of the printer because there are very few worthwhile uses for it, other than feeding to another printer of exactly the same characteristics, in which case you're better off with the PostScript stream anyway. Glenn P.S. A general admonishment: postings that say things like "Definitely." or "I agree 100%." or "incorrect." or whatever, should either be deleted before sending, if you don't add anything to the conversation other than that you agree or disagree, or else the burden is on you to say something carefully thought-out, well expressed, and actually make a contribution. The cost in bandwidth to the network to include a whole article and then say "verily" at the end should be billed to the sender. They go to China, to Finland, to Australia, to South America, even as far as the United States (My humble attempt to avoid nationalism)! Every byte counts. And I apologize for typing so many of them.
woody@rpp386.cactus.org (Woodrow Baker) (02/20/90)
In article <1990Feb19.172134.12850@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <17975@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) > writes: > > That has more to do with the printer than with PostScript. You could > output PostScript on a plotter, or an automatic vinyl cutter, or any > number of other devices that wouldn't know what a bitmap is if you threw > one at them. A PostScript program is an abstract description of how to > render an image. It says nothing about the actual end result > of rendering that image. The fact that most PostScript renderings are done > inside 300 dpi black & white printers is irrelevant. > I don't think it is irrelavant. Consider, over 95% of all Postscript speaking devices are 300 dpi lasers, maybe even more volume wise. True a bitmap of a POSTSCRIPT PROGRAM makes no sense, as it is TEXT, but the RESULT does. When someone talks about bitmaps, it is a given that they are refering to the RENDERED RESULT, not the program. A bitmap of my mailing program would be useless, but a bitmap of the SHEET of LABELS produced might not. Now, the mailling list program is fast at putting things on the paper, and very reproducable. BUT, consider a program that takes 4 or 5 hours to produce it's results and render a bitmap. It would certainly be advantagous to be able to grab the bitmap if you *ever* needed to create the printout again, because it would be lots faster to download the bitmap. Then again, you might want to do other things with it, like transfer it to a slide. > > All right, let's take another example. What would a bitmap of your > PostScript mailing-list program look like? > > If what you want is to render a PostScript program into a bitmap, something > like UltraScript, Freedom of Press, or LaserTalk should do the trick to > one degree or another, but I agree with Elizabeth--let's stop arguing about > the evils of Adobe, or at least take it to alt.religion.computers. I am not currently arguing about "the evils of Adobe", I'm taking issue with whether or not it is desireable, or needed to get a bit map back. I think that this thread was touched off by a request to the effect of "is is possible" and to that, the answer is yes. If anyone will hook 2 macs up to appletalk, run a bus monitor program on one to monitor Appletalk, and use Lasertalk on the otherone to send a program to the printer, and get a bitmap back, and then send me the captured file, I'll be glad to provide a definitive answer, and if possible a way to do it that doesn't infringe on anyones' code..... Cheers Woodyl
amanda@mermaid.intercon.com (Amanda Walker) (02/21/90)
In article <144@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > In the red book, it states explicitly that PostScript > is intended for raster devices. [flip, flip, flip] Hmm. You're right. I still think the imaging model itself is abstract enough that the fact that you're using a raster device is still irrelevant in most cases. Point taken, though. > you can't really do halftoning or implement even-odd fill algorithms on a > vinyl cutter. At least I couldn't. I admit that halftoning would be a bit of a problem unless you used a really low screen frequency :-). I don't see any problem with even-odd fills as long as the operator peels off the right pieces, though... > Adobe did not "prohibit" getting at the > bitmap in the political sense, they "prevented" it in the technical sense. True enough. > The point that Chris Kent was trying to make, and which Woody missed, was > that in the GENERAL sense, you cannot guarantee that the bitmap is there. This was also part of what I was trying to say, although it seems to have come out a little muddled. Sigh. > Adobe didn't implement any but very specialized, undocumented ways of > prying the bitmap out of the printer because there are very few worthwhile > uses for it, other than feeding to another printer of exactly the same > characteristics, in which case you're better off with the PostScript > stream anyway. If I were wearing a hat, it'd be off to you, Glenn. This is the most succinct way of putting that I have read. And with that, I'm out of this discussion. Back to PostScript! -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
jaap+@andrew.cmu.edu (Jaap Akkerhuis) (02/21/90)
Excerpts from netnews.comp.lang.postscript: 20-Feb-90 Re: Bitmap of PostScript co.. Glenn Reid@heaven.woodsi (3415) > ..... but that bitmaps are really pretty big, heavy, ugly, and useless things, for most purposes..... > Adobe didn't implement any but very specialized, undocumented ways of > prying the bitmap out of the printer because there are very few worthwhile > uses for it, other than feeding to another printer of exactly the same > characteristics, in which case you're better off with the PostScript stream anyway. Admitted, but one really nice feature would be to store them on a disk to cache the bitmaps and allow multiple processors to work on a spooling queue for a printer. The idea is to do the next thing: Suppose you have a (hypothetical) fast printing engine, say 100 pages a minute for raw speed. Normally you have one postscript engine, and now look at the speed you will get in the end. Well, since postscript is interpreted, fonts might not be in the cache etc, it takes a while for the pages to be processed. What is really frustrating is that you now know that the printer can run on 100 pages a minute (you checked this with fooling around with #copies) and you actually will see 30 pages a minute or so. It is easy to imagen a setup where you have a couple of processors with (quite) some disc space. Each individual job is directed to a different proccessor, the bitmaps are stored to disk and the printer can be fed with the bitmaps at full speed (after which the bitmaps are removed) with the bitmaps of one job while the other jobs in the queue are calculated. Of course, slightly more complicated setup can be thought of. Note that I don't propose to take the bitmaps and store them to a general purpose machine for turning them into group 3 encoding or other uses. I would consider above described setup as a black box, just as I consider my current printer as a (whatever colour painted) black box. I have heard a rumour that the reason that this is not possible to, do is due to the fact that the Adobe licencing rules state that the bitmap is not allowed to survive a power cycle. jaap
murphyn@cell.mot.COM (Neal P. Murphy) (02/21/90)
glenn@heaven.woodside.ca.us (Glenn Reid) writes: >In article <1990Feb19.172134.12850@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >bitmap device, and that's an important distinction (see below) But you >can't really do halftoning or implement even-odd fill algorithms on a >vinyl cutter. At least I couldn't. Sure you could! You could even design a machine that would cut cloth for patchwork quilts with any shape or design. Such a machine would simply select, from inventory, the pattern that most closely matches the requisite half-toning or even-odd fill specification, perhaps selecting the smallest piece that could be used, and cut it. The two reasons that PostScript has pixel-map capabilities built in are: 1) region-filling is difficult with vector devices, and 2) raster devices are far more common. Ideally, PostScript should be used with vector devices, since PostScipt's internal representing scheme uses vectors. As I recall, the old Tektronix 4014 had a screen resolution of about 400 dpi (3k dots high by 4k dots wide on a 14 (diagonal) CRT.) I believe it could also draw: bright and normal vectors, focused and unfocused vectors These characteristics would allow it to present a nicer image than can be had from a 300 dpi laserprinter. But it was a vector device. It would have the Devil's own time displaying a pixel map! PostScript can be adjusted to drive most any two dimensional device, and, with a fair amount of work, it could probably drive a 3-D device. Such 'abnormal' devices would include an NC milling machine, or an NC lathe, plexi-glass display cutter, trophy engraver, ice sculpture cutter and other such machines. PostScript is designed to work with raster devices simply because such devices are the most prevalent today. But it can work with any device that prints, cuts, moves, draws, or paints. NPN
woody@rpp386.cactus.org (Woodrow Baker) (02/21/90)
some more bitmap thoughts... While postscript is indeed a raster type language, and your points on that are very well taken, and said, it should be realized that the core graphics primatives are just as applicable to vector devices. Now, while it would be difficult to implement gray shades on a MECHANICAL vinyl cutter, there does exist as subset of ps, consisting of the curveto, arcto, lineto,moveto and relative versions, as well as the transforms that are very applicable. An implementation that could only do black or white (material removal or not) is a useful and valid set of postscript. It would not be difficult to do grayshades and fills on a waterjet cutter, abrasive stream cutter, or lasercutter for fabrics, wood, vinyl, paper, metal etc. These are typicaly vector devices. The cutter stays stationary, and the table holding the material to be cut, moves, and moves directly from point A to point B, not via rastering. A related device is the TEKTRONICS 4015 type terminal. A vector device, that could be made to run PS rather nicely. Many of these would not need a bit map, and thus the arguement that bitmaps are perhaps needed would not hold for some of these, although the COULD be implemented via a bitmap. The bitmap is the "rosetta stone" of the graphics world. Postscript is not. What I mean, is that a bitmap is the lowest common denominator for graphics representation. If I want to move an image between a sun, or a mac, or a pc, the way to do it, is to convert bitmaps. If I want to display a mac image on my pc, I can convert the bitmap. If I digitize a video source on my pc, and wish to transfer it elsewhere, I use a bitmap. Currently there is no language to describe digitized video images. If I want to print these images, Postscript will even allow me to do that with the image operator. If I generate a page in Postscript, the bitmap should be available to other entities. Postscript won't allow that. This appears to me to be rather myoptic. Consider: I create a complex page that takes 20 min or more running under postscript. I wish to create a slide for a presentation. What are my choices? 1. Purchase an *EXPENSIVE* postscript to slide converter/printer unit. 2. Print it out, then photograph it (the most common way). Perhaps photographicaly transfer the video image to slide, or photograph the page with a video camera (losing a LOT of resoluteion) 3. Grab the bitmap, and send it to an inexpensive bitmap to slide converter, or send it to a video recorder. Now: number 3 does not do much for Adobe, as a competing media (bitmap vs postscript) output device is used. If I use a PS interpreter to generate the bitmap it does. The bottom line, is that bitmaps are VERY valuable things to have around, they may be big, but hardly ugly. They are a fact of life. The world does NOT revolve around an abstract page description language, and certainly never will, as it is not suitable for all things. Neither are bitmaps, but they are a good deal more general purpose than the page description language. I have a real problem with the attitude that "nothing else matters...We set the standard", whether it is IBM (the microchannel) or Microsoft (OS/2 ) or Alan Bradley (industrial controllers) or....... you name it. Cheers Woody Cheers Woody
tinkelman@ccavax.camb.com (02/21/90)
Previous postings in this chain have discussed (among other things)
the rights of the owner of a PostScript device with respect uses of
the PostScript generated bitmaps, other than the use intended by
the manufacturer and Adobe.
When you buy a printer, you don't generally sign a lengthy legal
document agreeing to limitations to your use of a printer. Hence,
I thought some people would find it interesting to see what one
manufacturer (Digital) includes as license terms with one of its
products.
As background, Digital has at least three products that I know of
which include some form of Adobe PostScript running on a VAX. These
are their DECwindows server (with Display PostScript) and printer
support software for Sixel printers and for their LN03-Image printer.
The printer support software translates PostScript input files into
Sixel or bitmaps, respectively, before downloading to the printers.
I've attached the description of the second of the printer support
software packages, as downloaded from the Digital Electronic Store.
I thought about editing it down to include just the License Terms
and Agreement, but as that seemed to be most of the document, I
figured I'd leave it intact.
Enjoy.
--
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830
bob@ccavax.camb.com or ...!uunet!ccavax!bob
-------------------------------------------------------------------
DESCRIPTION
The VAX LN03 Image Support Software consists of a VMS device driver for the
LN03 Image printer and associated MD300 scanner. The LN03 Image Support
Software also includes a PostScript library used exclusively by VAX
ScriptPrinter Software.
PostScript is a registered trademark of Adobe Systems, Inc.
Calls are made to the PostScript library from VAX Scriptprinter Software to
convert PostScript data into Bit-Mapped data capable of being printed by the
LN03 Image printer.
The LN03 Image subsystem consists of a Q-bus controller board and the LN03
Image printer.
INSTALLATION
Only experienced customers should attempt installation of this product. DIGITAL
recommends that all other customers purchase DIGITAL's Installation Services.
These services provide for installation of the software product by an
experienced DIGITAL Software Specialist.
HARDWARE REQUIREMENTS
VAXstation configuration as specified in the System Support Addendum (SSA
31.52.00-x).
SOFTWARE REQUIREMENTS *
VMS Operating System
VAX ScriptPrinter Software
* Refer to the System Support Addendum (SSA 31.52.00-x) for availability
and required versions of prerequisite/optional software.
ORDERING INFORMATION
Software License: QL-VZRA*-**
Software Media: QA-VZRA*-**
Software Documentation: QA-VZRAA-GZ
Software Product Services: QT-VZRA*-**
* Denotes variant fields. For additional information on available
licenses, services and media, refer to the appropriate price book.
SOFTWARE LICENSING
The license for this software product is only available with the
purchase of the hardware system.
This software is furnished under the licensing provisions of DIGITAL's
Standard Terms and Conditions. For more information about DIGITAL's
licensing terms and policies, contact your local DIGITAL office.
Adobe Systems Incorporated, License Terms and Agreement
1. Licensor grants to Licensee a nonexclusive sublicense, subject to
Paragraph 8 below and the other provisions hereof (a) to use a single
copy of the IMPP ("Software") solely for Licensee's own internal
business purposes on a DEC Computer; (b) to use the digitally-encoded
machine-readable outline and bitmap programs ("Font Programs")
provided by Licensor in a special encrypted format ("Coded Font
Programs") and identified herewith to reproduce and display designs,
styles, weights, and versions of letters, numerals, characters and
symbols ("Typefaces" and "Screen Typefaces") solely for Licensee's
own customary business or personal purposes on the screen of the DEC
computer; and (c) to use the trademarks used by Licensor to identify
the Coded Font Programs and Typefaces reproduced therefrom
("Trademarks"). Licensee may assign its rights under this Agreement
to a licensee of all of Licensee's right, title and interest to such
Software and Coded Font Programs provided the licensee agrees to be
bound by all of the terms and conditions of this Agreement.
2. Licensee acknowledges that the Software, Coded Font Programs,
Typefaces and Trademarks are proprietary to Licensor and its
suppliers. Licensee agrees to hold the Software and Coded Font
Programs in confidence, disclosing the Software and Coded Font
Programs only to authorized employees having a need to use the
Software and Coded Font Programs as permitted by this Agreement and
to take all reasonable precautions to prevent disclosure to other
parties.
3. Licensee will not make or have made, or permit to be made, any copies
of the Software or Coded Font Programs or portions thereof, except as
permitted under the terms of its single-use license on a DEC Computer
hereunder. Licensee agrees that any such copies shall contain the
same proprietary notices which appear on or in the Software of the
Coded Font Programs.
4. Except as stated above, this Agreement does not grant Licensee any
rights to patents, copyrights, trade secrets, trade names, trademarks
(whether registered or unregistered), or any other rights,
franchises, or licenses in respect of the Software, Coded Font
Programs, Typefaces, or Trademarks. Licensee will not adapt or use
any trademark or trade name which is likely to be similar to or
confusing with that of Licensor or any of its suppliers or take any
other action which impairs or reduces the trademark rights of
Licensor or its suppliers. Any use of the Trademarks must identify
the applicable "Trademark Owner". At the reasonable request of
Licensor, Licensee must supply samples of any Typeface identified by
a Trademark.
5. Licensee agrees that it will not attempt to alter, disassemble,
decrypt or reverse compile the Software or Coded Font Programs.
6. Licensee acknowledges that the laws and regulations of the United
States restrict the export and re-export of commodities and technical
data of United States origin, including the Software or Coded Font
Programs. Licensee agrees that it will not export or re-export the
Software or Coded Font Programs in any form without the appropriate
United States and foreign government licenses. Licensee agrees that
its obligations pursuant to this section shall survive and continue
after any termination or expiration of rights under this Agreement.
7. The Software licensed hereunder is restricted to use on a DEC
Computer to generate bitmap images to output devices with (i)
resolutions up to 400 dpi and speeds of 10 ppm or less in the case of
monochrome devices or (ii) resolutions up to 200 dpi and speeds of 10
ppm or less in the case of color devices. Licensee agrees not to make
use of the Software, directly or indirectly, to print bitmap images
with print resolutions of over 400 dots/per/inch, or to generate
Fonts or Type-faces for use other than with the DEC Computer. Any
failure of Licensee to comply with this provision is a material
breach of this End User Agreement.
8. Licensee agrees that Adobe Systems Incorporated is a third party
beneficiary of this End User Agreement.
LICENSE MANAGEMENT FACILITY
This layered product supports the VMS License Management Facility.
License units for this product are allocated on a User/Activity basis.
For more information on the License Management Facility, refer to the VMS
Operating System Software Product Description (SPD 25.01.xx) or the
License Management Facility manual of the VMS Operating System
documentation set.
For more information about DIGITAL's licensing terms and policies,
contact your local DIGITAL office.
SOFTWARE PRODUCT SERVICES
A variety of service options are available from DIGITAL. For more
information contact your local DIGITAL office.
SOFTWARE WARRANTY
Warranty for this software product is provided by DIGITAL with the
purchase of a license for the product as defined in the Software Warranty
Addendum of this SPD.
VAX, VMS, VAXstation, LN03 and ScriptPrinter are trademarks of
Digital Equipment Corporation.gillies@p.cs.uiuc.edu (02/21/90)
> I'm sure that this has been posted before (and probably again), but > now I need the answer. How can you get a bitmap of a PostScript file? > Is it possible to get a filter that can dump the print out to a file > in a bitmap format? Please answer by mail, since most netters have > possibly seen this already... If you have access to a NeXT workstation, then there is a public-domain postscript previewer that sort of does what you want, but I'm not sure how you would save it. You could probably hack on the source code.
bjones@uhccux.uhcc.hawaii.edu (Brad Jones) (02/21/90)
In article <1990Feb19.172134.12850@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >[omitted section]... You could >output PostScript on a plotter, or an automatic vinyl cutter, or any >number of other devices that wouldn't know what a bitmap is if you threw >one at them. A PostScript program is an abstract description of how to >render an image. It says nothing about the actual end result >of rendering that image. The fact that most PostScript renderings are done >inside 300 dpi black & white printers is irrelevant. In the strict theorectical sense, yes. But I think this discussion has become too esoteric. Some of us have very practical, real-world, needs for Postscript-to-bitmap conversion. I have a plotting program that writes Postscript code. I plot my data, and print the plots on a PS printer. When I need to make presentation graphics for a scientific meeting, I use Framemaker. Framemaker doesn't interpret Postscript but it will import bitmaps from encapsulated Postscript. If I have such a bitmap, Framemaker will display the graphic image so I can add a label, etc. Since I use the PS printer to print the end result, I'm not taking anything from Adobe, but they could sure help me by making this mechanism available. >[omitted section]... lets stop arguing about >the evils of Adobe, or at least take it to alt.religion.computers. I'm not as interested in Adobe's copyrights or trade secrets as I am in producing top-quality scientific graphics with minimal effort. If the mechanism exists to create bitmaps within my printer, I want to know how to get them. Why should everyone have to reinvent the wheel (by writing Postscript interpreters) while Adobe stifles progress and creativity by clinging to "trade secrets"? -- Brad Jones bjones@uhccux.uhcc.hawaii.edu bjones@uhccux.bitnet
kent@wsl.dec.com (Christopher A. Kent) (02/21/90)
Why should everyone have to reinvent the wheel (by writing Postscript interpreters) while Adobe stifles progress and creativity by clinging to "trade secrets"? I'm going to regret this, but... Adobe isn't stifling progress. There are at least two, no, it's three now that IBM has announced, products that let you do exactly what you want, or at least build the application that you want, using Display PostScript. You can do it with two different window systems, NextStep or X. I think WriteNow on the NeXT handles encapsulated PS just fine. I know that DECwrite does (or will when they release the current version). They both use Display PostScript to do the job. I can write a program with XDPS that animates an arbitrary PostScript file by saving the bitmaps into pixmaps. Of course I can use the bitmaps in my program -- that was the point of doing the integration. DPS is good for some things, and X is good for others. I'm not *allowed* to save the bitmaps onto a file or transmit them to another machine -- those are the terms of the license agreement I knowingly signed when I bought it. This isn't about stifling progress folks -- let's be fair. This is about not wanting to pay for using the fruits of Adobe's labor. You're hooked on PostScript because it's so good that the printing market has made it damn near ubiquitous, and now you want it on your workstations for free. If you want to use DPS in your application, pay for it. If your workstation vendor doesn't use it, gripe at them. If they don't listen, switch vendors to one that does. Complain to someone who can do something about it, eh? Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
glenn@heaven.woodside.ca.us (Glenn Reid) (02/22/90)
In article <cZsNFDO00VswE1p342@andrew.cmu.edu> jaap+@andrew.cmu.edu (Jaap Akkerhuis) writes:
+ Suppose you have a (hypothetical) fast printing engine, say 100 pages a
+ minute for raw speed. Normally you have one postscript engine, and now
+ look at the speed you will get in the end. Well, since postscript is
+ interpreted, fonts might not be in the cache etc, it takes a while for
+ the pages to be processed. What is really frustrating is that you now
+ know that the printer can run on 100 pages a minute (you checked this
+ with fooling around with #copies) and you actually will see 30 pages a
+ minute or so. It is easy to imagen a setup where you have a couple of
+ processors with (quite) some disc space. Each individual job is directed
+ to a different proccessor, the bitmaps are stored to disk and the
+ printer can be fed with the bitmaps at full speed (after which the
+ bitmaps are removed) with the bitmaps of one job while the other jobs in
+ the queue are calculated. Of course, slightly more complicated setup can
+ be thought of. Note that I don't propose to take the bitmaps and store
+ them to a general purpose machine for turning them into group 3 encoding
+ or other uses. I would consider above described setup as a black box,
+ just as I consider my current printer as a (whatever colour painted)
+ black box.
Are you sure you can feed bitmaps to the marking engine that fast? I'm
not sure, but I doubt that the bandwidth on most disks would even come
close. Given a 300dpi frame buffer, which is roughly 1 megabyte of data,
you would have to be able to feed 100 megabytes a minute. Maybe that's
possible. What is the bandwidth to/from most disk drives, anybody know?
I think you just need a faster controller, or perhaps better-formed
PostScript code, to really get 100 ppm. Maybe the disk scheme would
work, but I vaguely remember people saying that it wouldn't even work
on an 8 ppm printer, but maybe with some compression/decompression scheme
you could do it.
In any case, you raise a good point. The bitmaps in your example are more
like a "cache", an optimization. They still have only one purpose, to be
fed to the marking engine for which they were rasterized.
Glenn Reidglenn@heaven.woodside.ca.us (Glenn Reid) (02/22/90)
In article <6675@uhccux.uhcc.hawaii.edu> bjones@uhccux.uhcc.hawaii.edu (Brad Jones) writes:
+ In the strict theorectical sense, yes. But I think this discussion
+ has become too esoteric. Some of us have very practical, real-world,
+ needs for Postscript-to-bitmap conversion. I have a plotting program
+ that writes Postscript code. I plot my data, and print the plots on a
+ PS printer. When I need to make presentation graphics for a
+ scientific meeting, I use Framemaker. Framemaker doesn't interpret
+ Postscript but it will import bitmaps from encapsulated Postscript.
+ If I have such a bitmap, Framemaker will display the graphic image so
+ I can add a label, etc. Since I use the PS printer to print the end
+ result, I'm not taking anything from Adobe, but they could sure help
+ me by making this mechanism available.
Brad, FrameMaker will import the PostScript code directly, which will
give you much better results than if you try to paste in the bitmap.
If you run Frame on a NeXT machine, you can just "Import" the PostScript
code, and it will be drawn on your screen by the on-board interpreter.
(It may need to be a valid EPSF file, with %%BoundingBox, actually).
If you run Frame on a Sun or an Apollo, you'll have to create a text
rectangle, paste the PostScript code into it, then grab the textrect
and flag it as "Printer Code". Then, when you print from Frame, it will
just include the PostScript plot file right in the middle of the PS code
that Frame generates.
I haven't used Frame for a while on a non-NeXT machine, so I can't remember
precisely how to do it. If it's not obvious, call Frame, they'll tell you.
Most publishing applications make some provision for pasting PostScript
graphics into the document, and then including the PostScript when the
whole document is sent to the printer. That's what "Encapsulated PostScript"
is all about. It's better than getting the bitmap and pasting that in.
Glenn Reidjordan_b_pollack@toto.cis.ohio-state.edu (02/22/90)
Chris Kent writes: >> This isn't about stifling progress folks -- let's be fair. This is about >> not wanting to pay for using the fruits of Adobe's labor. This isn't quite so. Adobe got paid for its labor with a walloping piece of the money paid for my Apple Laserwriter and will recieve a walloping piece of the money going to QMS for Ultrascript to solve MY problem of desktop presentation of scientific results. And much of the fruit, in the first place, was developed by Xerox anyhow! (obligatory Adobe Bash:) Since I have official Postscript in a printer connected to workstation why should I have have to buy it again for to see bitmaps displayed, if it is technically possible to get them back from the printer? Imagine the cost of a NeXT machine if Jobs had to buy a separate postscript/font license for the printer! -- Jordan Pollack Assistant Professor CIS Dept/OSU Laboratory for AI Research 2036 Neil Ave Email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890
ralerche@lindy.Stanford.EDU (Robert A. Lerche) (02/22/90)
A simple way to grok disk speed: 60 revolutions / second is the typical hard disk speed. So, with 17 sectors on a track (again, typical), 512 bytes/sector, we have around 500 K bytes/second (about 30 M bytes/minute) at 1:1 interleave. Many factors affect the actual throughput of a hard disk, like, for example, whether the controller and host system are capable of running full speed at 1:1 interleave. So, using raw bitmaps it's a problem to drive a 100 page/minute marking engine. However, with some fairly simple compression it's probably good enough. A historical note: 60 revs/second is the same speed that mainframe hard disks have run at for years and years. Some of IBM's disks run a bit faster nowadays (I think the current 3380's go at about 80 revs/second). The mainframe disks have much more data per track, though, and so achieve much higher transfer rates (up around 4 M bytes/second).
lishka@uwslh.slh.wisc.edu (Chris Lishka (controlled by cockatiels) ) (02/22/90)
glenn@heaven.woodside.ca.us (Glenn Reid) writes: > [...] Everything that is reduced >to a bitmap becomes fixed, unwieldy, single-purpose, or otherwise boring. >Adobe didn't implement any but very specialized, undocumented ways of >prying the bitmap out of the printer because there are very few worthwhile >uses for it, other than feeding to another printer of exactly the same >characteristics, in which case you're better off with the PostScript >stream anyway. Although this may deviate from the original thread slightly, I think that a bitmap *is* a useful object to have. In fact, a postscript interpreter that is capable of producing an *arbitrary* size bitmap would be a very useful tool, because one could use it to create bitmaps of different sizes to send to many different types of printers (or to computer screens). Bitmaps are a useful way of moving from postscript code to a non-postscript output device, because many output devices use a bitmap-like "model" for printing. On the other hand, I can see where trying to get the 300dpi bitmap produced by a postscript printer (such as a LaserWriter) is sort of silly. Sure, it would be good for dumping to LaserJets or anything else that has 300 dpi, but like the Mr. Reid said if you have the LaserWriter in the first place, you may as well use it to do the printing and forget about the bitmap. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Somebody said to me, `But the Beatles were Wisconsin State Lab. of Hygiene antimaterialistic.' That's a huge myth. John lishka@uwslh.slh.wisc.edu and I literally used to sit down and say `Now, uunet!uwvax!uwslh!lishka let's write a swimming pool'."--Paul McCartney
hwt@.bnr.ca (Henry Troup) (02/23/90)
In article <cZsNFDO00VswE1p342@andrew.cmu.edu> jaap+@andrew.cmu.edu (Jaap Akkerhuis) writes: >Suppose you have a (hypothetical) fast printing engine, say 100 pages a >minute for raw speed... >minute or so. It is easy to imagen a setup where you have a couple of >processors with (quite) some disc space. Each individual job is directed >to a different proccessor, the bitmaps are stored to disk and the >printer can be fed with the bitmaps at full speed (after which the >bitmaps are removed) with the bitmaps of one job while the other jobs in >the queue are calculated. Such as a XEROX 9700 with several ENTIRE postscript(tm) engines. This technology does exist, and is used widely - on large systems. People interested in PostScript such try to get hold of the XEROX-L mailing list, or the bit.listserv.xerox-l feed from uunet. This stuff comes up there a lot - everyone wants to reclaim the capital invested in large central laser printers, few of which natively do PostScript. XEROX-L is available from LISTSERV@TAMVM1 and other listservers. Very long report follows: NET 55 1990 Jan 25 at 22:38 EDT from: <XEROX-L@TAMVM1.BITNET> (NETNORTH) subject: Xerox, PostScript, etc... Reply-To: The Xerox Discussion List <XEROX-L@TAMVM1> From: Edward Garay <U12570@UICVM.BITNET> Subject: Xerox, PostScript, etc... The following article will appear on the proceedings of the Xplor International Annual Conference, San Antonio Texas 1989. I am sending it to the Xerox-L list as it may provide some further information on inquiries recently posted. --- Ed --- ------------------------------------------------------------------- [19965] FRI 12/29/89 20:41 FROM U12570: Xplor'89 PostScript QTIE Session: PostScript QTIE Chaired by: Edward Garay University of Illinois at Chicago Attendance: 100 people, approximately The chairperson presented an overview of the recently announced Xerox 4045 Model 160 laser printer. He shared his experiences, thus far, with the X4045/160 beta test: The Xerox 4045 Model 160 is an innovative state of the art printer. It can print up to 10 pages per minute. It comes standard with 4 megabytes of memory, one input tray (250 sheets), a resident XGRAPH (vector commands) capability for use in 2700 mode, and an Intel 80386-based Electronic SubSystem capable of supporting five printer emulations: 2700 mode (XDCS commands), HP LaserJet Plus/500 Plus, PostScript, InterPress and Diablo 630 ECS. The X4045/160 has the 35 "standard Apple LaserWriter Plus" Contour fonts for use in the PostScript and InterPress PDL emulations. In addition, there are 7 Raster fonts available for non-PDL printing. Printer emulations can be switched dynamically, under software control. It also comes standard with the Centronics parallel and RS232 serial communications interface. The X4045/160 offers a number of upgradable options including a 2MB memory upgrade for a total of 6MB RAM, a high-capacity Feeder-stacker for a total of 750 input sheets with collated output, and a Dataproducts parallel or RS422 serial/Appletalk communications inteface. This 300 dpi laser printer is essentially a Xerox 4045/150 print engine equipped with the necessary electronics to support the five printer emulations, particularly, PostScript and InterPress. The PostScript implementation works extremely well, although it is not an Adobe implementation. The 35 contour fonts are Bitstream fonts in Xerox Font Interchange Standard (FIS) format. Xerox officials stated that the X4045/160 will support Adobe Type 1 ("hinted") fonts by 4Q90. Among the many plusses of the X4045/160 are its software switchable printer emulations, its robustness (20K monthly duty cycle), and its high input/output capacity. Preliminary runs at the University of Illinois have shown that the Xerox 4045 Model 160 is approximately 30% faster than the Apple LaserWriter NTX ($5,999 list price), and about 50% faster than the QMS PS-810 ($3,999 list price). For the most part of the beta test at UofI, the X4045/160 is connected as an RSCS (spooling system) device on an IBM 3081 mainframe. The connection is done through an IBM 7171 Communications Controller, using the serial interface at 9600 baud with XON/XOFF handshaking. The primary documents being tested at UofI are being printed using the 2700 and PostScript printer emulations. 2700 tests include soft fonts downloading, vector and raster XGRAPH graphics, UDK documents created by miscellaneous document composition systems and FAX documents printed as bitmapped graphics. PostScript tests include printing of small, medium and large size documents of diverse complexity, some with integrated text and graphics, others in foreign languages, or with mathematics and complicated scientific notations and formulae. All problems or bugs encountered during the beta test have been fixed or are being corrected by Xerox in a timely fashion. One problem of extreme importance to the University has been the retention of raster soft fonts (e.g. X2700 downloaded) across PostScript emulation switches. As of this writing, the problem has been resolved as follows: A 4MB RAM configured printer is capable of retaining up to 70KB of raster fonts; a X4045/160 outfitted with 6MB of RAM can retain up to 800KB of bitmapped fonts, approximately. The number of font retainable bytes is specified via X4045/160 non-volatile-memory commands. These NVRAM commads are very easy to use and are another interesting feature of this printer. All things considered, UofI feels the X4045/160 has only two drawbacks: 1) its HEFTY price: $9,995 list price for the standard configuration, and $11,695 with the Feeder-stacker option; and 2) the fact that it currently is not a fully compatible Adobe PostScript printer in that it does not support Adobe Type 1 "hinted" fonts -- however, as stated earlier this represents a minimal problem and should only affect those shops who must use and download additional Adobe PostScript fonts. It should be noted, however, that Xerox provides additional PostScript compatible contour fonts through the Xerox Font Center. Chis Scussel, of AT&T Bell Laboratories in Naperville Illinois, is also beta testing the Xerox 4045 Model 160. He seconded the review presented by Ed Garay, and also agrees that while the X4045/160 is a great printer, it may be priced a bit too high. After the Xerox 4045 Model 160 presentation and discussion, the floor was opened for miscellaneous questions and answers. The following is a brief description of what was discussed in this lively session. A couple of Xerox fellows gave a very quick overview of the new Xerox 4030 -- an 11ppm/300dpi HP LaserJet compatible printer recently made available in Europe. It is based on a Fuji-Xerox print engine. Xerox plans to make available a PostScript cartridge for this printer. As for all PostScript cartridge implementations, it is expected that the PostScript interpretation be somewhat slower than for actual PostScript compatible printers. Also, while the X4030 was being demonstrated at the conference's exhibit, it was unclear when the X4030 was going become available in the US. Numerous attendees showed a lot of interest in this printer, however. A brief discussion on PostScript Simple took place as initiated by Bruce Damer of Elixir Technologies. The principle behind a simplified PostScript subset is that it could allow for faster interpretation to keep up with higher speed print engines such as the Xerox 4090 and Xerox 4650. It was stated that Bezier cubics processing for high speed laser printers may require 2 million MIPS of CPU power! Such high CPU intensive requirements, make it virtually impossible *today* to interpret PostScript directly at the high-speed electronic printing system. Front-end converters such as Entire, Xerox Archer and cdpScript are unfortunately needed to allow printing of PostScript documents on Xerox high-speed output devices. Several Xerox technical staff, and users of these front-end converters proceeded to describe these products: Entire Fibre 200, Xerox Archer and CIS Postscript Compiler, and cdpScript. Entire's Fibre 200 and Xerox Archer are essentially similar products. They are turnkey systems which convert PostScript to Interpress Graphics (i.e. GHO IMG files with XNS jobticket headers). The XNS datastream is fed to the Xerox Electronic Printing System in the background, through an XNS gateway. Both are Unix applications, costing between $15K - $20K. Entire's Fibre 200 runs on an Intel 80386 PC. It supports TCP/IP, and can also convert HP LaserJet (PCL), PC PaintBrush (PCX) and Tagged Image File Format (TIFF) datastreams for X9700F EPS printing. Customization is available, and at least one person in the audience was using it and was quite pleased with it. For more information, contact Entire: 445 West Commercial Street, East Rochester, New York 14445; (716) 381-7500. Archer, is a new product being marketed by the Xerox Custom Systems Division. It is based on the Control-C software, and like Entire, Archer also supports TCP/IP and can also be customized. Archer runs on a SUN/3 workstation and was scheduled for launch in January of 1990. There are also plans to port it to a SUN SparcStation in the near future. In fact, it may be probably ported to other platforms in the second half of 1990. For more information, contact Xerox Custom Systems Division: 1616 N. Fort. Meyer Drive, Arlington, Virginia 22209; (703) 247-7160. CIS PostScript Compiler is a product being marketed by the Xerox Commercial Integrated Systems division. It is an MS-DOS application based on the popular Freedom Of The Press interpreter from Custom Applications Inc (CAI). In synthesis, this front-end uses the CAI interpreter to ultimately convert PostScript documents into InterPress masters. It runs on an IBM PC/AT 80386/80486 workstation and can be tailored for each customer's unique input/output and job management environment. Printing is supported on X9700F EPSs *and* Xerox 4045 Models 50/150 and Xerox 3700 distributed laser printers. For more information, contact: Xerox Commercial Integrated Systems, 1616 N. Fort Meyer Drive, Arlington, Virginia 22209; (703) 247-7160. cdpScript is a product developed by CDP Communications Inc that runs on an MS-DOS platform. It is based on the GoScript interpreter from LaserGo Corporation, and converts PostScript to Xerox IMG (GHO) graphics. Unlike the previous decomposers, cdpScript/97 is more limited, but less expensive ($3,999 list price). There is a version called cdpScript/45 available for the Xerox 4045s. This company has announced an MVS port for IBM mainframes scheduled for release in 1990. For more information, contact: CDP Communications Inc, 17 Dundonald Street, 3rd Floor, Toronto, Ontario M4Y 1K3; (416) 323-9666. Although not discussed at the QTIE, two other possible ways of printing PostScript on high-speed Xerox EPSs should be mentioned: 1) IBM shops with a solid Advanced Function Printing (AFP) installation could convert PostScript with the IBM PostScript to AFP/DS interpreter, and further convert the AFP datastream with Xerox XPAF. Although it is felt that this may be an overkill approach, it may attractive to those users who already have AFP and XPAF software installed. 2) CAI's Freedom Of The Press ($499) interpreter could be run on MS-DOS to output HP LaserJet PCL which could then be converted for Xerox printing with Elixir's HP2XRX ($2,500) utility. Freedom Of The Press is a very useful tool. It converts PostScript into numerous non-PostScript datastreams -- from dot matrix printers, to HP LaserJets and Color InkJet output devices. CAI has versions of FP that run on PCs, PS/2s and Macintosh systems. Regardless of the front-end in use, there are several critical issues affecting the imaging of PostScript documents on non-PostScript printers. Several of these were discussed at length, during the QTIE. All enablers support the 35 Apple LaserWriter Plus outline fonts. Some support additional PostScript fonts, others do not. Most, including Archer, CIS PostScript Compiler and Archer can output images in multiple resolutions (e.g. 300dpi and 600dpi, for example). PostScript interpretation is inevitably slow. Initial decomposition is usually very very slow: 2 - 4 minutes. The less font variations and graphics are used, the faster the document will be decomposed. Accurate page rendition is directly dependent on the quality of the PostScript code emitted by the originating document and/or graphic composition system. While PostScript is an industry standard, there is "well behaved and conforming Postscript", and then, there is poorly written PostScript which not always will print correctly. Xerox and several other vendors at the conference expressed their concerns about poor PostScript emitters. Duplex printing of X9700F IMG graphic files, which all the front-ends currently use, is limted by the complexity of the generated graphic files and the target printer. For instance, the new Xerox 4090 and 4650 EPSs will be able to print virtually all "PostScript converted documents" in Duplex, if enough GVG graphic memory is available on this printers; older Xerox 8790 and 9790 EPSs with a more limited GHO graphic memory, on the other hand, may not always be able to print large graphic IMGs in Duplex mode. Besides the difference in GHO vs. GVG graphic memory limitations, there may be the additional complication of the printer's speed to read the page logs and IMG files off the printer's disk(s). Another subject discussed during the QTIE was the performance and user experiences with the Kodak 1392 Model 24 PostScript printer. For the most part, current customers are happy with this 92ppm/300dpi $200K+ printer. One attendee stated that he is getting about 25ppm throughput on the first copy, and full speed 92ppm printing on multi-copy runs. Customers agreed that the Kodak UltraScript PostScript interpreter is a robust one. In line printer mode, the Kodak 1392/24 prints sysout at about 72ppm, on the average. High marks were also given to the Kodak Service staff. It was also interesting to note that, unlike Kodak, Xerox officials do not seem to believe that there is a market for multi-copy PostScript high-speed output devices. Some customers, however, told Xerox that indeed they have requirements to print multi-copy and large-size PostScript documents *today*. Finally, in liue of the complexity and infinite variety of pages which can be imaged with PostScript, all vendors and customers at the QTIE agreed that there should be a Common Performance or Benchmarks standard developed to better attest the execution of PostScript enablers and output devices. End of NET 55 -- Henry Troup - BNR owns but does not share my opinions ..utgpu!bnr-vpa!bnr-fos!hwt%bmerh490 or HWT@BNR.CA
larry@csccat.UUCP (Larry Spence) (02/23/90)
In article <18001@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >While postscript is indeed a raster type language, and your points on that >are very well taken, and said, it should be realized that the core graphics >primatives are just as applicable to vector devices. Read Warnock & Wyatt's paper (1982 SIGGRAPH?) on the imaging model. They say something to the effect that "the imaging model becomes strained if extended to vector devices." One of the nice things about PS is its elegance, power, and portability. You would lose a lot of that elegance and portability if you started creating "vector subsets" for vinyl cutters, etc. You would end up with a scenario where you would have millions of dialects, just the problem you now have with bitmaps. >The bitmap is the "rosetta stone" of the graphics world. Postscript is >not. Look, PS isn't perfect, but it's one of the few truly useful and powerful standards that exist in graphics. I think you're complaining more about Adobe's implementation than the language itself. Just go buy someone else's implementation, like UltraScript or Go Script or Freedom of Press, they'll let you export bitmaps. If the other guys don't do as good a job, then Adobe deserves whatever spoils they can get -- if the other interpreters are good enough, there will be pressure on Adobe to loosen up. Simple free-market economics. >If I want to move an image between a sun, or a >mac, or a pc, the way to do it, is to convert bitmaps. Why do you say this? PS seems like a good solution to the portability problem. You have a graphic object on your Mac (displayed at 72 dpi) and you want to print it on your 300 dpi LaserJet, and you want to SCALE BITMAPS?!? I thought it was pretty much agreed that device-independence is a Good Thing. And PS is just another device-independent graphics format, if perhaps a very good one. If your app can't export a decent object-oriented format like EPS or CGM or something, that seems like the application's problem. >If I generate a page in Postscript, the bitmap should >be available to other entities. Postscript won't allow that. This appears >to me to be rather myoptic. Buy someone else's interpreter. There are plenty out there now. There may be tradeoffs involved, though. >The bottom line, is that bitmaps are VERY valuable things to have around, >they may be big, but hardly ugly. Scale a 300 dpi bitmap up to 2540 dpi and run it out to your Lino. Ugly. Look at the size of the 2540 dpi bitmap on your hard disk. Ugly. >The world does >NOT revolve around an abstract page description language, and certainly >never will, as it is not suitable for all things. Neither are bitmaps, but >they are a good deal more general purpose than the page description >language. But what about the vinyl cutters, etc., that you mentioned? They won't like those bitmaps one bit (ahem)! The abstract geometric description is a better lowest common denominator than a bitmap, IMHO. If you HAD to, you could write an interpreter for a "vector subset" of PS for a vinyl cutter, while you could not write a bitmap converter for the same device. The world does not have to revolve around PS, but it probably should revolve around SOME object-oriented description of graphics, IMHO. >I have a real problem with the attitude that "nothing else >matters...We set the standard", whether it is IBM (the microchannel) >or Microsoft (OS/2 ) or Alan Bradley (industrial controllers) or....... >you name it. If there's an unsatisfied demand for PS interpreters for vinyl cutters, you could make big bucks by filling it. Do it! You gain a LOT by excluding vector devices from the imaging model. They didn't do it just to piss you off, Woody! It's the usual scenario: you can't make progress if you have to maintain compatibility with EVERY prior technology, or at least not as much progress. PS was a step FORWARD, not BACKWARD. And hey, I work for a company that competes with Adobe in application software to some extent. Why do you assume that Adobe is the problem? Our application didn't want to depend on DPS and its resource and licensing requirements, so we implemented Bezier rendering, clipping, styled lines, etc., ourselves. It's not like if Adobe doesn't let you do something, there's no alternative. The spec is in the public domain, after all. Again, if apps have trouble doing the things that PS does, that means Adobe has earned their bucks fair and square. It would be a different story if PS itself were encrypted, and the spec was private. It's not. Type 1 fonts are the exception, but won't be as soon as Adobe gets around to releasing the spec, as they say they will. If I've gotten a bit strident, Woody, I apologize. It just seems to me like the whole intent of PS is to discourage expedient hacking of the sort you like so much. It's like adding little custom exit ramps to a streamlined (ahem) superhighway. Sure, it may help you with your particular problem, but it's not something that the designers of the superhighway want to encourage. And with good reason. -- Larry Spence larry@csccat ...{texbell,texsun,attctc}!csccat!larry
jeynes@adobe.COM (Ross A. Jeynes) (02/23/90)
jordan_b_pollack@toto.cis.ohio-state.edu writes: > This isn't quite so. Adobe got paid for its labor with a walloping > piece of the money paid for my Apple Laserwriter and will recieve a > walloping piece of the money going to QMS for Ultrascript to solve MY > problem of desktop presentation of scientific results. And much of It seems that there has been some confusion about this lately. Ultrascript is not an Adobe product; it is a clone PostScript interpreter made by Imagen/QMS. Ross Jeynes Developer Support jeynes@adobe.com Adobe Systems Incorporated {sun|decwrl}!adobe!jeynes
amanda@mermaid.intercon.com (Amanda Walker) (02/24/90)
In article <3568@csccat.UUCP>, larry@csccat.UUCP (Larry Spence) writes: > If there's an unsatisfied demand for PS interpreters for vinyl cutters, you > could make big bucks by filling it. Actually the vinyl cutter was just an example I came up with off the top of my head. I don't know if there really is a market for a PS front end for one, but I do know of at least one typesetting house that would give its proverbial eyeteeth to be able to draw shapes and type in, say, Adobe Illustrator instead of typing coordinate pairs into an Apple II... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
clewis@eci386.uucp (Chris Lewis) (02/24/90)
In article <8167@lindy.Stanford.EDU> ralerche@lindy.Stanford.EDU (Robert A. Lerche) writes: > A simple way to grok disk speed: 60 revolutions / second is the typical > hard disk speed. So, with 17 sectors on a track (again, typical), 512 > bytes/sector, we have around 500 K bytes/second (about 30 M bytes/minute) > at 1:1 interleave. Eg: this is *absolute* maximum thruput from a ST506 drive - no missed rotations, exactly one rotation per track, 1:1 interleave. This is rather hard to achieve (or utilize for that matter) in most cases.... Some benchmarks I've done suggest that typical random reads of 4-8K through UNIX buffered disk devices (not files) is typically *less* than 1/4 of that. A surprising number of "reasonable" machines get an effective bandwidth of 25-50K/sec at most.... Micropolis 1570 (SCSI) or 1550 (ESDI) series, on the other hand, is 512 (sectorsize) * 36 (sectors/track) * 3600 / 60: 1105920 bytes/sec. (Most other SCSI and ESDI drives should be the same, if not a bit more depending on bit encoding) So, roughly double the effective bandwidth - though, some disk drivers are capable of doing considerably better. > ... So, using raw bitmaps it's a problem to drive a 100 > page/minute marking engine. You're not kidding. > However, with some fairly simple compression it's probably good enough. It depends on "how busy" the bitmap is. If it's text and line drawing a simple RLL encoding would work well, but rasterized images may often be a different story... > A historical note: 60 revs/second is the same speed that mainframe hard > disks have run at for years and years. Some of IBM's disks run a bit faster > nowadays (I think the current 3380's go at about 80 revs/second). The > mainframe disks have much more data per track, though, and so achieve > much higher transfer rates (up around 4 M bytes/second). CDC Hydra goes at 120 revs/sec. (US Export Control requires special licensing for drives that rotate faster than X RPM, I'm not sure whether "X" is 3600 or slightly higher) -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list
woody@rpp386.cactus.org (Woodrow Baker) (02/24/90)
In article <1990Feb22.155435.1578@uwslh.slh.wisc.edu>, lishka@uwslh.slh.wisc.edu (Chris Lishka (controlled by cockatiels) ) writes: > glenn@heaven.woodside.ca.us (Glenn Reid) writes: > > Although this may deviate from the original thread slightly, I think > that a bitmap *is* a useful object to have. In fact, a postscript > interpreter that is capable of producing an *arbitrary* size bitmap > would be a very useful tool, because one could use it to create > bitmaps of different sizes to send to many different types of printers > (or to computer screens). Bitmaps are a useful way of moving from > postscript code to a non-postscript output device, because many output > devices use a bitmap-like "model" for printing. > As I said before the bit map is the rosetta stone of graphics world. They are the most portable form of graphics file. They are easy to convert from one representation to another. > On the other hand, I can see where trying to get the 300dpi bitmap > produced by a postscript printer (such as a LaserWriter) is sort of It would certainly be large, but suppose that you could just grab Specific regins?.... Cheers Woody
bill@chelgraph.CO.UK (bill davy) (02/26/90)
Chelgraph has a patent on compression to/from disc for bitmap output devices.
nazgul@alphalpha.com (Kee Hinckley) (03/01/90)
In article <2839@bacchus.dec.com> kent@wsl.dec.com (Christopher A. Kent) writes: >Adobe isn't stifling progress. There are at least two, no, it's three Agreed. >This isn't about stifling progress folks -- let's be fair. This is about >not wanting to pay for using the fruits of Adobe's labor. You're hooked Wrong. The problem with Display Postscript is not the price, it's the damn licensing terms. I know of several companies who have been negotiating for *years*, no exageration, to get reasonable licensing terms and have failed. Furthermore, everytime you come out with a new piece of hardware you have to wait for Adobe to have the time to do another port, because they won't trust you to compile their source code. >If you want to use DPS in your application, pay for it. If your >workstation vendor doesn't use it, gripe at them. If they don't listen, >switch vendors to one that does. Sure, just throw out a few hundred thousand dollars worth of investment. Do it all the time! >Complain to someone who can do something about it, eh? People have, the one company most capable of doing something about it is Adobe, and people are complaining. I don't see the problem. I've got a Mac, I'd like to have DPS on that. Apple doesn't have it, so why doesn't Adobe sell it directly? I'd buy it. Ditto for my Apollo. What's the problem? I'm not flaming, I just don't understand it. -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | BBS: 617/641-3722 | | Arlington, MA 02174 | Dumb fax, dial number, | | | nazgul@alphalpha.com | wait for ring, press 3. | BBS line is still dead | +-----------------------------------------------------------------------------+
mgresham@artsnet.UUCP (Mark Gresham) (03/03/90)
OK. ENOUGH ARGUING ABOUT POSTSCRIPT VS. BITMAP! If you are interested in PostScript to bitmap conversion (and some software) contact: LaserGo, Inc. 9235 Trade Palce, Suite A San Diego, CA 92126 USA Telephone: (619) 530-2400 FAX: (619) 530-0099 The simplest is their DOS-based GoScript, which can produce bitmaps of a variey of resolutions. I'm sure they'd come up with a Unix-based program (if they don't have one already) if there were sufficient interest. I'm also sure they would be interested in any NEW product ideas for PostScript to bitmap conversions, even if Adobe isn't. SO THERE! Cheers, --Mark ======================================== Mark Gresham ARTSNET Norcross, GA, USA E-mail: ...gatech!artsnet!mgresham or: artsnet!mgresham@gatech.edu ========================================
malloy@nprdc.arpa (Sean Malloy) (03/06/90)
In article <713@artsnet.UUCP> mgresham@artsnet.UUCP (Mark Gresham) writes: >OK. ENOUGH ARGUING ABOUT POSTSCRIPT VS. BITMAP! >If you are interested in PostScript to bitmap >conversion (and some software) contact: . . . LaserGo, Inc. < . . . > >The simplest is their DOS-based GoScript, which can produce >bitmaps of a variey of resolutions. I'm sure they'd come up with >a Unix-based program (if they don't have one already) if there >were sufficient interest. I talked to the people at LaserGo yesterday, and they do not at this time have any plans for putting out a Unix-based version of GoScript. However, this is being considered in internal meetings; apparently, it has been one of the more popular subjects for comments that they have received from users and at Comdex. If you want to see them do it, write them and encourage it. Sean Malloy | Navy Personnel Research & Development Center | "The morning was death San Diego, CA 92152-6800 | with birdsong." malloy@nprdc.navy.mil | -- _The Wizardry Compiled_