smithda@cpsvax.cps.msu.edu (J. Daniel Smith) (12/13/89)
In article <17433@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >In article <28@macuni.mqcc.mq.oz>, ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) writes: >> In article <POLLACK.89Dec5120903@toto.cis.ohio-state.edu> pollack@cis.ohio-state.edu writes: >> >[..] >> Re the showpage hidden ops. Presumably Adobe will publish them when >> >> One option to find these special "unlisted" instructions is to dump the >> ROM contents using the PEEK operator posted a couple on months ago. If > >The Redstone monitor is indeed in the roms. It turns out that on version >38.0 and below, you can download s1-s9 records and alter registers. on ver >[..] >crude, but does work. There is a reference to a peek operator that was posted >[..] >other neat and useful functions available also. I arrived at these quite >independantly of Adobe. Why are we being forced to resort to dis-assembling ROMs to find out all the features of PostScript printers? While it does sound rather mystical and exciting (like the old days of computing), it is a lot of work. Doesn't Adobe know that there are people determined to find this kind of stuff out, and its just a matter of time before all their secrets are common knowledge? I find it a bit silly that people are using ROM monitors to find "secret" PostScript commands when Adobe's "red book" claims to be the complete discription of the PostScript language. I realize that Adobe needs to make a profit and protect its trade secrets, but I don't think this is the way to do it. Just a few thoughts after following a couple weeks on this topic... Dan ========================================================================= J. Daniel Smith Internet: smithda@cpsvax.cps.msu.edu Michigan State University BITNET: smithdan@msuegr East Lansing, Michigan Usenet: uunet!frith!smithda God created the integers; all the rest is the work of man. - Leopold Kronecker =========================================================================
geller@tfd.UUCP (David Geller) (12/15/89)
> "secret" PostScript commands when Adobe's "red book" claims to be the > complete discription of the PostScript language. The Red Book was probably written before or during development of the code for the Laserwriter. It does not contain all that is within the Laserwriter. If you require more extensive information about the actual workings of a 300 dpi laser printer using Adobe's PostScript try the following: INSIDE POSTSCRIPT "An analysis of the PostScript Interpreter on Canon Print Engines" by: Frank Merritt Braswell Published by Systems of Merritt, Inc. 2551 Old Dobbin Dr. East Mobile, AL 36695 (205) 660-1240 Also, pick up Emerald City's LaserTalk - for the PC, MAC or NeXT! David Geller Electric Logic, Inc. Washington, D.C.
jeynes@adobe.COM (Ross A. Jeynes) (12/15/89)
In article <5775@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (J. Daniel Smith) writes: >work. Doesn't Adobe know that there are people determined to find >this kind of stuff out, and its just a matter of time before all their >secrets are common knowledge? > >I find it a bit silly that people are using ROM monitors to find >"secret" PostScript commands when Adobe's "red book" claims to be the >complete discription of the PostScript language. I realize that Adobe Hi, Yes, Adobe does realize that people are determined to find this stuff out. Most of the code that you're talking about, however, is very device- dependent. Besides that, things like ROM monitors aren't typically useful in a page description. :-) PostScript was designed to make marks on a page, and that's what it's best at. There just aren't very many people who need to know about PS ROM monitors, and those who do will find it out, as you have observed. Anyway, if we published information about the limited ROM monitor capabilities (that are completely device-dependent), people would probably just complain that our ROM monitor was lame and needed to be fixed. What I'm getting at here is that we're not trying to "keep secrets" from the world; there are other reasons behind the decision to not document the ROM monitor, etc. We've documented the device-independent/mark-making part of PostScript quite clearly, which is the part that people need to print documents. (After all, it is a printer :-) Ross Jeynes Developer Support jeynes@adobe.com Adobe Systems Incorporated {sun|decwrl}!adobe!jeynes
woody@rpp386.cactus.org (Woodrow Baker) (12/15/89)
In article <1531@adobe.UUCP>, jeynes@adobe.COM (Ross A. Jeynes) writes: > In article <5775@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (J. Daniel Smith) writes: > >work. Doesn't Adobe know that there are people determined to find > >this kind of stuff out, and its just a matter of time before all their > >secrets are common knowledge? > > > >I find it a bit silly that people are using ROM monitors to find > >"secret" PostScript commands when Adobe's "red book" claims to be the > >complete discription of the PostScript language. I realize that Adobe > > Hi, > > Yes, Adobe does realize that people are determined to find this stuff out. > > Most of the code that you're talking about, however, is very device- > dependent. Besides that, things like ROM monitors aren't typically useful > in a page description. :-) > > PostScript was designed to make marks on a page, and that's what it's best at. > There just aren't very many people who need to know about PS ROM monitors, > and those who do will find it out, as you have observed. > > Anyway, if we published information about the limited ROM monitor capabilities > (that are completely device-dependent), people would probably just complain > that our ROM monitor was lame and needed to be fixed. > > What I'm getting at here is that we're not trying to "keep secrets" from > the world; there are other reasons behind the decision to not document > the ROM monitor, etc. We've documented the device-independent/mark-making > part of PostScript quite clearly, which is the part that people need to print > documents. (After all, it is a printer :-) > > Ross Jeynes > Developer Support jeynes@adobe.com > Adobe Systems Incorporated {sun|decwrl}!adobe!jeynes Ah, but it is also a full fledged computer. Adobe left a lot to be desired with the design of PS. Of course, these things come with hindsight. I find that the mechanisms are in place to handle these diffrences (APD etc). In addition the preponderance of PS printers are 300 dpi lasers. Now, it is true that a very few printers don't map the entire page at one time, but ALL of the afordable, easily available printers do. Why was a PATHBLIT or BITBLIT operator left out? It would imensely speed up many things. Yes I know you can fake it by faking the font mechanism, but there appears to be a finite limit to the amount of space that gets chached. The ability to read the memory map is also missing. The ability to do a transparent overlay (the imageing model uses opaque overlays, ignoring the need for transparent overlays), the ability to peek and poke to memory and screen ram. The ability to have **8 bit transparent** interface access bidirectionaly, and I could go on and on. If you all would document how to download ml programs etc, there would not be any need to go digging. CLEVER hackers would create the missing tools, since you all won't. The rom monitor is useful for taking apart PS code, and finding the memory maps of the printer. In the hands of a good pgmr, much can be revealed that will be useful. I'm at the point of turning a logic analyzer loose on a PS printer to find out certain things. Sure would be nice *NOT* to have to. Device independance is an admirable goal, but documenting the special stuff and non-portable i.e. not device independant stuff would make a ***LOT*** of people much happier. Other companies will, if you won't, and you'll loose users. Other PS clones are out, and some of them have extended or ar planning to extend the language to fix the problems. IF Adobe doesn't follow suite, they have an extrememly good chance of having the standard torn from thier hands, and loosing market share. It would be the most prudent thing to ****LISTEN**** and respond to the user community. Cheers Woody
rcd@ico.isc.com (Dick Dunn) (12/21/89)
background - talking about printer internals... > > >...Doesn't Adobe know that there are people determined to find > > >this kind of stuff out, and its just a matter of time before all their > > >secrets are common knowledge? These aren't "secrets" any more than it's a "secret" that there are rings on the pistons in your engine. They're internal characteristics which are mostly irrelevant to the end user. > > >I find it a bit silly that people are using ROM monitors to find > > >"secret" PostScript commands when Adobe's "red book" claims to be the > > >complete discription of the PostScript language... I find it a bit silly too, but for a reason entirely at the other end of the spectrum. The red book IS pretty much a complete description of the language--meaning that it describes what you can count on, as opposed to what might happen to work, on some printers, sometimes. woody@rpp386.cactus.org (Woodrow Baker) writes: > Ah, but it is also a full fledged computer... Well, PostScript is Turing-complete, and that's important in the sense that it's free of the zillion stupid special cases and restrictions that plague other printer interface "languages". But it's a special-purpose language, and a printer, if you want to consider it a computer, is special-purpose also. It's not intended for general computation. Folks like to say "but think of all the cycles just going to waste..." Well, think of all the office space that goes to waste 3/4 of the time, and think of all the cars that sit idle most of the time. It's a specious argument. >...Adobe left a lot to be desired > with the design of PS. Of course, these things come with hindsight... This flies in the face of the experience of almost everyone who has used PostScript for serious work. Adobe's design is carefully thought out, about as complete as could be expected, and has withstood the test of a moderate period of time with almost no need for change to the language. I've found it to be remarkably good. In fact, it seems that people have problems with PostScript and start finding it inadequate when they start trying to use it for something it wasn't intended to do. To that, the only sensible answer is "don't do that." If you're trying to use a wrench as a hammer, you're going to find that it's inadequate. The solution is not to redesign the wrench. > ...In > addition the preponderance of PS printers are 300 dpi lasers... Today, yes. So what? That could change in a couple of years. Do you want to design in obsolescence (AND machine-dependence)...in *spite* of Adobe's best intentions??? Fella, they're trying to help you. They're trying to keep you from hurting yourself (and others). > ...Why was a PATHBLIT or BITBLIT operator > left out? It would imensely speed up many things... What would it speed up, by how much, and how do you really know that? Remember that printers are doing text most of the time, and PostScript interpreters are generally very good at that. I've found that the imaging operators are reasonable when you're doing 1:1, which is analogous to the bitblt case. It's a good idea to leave out bitblt anyway, since (as many folks have noted in the past decade or so:-) it doesn't generalize usefully when you add gray scale or color. >...Yes I know you can fake it > by faking the font mechanism, but there appears to be a finite limit to the > amount of space that gets chached... ??? Do you expect an infinite cache? I can't make sense of this. >...The ability to read the memory map is > also missing... It's not missing from a language which doesn't assume the existence of a memory map. PostScript is NOT an interface language for a 300 dpi printer. Think about the common case of layout and proof at 300 dpi, then going to a phototypesetter for final output. Do a quick calculation of how much memory it takes to map a page at 2540 dpi! >...The ability to do a transparent overlay (the imageing model > uses opaque overlays, ignoring the need for transparent overlays),... ...something other than imagemask and/or the font mechanism? The PostScript imaging model is a painting model. It's consistent. If you want transparent overlays (which really aren't that common) you can prepare them. Transparency isn't a simple idea. >...the ability > to peek and poke to memory and screen ram... This is getting ridiculous! At the risk of putting words in Adobe's mouth, I DO NOT believe they were trying to build you a hacker's toy. They were trying to produce a tool for getting real work done. >...The ability to have **8 bit transparent** interface access > bidirectionaly,... The design was to make the language expressible in 7-bit ASCII. That's a specific decision. > The rom monitor is useful for taking apart PS code, and finding the memory > maps of the printer. In the hands of a good pgmr, much can be revealed > that will be useful... This is not what a "good programmer" would do. This is what an amateurish hacker would do. > Device independance is an admirable goal, but documenting the special stuff > and non-portable i.e. not device independant stuff would make a ***LOT*** of > people much happier... I don't think it's that many people. PostScript is incredibly useful just as it is...and in fact, I'm glad that the language is designed so carefully to be printer-independent, resolution-independent, etc. It minimizes the hassles I have to deal with. >...Other companies will, if you won't, and you'll loose > users... > ...IF Adobe doesn't follow suite, > they have an extrememly good chance of having the standard torn from thier > hands, and loosing market share... If they start introducing printer dependencies, back doors, dark corners, etc., they won't have a standard at all. There is a mechanism for intro- ducing the few needed printer-specific characteristics as operators you can test for and use. You may have noticed that Adobe is not exactly losing market share! It's important to understand that the specification of the language not only defines what is IN the language but, by omission, tells you what is NOT in the language. If you happen to find things you can do with a particular implementation, but they're not defined in the language defi- nition, you're outside the language and looking for trouble. The spec tells you what you can count on. >...It would be the most prudent thing to > ****LISTEN**** and respond to the user community. Well, OK, I'm part of the PostScript user community too, and I want Adobe to listen to me too! I think PostScript is doing fine as it is, and I want it to stay as a useful tool for serious use. I *don't* want it to be turned into a PC-world hacker toy. I don't want all manner of printer- specific gunk to be part of the language (tho I think there's small danger of that). -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
woody@rpp386.cactus.org (Woodrow Baker) (12/22/89)
Dick Dunn writes rather facinating articles. However, he is quite wrong in some assumptions. First, PS is a GENERAL PURPOSE programming language with an imaging model as it's base. It is everybit as potent and powerful as anything you can stack it up against, APL might be more compact, and better at marices, but PS can handle most of that as well. Because of that, it is useful for lots more than printing. I have a ps printer setting on my desk at home. 90% of the time it is NOT doing printing. It is just sitting there. Why not offload some computing work on it. It is, afterall a 68000 with full floating point math, and a file system. There is no reason not to use it. Yes it is a "hackers" dream. Not by the current definition of "hacker", but by the classic definition "one who knows more about a machine because he takes the time to explore it more throughly that 99% of the people out there". The guru type hackers. I am NOT an amature "hacker". I am a classic "hacker". I look for as much power out of a machine (it costs > $5000) remember. The decision to cripple the printer by going to 7 bit ascii (who uses that? That disappeared with OCTAL for crying outloud!) is a rather serious mistake, because it severly limits what you can do with the machine. more odious, however is the inability to create a truely TRANSPARENT channel where control D', C's, T's etc can get through. That is teh real problem. As for the bit blitter, consider: I have a program that I used heavily. The program prints business cards. IT draws 10 cards to a page. Doing anything facny like grayfilled shaded letters, or curved printing takes a while. It takes a LOT of time, sometimes 20 min to image a real complex card. I don't have the luxury of that amount of time when I'm setting at a table at a fair or fleamarket making business cards on demand. All that interpreting is slow, even with a 18mhz 68000. the code is Crisp, that is the PS code is optimized for speed, but it takes more time than it needs to. I need to be able to image 1 card, then pick it up and "rubber stamp" it all over the page. In addition, I do mailing labels. Drawing the boarders for 33 labels, then going back and filling them in takes time. Bit blitting would help tremendously. I don't use my printer for "type setting " that much, but rather as a general purpose printer, and graphics printer. I also use it as a tool for general programming. It apparent that Dick never had an ounce of curiosity, nor grew up during the early 70's with microcomputers. I started programming micros back in 76, when a 256 BYTE machine was normal, and no one knew what to curiosity bumps. We dug through code to see how it was written, what it did, and how to wring the most possible out of both it and the machine. That kind of poking and prying is still valuable. Perhaps I am a bit of a hacker, if some one tells me something is "off limits" etc, I'm going to find out why. This discussion group is not a place for flames, or diatriabes or even personal attacks. So right now, I will say, that I have just violated that with the above paragraph, and I applogize for that. The Rom monitor was installed for testing, and debugging. It is still useful for that. Wouldn't you love to be able to retrieve the bitmap? amoung other things? The only way apparently to find out how to do that, is either to pay Adobe a chunck, or go get it your self. Dick, If you want to pay for the information for my, if you can get Adobe to turn lose of it I'll shut up and crawl back in my hole, but until that time, I am going to keep digging. The only way up, is down. Cheers Woody 16K of memory. People who grew up through that era developed large curiosiutsoh
pollack@giza.cis.ohio-state.edu (Jordan B Pollack) (12/22/89)
Because of the relative slowness of graphic creation, I did my (3 by 4") mailing labels by consing up a border form, replicating it 6 times and printing the page out multiple times with #copies. (Unfortunately, the (avery) label glue seems not to be able to withstand multiple passes through the printer's heat circuits!) It would be nice to have the complex image stored as a bitblt-able image stamp! BitBlt is, of course, exactly isomorphic to my original query on on previewing! If you could indexed-read the screen memory into bitmaps, you can send the bitmaps home. I get the feeling Woody really solved it, but is bound by oath (or capitalism) to not fully let it loose. However, given a good bitblt, his other gripe, the 7 versus 8-bit problem might be elegantly solved using speedy built-in image scaling: Take each group of 7 bytes and send them (using \nnn as nec) as a 64-bit wide image, padded in such a fashion that when it is scaled to 7/8th of its width (to 56 bits) and imaged in a new bitmap, the bits that dissappear were just padding. You can then read out 7 bytes from each row of the array. Along with Woody, I guess I also view postscript as my long-sought-after write-only replacement for APL! Seems like we could start discussing the design of a general array package for postscript... -- Jordan Pollack Laboratory for AI Research CIS Dept/OSU 2036 Neil Ave email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890
ted@mbunix.mitre.org (Ede) (12/23/89)
In article <17480@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >Dick Dunn writes rather facinating articles. However, he is quite wrong >in some assumptions. First, PS is a GENERAL PURPOSE programming language >with an imaging model as it's base. PostScript is a device-independent page description language. Or at least that's what the back of my Blue Books says. I don't think Adobe ever envisioned the printer to be used as general purpose computer. I just can't see Warnock saying to Gesche, "Hey Chuck, let's build a general purpose computer with a built-in Cannon print engine." >It is everybit as potent and powerful >as anything you can stack it up against, APL might be more compact, and better >at marices, but PS can handle most of that as well. Because of that, it >is useful for lots more than printing. I have a ps printer setting on >my desk at home. 90% of the time it is NOT doing printing. It is just >sitting there. Why not offload some computing work on it. It is, afterall >a 68000 with full floating point math, and a file system. There is no reason >not to use it. Agree, so let it sit there an do an LU decomposition of a zillion by zillion matrix. It can blast the results of the serial line using 7-bit data. Or you could do something really bizarre like PRINT OUT the results. > Yes it is a "hackers" dream. Not by the current definition >of "hacker", but by the classic definition "one who knows more about a machine >because he takes the time to explore it more throughly that 99% of the people >out there". The guru type hackers. I am NOT an amature "hacker". I am a >classic "hacker". Ooh boy, hacker discussions. I have no doubt that you are NOT an amature hacker. I look for as much power out of a machine (it costs > $5000) > remember. The decision to cripple the printer by going to 7 bit ascii >(who uses that? That disappeared with OCTAL for crying outloud!) is a rather >serious mistake, because it severly limits what you can do with the machine. Be serious. It only limits what YOU can do with the machine. Our P&G department which bangs off thousands of pages a month doesn't seem to be limited. >more odious, however is the inability to create a truely TRANSPARENT channel >where control D', C's, T's etc can get through. That is teh real problem. Yeah, an 8 bit data path would reduce image xfer by 50%. That's the only benfit that I see. [part about inability to print business cards at a flea market deleted] >All that interpreting is slow, even with a 18mhz 68000. Well, do something useful. Write a compiler/assembler for PostScript to 68000. I realize it's a very difficult problem, but a "classic hacker" should be able to handle it. >Drawing the boarders >for 33 labels, then going back and filling them in takes time. Bit >blitting would help tremendously. I don't use my printer for "type setting >" that much, but rather as a general purpose printer, and graphics >printer. I also use it as a tool for general programming. Bit blitting isn't posible on every platform that support PostScript. >It apparent that Dick never had an ounce of curiosity, nor grew up during >the early 70's with microcomputers. Your assumption. Just because Dick doesn't invest his efforts on oddballs efforts of marginal usefulness it doesn't mean he's not curios. >I started programming micros back >in 76, when a 256 BYTE machine was normal, and no one knew what to curiosity >bumps. We dug through code to see how it was written, what it did, and >how to wring the most possible out of both it and the machine. That kind >of poking and prying is still valuable. So post it to alt.computer.folklore. >Perhaps I am a bit of a hacker, >if some one tells me something is "off limits" etc, I'm going to find out >why. I assume it's the obligation of every PostScript programmer to do so? >This discussion group is not a place for flames, or diatriabes or even >personal attacks. So right now, I will say, that I have just violated that >with the above paragraph, and I applogize for that. Get a real life. Flame then apologize. Be serious. You have an editor, use it. >The Rom monitor was installed for testing, and debugging. It is still >useful for that. Wouldn't you love to be able to retrieve the bitmap? Not really. >amoung other things? The only way apparently to find out how to do that, >is either to pay Adobe a chunck, or go get it your self. Dick, If you want >to pay for the information for my, if you can get Adobe to turn lose of it >I'll shut up and crawl back in my hole, but until that time, I am going >to keep digging. The only way up, is down. Keep digging Woody. We'll be printing with our printers. Now for a final exercise, print out ten pages of: "The LaserWriter is a PRINTER" Feel free to experiment with various typefaces, point sizes and leading. Who knows, you may learn something about typography. Cheers, Teddy |Ted Ede -- ted@mbunix.mitre.org -- The MITRE Corporation -- Burlington Road| | linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B090 -- (617) 271-7465 | | - this line intentionally left blank - | +---------------------------------------------------------------------------+
murphyn@cell.mot.COM (Neal P. Murphy) (12/23/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: >... >my desk at home. 90% of the time it is NOT doing printing. It is just >sitting there. Why not offload some computing work on it. It is, afterall >... I agree. At my previous job, I had to generate a fair number of linear-regression graphs on log-log paper. I wrote a postscript function, sent it to the printer. Then I sent sent the data as a matrix of reals, and various labels to the printer. Next I called the function. It scaled the graph, drew it, labelled it, calculated the slope and intercept of the line, and plotted it and the data on the graph. If I remember, the printer ran at or near its rated speed (8 or 40 ppm). The point here is that computing that is directly related to producing the printed page should be downloaded to the printer, but not to the point of overloading the printer. For example, I wouldn't even *think* of considering asking the printer to calculate a non-linear regression curve, or a non-linear interpolation curve. But the printer should not be loaded down to 100% computing 100% of the time. This is akin to asking the same of the computer in your car; after all, it does spend most of its life shut off. NPN
larry@csccat.UUCP (Larry Spence) (12/23/89)
In article <17480@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >I need to be able to image 1 card, then pick it up and "rubber stamp" it >all over the page. In addition, I do mailing labels. Drawing the boarders >for 33 labels, then going back and filling them in takes time. Bit >blitting would help tremendously. In Display Postscript, there is a notion of a "user path" -- essentially a form of caching for paths. Adobe doesn't say whether DPS is caching bitmaps, flattened paths, or what, but the net effect is that when you translate a user path and reimage it, the rendering is a lot faster. And... Adobe has said that some of the enhancements in DPS "may" eventually migrate down into printer PS interpreters. Of course, first they have to convince enough people to use DPS to make it the standard that printer PS is now. And this doesn't solve your current speed problem. The usual hacking conventions apply: you paid for the printer, you can do any perverted thing with it you please. But Adobe isn't under any moral or legal obligation to support you in doing so. All the eexec tools, etc., have appeared repeatedly on the net and on bulletin boards, so if you need to do that kind of thing, it can be done without Adobe's help. -- Larry Spence larry@csccat ...{texbell,texsun,attctc}!csccat!larry
rcd@ico.isc.com (Dick Dunn) (12/23/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: > [Dick Dunn] is quite wrong > in some assumptions. First, PS is a GENERAL PURPOSE programming language > with an imaging model as it's base. It is everybit as potent and powerful > as anything you can stack it up against,...[etc.] What wrong assumptions have I made? I said that PostScript is Turing- equivalent - that's about as strong a statement as you need to make about the (theoretical) power or generality. It's a general-purpose language in a sense, yet it's intended for a specific purpose (or set of purposes) - there are things it's good for and that's what it's used for. Show me some wrong assumptions. Convince me that, say, more than 2% of PostScript usage is for anything unrelated to imaging. > ...The decision to cripple the printer by going to 7 bit ascii > (who uses that? That disappeared with OCTAL for crying outloud!)... Somebody here leads a very sheltered existence. As for the business-card program - you're only doing "play" cards if you're doing them on a 300 dpi printer, so let's keep that in mind. (I've done that too in a pinch; it's not a bad idea but you need a little perspective.) I don't know why you want to get really fancy or complicated when you're at the lower end of acceptable quality, but that's your business. > It takes a LOT of time, sometimes 20 min to image a real complex card... I'd say you're doing something wrong...can't much tell what at this distance, but that's an eternity. OK, so if you want to find some hacks to speed that up, go ahead and find them! But just because you've found one situation where PostScript and your particular printer won't do what you want, doesn't mean there's a general language deficiency. Take a broader view. > It apparent that Dick never had an ounce of curiosity,... Yer smokin' rope, kid. I wasn't complaining about your curiosity. I was complaining that you're sitting around whining about Adobe not solving your little problems for you. >...nor grew up during > the early 70's with microcomputers... No, I had already grown up by then (to the extent it can be said that I've ever grown up:-). I was teaching by the time the 4004 was out. I've got lots of curiosity about how things work, and I've disassembled my share of code--more often to find out *why* something *didn't* work than *how* it *did* work, but that's neither here nor there. >...I started programming micros back > in 76, when a 256 BYTE machine was normal,... 256-byte machines were never normal. (Not everything which has existed is normal.) We're digressing here, but we'll get back to it. >...and no one knew what to curiosity > bumps... Hmmm...well, I certainly didn't. >...We dug through code to see how it was written, what it did, and > how to wring the most possible out of both it and the machine... And that, to some extent, was going on a long time before you started programming, and still goes on today. But it's a lot less "necessary" now than back then. F'heaven's sake, CPUs are commodity items, memory is under $100/Mb (again, thankfully:-), disk is $5/Mb or so...it's time to get up out of the muck and work at a higher level. In fact, it's just the shift in costs that made PostScript a viable "mass market" tool. It does some very high-level stuff and it requires a lot of computing power. The world in which people - as individuals - can afford a PostScript printer is one in which the intense bit-fiddling just isn't necessary...and if it isn't necessary, it really isn't desirable. (It can be fun, sure, but I'm talking about getting work done.) > "hacker" ... by the classic definition "one who knows more about a machine > because he takes the time to explore it more throughly that 99% of the people > out there". The guru type hackers. I am NOT an amature "hacker". I am a > classic "hacker". If you want to pat yourself on the back that way, fine...I think there are plenty of "classic hackers" like myself who will disagree with your assess- ment of yourself. > ...Perhaps I am a bit of a hacker, > if some one tells me something is "off limits" etc, I'm going to find out > why... Fine, go ahead. But the point is that "what you can find out by poking around" is a lot different from "what's specified and guaranteed to work." If you find something that seems to work for you, and you want to take your chances, go ahead...but you don't need to whine about Adobe not handing it to you on a platter. > This discussion group is not a place for flames, or diatriabes or even > personal attacks. So right now, I will say, that I have just violated that > with the above paragraph, and I applogize for that... Not really necessary; it wasn't that bad and the egg's on your face anyway. But how could the apology be sincere? It's in the same article as what you're apologizing about...if you didn't want to say it you could have deleted it. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
amanda@mermaid.intercon.com (Amanda Walker) (12/23/89)
In article <17480@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > First, PS is a GENERAL PURPOSE programming language > with an imaging model as it's base. This is true, and both the language and the imaging model are quite well documented. The fact that the PostScript imaging model does not provide a means to "read back" the current image isn't a deficiency in Adobe's docs--it was a conscious design decision, and one (in fact) that I agree with. 300 dpi bitmaps are tractable; 2540 ones aren't, and there do in fact exist PostScript printers that use display lists instead of a page buffer (and then they render things a band at a time). One of the nice things that NeWS does is to add a few operators (like "copyarea") that act on the page image without letting the programmer make any assumptions about its resolution, etc. Of course, some enterprising hacker type could quite easily write a bit of 68000 machine code to do this and load it in with cexec... This would be a much more "traditional hacker" approach than whining :-). > Perhaps I am a bit of a hacker, > if some one tells me something is "off limits" etc, I'm going to find out > why. Even so, no one has any obligation to help you, especially not Adobe... Going off on your own is just that. No one is saying you can't hack your printer to your heart's content, Woody. All some of us are saying is that, however nifty the things are that you find out, they're not part of PostScript (except for Type 1 fonts, and even that's borderline), and that because of this, Adobe has very valid reasons for not encouraging people to write PostScript code that depends on them. They're parts of the LaserWriter (or maybe the Redstone controller, at best), not PostScript. Amanda Walker InterCon Systems Corporation --
geller@tfd.UUCP (David Geller) (12/24/89)
Can anyone assist me in compiling a list of PostScript compatible devices that use display lists and banding versus entire page buffering? Thanks. Apple Laserwriter Plus Display List Linotronic L100 DL Linotronic L200 DL Linotronic L300 DL Birmysetter 300 Full-page buffering Varityper Compugraphic DEC : I'll post a summary. David Geller Electric Logic, Inc. D.C.
woody@rpp386.cactus.org (Woodrow Baker) (12/25/89)
My car is to old to have a computer in it. I won't drive anything newer than about 1977. Too complex. If something goes wrong, there are to many gadgets, computers, etc. Give me an old 1950-1974 tecnology car, and I can fix anything that is that is wrong..... Why not let your PS printer do the complex stuff. It should be quite capable of it. I see no reason why you could not do simple raytracing with it, and image the results. I also see no reason not to use it as a dedicated floating point computer. Any one with a good algorythm for PI written in PS? I'm sure that Adobe didnot decide to create a general purpose computer but that is really what they wound up doing. Sure, they missed ATAN and some of the other nice stuff, but there isn't any class of program that can be solved on a general purpose computer, that can't be done in PS. Actually, a Compiled version of PS is not unreasonable. Given a good BNF of the language, YACC and LEX should make the parser a snap. Cheers Woody w
woody@rpp386.cactus.org (Woodrow Baker) (12/25/89)
In article <1651@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <17480@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) > writes: > > First, PS is a GENERAL PURPOSE programming language > > with an imaging model as it's base. > > This is true, and both the language and the imaging model are quite well > documented. The fact that the PostScript imaging model does not provide > a means to "read back" the current image isn't a deficiency in Adobe's > docs--it was a conscious design decision, and one (in fact) that I agree > with. 300 dpi bitmaps are tractable; 2540 ones aren't, and there do in > fact exist PostScript printers that use display lists instead of a page > buffer (and then they render things a band at a time). > > One of the nice things that NeWS does is to add a few operators (like > "copyarea") that act on the page image without letting the programmer > make any assumptions about its resolution, etc. > > Of course, some enterprising hacker type could quite easily write a > bit of 68000 machine code to do this and load it in with cexec... This > would be a much more "traditional hacker" approach than whining :-). > > > Perhaps I am a bit of a hacker, > > if some one tells me something is "off limits" etc, I'm going to find out > > why. > > Even so, no one has any obligation to help you, especially not Adobe... > Going off on your own is just that. No one is saying you can't hack > your printer to your heart's content, Woody. All some of us are saying > is that, however nifty the things are that you find out, they're not > part of PostScript (except for Type 1 fonts, and even that's borderline), > and that because of this, Adobe has very valid reasons for not encouraging > people to write PostScript code that depends on them. They're parts of the > LaserWriter (or maybe the Redstone controller, at best), not PostScript. Precisely. I'm trying to shake lose enough information to do just that. The only 2 things that I haven't got down about cexec ar how to set the relocation tables up, what they refer to, and some more of the system calls. I have doped out the important ones, dealing with getting and putting objects on the stack, and some of the other support stuff. I'm not "whining", I hav a fundamental diffrence of opinion with Adobe, and perhaps other folks, and I am taking the position that the information should be made available. Secondarily, it sounds like NeWs (whatever that is) might have the equivelent of the blit blitter, in copyarea. I'd like to see the PS definition of the copyarea operator. Cheers Woody
woody@rpp386.cactus.org (Woodrow Baker) (12/25/89)
To my knowlege, the Apple Laserwriter Plus, images the ENTIRE page into memory, before dumping it to the drum through the laser. QMS does the same, Apple Laserwriter does the same, the NTX I think does the same, infact I know of no 300 dpi lasers that do not build a complete bitmap first. The banding is apparantly related to those printers that either use a dot-matrix mechanical print method, or write directly to film with the laser. Cheers Woody
bradlee@cg-atla.UUCP (Rob Bradlee) (12/26/89)
In article <17490@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >Actually, a Compiled version of PS is not unreasonable. Given a good >BNF of the language, YACC and LEX should make the parser a snap. > So, anybody got a BNF of PostScript? Any Language experts out there want to comment on or give pointers to articles on parsing PostScript? -- Rob Bradlee w:(508)-658-5600 X5153 h:(617)-944-5595 AGFA Compugraphic Division. ...!{decvax,samsung}!cg-atla!bradlee 200 Ballardvale St. Wilmington, Mass. 01887 The Nordic Way: Ski till it hurts!
ted@mbunix.mitre.org (Ede) (12/26/89)
In article <17491@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > Secondarily, it sounds like NeWs (whatever that is) So much for following what's going on in the PostScript world. >might have the equivelent of the blit blitter, in copyarea. I'd like to >see the PS definition of the copyarea operator. ^^^^^^^^^^^^^ You mean the *non-portable* PostScript *extension*. Printer/system specific PostScript is a real drag. |Ted Ede -- ted@mbunix.mitre.org -- The MITRE Corporation -- Burlington Road| | linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B090 -- (617) 271-7465 | | - this line intentionally left blank - | +---------------------------------------------------------------------------+
ted@mbunix.mitre.org (Ede) (12/27/89)
In article <8195@cg-atla.UUCP> bradlee@cg-atla.UUCP (Rob Bradlee) writes: > >So, anybody got a BNF of PostScript? Any Language experts out there want >to comment on or give pointers to articles on parsing PostScript? Try disassembling the parser on the LaserWriter :-) |Ted Ede -- ted@mbunix.mitre.org -- The MITRE Corporation -- Burlington Road| | linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B090 -- (617) 271-7465 | | - this line intentionally left blank - | +---------------------------------------------------------------------------+
iphwk@TERRA.OSCS.MONTANA.EDU (Bill Kinnersley) (12/27/89)
[In "Re: *COMPLETE* Postscript Description", bradlee@cg-atla.UUCP said:]
:
: In article <17490@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker)
: writes:
: >
: >Actually, a Compiled version of PS is not unreasonable. Given a good
: >BNF of the language, YACC and LEX should make the parser a snap.
: >
:
: So, anybody got a BNF of PostScript?
:
A context-free grammar requires the parser to know in advance the
ary-ness of each operator it encounters. PostScript would not be
context-free.
--
--Bill Kinnersley
Physics Department Montana State University Bozeman, MT 59717
INTERNET: iphwk@terra.oscs.montana.edu BITNET: IPHWK@MTSUNIX1
226 Transfer complete.woody@rpp386.cactus.org (Woodrow Baker) (12/29/89)
In article <84919@linus.UUCP>, ted@mbunix.mitre.org (Ede) writes: > In article <17491@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > > Secondarily, it sounds like NeWs (whatever that is) > > So much for following what's going on in the PostScript world. > > >might have the equivelent of the blit blitter, in copyarea. I'd like to > >see the PS definition of the copyarea operator. > ^^^^^^^^^^^^^ > > You mean the *non-portable* PostScript *extension*. Printer/system > specific PostScript is a real drag. are you saying that NeWs uses ****SHUDDER***** *non-portable* *extensions* but that are apparently useful? NeWs apparently exists in the unix world, and does not cross over into non-unix worlds like DOS n > > |Ted Ede -- ted@mbunix.mitre.org -- The MITRE Corporation -- Burlington Road| > | linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B090 -- (617) 271-7465 | > | - this line intentionally left blank - | > +---------------------------------------------------------------------------+