W3C home > Mailing lists > Public > www-xsl-fo@w3.org > February 2002


From: Arved Sandstrom <asandstrom@accesswave.ca>
Date: Fri, 22 Feb 2002 07:21:24 -0500 (EST)
To: "Ilya Sterin" <isterin@ciber.com>
Cc: <www-xsl-fo@w3.org>
Message-ID: <NIECINNOJOOPPAIFLMIGCEKNCCAA.asandstrom@accesswave.ca>
-----Original Message-----
From: www-xsl-fo-request@w3.org [mailto:www-xsl-fo-request@w3.org]On
Behalf Of Ilya Sterin
Sent: February 22, 2002 12:28 AM
To: Arved Sandstrom
Cc: www-xsl-fo@w3.org
Subject: Re: XSL-Fo to PDF

> Just as an aside, I thought I should mention that I am in the throes of
> doing what David mentions was done for the XEP prototype, and what Ilya is
> in some stage of doing also. I have my xslfo-proc Sourceforge project, and
> a prototype in Perl is proving to be much more useful than UML.

Arved, I'll be very interested in taking a look at what you are doing and
possibly joining forces or somehow complimenting each other.  No need to
repeat the hard work.

[ SNIP ]

-----End of Original Message-----

I have a short holiday coming up this weekend; 5 days total. I intend to do
some intensive work and upload stuff on Tuesday or Wednesday. Nothing close
to completion but I have all the properties and FOs in place as modules that
I am interested in, some 260 total. Plus I am sketching out the actual
layout and area modules; there should be a fair bit to look at in a few
days. Placing properties (inherited, explicit, specified) on all the
elements more or less works; I haven't yet gotten to doing computed values
because that will happen as I work on layout.

We can start talking about technical details when you've seen product (:-));
I'll mention only that even where my Perl modules behave as objects they are
really C structs, and that is my intention in a C implementation. In
particular I am stressing composition & aggregation, and my intention is
that FOs themselves are layout-dumb; managers will handle the layout. This
is not entirely my idea; my fellow committers on FOP who are currently
pushing the redesign are using this approach. Many constraints in XSL
encompass several objects and hence the "manager" architecture is very

Since I have no intentions of putting a production Perl processor out there
I guess you are the man. I suspect that you are more up to speed with Perl
than I am - I've been using nothing but Java in real life for the past few
years.I think the fastest way will be as you suggested, to start from the
pure-Perl and optimize with XS. Since I have been doing XSL for a while
probably the real value to you will be that you can not so much borrow Perl
as you can borrow solutions. But I have no objections to wholesale borrowing
of the code either.

I certainly have no objections if you also wish to participate in the C
processor/library project. I welcome any input. As I mentioned it won't
start for a month or 2 in any case, since I want to do the prototype first.
And for that _I_ am going to stick with SWIG, because I am not restricting
myself to Perl.

Received on Friday, 22 February 2002 12:41:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:54 UTC