🚀 go-pugleaf

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