You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/06/27 12:32:24 UTC
Odds and Ends
Hi, all
Here are some assorted things.
1. Unless someone beat me to it, I'll go about getting a fop-users mailing
list set up. That appears to be the will of the majority (well, everyone
actually);
2. We require a release plan for FOP 1. I propose a very simple one - a
regular planned release the first week of every month, with a secondary
bugfix release 1-2 weeks later (second or third week). That means that
another will appear soon. Numbering of releases will _not_ be fixed; it will
depend on how much got done in the intervening month. Comments?
3. We need volunteers to step in and take charge of documentation, including
design and objectives, for FOP 1. We still want a revised Objectives
statement on the FOP main page, for example. Takers?
4. I am pretty much set on spending 80-90% of _my_ time on FOP 2, even
though we have neither formally defined FOP 2 nor actually kicked it off.
However, that doesn't mean that I am abandoning FOP 1 - I'll continue to
accept patches (I have one right now), plus do releases (unless somebody
else wants to give that a shot), and otherwise support testing. I am
currently doing some testing related to the CR->PR process.
I'd also like to lay claim to the pagination code for about a week - I want
to get page-position="last" happening, plus review properties on
page-sequence, and just in general tighten ship on FOP 1 pagination. If
anyone else is already in there, maybe you could let me know - if somebody
is doing stuff here already I don't want to re-invent the wheel.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 07:14 PM 6/29/01 -0500, Weiqi Gao wrote:
>On 29 Jun 2001 18:26:30 -0300, Arved Sandstrom wrote:
>> I'm open to suggestions from anyone as to a convenient label for the
>> redesign that Karen & I have described (and that others have also
contributed
>> to, I might add).
>
>Why not stick with the Apache tradition of coining names that start with
>an X and is hard to pronounce in English? Is 'Xiesel' hard enough?
>
>It starts with X.
>It rhymes with Diesel, so you can talk about the 'Xiesel engine' in an
>upcoming FOP release.
>It has the letters 'X', 'S', 'L' in it, and 'XSL' is the official name
>of the spec FOP is supposed to implement.
>
>Weiqi Gao
>weiqigao@networkusa.net
I have to grudgingly admit that I like this a lot. :-) Even if we just use
it informally, it's got a nice ring to it...and the imagery it evokes, plus
all the associations, are great.
What we could do is specify that the leading 'X' must be pronounced as a
Khoisan glottal dental click.
Regards,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Weiqi Gao <we...@networkusa.net>.
On 29 Jun 2001 18:26:30 -0300, Arved Sandstrom wrote:
> At 06:40 AM 6/29/01 -0500, Weiqi Gao wrote:
> >On 29 Jun 2001 06:37:00 -0300, Arved Sandstrom wrote:
> >>
> >> FOP2 is the term for a completely new layout engine, and so maybe
> >> we don't really want to call the thing "FOP2". Suggestions? I'll
> >> call it FOP1+ for now.
> >
> >Please spare us of the confusion and stick with simple numbers like 1 or
> >2.
>
> OK, that's fair...I just needed a label at that moment, so I picked a bad
> one.
>
> What we should probably really do is avoid attaching _any_ FOP version to
> the advanced layout/formatting redesign, because it is a _module_ redesign,
> not an overall FOP redesign. And in any case we do not even have a 1.0
> (production-ready, feature-complete) version available, so it is premature
> to allot versions that far out.
>
> I'm open to suggestions from anyone as to a convenient label for the
> redesign that Karen & I have described (and that others have also contributed
> to, I might add).
Why not stick with the Apache tradition of coining names that start with
an X and is hard to pronounce in English? Is 'Xiesel' hard enough?
It starts with X.
It rhymes with Diesel, so you can talk about the 'Xiesel engine' in an
upcoming FOP release.
It has the letters 'X', 'S', 'L' in it, and 'XSL' is the official name
of the spec FOP is supposed to implement.
--
Weiqi Gao
weiqigao@networkusa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 06:40 AM 6/29/01 -0500, Weiqi Gao wrote:
>On 29 Jun 2001 06:37:00 -0300, Arved Sandstrom wrote:
>>
>> FOP2 is the term for a completely new layout engine, and so maybe
>> we don't really want to call the thing "FOP2". Suggestions? I'll
>> call it FOP1+ for now.
>
>Please spare us of the confusion and stick with simple numbers like 1 or
>2.
OK, that's fair...I just needed a label at that moment, so I picked a bad
one.
What we should probably really do is avoid attaching _any_ FOP version to
the advanced layout/formatting redesign, because it is a _module_ redesign,
not an overall FOP redesign. And in any case we do not even have a 1.0
(production-ready, feature-complete) version available, so it is premature
to allot versions that far out.
I'm open to suggestions from anyone as to a convenient label for the
redesign that Karen & I have described (and that others have also contributed
to, I might add).
Regards,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Weiqi Gao <we...@networkusa.net>.
On 29 Jun 2001 06:37:00 -0300, Arved Sandstrom wrote:
>
> FOP2 is the term for a completely new layout engine, and so maybe
> we don't really want to call the thing "FOP2". Suggestions? I'll
> call it FOP1+ for now.
Please spare us of the confusion and stick with simple numbers like 1 or
2.
--
Weiqi Gao
weiqigao@networkusa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 08:52 AM 6/29/01 +0200, Jeremias Maerki wrote:
>Just an idea, but I don't have enough overview over FOP right now to know
>if it's feasible:
>Why not take a little time to encapsulate the parts to be redesigned, so
>the FOP 2 people can work on a separate repository (or just another
>package subtree)? Consequences:
>+ Encourages loose coupling and exchangability of algorithms
>+ Improvements on either side in the common stuff helps both sides.
>+ Less work to sync common stuff between projects
>+ This is a chance to tidy up some dirty spots and dependencies.
>- Some effort is neccessary before FOP 2 can start.
>- Probably more work for the FOP 2 people because they have to maintain
> compatibility.
This is _my_ personal inclination, what you describe above, particularly if
we were to go with the separate package(s) view. I am not anxious to do FOP2
as a CVS branch in any case - I think a completely new sub-project or new
drop-in modules is called for. I personally think new package(s) are enough.
A modified build.xml with new targets should be enough to handle building. I
don't think we have to duplicate the majority of FOP, so a new _CVS_ module
is probably unnecessary.
FOP2 is the term for a completely new layout engine, and so maybe we don't
really want to call the thing "FOP2". Suggestions? I'll call it FOP1+ for now.
(Note: we can certainly envisage a FOP2, which would be a much more thorough
rewrite and redesign, but that concept has not yet been described)
FOP as it stands is pretty good with modularization - not great, but pretty
good - at a high-level, although it gets rapidly worse at finer levels,
which is one big reason for FOP1+. I'd like to see us agree on interfaces,
first off, between the layout/formatting component(s) and everything else,
that both FOP1 and FOP1+ will obey. We're actually close to that now, I
think, as far as FOP1 is concerned. That way we can, as you suggest, just
drop in the complete new layout/formatter when the time comes.
>To ensure that as many people as possible help bringing FOP up to a
>version 1.0 or even 2.0, I think it's crucial to maintain an up-to-date
>list with things to do and with indications where and how non-committers
>can help best. Then people have to take ownership of their tasks which
>also should be tracked.
I had some ideas occur to me last night about this, and will try to develop
them over the next few days.
We also have a number of FT (or nearly FT) developers at the moment - I
think their input on this is critical.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Jeremias Maerki <je...@outline.ch>.
> Also if possible it might be good to create the branch for FOP II (2) after
> the next release so that there is a place to start working in.
> One question, how should we handle updates to FOP that are not specific to
> the new layout.
> For example: images, svg, logging, configuration etc.
> All things that need improvement.
> If we put these things in 1 then we may have trouble getting them into 2,
> if we put them in 2 then everyone will have to wait for 2 to be released.
> Is FOP 1 going to be feature frozen, interface frozen etc. or should this
> wait for a bit first.
Just an idea, but I don't have enough overview over FOP right now to know
if it's feasible:
Why not take a little time to encapsulate the parts to be redesigned, so
the FOP 2 people can work on a separate repository (or just another
package subtree)? Consequences:
+ Encourages loose coupling and exchangability of algorithms
+ Improvements on either side in the common stuff helps both sides.
+ Less work to sync common stuff between projects
+ This is a chance to tidy up some dirty spots and dependencies.
- Some effort is neccessary before FOP 2 can start.
- Probably more work for the FOP 2 people because they have to maintain
compatibility.
Bringing in Avalon at this point might help. I think I'm after similar
issues as Keiron (images, logging, config). Also, I think fonts need
some looking after to integrate them with the PostScript renderer. I'd
be glad to help in these corners, though I have to do this in my free
time.
To ensure that as many people as possible help bringing FOP up to a
version 1.0 or even 2.0, I think it's crucial to maintain an up-to-date
list with things to do and with indications where and how non-committers
can help best. Then people have to take ownership of their tasks which
also should be tracked.
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Odds and Ends
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 27 Jun 2001 12:32:24 Arved Sandstrom wrote:
> 2. We require a release plan for FOP 1. I propose a very simple one - a
> regular planned release the first week of every month, with a secondary
> bugfix release 1-2 weeks later (second or third week). That means that
> another will appear soon. Numbering of releases will _not_ be fixed; it
> will
> depend on how much got done in the intervening month. Comments?
I think that would be a good idea, regular releases.
Also if possible it might be good to create the branch for FOP II (2) after
the next release so that there is a place to start working in.
> 4. I am pretty much set on spending 80-90% of _my_ time on FOP 2, even
> though we have neither formally defined FOP 2 nor actually kicked it off.
>
> However, that doesn't mean that I am abandoning FOP 1 - I'll continue to
> accept patches (I have one right now), plus do releases (unless somebody
> else wants to give that a shot), and otherwise support testing. I am
> currently doing some testing related to the CR->PR process.
One question, how should we handle updates to FOP that are not specific to
the new layout.
For example: images, svg, logging, configuration etc.
All things that need improvement.
If we put these things in 1 then we may have trouble getting them into 2,
if we put them in 2 then everyone will have to wait for 2 to be released.
Is FOP 1 going to be feature frozen, interface frozen etc. or should this
wait for a bit first.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org