AltME groups: search

Not sure how it works in PDF, but I wrote a VID/Postscript converter, 
using the layout engine of VID to "typeset" in postscript. Maybe 
this is the way to go for a PDF typesetter.

I must say that I had a lot of fun coding that scheme, especially 
learning CUPS and coding some Postscript custom routines.

I've spent a lot of time with MDP, written a whole distributed application 
with pages based upon the principles of MDP.  The biggest mess in 
MDP is the need to make HTML pages, which is a fossil and pretty 
awful, but widespread.  People need HTML so we output that.  People 
may want PDF, or RTF or Postscript or MarkDown, or whatever.  Those 
parts will always be a mess because the formats of all those outputs 
are a mess.

From the postscript group - it makes more sense to bring the archive 
of posts made in web public groups into rebol.org

Do you see any text ?  Or, do you have to install some postscript 
fonts?

I just want to send some postscript to the attached postscript printer 
on the parallel port.

The http://www.bluishcoder.co.nz/2006/06/unenterprisey-languages-meeting.html
meeting was mildly interesting.  Robert Strandh showed how he reimplemented 
metafont in common lisp with the main aim that he could provide print 
services for his G# music score editor.  This was implemented as 
a DSL, and printing done by converting the DSL to postscript.  Familiar??

Glad to see that will be fixed.  Otherwise in the postscript dialect, 
you can't specify a point like 5.5x6.3 cms

I created a group on the challenges on creating postscript documents 
directly from REBOL.

It was suggested in the PDF-Maker group that it could be possible 
to convert a DRAW block to postscript. I think that would be a good 
approach.

PS is good for what nowadays? Printers? Who does use it?

 <--- most printers today accept postscript input through the driver. 
 It's incredibly relevant if you want to create printing applications 
 directly with rebol.

PDF is also only a subset of postscript, created so you don't need 
to compile your docs everytime they need to be displayed. PDFs are 
static. You still need postscript to do the actual printing AFAIK. 
The trick would be not necesarily to generate a PS file, but the 
data that could be fed to the printer through LP.

there are full docs on how both pdf and postscript work available 
from adobe.com

OK, if for postscript reasongs, then be it. I just hope we are not 
about to resurrect things like PS Viewer in View or something like 
that ...

pekr, this is mostly to make printing easier. postscript is also 
very cross platform.

I'm not sure there is anything particularly highend about postscript 
today. It was originally created to make printers output graphics 
somewhat consistently with what is shown on screen. Early printers 
only had this in hardware, but most printers today can act as software 
postscript printers.

Also I'm trying not to be document centric. That comes before the 
postscript part. Postscript is any kind of graphics.

Gabriele mentioned that a postscript emitter wouldn't be very hard 
to do, compared to PDF.

As I said in the pdf maker group ... postscript is a much easier 
thing to do than pdf.  I could then do high resolution graphs in 
postscript, and then use ghostscript or other utilities view and 
print.  Conversion to pdf is another possibility.

this is a simple guide to postscript .. I read this the other day, 
and was programming in postscript the next.

http://www.cs.indiana.edu/docproject/programming/postscript/postscript.html

Graham - either give me native rebol post script viewer, or forget 
it. I will not install ghost script - being there, done that. Because 
- today, in corporate sphere, there are two output interfaces - browser, 
or PDF Reader - noone will install anything else. I do agree that 
to get things right using html/css in cross browser manner may be 
pretty difficult task, but imo that postscript should be somehow 
- hidden?

I have no wish to defend my desire to see a postscript emitter.  
I only wish to see it done by people who have a mutual interest. 
 If you don't think it is of interest, please do not post negative 
comments.

Here's a first attempt at drawing postscript and then converting 
to pdf ... http://www.compkarori.com/emr/growth.pdf

Both PostScript and PDF ref. manuals are found on www.adobe.com. 
I took a quick look and found out, that PDF is mainly a document 
format incl. things as hypertext links and logical structure information 
for document interchange. Postscript's primary application is to 
describe the appearance of text, graphical shapes, and sampled images 
on printed and displayed pages. It makes good sense producing PostScript 
from REBOL to enhance printing abilities, and if it's much easier 
than pdf (as Graham points out), there is good probability of success. 
And supporting PostScript doesn't exclude pdf. We can have both, 
and it's two different things with different goals.

Gregg, it's like cgi... unless you've got a web server, cgi is a 
waste of time for you.  If I have a web service that uses a postscript 
dialect to create a postscript image, and then uses ghostscript to 
convert to pdf .. well, that is useful to those running web services, 
but a waste of time for those who don't.

I've got a colour laser printer on my network which I think supports 
postscript.  I presume to print a postscript file, I just send it 
to the ip address of the printer?

and I printed out my postscript file with no problems.

That was pretty easy ... create the postscript  file, and send it 
directly to the printer, or print server.

moveto 72x72, or moveto 72 72 
postscript is RPN, so that looks like 72 72 moveto

I guess if the main aim is to take drawings to postscript, then that 
makes sense.

So, for example, if we used to plot dialect to draw a graph, we can 
then emit postscript and send directly to the printer.

An eps file is just a postscript file which is written in a special 
way ...

DRAW is also a function used like:
img: make image! 100x100
DRAW img <some draw commands>

With PostScript, I'm thinking something like:
ps-output: ""
POSTSCRIPT ps-output <some PS commands>


ps-output could then also be a file! or port! and send the output 
directly to the destination.

Is the aim to take a draw block and process it so that postscript 
is produced.

but let's start with a postscript dialect and then see if we can 
retrofit draw to it.

this has a reference at the end : http://www.cs.indiana.edu/docproject/programming/postscript/postscript.html

Is this works, you can then render your paint images to postscript 
printers :)

PostScript dialect test ready. Try this:
do http://home.tiscali.dk/postscript/postscript.r
s: postscript [font ["Times-Roman" 20] ["Hello World!"]]


s is now the PostScript output, that can be saved to a PS-file or 
sent to a printer.

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

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

** User Error: Error.  Target url: http://home.tiscali.dk/john.niclasen/postscript/postscript.r
could not be retr
ieved.  Server respons...

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

you need to tell the postscript engine where to place the text.

there's also a postscript preamble or header.

Oh, misunderstood.
Try:
s: postscript [font ["Times-Roman" 20] [at 72x72 "Hello World!"]]

I need to learn more about PostScript.

things like 'box can be defined as a function in postscript.

his dialect must cover the same problems .. as pdf is a subset of 
postscript.

I'm not sure .. I've only read about postscript in the last day.

New version. The postscript block consists of font definitions and 
pages. A page consists of paths and transformations. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

print postscript [font [Times-Roman 20] page [path [at 72x72 rotate 
45 "Hello World!"]]]

The "page" and "path" words are optional, so this'll give same result:

print postscript [font [Times-Roman 20] [[at 72x72 rotate 45 "Hello 
World!"]]]

A postscript block can have several pages, and every page can have 
several paths.

I found this document describing PostScript structure:

http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

PostScript has a lot of operators (commands). For this REBOL dialect 
to be usefull, we should keep the number of features at a minimum. 
It's always hard to learn something new, and if the number of commands 
is too big, less will use it. I would like feedback on, what features 
should be supported in the dialect for a first version. This dialect 
can then be used in REBOL programs, that would like to do PostScript 
output. And I could make a PostScript output from my NicomDoc format. 
And then we could also have a DRAW -> PS converter.

Ok, text and vector graphics ... and some grey-tone/colour for a 
start. And then the rotate, scale and translate, that's already included 
in my postscript dialect.

that should be very easy to do with a postscript dialect.

New version! Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r
print postscript [page [path [linewidth 10 at 72x72 box 72 72]]]

I do:

write %test.ps postscript [page [path [linewidth 10 at 72x72 box 
72 72]]]
and then open test.ps with Finder.

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

write %test.ps postscript [page [linewidth 5 path [setgray 0.5 at 
72.5 72 boxfill 72 72]]]

you can write postscript functions that translate from one coordinate 
to another.

PostScript normally uses units of "points" for placing graphics on 
the page. I find it more convenient to work with centimeters. I got 
the following snippet of PostScript code from a public domain program 
called "GLE" which I believe is available at any large ftp site; 
I recommend this graphics program. By examining the PostScript output 
of that program I collected the following piece of PostScript code:


matrix currentmatrix /originmat exch def /umatrix {originmat matrix 
concatmatrix setmatrix} def [28.3465 0 0 28.3465 10.5 100.0] umatrix


What this basically does is rescale the page so that now all following 
commands will work as if the centimeter is the basic unit of length. 
This places (0,0) near the bottom left of the page and (21,24) near 
the top right of the page.


If you don't do this, then (0,0) is the bottom left corner of the 
page and (612,792) is the top right corner of the page (if you are 
using an 8 1/2 inch by 11 inch sheet of paper). These are the default 
PostScript units; 72 of these to an inch. 28.3465 to a centimeter, 
thus the numbers above in the last line of PostScript code.

New version with cm!
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [setcm linewidth 20 path [setgray 
0.5 at 2.5 2 boxfill 8 12]]]

setcm seems to influence font size. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [font [Times-Roman 1] setcm linewidth 
0.5 path [setgray 0.5 at 2.5 2 box 8 12] path [at 5x8 rotate 45 "Hello 
World!"]]]

well, my postscript printer printed out a gray box!

whether it's postscript, pdf or whatever.

New version with line, try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [linewidth 5 path [setgray 0.8 line 
72x72 100x72 102.5 87.3 200x115]]]

150 lines of code so far. Can be seen here: http://home.tiscali.dk/john.niclasen/postscript/postscript.r

Postscript is copyrighted?

Adobe gives permission to anyone to:
Write drivers to generate output 
consisting of PostScript language commands.
It's from the ref manual.

I managed to switch y-axis, try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [switchy setcm linewidth 0.1 path 
[setgray 0.8 line 1x1 5x5]]]

Hey, cool PostScript pic, Henrik! :-)

mapping colours from rebol to postscript.

New version! PostScript is default set to DeviceGray with no colours. 
To set it to DeviceRGB, I made a command in the dialect for that. 
Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [DeviceRGB page [switchy linewidth 5 path 
[setcolor 255.0.0 line 50x50 50x100 setcolor 0.255.0 line 50x100 
100x100 setcolor 0.0.255 line 100x100 100x50 setcolor 255.0.255 line 
100x50 50x50]]]

Another example:

write %test.ps postscript [page [font [Times-Roman 40] linewidth 
0 path [at 72x720 "REBOL PostScript Dialect"] path [line 72x716 520x716] 
font [Times-Roman 16] path [at 96x680 "With this dialect it's possible 
to easily produce PostScript output."] font [Helvetica-Oblique 12] 
[at 72x72 "PostScript is copyright Adobe."]]]

now I'm thinking about making postscript output for it

Example with different fonts:

write %test.ps postscript [[font [Verdana 20][at 72x700 "Verdana"] 
font [Helvetica 20] [at 72x650 "Helvetica"] font [Times-Roman 20] 
[at 72x600 "Times"]]]

I guess, it looks at the fonts installed on the system. I'm not sure, 
how 'clever' it is to guess the names.

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.

it would have been a lot more fun if they just used postscript :-)

No, it would have been horrible. There is a reason that even Adobe 
has moved away from Postscript - its model has major problems.

Read up on the research on PDF sometime before you start promoting 
Postscript. It is even a good idea to use PDF instead if you are 
outputting through Ghostscript - it can handle it.

That doesn't even include the execution model change from programmatic 
(Postscript) to declarative (PDF).

That's why Apple based its Quartz model on PDF, when they already 
had a Postscript model from NeXT.

It might have had problems, but it would have been a much better 
starting point, had Microsoft embraced postscript from the start. 
There would have been a common starting point and a much larger incentive 
for building hardware postscript printers at the time. If that had 
been done, printer drivers would not be necessary under any platform 
today, or they would be limited to being postscript rasterizers.

At the start, postscript printers cost thousands of dollars but dot 
matrix printers cost a couple hundred. If MS had gone with Postscript, 
printing would have been stillborn outside of large companies.

no, they would have made postscript rasterizers to make postscript 
work properly on cheap printers.

Postscript printers had much more RAM than that, even then.

Remember that the procedural model of Postscript meant that a Postscript 
printer was a computer, and definitely a more powerful and more expensive 
computer than most people could afford. Even faking Postscript support 
required a computer of at least the same scale.

Well, I still think postscript should have become more widespread 
than it ended up being. And you can't change my opinion on that. 
:-) I crave standardization. OK, so if postscript was too hardware 
hungry, then a lighter version could have helped, which is why I 
wonder why PDF came so late.

So, we need to continue supporting postscript.

It wouldn't be the wrapping of the Windows API that would help Linux 
users, it would be his initial work on making a Draw-like printing 
dialect. Defining the dialect is a large part of the process of supporting 
printing in REBOL. There will be non-Windows-specific parts of Doc's 
implementation that can be adapted to a general printing model for 
REBOL, one that can have multiple implementations with different 
backends. For that matter, there would need to be at least 3 backends: 
GDI (for Windows), Postscript (for Ghostscript) and PDF (for Mac 
Quartz), with a possible XPS backend as a minor variation on the 
PDF one.

I wish I could integrate this with my own printing system, but it's 
highly postscript oriented.

mine focuses more on the UI side, offering various methods of printing 
postscript. there is also a printer queue system as well as a printer 
server.

For information, I've successfully tested direct printing in Linux 
and OS X using PostScript format documents and CUPS as backend. I'm 
currently trying to implement a Draw dialect compiler targeting PS. 
Unix and OS X support wasn't needed for my project, but I couldn't 
resist to give it a try ;-).

Update on the work-in-progress : http://softinnov.org/tmp/test-page.zip


Both files are printed from the same Draw dialect source, using my 
printer:// scheme. The PDF file is printed through Bullzip PDF Virtual 
printer. The PS file is directly generated by the printer scheme 
(for UNIX/Cups direct printing).


Most of the PostScript support is done (see %test-page.ps), but there's 
still a lot of details to enhance/fix/add: 

o Add center/right alignement support

o Add underline style for fonts

o Fine-tune positionning and bold level.

o Fix minor differences with the GDI version.

There are a few good justifications schemes available for postscript

there's also a very nice bar code generator for postscript.

Looks like rebolized PostScript

yes, to make it easier to convert to postscript  and to draw.

gonzo is a postscript utility to do micro justification and other 
goodies

has to be ... can't hide postscript source!

I've uploaded the 35 gnu ttf so that you can use postscript fonts 
for draw http://rebol.wik.is/Protocols/Printer