🚀 go-pugleaf

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."