World: r3wp

It might make more sense for R3, mostly as a thought experiment to 
help us decide on the semantics of the REBOL printing model.

From what I can tell, they did a lot of interesting research when 
they came up with XPS - food for thought.

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

Here's a nice introduction to XPS : http://msdn.microsoft.com/en-us/library/ms742418.aspx

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.

XPS is like a cleaned-up, extended PDF, with an XML representation 
if you're into that. The models are similar.

It would probably be easier to get AGG to output stuff in a form 
GDI would like though, with more overhead from pushing around all 
of that bitmap data of course.

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.

That was considered a hard problem on 8086 computers. Remember how 
far back the "beginning" was...

Initial versions of GDI predate Windows 2.

You know, when they added 80286 support.

Windows 1 ran in 512k or less of RAM, as I recall (likely badly).

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.

And I think it sucks that Microsoft choose to invent yet another 
printer driver mess, rather than converge with existing systems.

But they did converge with existing systems, in semantic model. XPS 
is not that far off of PDF in semantics.

but they are not source compatible, are they?

I guess what I would want for printers, would be like what HTML does 
for webbrowsers.

or perhaps more appropriate, what OpenGL does for displaying 3D graphics 
on screen.

Well, if you are using the OS's facilities for printing you are using 
the API version of the semantics, not necessarily the source. What 
really matters is the semantics - the source is just a generated 
representation.

Wrapping the windows printing api doesn't help linux users :)

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.

So would or wouldn't you advise to go through PDF for printing to 
GhostScript?

I'm very interested in this for both REBOL and Syllable

First test release of Printer scheme for direct printing on Windows 
platforms : http://softinnov.org/tmp/printer.zip

No docs for now, look at the sample %test-page.r script and at the 
scheme implementation. Input dialect is a subset of Draw dialect.

There's still some glitches and it needs some fine-tuning before 
providing real WYSIWYG results when compared to Draw rendering.

Draw dialect maps very well with Windows drawing API (GDI). It's, 
in most cases, a one to one mapping.

But Draw dialect is really too level for a daily use. A higher level 
dialect with relative positionning and higher level constructs (e.g. 
tables support), like VID or HTML is needed.

I highly recommand the excellent Bullzip free PDF Printer for testing 
: http://www.bullzip.com/download/pdf/BullzipPDFPrinter_5_0_0_609.zip

Example of multiples pages printing :

p: open printer://
insert p 'start-doc

insert p 'start-page
insert p [text "Page 1" 50x50]
insert p 'end-page

insert p 'start-page
insert p [text "Page 2" 50x50]
insert p 'end-page
...
insert p 'end-doc	;-- this one triggers the real printing
close p

Btw, the printer dialect use milimeters as unit for positioning and 
size.

Possible additionnal features :


- Support for preview View window is possible, but requires some 
fine tuning first in Printer scheme, for WYSIWYG support. 


- Support for Windows standard printer dialog window could be added.


- Support for setting page orientation, page copies, etc...could 
be added.

I don't think that I will have time to add all those features, so 
it's left as an exercice for the community ;-).

Last but not least, the usual one-liner : write printer:// [text 
10x10 "Hello World!"] ;-)

Awesome Doc! I thought I had forever gotten away from start-doc/end-doc, 
but I guess old APIs never die. :-)

Fantastic!

Gregg: I must admit that I missed the good old VB printer object. 
So now, who wants to clone Crystal Reports ? ;-)

I'm unable to test it here, but what about bringing up the printer 
dialog? Does that happen?

Not currently, but it could be added.

Btw, it's possible to list the available printers using : probe printer/enum

It must be said clearly YOU ARE THE GREAT! thx for this all