Ed Leafe wrote:
> On Feb 27, 2007, at 9:19 PM, Michael Hipp wrote:
>
>>> This is still uncharted territory, mainly because nobody has looked
>>> into it yet. I suppose we would take what wxPython uses and perhaps
>>> clean it up a bit, but until then, you still have the full wxPython
>>> printing mechanism available to you.
>> Unfortunately I find the wx printing framework to be a bit like
>> programming in
>> assembler. It is a "low level" tool shall we say. ReportLab has
>> spoiled me.
>>
>> At present I'm having pretty good success using ReportLab with
>> Ghostscript to
>> to print the resulting PDF. But Ghostscript seems a bit rickety at
>> times.
>
> Do you have ideas about a better way to approach this? If anything,
> Dabo is about finding that 'better way'.
Yes. Tho I definitely can't claim all of them as my own.
Ideas:
------
1) Use XML as a document descriptor and create a "processor" that takes the
XML and calls the wx print framework to do the actual printing. Kinda like the
XRCed stuff in wxPython. Michele Petrazzo on the wxPython list has done some
initial work on this and I intended to help flesh it out but time pressures
dictated otherwise.
Pros: printouts can be changed without recompiling
Python knows how to do XML
Cons: I hate XML
The XML DOM API is rather baroque
2) Instead of XML, put some effort into fleshing out the HTMLprintout stuff in
wxPython and make it more capable as a print description template.
Pros: Lots of work already done
Cons: HTML is a lousy print description language
3) Replace the "pdf" layer at the bottom of ReportLab with something that
makes calls to the wx print framework instead.
Pros: No need to re-invent the wheel of high level stuff in ReportLab
Could probably achieve a high % of success with moderate work
Cons: Some of the PDF-centric calls would take some serious effort to
imitate
4) Re-create a subset of the ReportLab API only having it use the wx print
framework instead of creating PDFs.
Pros: Good API as a starting point
Cons: Lots of work
The ReportLab API contains some amount of cruft
License or copyright issues(?)
5) Incrementally build some higher level print "widgets" (tables, paragraphs,
headings, footers, etc.) Dabo-style on top of the wx print framework. Make it
easy for contributors to add more widgets and slowly build up a comprehensive
API and widget library.
Pros: Can eat the elephant one bite at a time
Allows for design decisions to evolve over time
Could be made agnostic toward wx
Cons: No finished product for a long time
Design discussions must be held before any real work can be done
The wx print API is a tough starting point
#4 and #5 are obviously somewhat similar.
I lean toward #1 or #5. Neither is easy and there's significant work to be
done before anything concrete could take shape.
An early decision point would be whether we want the "page description
language" to be Python or something else (e.g. XML). There are pros and cons.
(Surely someone somewhere has already created a generic printed page
description language that we could use or at least study for ideas)?
We probably wouldn't get very deep into this before voices would begin to
request the inclusion of a GUI "layout designer".
This whole issue has been the one nearly insoluble problem in my apps. I'd
look forward to collaborating on a solution.
Michael
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
