On Mon, Jun 09, 2003 at 12:19:48PM -0500, Alex Roitman wrote:
> I think starting a new one should be a good idea. We could start the=20
> whole new category of the reports that use XSL stylesheets. That would=20
> be different from the existing reports in some aspects:
I don't mean to use the XSL stylesheet I've already written, just to
create a Python report module that creates similar output. My
immediate goal is to get good print output, and I haven't found a good
way of getting that from XHTML.
So I was going to make a Python report module that uses the current
TextDoc stuff for several different output formats.
Things I want it to include:
- Omitting 'x married y' if the fact has already been stated
- Omitting details person descriptions if they have already been
- Optionally including photos of people and their spouses
- Listing children and (briefly) grandchildren
- Better description of events (there are bugs in the FTM ancestor
report here: for example if a place is known for an occupation the
output is off)
- Where someone has married several times, use 'later married'
They are all enhancements really, which is why I'm not sure whether to
start with an existing report and make it better, or if the full set
of enhancements really makes it a different type of report.
Now the points you raise about the experimental XSL approach to
> 1. XSL way creates great XHTML, but what about other formats (pdf?)=20
> Existing reports have support for several formats. I guess XHTML could=20
> be eventually converted to these, but until this works it'd be nice to=20
> keep the old framework intact.=20
This is the problem. I haven't got a solution I'm afraid. There is
always XSL-FO I suppose, or else perhaps there is a solution to be
found by making an XSL version of TextDoc.
> 2. XSL way assumes that the data is store in XML. It makes great sense=20
> to store data in XML and I'm all for it, but there are some scenarios=20
> where this is not guaranteed: (1) existing ZODB database, (2)=20
> prospective gnome-db--mysql backends, and (3) a simple case of=20
> importing gedcom and writing a report without saving XML datafile.=20
> These are just a few concerns that come to mind, there may be more. On=20
> the other hand, it makes perfect sense to enable stylesheet-based=20
> reports when XML data exists and XHTML output is desired. So I would=20
> add new XSL reports and keep the old-style reports.=20
Well here my plan was to hook into the python bindings for libxslt and
just build a temporary XML file.