Forth versus Postscript
Mauro DiNuzzo
I am starting to look at stack-oriented languages using postfix notation
(i.e. RPN) and I recalled jForth on my old Amiga computer. However, surfing
around I stopped at Postscript, which I like very much.
Now I am trying to implement my own RPN language (everyone does it ;-).
Nonetheless, I was just wondering what do you think about Postscript-like
languages with respect to your experience with Forth.
Regardless of the real usage, I had the impression that PS is more
easy/intuitive compared with Forth.
Which is the strength of Forth, according to Forth users, that render it
preferred over PS?
Thank you very much.
M
Anton Ertl
>Nonetheless, I was just wondering what do you think about Postscript-like
>languages with respect to your experience with Forth.
You may also want to look into Factor, which is syntactically close to
Forth, but semantically closer to Postscript.
>Regardless of the real usage, I had the impression that PS is more
>easy/intuitive compared with Forth.
>Which is the strength of Forth, according to Forth users, that render it
>preferred over PS?
Forth is a low-level language. You can do things with Forth that you
cannot do with Postscript (e.g., accessing memory-mapped peripherals).
Conversely, the higher level of Postscript (including automatic
storage management) supports a programming style that cannot be used
in Forth in general.
However, I have the impression that Postscript could do with some
improvements that would make it nicer for programming (and that are
not added because most Postscript programs are so simple that they
would not profit from these features).
E.g., not too long ago I wrote a Postscript program for displaying
some data organized in a matrix. There was some data missing, and I
found Postscript pretty cumbersome for processing that data. There is
no good support for exception or other error handling, so I had to
make do with lots of definitions along the lines of:
%propagate error
/err21 { << /proc rot >> begin
over error eq over error eq or {drop drop error} /proc load end
ifelse
} def
%r1 r2 -- r3
/xdiv { {div} err21 } def
Crossposted to c.l.forth, c.l.postscript; please set followup
appropriately.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Steve
>
>You may also want to look into Factor, which is syntactically close to
>Forth, but semantically closer to Postscript.
Hello,
Do you have a good link to describe Factor?
Thanks,
Steve N.
Marek Kubica
Bo...@Embarq.com (Steve) wrote:
> Do you have a good link to describe Factor?
Apart from the homepage, <http://factorcode.org/> and the wiki (which
is written in Factor, btw) there is not much documentation available.
For a general overview, you can read the article in Wikipedia. For
specific questions, it is probably best to use their mailing list or
their IRC channel.
regards,
Marek
Matti Vuori
news:2010Mar...@mips.complang.tuwien.ac.at:
> improvements that would make it nicer for programming (and that are
> not added because most Postscript programs are so simple that they
> would not profit from these features).
Perhaps it is not because the programs are simple, but because people are
really not using Postscript for "programming" and never were.
Phil Martel
"Matti Vuori" <xmv...@kolumbus.fi> wrote in message
news:Xns9D3318142255F...@195.197.54.114...
There is this: http://www.tinaja.com/post01.asp Don Lancaster did a lot of
his programming in Postscript.
Jerry Avins
He started that when his printer had more computing power than his computer.
Jerry
--
It matters little to a goat whether it be dedicated to God or consigned
to Azazel. The critical turning was having been chosen to participate.
�����������������������������������������������������������������������
Jeffrey H. Coffield
I guess that means that I am not a person. I not only program in
PostScript but have made quite a lot of money doing it.
Jeff Coffield
Anton Ertl
People write the preludes that programs producing Postscript output as
part of the Postscript they output. And people write code that
generates the data-dependent part of the Postscript output.
What I meant is that, for the kind of data manipulation that I used in
Postscript (and where I found Postscript lacking), they usually do it
in another programming language, and only output the result as
Postscript. So their preludes also don't need these data manipulation
and error handling capabilities.
Don Lancaster
> ...(and where I found Postscript lacking),...
I think I found your problem.
http://www.tinaja.com/post01.asp
http://www.tinaja.com/glib/gonzotut.pdf
--
Many thanks,
Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: d...@tinaja.com
Please visit my GURU's LAIR web site at http://www.tinaja.com
David Combs
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
...
>
>However, I have the impression that Postscript could do with some
>improvements that would make it nicer for programming (and that are
>not added because most Postscript programs are so simple that they
>would not profit from these features).
One example of something that could pretty easily be
done to improve postscript re writing easier to
(write and) READ programs.
Have a look at the HP-48 or HP-50 calculators (programmable, and
how!).
Obviously, being HP, it works in reverse-polish (just like Postscript).
It lets you create functions, with local variables, obviously VASTLY
easier to read that trying to dope out the something full of exchanges
and pushes and pops (and then more exchanges), etc.
If anyone is interested, I'll retrieve my hp manuals and type in
an example or two.
---
Clearly memory on chips has gotten far larger, and cheaper too,
than back in the late 70's when the Apple Laserwriter, and Postscript,
came out.
It'd be so easy to add local and global variables and then
"compile" them into "raw" efficient postscript when needed.
People of course do write postscript, and not always short
and simple programs either.
Should would maie it simpler, and far less easy to make
stupid errors.
David
David Combs
Don Lancaster
Don Lancaster
Um, not even wrong, actually.
Peter Davis
platform-independent, printer-independent graphics code. Much of its
beauty stems from the fact that it's self-contained ... it's fully
defined and neither needs nor offers interfaces to other programming
languages or systems. This is also part of it's limitation, because
it's impractical to try to incorporate PostScript into systems that
also make use of other programming models, such as C++. There's no
particular limit to what you can do in PostScript (though it may not
offer the best performance for many types of applications), but that
fact that it's oriented towards creating page descriptions tends to
narrow it's usage. Also, the fact that Adobe has all but dropped it
from further development hasn't helped.
I've used PostScript extensively, not just for writing page
descriptions, but also for writing code that interprets PostScripts.
I've also used it extensively for developing graphics algorithms.
I wish Adobe had added transparency and some of the other features
that PDF has acquired. I think it could certainly have grown in the
direction of JavaScript and ActionScript ... an interpreted language
for manipulating a browser DOM, but the PostScript imaging model is
much lower-level than a DOM, so a fair amount of re-tooling would have
had to take place. PostScript could easily have objects at the DOM
level, but browsers probably did not want to provide access at the
PostScript (individual glyph placement, traversing glyph outlines,
etc.) level. This is changing though.
-pd
Sp...@controlq.com
> Date: Tue, 1 Jun 2010 06:57:56 -0700 (PDT)
> From: Peter Davis <pfd...@gmail.com>
> Newsgroups: comp.lang.forth, comp.lang.postscript
> Subject: Re: Forth versus Postscript
>
> PostScript is a simple, beautiful language that makes it easy to write
> platform-independent, printer-independent graphics code. Much of its
> beauty stems from the fact that it's self-contained ... it's fully
> defined and neither needs nor offers interfaces to other programming
> languages or systems. This is also part of it's limitation, because
> it's impractical to try to incorporate PostScript into systems that
> also make use of other programming models, such as C++. There's no
> particular limit to what you can do in PostScript (though it may not
> offer the best performance for many types of applications), but that
> fact that it's oriented towards creating page descriptions tends to
> narrow it's usage. Also, the fact that Adobe has all but dropped it
> from further development hasn't helped.
>
> I've used PostScript extensively, not just for writing page
> descriptions, but also for writing code that interprets PostScripts.
> I've also used it extensively for developing graphics algorithms.
Peter,
Can you provide any interesting, non-trivial code snippets which might be
run in, say ghostscript or GV to demonstrate your point? Your enthusiasm
certainly begs the question 8-).
Cheers,
Rob Sciuk
Peter Davis
> Peter,
>
> Can you provide any interesting, non-trivial code snippets which might be
> run in, say ghostscript or GV to demonstrate your point? Your enthusiasm
> certainly begs the question 8-).
>
> Cheers,
> Rob Sciuk
Is there a line limit for posts to this group? I have a sample that
takes a path and produces a simulated airbrush stroke, but that's
about 300 some odd lines.
Some other things I've used hand-coded PostScript for:
1) "Personalizing" images by overlaying text formed from smaller
images.
2) De-constructing Illustrator files to create various visual effects.
3) Simulating transparency.
4) Detecting shape intersections in order to put text inside one
shape, and have it flow around another shape
5) Redefining operators to detect and modify features of other
PostScript code.
etc.
-pd
Albert van der Horst
Peter Davis <pfd...@gmail.com> wrote:
>On Jun 1, 11:53=A0am, S...@ControlQ.com wrote:
>> Peter,
>>
>> Can you provide any interesting, non-trivial code snippets which might be
>sm
>> certainly begs the question 8-).
>>
>> Cheers,
>> Rob Sciuk
>
>Is there a line limit for posts to this group? I have a sample that
>takes a path and produces a simulated airbrush stroke, but that's
>about 300 some odd lines.
>
>Some other things I've used hand-coded PostScript for:
>
>1) "Personalizing" images by overlaying text formed from smaller
>images.
>2) De-constructing Illustrator files to create various visual effects.
>3) Simulating transparency.
>4) Detecting shape intersections in order to put text inside one
>shape, and have it flow around another shape
>5) Redefining operators to detect and modify features of other
>PostScript code.
I've used it to show clouds of poison gaz on maps. It is pretty
easy to extract a whole map from e.g. a CAD database and print
it in postscript.
Background shades like on geographic maps to indicate elevation are a
snap.
Specifying the coordinate system is possible, so you
plot the real coordinates.
On my site below there are some simple examples printing
Assembler Code Maps, especially recommended because they
show one of the maior conveniences: things can be printed
in random order and cadres are easy too.
PostScript is well supported on Ubuntu, and by my Brother
printer. Ghostview made it easy to use on even Windows 3.11
and the first HP printers.
texinfo can generate postscript. I will supply .ps files
for ciforth documentation alongside the pdf's for an
undefinite time.
>etc.
etc.
>
>-pd
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>Is there a line limit for posts to this group? I have a sample that
>takes a path and produces a simulated airbrush stroke, but that's
>about 300 some odd lines.
In comp.lang.forth there is no line limit (don't know about
comp.lang.postscript). However, my experience is that people are not
very amenable to discuss long programs (and I guess that this holds
even more for non-Forth code). Instead, put the code on the web for
downloading and running, and in your posting include a link, and maybe
some interesting and short fragments in the posting where you can show
your points.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2010: http://www.euroforth.org/ef10/
Peter Davis
Ok, you should be able to get airbrush2.ps from ftp://ftp.pfdstudio.com/
It's a simplified earlier version of the airbrush simulation code. It
generates a bunch of random Bezier curves, and renders them with
different colored airbrush strokes.
I make no claims for it's being a great example of PostScript
programming. It simply illustrates that fairly complex programs are
possible. The book, _Mathematical Illustrations_, by Bill Casselman,
is a much better illustration of the power of PostScript. It's
available on-line here:
http://www.math.ubc.ca/~cass/graphics/manual/
-pd
Robert Bonomi
I can't share the code, but I've (hand-) written _production_ PostScript code
for formatting tablular data. Give it a page Title, sub-title, page number,
date, and a matrix of data, and it 'did the right thing'. The PS calculated
column widths, inter-column spacing, decimal-aligned all-numeric columns, etc.
It would adjust the font size, and/or tweak the 'set width' (giving a moderatly
'condensed', or 'expanded' face), etc., as needed. Throwing a table of data at
the printer, one did _not_ know what it was going to look like coming out, just
that it *would* 'look right'. :)
When you're publishing books of nothing but statistical tables, something like
this is *really* handy for ensuring uniformity.
I _could_ have done this on the host computer, *but* it would have required a
_lot_ of detail information about the font(s) being used. Something as
'trivial' as an equivalent for PS's "stringwidth" takes a fair bit of code to
account for things like 'kerning pairs', etc. PLUS, you have to have all those
font metrics available to, and accessible by, the application.
All that information is _already_ available inside the postscript interpreter
envirnment, and is _guaranteed_ to be consistent with the atual page rendering
(for 'obvious' reasons <grin>) so it 'just made sense' to do it 'in the
printer'.
It's also worth noting that if one font was requested, and a a -different- font
was substituted -- with *differnt* font metrics -- the page *still* rendered
'correctly'. Unlike what happens with host-based layout using a font _it_
knows about, and a printer substituting something with different metrics.
Aside, the 'table' procedure was downloaded and stored 'permanently' in the
printer (a high-end printer, with it's own internal hard-disk), so a minimal
print-job looked like this:
%!PS-Adobe
(Page Title)
(Sub-title line)
(Page number)
(Date)
[
[ (col 1 hdr) (col 2 hdr) (col 3 hdr) ... ]
[ (col 1 row 1 data) (col 2 row1 data) ... ]
[ (col 1 row 2 data) .... ]
[ (col 1 row 3 data) .... ]
...
...
]
table
showpage
^D
Even the most 'moronic' line-printer-only oriented database report-writer can
produce -that- kind of output, with very little 'persuasion'. Can 'proof'
for accuracy from a line-printer or glass TTY, etc.
Peter Davis
> In article <alpine.BSF.2.00.1006011151210.49...@yoko.controlq.com>,
>
> I can't share the code, but I've (hand-) written _production_ PostScript code
> for formatting tablular data. Give it a page Title, sub-title, page number,
> date, and a matrix of data, and it 'did the right thing'. The PS calculated
> column widths, inter-column spacing, decimal-aligned all-numeric columns, etc.
> It would adjust the font size, and/or tweak the 'set width' (giving a moderatly
> 'condensed', or 'expanded' face), etc., as needed. Throwing a table of data at
> the printer, one did _not_ know what it was going to look like coming out, just
> that it *would* 'look right'. :)
The whole area of in-printer page formatting is interesting. You're
right that it's the best way to get accurate font metrics, page
dimensions, and even device resolution (as used in my airbrush code).
Xerox has a whole product-line based on PostScript code that does in-
printer formatting. Graham Freeman's Quikscript is another example, a
formatter that uses a PostScript prologue to parse mark-up commands
embedded in document text and layout the document during printing.
-pd
Helge Blischke
See also
http://www.cappella.demon.co.uk/tinyfiles/tinymenu.html
The PostScript Markup for Self-Printing Books.
Helge
François Robert
...
> Can you provide any interesting, non-trivial code snippets which
> might be run in, say ghostscript or GV to demonstrate your point ?
An example of PS coding was a ray-tracing program that dates back from
1988 circa:
http://www.physics.uq.edu.au/people/foster/postscript.html
Also uncovered an HTTP web server :
http://www.informatik.uni-freiburg.de/~danlee/fun/
Finally, professional DTP software (InDesign, etc...) come with a
separation procset. There also used to be a free example of such a
piece of PS code called "Aurora" but I can no longer find it online.
A separation procset is a PS program (a "prelude" if you prefer) that
"overloads" graphical operator with same-name procedures so that they
produce a single ink output (in grayscale usually). This was (and
still is) used to produce the plates used in offset quadrichromy
printing (Cyan, Magenta, Yellow, Black inks) plus any spot ink.
The idea is as follow (for a Cyan ink output). If you define :
/setcmykcolor {pop pop pop 1 exch sub setgray} bind def
then your plain code
0.5 0.5 0 0 setcmykcolor
0 0 100 100 rectfill
suddenly starts to draw a 50% gray square (which corresponds to the
Cyan plate content).
Of course a complete separation procset must deal with all the
capabilities of the PS language (all colorspaces, gradients, images,
vector drawing, text, overprint....) and with some adhoc extensions
(Adobe TN1044). That and the PS code you intend to separate must be
well behaved (hence the EPS conventions).
All of this has been more or less obsoleted by In-RIP separation.
François Robert
Forgot to mention also the tools that come with GhostScript (/lib/
*.ps, along with some wrapper shell scripts for invoking them) :
in particular GIF / JPEG / BMP viewers that read and parse files from
the filesystem to render them in GS graphical window.
Still more example include some code posted here
(comp.lang.postscript). Among contributions of mine, a procedure that
loads a font from a PFB / PFA file, and some code that generates a
Type 3 font for EAN/UPC barcodes. I recall seing a TIFF parser too.
LC's No-Spam Newsreading account
>> Can you provide any interesting, non-trivial code snippets which
>> might be run in, say ghostscript or GV to demonstrate your point ?
Quikscript is an entire word processor written in PostScript, does it
qualify ?
http://www.itee.adfa.edu.au/~gfreeman/qs.html
--
----------------------------------------------------------------------
nos...@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
tlvp
> ... The book, _Mathematical Illustrations_, by Bill Casselman,
> is a much better illustration of the power of PostScript. It's
> available on-line here:
>
> http://www.math.ubc.ca/~cass/graphics/manual/
Peter, thank you for this marvelously informative reference manual URL!
Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP