World: r3wp

the point of writing conforming postscript is that a manager might 
take that document and print it 2 or 4 up or whatever.

Looks like images can be incorporated into the ps file as hex data.

Graham, thanks for the info. I'll deal with these things in one of 
the following days.

Just wondering whether it is preferable to build the dialect so that
postscript-dialect => postscript, or => draw

rather than trying to write a parser that converts draw to postscript.

I think the most common scenario for those of us wanting to do printing 
is to to compose a page, preview it and then print it.  This way, 
we have the one dialect that covers both bases.

the draw dialect is too low level I think for this.

Intersting...

So many dialects needed.

dialects cover specific problem domains.

Oh, agreed....................my thought was simply how many dialects 
we are all working with, and how this number will grow until there 
is need for a new approach.


For example, XML is a dialect of sorts, for transmitting discrete 
data.  PS for rendering information in 2D.  HTML for rendering information 
in such a way that those that are challenged can us verbal readers, 
or physically challenged can ID links and important parts.  MakeDoc 
for converting  few symbols to complex rendering instructions that 
can be represented by HTML.

Esperanto didn't cut it.

Reichart, don't confuse language with dialect. PS and HTML are languages, 
not dialects (you can say that HTML is a dialect of SGML, to some 
extent).

i.e. there is no common ground between PS and HTML and so on.

I guess, the number of dialects is defined from the number of problem-domains. 
I think of them as the sub-languages different professions have. 
Doctors use their words, car-mechanics theirs, programmers yet other 
words and terms. So there might not be a limit for dialects, like 
there might not be a limit for new professions.

I think, it was Gregg, who pointed it out at last DevCon: Define 
a dialect, and you've solved the problem. Once you've defined the 
perfect dialect to solve some problem, the problem-solving code (programmed 
in the dialect) might just be 10 lines.

Can we make this group web-public?

Ok by my.

me

(Damn, now the public will se, how bad my english is.) ;-)

not if you hide behind a pseudonym!

Ok, made web-public .. can now point people to this thread who are 
interested in postscript.

But remember they'll only see the most recent 300 messages.

So the more popular a group is, the less the public can see of it.

Maybe we need a [web-archive] flag too for groups that will be published 
in full [reply in chat as this is off-topic for postscript)

New version of postscript.r uploaded! I've add the prolog %! and 
epilog %%EOF as Graham suggested. I also wrapped paths in the postscripts 
commands gsave and grestore, so transformations give less trouble. 
Try this:

do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript load http://home.tiscali.dk/john.niclasen/postscript/test.txt


You now have a postscript file "test.ps" produced by the dialect. 
It's content looks like this:
http://home.tiscali.dk/john.niclasen/postscript/test.png

To see, how using the dialect look in use, see the "test.txt" file.

I'm building EAN13 barcode support for PS now. not very hard

The output postscript file from the dialect can be sent to a postscript 
printer, so no driver is needed.

Great, Henrik!

The dialect is just a version 0.2.3, so it can be better!

now I'm imagining: this is really lowlevel stuff, but I think it 
would be neat to build standardized higher level primitives. a barcode 
is such a primitive. barcharts, 3D views and complex symbols could 
be other types of primitives. just brainstorming...

Yes, good ideas! It's not the meaning, that people should write in 
the postscript dialect directly. Building higher level dialects and 
primitives/applications on top of the dialect is the way to go.

but it should also be consistent. a dialect with primitives? a library?

The postscript dialect is just there to make printing easier, as 
was your intension with making this group.

that's true... maybe it would be better to approach it through DRAW 
and let postscript.r do the dirty work

Developer libraries and standards are good! It's been a big part 
of my job the last 15 years or so making programming libraries for 
developers. If I could make money developing REBOL standards and 
programming libraries, I would use more time on it.

I'm sometimes thinking about, if REBOL developers are willing to 
invest in programming libraries. Maybe there are too few?

I think there are too few, then again, more might come if there was 
a consistent set of libraries. more than the current collection of 
scripts on rebol.org anyway

I think this was the idea of the Rebol Powerpack?

and slim.

and steel.

geomol, I don't know if you've seen this link: http://www.cs.wisc.edu/~ghost/doc/gripes.htm

No, didn't know that one. Good to stick to the rules, thanks!

Let's see ... what is needed more in the dialect, before a DRAW -> 
PostScript converter can be made? Images! Something else?

curves?

fills?

haha, you're faster than me. I was just going to say curves.

How fills? You can fill a box with boxfill.

We also miss circle.

and clipping ... argh, tough one, me thinks.

arcs

is there any typography handling?

Not in DRAW, I think.