World: r3wp

Well, the dialect doesn't take PS as input, it produces PS. A PS 
file can be printed from REBOL in a way, Graham showed. Like:
>> port: open/direct tcp://192.168.1.253:9100
>> insert port read %boys-0-36-length-weight.ps
>> close port


192.168.1.253 is the IP of the printer, 9100 is the port, where the 
printer get data.

The dialect, I'm developing here, is for making it easier to produce 
PostScript output from within REBOL. Next step is to make a converter 
from the DRAW dialect to PostScript, so any DRAW data can be printed.

And now I'm at it, learning a bit PS and all, it'll make sense for 
me to make PS output from my NicomDoc format.

Reichart, the thing, you're asking, is taking a PS-file as input 
and render it, like GhostView does. It'll take a bit more work to 
parse PS-files, but it's not impossible. I have no intension doing 
that for now though.

Got it..............cool.

reichart, on your mac, Preview.app eats PS files for breakfast, in 
case you want to try that

John, postscript uses a number of defined fonts.  Ignore the fonts 
on your system. The ones important are the ones in your postscript 
printer.

louis, check out http://www.hmkdesign.dk/rebol/barcode/

There are no docs, but I hope the demos are a bit explanatory

Henrik, thanks, I will play with it.  I have this great Mac sitting 
on my desk, but I don't seem to use it enough.


NOTE: I'm still tied to my PC, and TRYING to get away....so far it 
seems I'm held to just a couple of issues....I have not had time 
to write up the "PC MAC LINUX" chart I want so I can figure out what 
it takes for me to move over.  But the first big one is still a thumbnailer. 
 I use ThumbPlus.  If they were on Mac and Linux, then I think the 
move would be a lot better.  I use this about 10 times every day. 
 We can move this chat if you want to engage me on the Mac issue.

John, just reading that link you gave to a postscript document structure, 
and I think we should change the prolog to say 
%!
instead of
%!PS-Adobe-3.0
as the latter says that the document is fully conforming.

The prolog is quite important to allow document managers to manage 
the postscript file properly.

It was interesting to note that postscript file managers can pull 
out the colour graphic pages and send them to be printed on colour 
lasers, and let the rest be printed on the monochrome lasers.

.. meant document print manager.

Looks like we need to terminate the document with a comment
%%EOF

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.