[REBOL] Re: Printing Dialect
From: greggirwin:mindspring at: 2-Oct-2003 11:40
Gabriele, Andrew et al
AJM> Is there an approach that you can see that I've failed to see? Perhaps you
AJM> can think of a better and easier to understand printing dialect? One
AJM> important point is that I'd like to see exact placement on the page (like
AJM> the C# code shows), along with a few shortcuts (like the Rebol dialect
AJM> does).
GS> How should the PDF Maker be simplified? So I can add to the to do
GS> list for version 2.
There are two sides to this coin as I see it:
1) The outer dialect; and parallel to VID
2) The underlying engine that provides primitives used in the
dialect.
The exact dividing line between the two isn't clear, because you
may want to "print" to many different "devices" (printer, fax, email,
HTML, TeX, XML/docbook, PDF, etc.) for many different purposes
(documents, forms, envelopes, labels, bar codes, print-preview, mail
merge, reports). Having specialized dialects seems like the best way
to make those accessible. What's hard to account for is the different
elements that are important in each one. For example, a government
form, label, or envelope will require very specific positioning; a
document will have "areas" and *may* specify page breaks (think WP vs
Acrobat); a report may have a stream of items and page breaks should
be handled automatically; text based formats have much coarser
positioning than graphic devices.
digression [
Anyone ever write stuff that had to print text that shows in a window
on an envelope? Ever had to change code when a new envelope was used?
:) What if your dialect had envelope styles (where you could specify
the window offset and size) and you could tag the data that should
show in the window?
]
We may also want to think about things like sub-dialects (e.g. tbl,
eqn, pic) that are used for elements.
If we can identify the primitives that the low level dialect needs to
support, then all the other dialects are built on top of that and new
output formats just means writing a new "renderer" that supports the
required primitives. I think a VID-like approach could work well,
where you can define styles, layout attributes, and elements that are
intelligently handled, but also allows you to override things for more
control. Easier said than done though. :\
I think PDF-maker has lots of great elements, but the different
coordinate system is kind of a pain and it can be pretty verbose if
you have lots of inter-element changes. Can't beat it for flexibility
and output quality though.
=== Primitive Thoughts :)
text
single-line
multiline
alignment
/horizontal [left center right justified]
/vertical [top middle bottom justififed
font
table/grid
header
rows
columns
shading/fill
sub-layout (like LIST)
data
shapes
line [width style]
box [line-width fill]
circle [line-width fill]
images (BMP JPG PNG SVG EMF charts?)
special (bullets, math symbols, etc.)
-- Gregg