AltME groups: search

xavier: ghostscript maybe!? Depends on your OS. If you have a PS-net-printer, 
it's also possible to send it to a port on the printer.

it worked ... i was searching a dialect for formatting outputs that 
have to be printed ... and just find it

Very cool John! Now, if we can get a DisplayPostscript engine in 
R3....

Cyphre .. how feasible would a PS renderer be in R3?

Graham - isn't PS rendering "just" a question of particular dialect, 
translating into View faces rendering? (sorry, I am not fluent with 
PS, so dunno what would be needed, just asking)

I did a demo somewhere which showed the problem.

the other thing that PS has is a way to save the graphic state .. 
do stuff... and then restore the state

imo draw, as introduced to View, is a hack .... it lives in effect 
pipeline, is that correct?

maybe face, as a gob, should be more general, with some pluggable 
mechanisms ....

r: rot: 0 view layout [origin 0 box 400x400 white effect [draw [pen 
black translate 200x200 rotate

 rot translate -200x-200 box 100x150 300x250]] rate 0 feel [engage: 
 func [f a e][if a = 'time [r: r +
 1 rot: 360 // 360 - r show f]]]]

I like the look of DRAW! :-) (Of course it's due to AGG.) I still 
miss a version of REBOL for Mac with full DRAW, as the Windows version 
has it.

Pekr, yes I still have Canvas RPaint on hold until I can release 
a final version 1.0 for Windows, OS X and Linux at the same time. 
Some DRAW things are missing, which Windows version has.

do you need cross-platform compatibility for intitial release? Hmm, 
maybe so, as a marketing advantage ...

When I was just about to release it, I desided to wait for better 
support of DRAW on the other platforms (and in some way for rebcode 
too). Looking back, I should maybe have release it almost a year 
ago. It's just, that Windows always get the good stuff. I use OS 
X now, and REBOL is cross-platform, so a thing like RPaint should 
be the same on all platforms. I'm also concerned about marketing, 
as you say. Releasing for three platforms at the same time is preferable 
for me.

We don't know for sure. That Carl is using OS X daily now might be 
a good thing for my situation. We can hope, wait and see.

Do this in a REBOL prompt to run the test:

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

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

Now the file %test.ps holds the postscript output.

are those dialects a bit compatible, or completly different syntaxes?

reading your Synapse link reference - actually that is the quesiton 
of POV, for me the first paragraph has completly reverse meaning 
"The advantage of using PostScript is that Synapse EMR can display 
them nativey, and does not use PDF for printing.". I think that most 
ppl and platforms do have PDF Reader of some form, which means - 
I've got a preview mechanism, avoiding user to easily modify the 
output.

Shortly you can say, PS is a language (used by professionals describing 
output in a very precise way) and PDF is a document format.

pekr, the advantage of using the PS dialect is that it can be fed 
directly to a postscript printer. This enables printing in all versions 
of REBOL. PDF needs to go through an external PS conversion program 
to do the same.

Pekr: from the geomol's link: "A PDF file is actually a PostScript 
file which has already been interpreted by a RIP and made into clearly 
defined objects. These objects are viewable on screen not in code, 
but in visual objects that everyone can see."

TeX is a markup system, kind of like HTML. you can produce PS documents 
from TeX files.

Yes, it might be a bit difficult for end-users to preview PS (unless 
you use Mac OS X or the like), where PDF might be easier to preview, 
because "everybody" now-a-days has Acrobat Reader.

Henrik - 95% of everythin I want to print, goes via preview first. 
The need to install GSview or something like that is total problem 
(because of already current penetration of Adobe Readers, I regard 
it being a solved case :-)

something with clearly defined graphics, maybe with a few varying 
text fields.

I tried and failed, but I might have used a wrong approach. Graham 
has done some PS previewing in a demo.

PDF is basically a compiled PS document. Requires less "brainpower" 
to display.

geomol, I think that it should be kept at a low level. This way I 
or someone else can build a library of standard things on top of 
it to generate formatted pages, tables, formatted paragraphs and 
such.

Henrik, yes, the postscript dialect should be low-lever as it is 
now. It's a fine base for further development. You can use it directly 
as you do, or someone could build new dialects producing postscript 
dialect output, which then can be made into final PostScript. (If 
you know, what I mean. Difficult to explain.) :-)

yes, it can become very powerful. one could actually build a system 
like LAYOUT this way to build PS documents.

in fact, I think it would be a good idea to coordinate this, in case 
someone wants to start building such stuff to avoid duplicate or 
overlapping efforts.

ps2pdf is also a command (I think included with Ghostscript): http://www.cs.wisc.edu/~ghost/doc/AFPL/6.50/Ps2pdf.htm

Pekr, what about making a small REBOL program, which can load postscript 
dialect txt-file, convert it to a .ps file, then call ps2pdf and 
finally call a PDF-viewer (Acrobat Reader) to see the result. You 
could also include a button to send the .ps file to a printer. Then 
you'll have PostScript with preview and all (also under Windows).

(Also I'm on OS X, so I don't have the preview problem, because the 
OS auto convert to PDF, if I'll like to see a .ps file.)

Rebolex, that's such a nice target for liquid... is the code anywhere?

Perhaps we need a little print-spooler in a multi-user environment? 
May be a good job to solve using REBOL. It should be able to receive 
printjobs from plenty of users at the same time (using multi-threading 
much like the way Apache serve multiple users with web-pages) and 
then send the jobs to the printer one at a time. Maybe someone already 
did it in REBOL? Or if there is a server at hand, just send the jobs 
to the spooler in the server. I'm not too familar with spoolers. 
Will they leave the PostScript printjob as it is, and just send it 
to the printer? I could figure, that Windows spoolers would like 
to change the PS into something else using a print-driver.

I wrote a very small one, about 2 kb in size with a GUI. I can't 
remember, but I think it uses Rugby.

I made it for a very specific purpose (as one would do in REBOL), 
so it may have to be rewritten.

is there someone who have an idea for printing in rebol on a dot 
matrix printer ? i have to pilot it for printing a pre formated bill 
for dental care.  If anybody see what i mean..  I was wondering about 
how to do it in rebol, by passing by a markup langage but i dont 
know how it work.  if anybody got an idea...

i probably have to do it with a tally manesman if it can help

and a dot matrix printer is not supposed to be connected by something 
else then the lpt port

if you have access, try this on the machine in a dos prompt:

echo test > lpt1:

You may wnat to investifate Epson escape codes, eg:
http://www.cyberroach.com/analog/an10/epson.htm

There is a chance the printer will respond to them, and it may give 
you extra flexibility -- eg sending tabs rather than loads of spaces; 
or bolding, underline etc.

A bit like curses:
http://www.rebolforces.com/articles/tui-dialect/

neat. could sometimes be nice if you are using SSH terminals a lot.

it must be possible to describe a document for a dot matrix printer 
with that

That would be cool. I'd like to see if there would be a way to make 
it more powerful, something along the lines of Functional PostScript.

I always thought Scheme was a little clumsy for that. REBOL should 
be better.

The latest version got rid of many of the blocks:
http://home.tiscali.dk/john.niclasen/postscript/postscript.html

A test source: http://home.tiscali.dk/john.niclasen/postscript/test.txt

Sweet. I'll take a look next week.

right, but does the printer center the drawing or put it in a corner 
or scale it up or how?

I'm just not sure that is a good way to handle page sizes

most of the time I think most eps printing is done inside a dtp program 
and you can then shift the image around to where you want it.

you would need a postscript interpreter to find out where the image 
is going to go.

it seems Preview insists on using Letter as page size for postscript.r 
output. I have to assume that a real printer does the same. I need 
A4 and A5 both in portrait and landscape.

because eps is just a special postscript file that does not permanently 
alter the environment

you need a bounding box in your ps file

oh, hang on. there was a combination of things I didn't try here...

it behaves like a printer with letter paper in it. and just scales 
anything to fit in it.

if I ask for a print preview and specifically ask for A5 paper, it 
clips the drawing like a printer would

created a postscript knowlegde base checklist

A couple of useful PS links:

How to generate portable Postscript: http://alumni.media.mit.edu/~szummer/postscript/

What is the physical size of the page?: http://www.postscript.org/FAQs/language/node64.html

How to use Adobe PostScript language files properly.: http://www-cdf.fnal.gov/offline/PostScript/AdobePS.html

(Look under "Paper bin, tray, size, feed mode, etc. selection", where 
you also find a link to:)
PostScript Sins: http://www.byte.com/art/9508/sec13/art3.htm
Gripes: http://www.cs.wisc.edu/~ghost/doc/gripes.htm

Geomol, I made a checklist for links

Geomol, I've added EPS output, bounding box and page orientation 
to postscript.r. This is done with a 'preamble which is followed 
by a block.

Regarding landscape, then I think, it's just a comment in PS (%%PageOrientation) 
used for previewing.

It may be more clear, if we look at PS as a low level language to 
control some type of printer or typesetter. It goes like: move to 
this position, print this text using this font, move to this other 
position, print text, ...

Landscape is done with 90 degree rotation before doing the print 
command.

which is also why it would be tough to do in VID, since it does not 
have a method for easy 90 degree rotation of text

well, DRAW can't use proper centering and right alignment... somehow 
this reminds me of a toolbox with a broken hammer and bent nails...

Must be a change of heart occuring .. Carl said he never imagined 
anyone doing type setting with Rebol!

but a basic thing like placing text according to the baseline is 
also missing. this is also not brought up to REBOL level.

Yeah, it's a bit tricky. There's a link in the DRAW docs to: http://www.w3.org/TR/SVG/coords.html#EstablishingANewUserSpace
where you might get some explanation.

It's just a general way of combining different effects.

I messed around with it a bit to get it to print on A5 sheets, but 
ended up just drawing on the A5 area.

Yes, if it's a good idea to put pagesize in there. I did a test and 
missed some lines in the top of my document, when producing ps output.

I was afraid of messing with it, since only a single error, such 
as leaving a standard postscript command out or putting another one 
in, caused some printers to stop working with it.

There is a bug with printing multiple pages on certain HP printers. 
After the first page, some char is missing, that causes it to wait 
until you press the Online button or page feed button. I really would 
like that to be fixed. The work-around is to print to a file and 
have it printed using Printfile under Windows.

it was a panic situation .:-)

Added PageSize and images to the PostScript dialect. There seem to 
be a problem with jpg!?
Henrik, try this:

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

write %imagetest.ps postscript [page [translate 100 600 scale 72 
72 image logo.gif translate 100 500 scale 144 144 image logo.gif 
translate 100 300 scale 288 288 image logo.gif]]

Then view or print the file imagetest.ps

This gives a result, that I can't view on my Mac for some reason:


write %imagetest.ps postscript [page [translate 100 400 scale 72 
72 image http://www.rebol.com/view/palms.jpg]]

Any suggestions?

I have problem viewing the test with jpg here. It can't convert it 
to a viewing format (prob. PDF). Can you test the ghostscript viewer?

Yes, images are handled as REBOL image! types. If the dialect is 
given a file! or url!, it'll load the image. It can also take a word!, 
which is the image. It then convert the image/rgb to base-16 and 
put it in the ps-file.

So images in postscript files take up a lot of space! Most people 
knows this already. I tried to put a 100k png image in a postscript 
file, and it then was > 11MB.

But if the image is big, it remains big ... not that it's a problem 
because it's being dumped to a printer.

it's a problem for speed, but perhaps there really is no way around 
it

Here's an article on coverting a jpeg to image using postscript functions 
http://www.tinaja.com/glib/jpg2pdf.pdf

This with large printfiles, it's the same, that happens, if you print 
text using a font, that the printer doesn't know. Everything is converted 
to image data, and one page can be several MB.

The image problem seems to be related to size. I tried to make a 
little image entirely in REBOL, and I can see that. Making a larger 
image, and Preview under OSX can't convert it to PDF. I would like 
to know, if my example above with palms.jpg can be printed on paper.

Since postscript is a printer language, it can print the stacks if 
it encounters an error.

sure if you're using ghostscript .. I meant if you were testing on 
a postscript printer.

You have to write a postscript function that prints the stacks.

No.  Just a debugging function that you add to your postscript file 
that you are trying to print.

perhaps that would be a good thing to include in the dialect.

wow, that took a long time to generate.

Maybe because it had to load image from web also!? Try with a local 
version of the image.

Maybe your system had a hickup? Try again!

will test with a local file soon

Try take a local copy of postscript.r and change the load-image to 
not do a /update.

perhaps 12 seconds with a local palms.jpg file

Images are implemented in postscript.r using ASCIIHexDecode filter, 
which double the size of image data. It would be better to implement 
ASCII85, which does a 4:5 increase only.


Also images are handled in something called dictionaries in PostScript. 
This require PostScript v. 2.0.

If you look in postscript.r, I encode the image data in line 211-220. 
It's just normal hex written as ASCII, so you get '0'-'9' + 'A'-'F'.