r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

World: r3wp


This group is about Printing solutions for REBOL.
I've just built a direct printing library for R2, Windows only. It's 
a wrapper on Win32 Print API, so it supports all printers. It support 
a subset of Draw dialect as input. I was needing it to print reports 
for the project I'm currently working on. It still needs some additionnal 
work to be released publicly (like adding a port scheme layer for 
more intuitive usage).
My library is just a thin layer that maps Draw dialect to Win32 Printing 
How well does the Draw semantic model map to the Windows printing 
semantic model?
Quite well so far. I currently only supports the following Draw commands 
: text, line, box, font, pen
Have you considered the XPS printing API? I gather the semantic model 
is much better.
I also need to add extend Draw dialect with a new command: text-box. 
It's an improved version of 'text that allow you to define a bouding 
box, align the text horizontally and vertically and auto-wrap text.
For R3 you might look into the rich text support. I am less familiar 
with R2's Draw (and that's saying a lot).
The Gob model is much better-suited to adaptation to printing, IMO.
DocKimbel, you'll find that R2 Draw has kerning problems. Or at least 
that's what it had the last time I looked. That makes it difficult 
to center and right align text. This is not an issue in R3.
I had a quick look at XPS API, but it looked more complicated and 
required more work than GDI API. There was also the compatibility 
issue, I needed a solution that would work with any printer. I'll 
gave a deeper look at XPS latter.
Righ, gobs being lower level would require less work to map to OS 
Printing API.
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 
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 
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 :