RE: [Proposal] I volunteer to help with 0.20.6

[Victor Mote]

Anton Tagunov wrote:

> Perhaps Victor and/or some other patch authors would assist.

I wish I could help you, but I am blocked from development on that branch as
well.

Victor Mote

Re: [Proposal] I volunteer to help with 0.20.6, part II

[Chris Bowditch]

Anton Tagunov wrote:
amendment:
It really is not such a nonsense as it may seem, Tomcat
3.x.y piecfully co-exist with 4 and 4 coexists with 5.
The trouble is everyone always focuses on 0.20.x to the detriment of 1.0 
development. Going for the low hanging fruit in 0.20.x may help fix a few 
minor issues but you cant escape from the fact that keep-* properties cant be 
implemented there.

To reduce mess in the cvs if this proposal is wellcomed we
could create a svn subdir, something like
fop-0-20-2-maintain.
No one said there is a mess in CVS. I dont think there is a need to create a 
separate directory. A branch is fine.

Let me repeat again: I will ask PMC not to vote for the
release if I get bogged down into anything but most
simplisting bug fixing. Just go through Bugzilla and apply
most evident and simple patches. And then ask people: has
anthing become worse since 0.20.5.
The concern with allowing development of 0.20.x is not that we introduce 
regressions or that there are large changes. Simply, that it distracts from 
the real goal of FOP: getting the few simple bits finished in 1.0 so that we 
can do a release. And we really arent that far away. I reckon a developer with 
a good knowledge of the layout code could plug the main gaps in about 3-4 
months solid work.

(What really killed me in 0.20.5 were troubles with table
rendering when cells do have a background. And awt renderer
produced pour-quality images cause it used int-based
Graphics interface not a double-based one. And I have patch
for that too. But some other patches as simple is that are
floating around, some hyphenation patch.)
Chris

Re: [Proposal] I volunteer to help with 0.20.6

[Chris Bowditch]

Anton Tagunov wrote:
Hi, gang!
I'm Anton Tagunov, a committer with Avalon and Excalibur
apache projects. I'm afraid I have not been much active
withing these projects lately, but I've still got the commit
priviliges and an active apache account.
Welcome.
I have a full understanding of current situation @fop:
0_20_2 branch has been frozen and all efforts have been
directed at reacheing 1.0 release. On the other hand there
has not been a release for quite a while. The only thing
available to users is 0.20.5. And I do know that a massive
refactoring has happened on the path to 1.0. And I do know
that 0.20.5 code is a bit messy which in the beginning
caused the refactoring.
Well, thats not the full picture. Refactoring was started because it is too 
difficult to implement keep-* properties into the maintenance code because of 
it architecture. Hence a new architecture was thought up and hey presto: work 
begins on 1.0.

However, being practicle we (I work for Deutsche Bank now)
definetely need fop NOW. We do use 0.20.5. And we do have
local patches for it. I feel these patches may be of a
certain value to others too. Also I would also like to
leverage public review available with open source. Besides
we do have at least several patches against 0.20.5 flying
around cvs.
What a small world. My company is working with Deutsche bank (London) on a 
project involving FOP. At the moment they are our only customer who still work 
 with FOP. Most of our customers must have XEP to get keep-* properties. This 
is the one area that FOP really falls down on. If FOP had keep-* properties it 
would be used much more. That is why we must focus our energies on the redesign.


The mantra of 0.20.6 would be: no new features, not much
labor, go for low-hanging fruit and fix what is easy to fix
and for what patches are already available.
That should be relatively easy. Piece of cake.
In a way I agree with you, and it looks like you will be taking on most of the 
work for yourself, and thus minimising the distraction from HEAD development. 
But I would much rather you concentrated on HEAD. Doing more development of a 
frozen architecture is only going to encourage more users for a dead code base.

On the upside FOP project which has not had releases for
quite a while while gains some more visibility and showes it
is alive. 0.20.6 announcements will be accompanied with a
big fat comment that it is just a bug-fix and the real
paradize is expected with 1.0.
1.0 isnt a real paradise, more like a 0.3. Just 0.20 plus keep-* properties. 
Well, thats the goal. In reality theres going to be some regression on 0.20.x 
functionality.

I do understand the nature of software development. I do
understnad you're at 1.0-dev. I honestly hope some day I
will find enought time and enery to dig into that. But being
practical this is what I can offer fop community right now:
assistance in 0.20.6 release. Low-hanging fruit. Light bug
fixing.
I have to say I think I'm against doing a 0.20.6. I dont like being negative 
toward someone who wants to improve the code, but I think its for the best if 
1.0 stands a chance. And I know whats it like not having much time, most of 
the other committers are in the same boat. Yet we have all made at least some 
contributions towards the 1.0 effort. I would like to see you doing the same.


Chris

Re: [proposal] How to do logging from the command line

[Finn Bock]

[Jeremias]
Hi Finn,
I took a look at it and I must say that I'm a bit confused, too.
Anyway, I have a proposal to make. I would expect a command-line
application to work like any other C-program such as "grep", "svn", "ls" or
whatever. That means you don't get any "[INFO]" before each line, but
you can define the log level (normally "quiet", "normal" and "verbose")
through command line switches. That'll work for most CLI-users.
Since the Fop class is the one to control the whole application it (or
rather the CommandLineOptions class) can also set up C-L to behave
exactly as explained above. That would probably mean not to use
SimpleLog but to provide a special implementation for command-line use.
At any rate, I don't agree with the way that SimpleLog is implemented.
Informational messages should go to System.out, errors to System.err.
Logging prefixes should be disabled. I've had to do the same for Avalon
Logging in Barcode4J [1] and I'm very pleased with the result. Using
this I was able to implement the Barcode4J CLI in a way that the
generated barcode could be output to System.out which may also be
desirable for certain people. You could even modify the whole thing in
way that you could implement FOP as a filter application getting the
input through System.in and sending the output to System.out, giving
error messages through System.err.
For those who know about C-L and want to do some special logging we
could have a command line switch that disables our special logger setup.
They can fully control C-L from outside.
For the cases where FOP is used embedded in a bigger software, FOP
shouldn't manipulate anything in C-L, it's simply the developer's job to
set up C-L from outside.
WDYT?
I like it. It will get consistent results for command line users without 
 them (practicly) ever having to do any logging configuration.

I have added a patch with an implementation of your proposal. Feel free 
to point out any mistakes that I have made.

Glen, I'm a bit confused about your objections. I don't think they apply 
to Jeremias' proposal at all.

- SimpleLog plays *no* part in this.
- There is no wrapping of c-l in any way, we just supply own very
  simple specialized logging implementation.
- Users can still use other c-l loggers (jdk14, log4j, etc.) by
  setting LOGCHOICE in fop.bat
regards,
finn

Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)

[Glen Mazza]

Just giving my opinion--I also recognize that the
output interface is a bit rough, as Finn was saying,
and may still need some work, possibly along the lines
of what you were suggesting.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> OK, forget it. I'm obviously worse at explaining
> things than I thought.
> I don't have the time to chew this through. It
> should have been quick
> and painless, but obviously it isn't. Hopefully,
> someone else has a
> better solution.
> 
> I'm sorry for wasting your time writing this answer.
> Back to my JNI
> wrapper for FOP...
> 
> Jeremias Maerki
> 
> 

Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)

[Jeremias Maerki]

OK, forget it. I'm obviously worse at explaining things than I thought.
I don't have the time to chew this through. It should have been quick
and painless, but obviously it isn't. Hopefully, someone else has a
better solution.

I'm sorry for wasting your time writing this answer. Back to my JNI
wrapper for FOP...

Jeremias Maerki

Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Hi Finn,
> 
> I took a look at it and I must say that I'm a bit
> confused, too.
> 
> Anyway, I have a proposal to make. I would expect a
> command-line
> application to work like any other C-program such as
> "grep", "svn", "ls" or
> whatever. That means you don't get any "[INFO]"
> before each line, but
> you can define the log level (normally "quiet",
> "normal" and "verbose")
> through command line switches. That'll work for most
> CLI-users.
> 

Errr, we're using Commons-Logging now.  I don't think
we should wrap it.  Perhaps we should switch to
System.out/.err for Command Line use though, a la
Xalan.

> That would probably mean
> not to use
> SimpleLog but to provide a special implementation
> for command-line use.

SimpleLog is out the window with 1.4 JDK--C-L uses
Java Logging by default there, which IIRC, doesn't
have those messages, or if it does can be configured
by the underlying implementation.  

No architectural decisions IMO should be based on the
behavior of SimpleLog--it's yesterday's news.

Remember, Xalan, Xerces, and Batik don't use logging, 
and I see FOP moving in this direction--logging less
and less over time.

> For those who know about C-L and want to do some
> special logging we
> could have a command line switch that disables our
> special logger setup.
> They can fully control C-L from outside.
> 

We don't do much for the user community in separating
them from C-L (a highly useful skill, its not like
we're forcing them to learn Icelandic), and having
them learn another nonportable logger implementation
instead.  

Ideally, if there's problems with C-L complexity the
solution should be to go to C-L team and complain on
the user's lists or send Bugzilla reports to get those
problems fixed.  Not for each of the 90 or so
open-source systems that use C-L to be wrapping it
instead.  

Glen

Re: [PROPOSAL] API Changes

[Simon Pepping]

On Sat, Jul 10, 2004 at 06:16:37PM -0700, Glen Mazza wrote:

> 1.)  Drop the apps.Driver class and incorporate its
> remaining code into apps.Fop.
> 
> Reason:  "Fop" appears to be a better self-documenting
> class name within user's embedded code.  It's also a
> neat name for a product.  User's code would move from
> looking like this:

> 2.)  Shall we roll the dice?  I wonder if we should go
>  100% JAXP for 1.0, i.e. coding just like this [1] for
> SAXSources and [2] for DOMSources, and removing the
> older methods from Driver where one would be using
> XSLTInputHandler.  We're currently that way with [2]
> (As of yesterday ;), the question is should we go that
> way with [1] now?

I am positive to both ideas.

> --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> > Have another look at the API proposals in the old
> > Wiki.
> >  
> >
> http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
> > 
> 
> Well, a bit too expansive for my (personal) tastes, at
> least for 1.0--but to be candid, much of it I still
> don't understand.  Regardless, the resources we have
> for 1.0 IMO should be focusing on other areas
> (fo's/layout/renderers) at this time.  Perhaps another
> reason for my recommendation for a "spartan" API
> similar to what we now have for 0.20.5.  
> 
> Our inputs I see for 1.0:
> 
> --XSL FO document (or xml/xslt)
> --preferred render type
> --FOUserAgent and UserConfiguration, whatever portions
> of functionality/coding in each.
> 
> That should be enough for us in 1.0, no?  Those more
> elaborate API goals appear best discussed post-1.0,
> presumably once more vital parts of the system have
> been addressed.  
> 
> More thoughts, anyone?  Simon, what would you be
> comfortable with API-wise in 1.0?

I agree with these priorities. Such a FOP would perhaps not have a
better API than the maintenance code, but it would be an
implementation of the redesign and thus end the unfortunate split
between maintenance and development.

I have not yet had the time to read Jörg's proposals, but I think I
would have the same conclusion: move it forward until there is more
time.

Perhaps it is indeed wise, as Glen concluded, to leave the API much as
it is, in view of the fact that we do not yet have a final view on
it. However we do it, we will go through two phases: implement the new
layout, and implement a new API, and there will be a time between the
two. 

I think moving to JAXP now is desirable, for all the reasons one
follows a standard API.

Note that the Xalan and other people call the javax.xml.transform part
TrAX. AFAIK, javax.xml.parsers is also in JAXP.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [PROPOSAL] API Changes

[Glen Mazza]

-- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > That should be enough for us in 1.0, no?  Those
> more
> > elaborate API goals appear best discussed
> post-1.0,
> > presumably once more vital parts of the system
> have
> > been addressed.  
> 
> A stable API is as important as other major
> features.
> If we do a mojor release, post-release API changes
> should
> be small and rare.
> 

Agreed, I have less problem however with *adding* to
the API as FOP gets more powerful.  But if we're going
from 3 methods to 40, then, yes, we probably would
need a new "major" release.

Now whether the changes I proposing (and the state of
the app after the rest of the system is more or less
complete) would warrant a 1.0 or a 0.30 is not of
concern to me.  The API-enhanced version would just be
a 2.0 or a 1.0, respectively.

Thanks,
Glen

Re: [PROPOSAL] API Changes

[J.Pietschmann]

Glen Mazza wrote:
That should be enough for us in 1.0, no?  Those more
elaborate API goals appear best discussed post-1.0,
presumably once more vital parts of the system have
been addressed.  
A stable API is as important as other major features.
If we do a mojor release, post-release API changes should
be small and rare.
J.Pietschmann

Re: [PROPOSAL] API Changes

[Glen Mazza]

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > There are two possible API changes I am wondering
> if
> > we should make.
> 
> Have another look at the API proposals in the old
> Wiki.
>  
>
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
> 

Well, a bit too expansive for my (personal) tastes, at
least for 1.0--but to be candid, much of it I still
don't understand.  Regardless, the resources we have
for 1.0 IMO should be focusing on other areas
(fo's/layout/renderers) at this time.  Perhaps another
reason for my recommendation for a "spartan" API
similar to what we now have for 0.20.5.  

Our inputs I see for 1.0:

--XSL FO document (or xml/xslt)
--preferred render type
--FOUserAgent and UserConfiguration, whatever portions
of functionality/coding in each.

That should be enough for us in 1.0, no?  Those more
elaborate API goals appear best discussed post-1.0,
presumably once more vital parts of the system have
been addressed.  

More thoughts, anyone?  Simon, what would you be
comfortable with API-wise in 1.0?

Thanks,
Glen

Re: [PROPOSAL] API Changes

[J.Pietschmann]

Glen Mazza wrote:
There are two possible API changes I am wondering if
we should make.
Have another look at the API proposals in the old Wiki.
 http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
1.)  Drop the apps.Driver class and incorporate its
remaining code into apps.Fop.
There should be a clear distinction between the API
and application wrappers. I suggested an API package
containing a FOProcessor, and keep the apps package
clean. Perhaps create subpackages in apps for CLI,
servlet, AWT or whatever sample/useful applications.
J.Pietschmann

Re: [PROPOSAL] API Changes

[Glen Mazza]

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> 
> FWIW, FAD merged Driver into Fop some time ago. 
> From memory, the only 
> issues were to do with the AWT renderer and its
> re-start capability 
> (which I gather is not functioning anyway.)
> 

Thanks for letting us know!  I was unaware of that.

> While we're at it, what about moving Fop to
> org.apache.fop?
> 

I think Fop needs to be in org.apache.fop.apps, so it
can view its sibling classes that don't have public
scope, also to be able to access protected members of
its sibling classes.

Glen 


BTW--On another note, I've been hearing about the
angry kangaroo problems in Australia [1].  Be careful
outside!  ;)

[1]
http://news.bbc.co.uk/2/hi/asia-pacific/3874379.stm

Re: [PROPOSAL] API Changes

[Peter B. West]

Glen Mazza wrote:
Team,
...
1.)  Drop the apps.Driver class and incorporate its
remaining code into apps.Fop.
Reason:  "Fop" appears to be a better self-documenting
class name within user's embedded code.  It's also a
neat name for a product.  User's code would move from
looking like this:
// Construct driver
Driver driver = new Driver();
   
// Setup Renderer
driver.setRenderer(Driver.RENDER_PDF);

Result res = new SAXResult(driver.
getContentHandler());

To this:
// Construct FOP instance
Fop fop = new Fop();

// Setup Renderer
fop.setRenderer(Fop.RENDER_PDF);

Result res = new SAXResult(fop. getContentHandler());

Does the lower look better--over the long term, will
it make FOP more well known, more used?  
FWIW, FAD merged Driver into Fop some time ago.  From memory, the only 
issues were to do with the AWT renderer and its re-start capability 
(which I gather is not functioning anyway.)

While we're at it, what about moving Fop to org.apache.fop?
Peter
--
Peter B. West 

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Jeremias Maerki]

Clay,

a vote is there to decide on certain things. A proposal is merely a
possible course of action that can be discussed. It may be concluded by
a formal vote once all the details are clear. I don't know of anyone who
is clearly against the creation of the XML Graphics PMC. I expect
everyone who has a problem with what's going on to make him/herself
heard, the sooner the better.

I'm simply trying to get attention by using "[PROPOSAL]" in the subject,
to invite everyone to participate in figuring out the details. When
everything's set, we're going to do a binding vote that will show the
board our consensus on the matter.

I hope that clears it up a bit.

On 25.06.2004 16:54:39 Clay Leeds wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Being new to this VOTING thing, I'm a bit confused. I believe I've made 
> it clear in a previous message, that I'm in favor of the PROPOSAL to 
> create the XML Graphics PMC which will be the new 'home' of FOP and 
> Batik, but I'm unclear on how this process works. I'm also in favor of 
> the votes for membership expressed below (scroll down a bit for my 
> specific votes...).
> 
> What I'm unclear on, is the 'legal' difference between PROPOSAL and 
> VOTE. I'd thought that the only time a VOTE really counts is when the 
> SUBJECT includes VOTE. I've searched through the ASF docs, and the only 
> place I can see PROPOSAL discussed, is[1], hence my confusion.:
> 
> [1]
> http://www.apache.org/foundation/how-it-works.html
> 
>Rules require that a negative vote includes an
>alternative proposal or a detailed explanation
>on the reasons for the negative vote.
> 
> In any case, My VOTE(s) for this PROPOSAL (assuming they are 
> appropriate now) are below:
> 
> Creation of the XML Graphics PMC
> +1


Jeremias Maerki

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Peter B. West]

Clay Leeds wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Being new to this VOTING thing, I'm a bit confused. I believe I've made 
it clear in a previous message, that I'm in favor of the PROPOSAL to 
create the XML Graphics PMC which will be the new 'home' of FOP and 
Batik, but I'm unclear on how this process works. I'm also in favor of 
the votes for membership expressed below (scroll down a bit for my 
specific votes...).

What I'm unclear on, is the 'legal' difference between PROPOSAL and 
VOTE. I'd thought that the only time a VOTE really counts is when the 
SUBJECT includes VOTE. I've searched through the ASF docs, and the only 
place I can see PROPOSAL discussed, is[1], hence my confusion.:

[1]
http://www.apache.org/foundation/how-it-works.html
  Rules require that a negative vote includes an
  alternative proposal or a detailed explanation
  on the reasons for the negative vote.
In any case, My VOTE(s) for this PROPOSAL (assuming they are appropriate 
now) are below:

Creation of the XML Graphics PMC
+1
Very sensible Clay.  It was somewhat premature of me to vote on 
membership before we had a formal proposal for the XML Graphics 
top-level project.  However, I assume the vote on members will still be 
valid when we get to putting a proposal forward, and voting on the 
acceptance of the charter.  If not, we can ask for it again.

Peter
--
Peter B. West 

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Clay Leeds]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Being new to this VOTING thing, I'm a bit confused. I believe I've made 
it clear in a previous message, that I'm in favor of the PROPOSAL to 
create the XML Graphics PMC which will be the new 'home' of FOP and 
Batik, but I'm unclear on how this process works. I'm also in favor of 
the votes for membership expressed below (scroll down a bit for my 
specific votes...).

What I'm unclear on, is the 'legal' difference between PROPOSAL and 
VOTE. I'd thought that the only time a VOTE really counts is when the 
SUBJECT includes VOTE. I've searched through the ASF docs, and the only 
place I can see PROPOSAL discussed, is[1], hence my confusion.:

[1]
http://www.apache.org/foundation/how-it-works.html
  Rules require that a negative vote includes an
  alternative proposal or a detailed explanation
  on the reasons for the negative vote.
In any case, My VOTE(s) for this PROPOSAL (assuming they are 
appropriate now) are below:

Creation of the XML Graphics PMC
+1
On Jun 25, 2004, at 2:28 AM, Peter B. West wrote:
Peter B. West wrote:
Formally, my votes for membership of the XML Graphics PMC are:
Joerg Pietschmann +1
+1
Glen Mazza+1
+1
Jeremias Maerki   +1 (conditional on his acceptance of nomination)
+1 (conditional on his acceptance of nomination)
Peter
Jeremias Maerki wrote:
Hi everyone,
4. I propose both Vincent Hardy and Thomas DeWeese from the Batik
project as PMC members. I'd appreciate if at least one of the two
accepted even if you can't actively participate in the development.
You know it isn't much to do but it's important to have at least 
someone
on board.
Note that I will vote for Vincent and/or Thomas if they express an 
interest.
As will I.
Vincent Hardy +1 (conditional on his acceptance of nomination)
Thomas DeWeese +1 (conditional on his acceptance of nomination)
Peter
--
Peter B. West 
Clay Leeds - [EMAIL PROTECTED]
- -- 
Web Developer - Medata, Inc. - 
PGP Public Key: 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkDcPLMACgkQRixs4Cbu7eh8+wCfSOT2Cr2MPV9QTC46QxTWhTh8
2/oAoLBA5e3j6x2/2pz++XTUP2Y0Cnz+
=savY
-END PGP SIGNATURE-

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Peter B. West]

Peter B. West wrote:
Formally, my votes for membership of the XML Graphics PMC are:
Joerg Pietschmann +1
Glen Mazza+1
Jeremias Maerki   +1 (conditional on his acceptance of nomination)
Peter
Jeremias Maerki wrote:
Hi everyone,
4. I propose both Vincent Hardy and Thomas DeWeese from the Batik
project as PMC members. I'd appreciate if at least one of the two
accepted even if you can't actively participate in the development.
You know it isn't much to do but it's important to have at least someone
on board.
Note that I will vote for Vincent and/or Thomas if they express an interest.
Peter
--
Peter B. West 

[Fwd: Re: [PROPOSAL] Finally creating the XML Graphics PMC....]

[Peter B. West]

This went only to general.  Must get into the habit of actually reading 
the To address.  The discussion seems to have migrated to 
[EMAIL PROTECTED]

Peter
 Original Message 
Subject: Re: [PROPOSAL] Finally creating the XML Graphics PMC
Date: Fri, 25 Jun 2004 18:43:55 +1000
From: Peter B. West <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Jeremias,
Thanks for the work on such thankless tasks as this, and thanks for the
nomination.  I have expressed some scepticism about the direction the
Board is taking with TLPs, but it doesn't hurt to have a sceptic on the
PMC.  Like you, I'm sure, I don't particularly like administrative work,
but I'm honoured to be nominated.
I would urge new committers to consider indicating a preparedness (on or
off line) to participate in the PMC.  When I was first elected to the
XML PMC as a FOP rep, I was quite up-front about the appeal of
membership on my C.V., so don't be shy.
I would also like to see you on the PMC, is only because it is fair to
recognise the amount of effort you have put into bringing this TLP into
being.
If you want to bounce ideas about, or drafts of, the charter off me,
please do so.  I'll give what assistance I can.
Formally, my votes for membership of the XML Graphics PMC are:
Joerg Pietschmann +1
Glen Mazza+1
Jeremias Maerki   +1 (conditional on his acceptance of nomination)
Peter
Jeremias Maerki wrote:
Hi everyone,
Berin thankfully pushed again and I'm taking the time for another round.
Considering what I think is the general opinion, here's what I propose:
1. We create that XML Graphics PMC taking Batik and FOP under the new
umbrella. I hope I don't have to explain again that nothing will change
for our users. We will still use the XML project's infrastructure.
2. We will take Batik in even though the patient is in a suboptimal
condition ATM. The PMC to-be-formed agrees to keep an eye on the project
and help if any potential new committer bubbles up. When Batik's life
energies come up to healthy levels again it shall be more strongly
represented in the PMC as people come available.
3. I propose the following FOP people for the minimal initial PMC: Peter
B. West, Jörg Pietschmann, Glen Mazza. I'd also propose at least someof
the more junior committers but I don't know how anyone feels about that.
Please propose any additional candidates as you see fit. I don't propose
myself but I'm available if anyone proposes me.
4. I propose both Vincent Hardy and Thomas DeWeese from the Batik
project as PMC members. I'd appreciate if at least one of the two
accepted even if you can't actively participate in the development.
You know it isn't much to do but it's important to have at least someone
on board.
I'll update the board resolution draft and set up a charter draft during
the next few days (also peeking at the other works). The proposed PMC
members are kindly invited to indicate whether they would be available
for the post. Votes of support are requested for the nominations.
If anyone is against this proposal (or parts of it) please speak up. We
need to get this done.
I appreciate any kind of help I can get.
Jeremias Maerki
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Chris Bowditch]

Glen Mazza wrote:
Reconsidered.  OK, I'll join, and reinstate my first
proposal, that of you joining the PMC and (yes) being
its head.
Hi Glen,
glad that you reconsidered, I agree with Jeremias, the PMC needs you. It also 
needs Jeremias, so I second your proposal to have Jeremias on the PMC.

Chris

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Simon Pepping]

On Sat, Jun 19, 2004 at 03:30:30PM +0200, Jeremias Maerki wrote:
> Hi everyone,
> 
> Berin thankfully pushed again and I'm taking the time for another round.
> Considering what I think is the general opinion, here's what I propose:
> 
> 1. We create that XML Graphics PMC taking Batik and FOP under the new
> umbrella. I hope I don't have to explain again that nothing will change
> for our users. We will still use the XML project's infrastructure.

I have not followed the discussion and do not know the advantages or
disadvantages. Therefore I am neither in favour of nor against this
proposal.
 
> 3. I propose the following FOP people for the minimal initial PMC: Peter
> B. West, Jörg Pietschmann, Glen Mazza. I'd also propose at least some of
> the more junior committers but I don't know how anyone feels about that.
> Please propose any additional candidates as you see fit. I don't propose
> myself but I'm available if anyone proposes me.

Sounds fine with me. I do care about organizational matters, as a
necessary evil. But I have little time to spend on FOP, and I would
not like to fragment it over multiple concerns. Therefore I prefer not
to be a candidate. I have not been long enough on the project anyway.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Glen Mazza]

Reconsidered.  OK, I'll join, and reinstate my first
proposal, that of you joining the PMC and (yes) being
its head.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen,
> 
> but the fact that you're already monitoring
> batik-dev already shows me
> that you're de-facto monitoring the project. Help
> keep an eye on how
> things go on over there. You don't need write access
> to Batik's codebase
> to do that. That's all that's needed. One part of
> the XML Graphics
> proposal (at least for me) is to work closer
> together. Maybe to develop
> common components later. That's another reason I'd
> like to have you in
> the PMC. You've contributed a lot to the XML
> Graphics discussion without
> being in the XML PMC in the first place. Shows me
> that you care. The
> biggest part to get this working is to set up the
> resolution and charter,
> from then on I don't think there's a lot to do. The
> XML PMC list is not
> that active. Please reconsider.
> 
> On 21.06.2004 00:52:04 Glen Mazza wrote:
> > I do know, however, that I don't need the headache
> of being concerned 
> > about it, or the maintenance responsibility for it
> should something be 
> > wrong.  I have way too much work on FOP.  And see
> nothing gained by 
> > being (1) responsible for a product while (2) not
> having write access to 
> > it.  (Even if I did get write access, SVG is not
> one of my main 
> > interests anyway.)  Accordingly, I'm taking myself
> out of this PMC 
> > proposal--I don't care to sit on this PMC.  But
> thanks for your offer.
> 
> 
> Jeremias Maerki
> 
> 

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Jeremias Maerki]

Glen,

but the fact that you're already monitoring batik-dev already shows me
that you're de-facto monitoring the project. Help keep an eye on how
things go on over there. You don't need write access to Batik's codebase
to do that. That's all that's needed. One part of the XML Graphics
proposal (at least for me) is to work closer together. Maybe to develop
common components later. That's another reason I'd like to have you in
the PMC. You've contributed a lot to the XML Graphics discussion without
being in the XML PMC in the first place. Shows me that you care. The
biggest part to get this working is to set up the resolution and charter,
from then on I don't think there's a lot to do. The XML PMC list is not
that active. Please reconsider.

On 21.06.2004 00:52:04 Glen Mazza wrote:
> I do know, however, that I don't need the headache of being concerned 
> about it, or the maintenance responsibility for it should something be 
> wrong.  I have way too much work on FOP.  And see nothing gained by 
> being (1) responsible for a product while (2) not having write access to 
> it.  (Even if I did get write access, SVG is not one of my main 
> interests anyway.)  Accordingly, I'm taking myself out of this PMC 
> proposal--I don't care to sit on this PMC.  But thanks for your offer.


Jeremias Maerki

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Glen Mazza]

Jeremias,
I agree with you.  Thomas apparently stopped working on it because of 
licensing issues.  For all I know about Batik--next to nothing--perhaps 
it links with 10-15 libraries, half of which may have incompatible or 
out-of-date licensing.  I have no clue, and I'm not motivated enough to 
study its code base to find out.

I do know, however, that I don't need the headache of being concerned 
about it, or the maintenance responsibility for it should something be 
wrong.  I have way too much work on FOP.  And see nothing gained by 
being (1) responsible for a product while (2) not having write access to 
it.  (Even if I did get write access, SVG is not one of my main 
interests anyway.)  Accordingly, I'm taking myself out of this PMC 
proposal--I don't care to sit on this PMC.  But thanks for your offer.

Also, based on your response, I'm going to rescind my three proposals.  
If you are interested in any of them, please propose yourself, or wait 
for another team member to propose you.

Thanks,
Glen
Jeremias Maerki wrote:
Yeah, take up some tedious job and end up with even more in your
rucksack. If it has to be I can do the PMC head job but I'd rather have
someone else do that, like Peter, for example. You know how limited my
Apache time budget is, lately. Nowadays I'm simply more an observer than
anything else.
As for the Batik committership idea, I don't think that's a good one. I
don't know the Batik codebase well enough to do any serious testing as
is required when you apply a patch. There's simply too much that can go
wrong. I'd have to find out how the whole testing infrastructure works
etc. etc. Too time-consuming. I'd rather we find ways to revive the
project from within the Batik community.
On 19.06.2004 16:15:55 Glen Mazza wrote:
 

Everything is fine--especially adding me to the PMC
;)--but three more proposals to add:
1.)  Jeremias Maerki added to this PMC and also made
head of it.  

2.)  Jeremias Maerki automatically added as committer
to the Batik project at (or just before) time of
formation of XML Graphics.  Batik has not been active
for quite some time, and it needs more committers to
be able to apply patches to its code base.  He is
already well trained in SVG and Java Graphics.
[Bulletin:  Apparently Batik will be getting one more
committer soon:
http://marc.theaimsgroup.com/?l=batik-dev&m=108739195725928&w=2]
3.)  Upon becoming committer, as "price" for Batik
committership, Jeremias will update the licenses on
its source files to the 2.0 license.
   


Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Jeremias Maerki]

Yeah, take up some tedious job and end up with even more in your
rucksack. If it has to be I can do the PMC head job but I'd rather have
someone else do that, like Peter, for example. You know how limited my
Apache time budget is, lately. Nowadays I'm simply more an observer than
anything else.

As for the Batik committership idea, I don't think that's a good one. I
don't know the Batik codebase well enough to do any serious testing as
is required when you apply a patch. There's simply too much that can go
wrong. I'd have to find out how the whole testing infrastructure works
etc. etc. Too time-consuming. I'd rather we find ways to revive the
project from within the Batik community.

On 19.06.2004 16:15:55 Glen Mazza wrote:
> Everything is fine--especially adding me to the PMC
> ;)--but three more proposals to add:
> 
> 1.)  Jeremias Maerki added to this PMC and also made
> head of it.  
>
> 2.)  Jeremias Maerki automatically added as committer
> to the Batik project at (or just before) time of
> formation of XML Graphics.  Batik has not been active
> for quite some time, and it needs more committers to
> be able to apply patches to its code base.  He is
> already well trained in SVG and Java Graphics.
> 
> [Bulletin:  Apparently Batik will be getting one more
> committer soon:
> http://marc.theaimsgroup.com/?l=batik-dev&m=108739195725928&w=2]
> 
> 3.)  Upon becoming committer, as "price" for Batik
> committership, Jeremias will update the licenses on
> its source files to the 2.0 license.


Jeremias Maerki

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Clay Leeds]

This seems like a sound proposal to me. Batik being such an important
component of the family, it is important to keep it maintained. See below
for other comments...

Glen Mazza said:
> Everything is fine--especially adding me to the PMC
> ;)--but three more proposals to add:
>
> 1.)  Jeremias Maerki added to this PMC and also made
> head of it.

Hear! Hear!

> 2.)  Jeremias Maerki automatically added as committer
> to the Batik project at (or just before) time of
> formation of XML Graphics.  Batik has not been active
> for quite some time, and it needs more committers to
> be able to apply patches to its code base.  He is
> already well trained in SVG and Java Graphics.
>
> [Bulletin:  Apparently Batik will be getting one more
> committer soon:
> http://marc.theaimsgroup.com/?l=batik-dev&m=108739195725928&w=2]

Makes sense to me...

> 3.)  Upon becoming committer, as "price" for Batik
> committership, Jeremias will update the licenses on
> its source files to the 2.0 license.

Having recently completed the same thing for FOP I can think of no one
more 'qualified'!

> Glen
>
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>> Hi everyone,
>>
>> Berin thankfully pushed again and I'm taking the
>> time for another round.
>> Considering what I think is the general opinion,
>> here's what I propose:
>>
>> 1. We create that XML Graphics PMC taking Batik and
>> FOP under the new
>> umbrella. I hope I don't have to explain again that
>> nothing will change
>> for our users. We will still use the XML project's
>> infrastructure.
>>
>> 2. We will take Batik in even though the patient is
>> in a suboptimal
>> condition ATM. The PMC to-be-formed agrees to keep
>> an eye on the project
>> and help if any potential new committer bubbles up.
>> When Batik's life
>> energies come up to healthy levels again it shall be
>> more strongly
>> represented in the PMC as people come available.
>>
>> 3. I propose the following FOP people for the
>> minimal initial PMC: Peter
>> B. West, Jörg Pietschmann, Glen Mazza. I'd also
>> propose at least some of
>> the more junior committers but I don't know how
>> anyone feels about that.
>> Please propose any additional candidates as you see
>> fit. I don't propose
>> myself but I'm available if anyone proposes me.

I'm happy to assist in any capacity I'm able to assist.

>> 4. I propose both Vincent Hardy and Thomas DeWeese
>> from the Batik
>> project as PMC members. I'd appreciate if at least
>> one of the two
>> accepted even if you can't actively participate in
>> the development.
>> You know it isn't much to do but it's important to
>> have at least someone
>> on board.

I couldn't agree more. Having the most active participants on the PMC is
important in maintaining the 'flow' of development. It might also be good
to invite other Batik contributors as well, although I'm not particularly
familiar with the history of Batik.

>> I'll update the board resolution draft and set up a
>> charter draft during
>> the next few days (also peeking at the other works).
>> The proposed PMC
>> members are kindly invited to indicate whether they
>> would be available
>> for the post. Votes of support are requested for the
>> nominations.
>>
>> If anyone is against this proposal (or parts of it)
>> please speak up. We
>> need to get this done.
>>
>> I appreciate any kind of help I can get.
>>
>> Jeremias Maerki

Thank you, Jeremias for doing all this work, and following thorugh to make
certain things go as smoothly as possible. This sounds like a well
thought-out proposal, and I hope it is viewed favorably by all involved.

Web Maestro Clay

Re: [PROPOSAL] Finally creating the XML Graphics PMC....

[Glen Mazza]

Everything is fine--especially adding me to the PMC
;)--but three more proposals to add:

1.)  Jeremias Maerki added to this PMC and also made
head of it.  

2.)  Jeremias Maerki automatically added as committer
to the Batik project at (or just before) time of
formation of XML Graphics.  Batik has not been active
for quite some time, and it needs more committers to
be able to apply patches to its code base.  He is
already well trained in SVG and Java Graphics.

[Bulletin:  Apparently Batik will be getting one more
committer soon:
http://marc.theaimsgroup.com/?l=batik-dev&m=108739195725928&w=2]

3.)  Upon becoming committer, as "price" for Batik
committership, Jeremias will update the licenses on
its source files to the 2.0 license.

Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Hi everyone,
> 
> Berin thankfully pushed again and I'm taking the
> time for another round.
> Considering what I think is the general opinion,
> here's what I propose:
> 
> 1. We create that XML Graphics PMC taking Batik and
> FOP under the new
> umbrella. I hope I don't have to explain again that
> nothing will change
> for our users. We will still use the XML project's
> infrastructure.
> 
> 2. We will take Batik in even though the patient is
> in a suboptimal
> condition ATM. The PMC to-be-formed agrees to keep
> an eye on the project
> and help if any potential new committer bubbles up.
> When Batik's life
> energies come up to healthy levels again it shall be
> more strongly
> represented in the PMC as people come available.
> 
> 3. I propose the following FOP people for the
> minimal initial PMC: Peter
> B. West, Jörg Pietschmann, Glen Mazza. I'd also
> propose at least some of
> the more junior committers but I don't know how
> anyone feels about that.
> Please propose any additional candidates as you see
> fit. I don't propose
> myself but I'm available if anyone proposes me.
> 
> 4. I propose both Vincent Hardy and Thomas DeWeese
> from the Batik
> project as PMC members. I'd appreciate if at least
> one of the two
> accepted even if you can't actively participate in
> the development.
> You know it isn't much to do but it's important to
> have at least someone
> on board.
> 
> I'll update the board resolution draft and set up a
> charter draft during
> the next few days (also peeking at the other works).
> The proposed PMC
> members are kindly invited to indicate whether they
> would be available
> for the post. Votes of support are requested for the
> nominations.
> 
> If anyone is against this proposal (or parts of it)
> please speak up. We
> need to get this done.
> 
> I appreciate any kind of help I can get.
> 
> Jeremias Maerki
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[J.Pietschmann]

Finn Bock wrote:
The same way that I locally solved the Jimi and JAI dependency:

copy d:\java\ant-1.5.1\lib\ant.jar lib

and adding the .jar to the "Java Build Path/Libraries".
You don't need the copy, you can add "external jars" as
well.
J.Pietschmann

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

Finn Bock wrote:
[me]

Now that ant.jar has been removed, the project is slightly less 
friendly to eclipse since ant.jar is required by the files in 
org.apache.fop.tools.anttasks.

It is easily solved locally, I just wanted to point it out.


[Peter B. West]

Finn,

I've been trying to find an Eclipse-clean way to solve this one.  How 
did you do it?


The same way that I locally solved the Jimi and JAI dependency:

copy d:\java\ant-1.5.1\lib\ant.jar lib

and adding the .jar to the "Java Build Path/Libraries".
I'm using 3.0 M5, and I have just defined a classpath variable for the 
ant.jar in eclipse/plugins.  Eclipse lets me add the variable to the 
classpath for the project.

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Finn Bock]

[me]

Now that ant.jar has been removed, the project is slightly less 
friendly to eclipse since ant.jar is required by the files in 
org.apache.fop.tools.anttasks.

It is easily solved locally, I just wanted to point it out.
[Peter B. West]

Finn,

I've been trying to find an Eclipse-clean way to solve this one.  How 
did you do it?
The same way that I locally solved the Jimi and JAI dependency:

copy d:\java\ant-1.5.1\lib\ant.jar lib

and adding the .jar to the "Java Build Path/Libraries".

regards,
finn

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

Finn Bock wrote:
Now that ant.jar has been removed, the project is slightly less friendly 
to eclipse since ant.jar is required by the files in 
org.apache.fop.tools.anttasks.

It is easily solved locally, I just wanted to point it out.
Finn,

I've been trying to find an Eclipse-clean way to solve this one.  How 
did you do it?

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Finn Bock]

[Jeremias Maerki]

I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh
to call a separately installed Ant. Instructions will be given on the
command-line if Ant cannot be found.
Now that ant.jar has been removed, the project is slightly less friendly 
to eclipse since ant.jar is required by the files in 
org.apache.fop.tools.anttasks.

It is easily solved locally, I just wanted to point it out.

regards,
finn

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Jeremias Maerki]

No, I guess that's what was needed. Thanks.

On 14.12.2003 09:57:50 Peter B. West wrote:
> Jeremias Maerki wrote:
> > I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh
> > to call a separately installed Ant. Instructions will be given on the
> > command-line if Ant cannot be found.
> > 
> > Peter, please test build.sh on Unix. I hope I got the whole thing right.
> > 
> 
> Jeremias,
> 
> It compiles when ANT_HOME is defined and valid, and gives the 
> instructions when it's not defined.  Do you need more extensive test run?


Jeremias Maerki

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

Jeremias Maerki wrote:
I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh
to call a separately installed Ant. Instructions will be given on the
command-line if Ant cannot be found.
Peter, please test build.sh on Unix. I hope I got the whole thing right.

Jeremias,

It compiles when ANT_HOME is defined and valid, and gives the 
instructions when it's not defined.  Do you need more extensive test run?

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Glen Mazza]

Well done--I particularly liked the Ant instructions
you added.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I've removed the embedded Ant in HEAD. I rewrote
> build.bat and build.sh
> to call a separately installed Ant. Instructions
> will be given on the
> command-line if Ant cannot be found.
> 
> Peter, please test build.sh on Unix. I hope I got
> the whole thing right.
> 
> 
> Jeremias Maerki
> 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Jeremias Maerki]

I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh
to call a separately installed Ant. Instructions will be given on the
command-line if Ant cannot be found.

Peter, please test build.sh on Unix. I hope I got the whole thing right.


Jeremias Maerki

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Jeremias Maerki]

On 12.12.2003 16:33:44 Clay Leeds wrote:
> Thanks for doing the legwork to get perspective on how important ant 
> is. I'll definitely be saddling up (yeehaw!) and checking it out.

You had to install Forrest, too, right? Another tool a fop-dev has to
come used to.

> However, I too don't think fop-users (maintenance branch anyway) should 
> have to download and configure ant for their purposes. Since ant is a 
> build tool, I guess if a fop-user downloads the binary version 
> (pre-built), they won't have to worry about ant anyway, so that point 
> is moot for binary fop-users.

Right. Users shouldn't have to come in contact with Ant IMO.

> In any case, I don't think fop-users (maintenance branch) should have 
> to download any more than necessary. I guess what this means, is that I 
> think the Maintenance Branch should include ant in the source 
> distribution, because I think it'll help limit traffic from people 
> asking for help. Regardless of whether or not the Maintenance Branch 
> includes ant, we may need to update the Build/Compiling page w more 
> info on how to use ant (it currently contains a link to Ant--is that 
> enough?).

Well, HEAD will again spawn a maintenance branch some time in the future.
Anyway, I think it's basically a matter of documentation and good
error/info messages. There are other problems, too: We simply can't
bundle some of the third-party JARs (Jimi, JAI) because of licensing
problems. I think there will always be some work involved until you can
run/build FOP (or any other Java product for that matter). It's our job
to make these tasks as unproblematic as possible.

Jeremias Maerki

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Clay Leeds]

Jeremias,

On Dec 12, 2003, at 7:13 AM, Jeremias Maerki wrote:
I don't think so, as potential fop-dev have to learn about other 
things,
too, especially CVS and how to build patches. I think that's a lot more
complicated than having to install Ant.

fop-devs can be expected to know about Ant because almost every Open
Source project written in Java I've encountered uses an Ant-based build
(or a build system based on Ant like Maven or Centipede). Actually 
every
Java developer can today be expected to know about Ant because it is 
the
de-facto standard for Java builds.

Simple users on the other side shouldn't be expected to build FOP. They
should never have a reason to rebuild FOP. If they do we've probably
failed to do every thing right.
Thanks for doing the legwork to get perspective on how important ant 
is. I'll definitely be saddling up (yeehaw!) and checking it out.

However, I too don't think fop-users (maintenance branch anyway) should 
have to download and configure ant for their purposes. Since ant is a 
build tool, I guess if a fop-user downloads the binary version 
(pre-built), they won't have to worry about ant anyway, so that point 
is moot for binary fop-users.

In any case, I don't think fop-users (maintenance branch) should have 
to download any more than necessary. I guess what this means, is that I 
think the Maintenance Branch should include ant in the source 
distribution, because I think it'll help limit traffic from people 
asking for help. Regardless of whether or not the Maintenance Branch 
includes ant, we may need to update the Build/Compiling page w more 
info on how to use ant (it currently contains a link to Ant--is that 
enough?).

Clay
--
There are only 10 kinds of people in the world: those who understand 
binary and those who don't.
Web Maestro Clay <[EMAIL PROTECTED]>

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Jeremias Maerki]

I don't think so, as potential fop-dev have to learn about other things,
too, especially CVS and how to build patches. I think that's a lot more
complicated than having to install Ant.

fop-devs can be expected to know about Ant because almost every Open
Source project written in Java I've encountered uses an Ant-based build
(or a build system based on Ant like Maven or Centipede). Actually every
Java developer can today be expected to know about Ant because it is the
de-facto standard for Java builds.

Simple users on the other side shouldn't be expected to build FOP. They
should never have a reason to rebuild FOP. If they do we've probably
failed to do every thing right.

Here are some of Apache's Java projects I checked:
- Xindice: build.bat/sh references separately installed Ant
- Xerces-J: embedded Ant
- Xalan-J: embedded Ant
- xml-security: only build.xml, not batch files, requires Ant
- Forrest: embedded Ant
- Crimson: only build.xml, not batch files, requires Ant
- XML Commons: only build.xml, not batch files, requires Ant
- Cocoon 2.x: embedded Ant
- Batik: embedded Ant
- WS SOAP: only build.xml, not batch files, requires Ant
- WS Jaxme: only build.xml, not batch files, requires Ant
- WS Axis: only build.xml, not batch files, requires Ant
- WS JUDDI: only build.xml, not batch files, requires Ant
- Maven: only build.xml, not batch files, requires Ant
- James: embedded Ant
- Velocity: not batch files, requires installed Maven
- Tomcat 4: only build.xml, not batch files, requires Ant
- Tapestry: Requires either installed Maven or Ant
- Struts: Requires either installed Maven or Ant
- Jakarta Regexp: only build.xml, not batch files, requires Ant
- POI: only build.xml, not batch files, requires Ant
- Log4J: only build.xml, not batch files, requires Ant
- Geronimo: not batch files, requires installed Maven
- Avalon Framework: Requires either installed Maven or Ant

On 11.12.2003 23:08:49 Michael Reiche wrote:
> I absolutely agree, you will loose potential fop-devs. Do NOT remove
> ant/build. I just recently discovered the easy all-in-one power of the
> FOP src package. Download, unpack, fiddle with some .java, and run
> build.sh! I know nothing about the use of ant, and would have had to do
> some surfing before even getting to the point of doing a recompile. Well
> I might benefit from this in other cases, but the word "build" tell a
> lot more about the job than "ant", and build.sh has worked very well for
> me.
> 
> I'm sure there is a lot of other things that can be done, to cure
> whatever fired this idea.

The fact that fired this idea was that the build behaved differently
between running the installed and the embedded Ant.

Some people will want to run the FOP build from their IDEs (like
JBuilder and Eclipse). In this case they can't use the embedded Ant
anyway.

Jeremias Maerki

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[J.Pietschmann]

Peter B. West wrote:
In the medium term, I think some sort of protocol for provides/requires 
and versioning will have to be established for matching jars.  It has 
always galled me that everyone bundles everything to ensure that a 
particular application runs.
Short: use Maven.

What does mavenizing entail?
Write a project.xml file which describes the project on a higher
level than the ant build file. Whether that's really easy for FOP
with all the weirdness and conditional compiles is another matter.
Because Maven downloads dependencies from a repository, we could
outsource some more common stuff more easy, and the source distro
becomes leaner.
J.Pietschmann

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

J.Pietschmann wrote:
Hmhm. The unix version (build.sh) added *all* jars in the
lib directory to the classpath, which made the "drop into
lib and call build.dh" much easier. If this has to be done
in build.xml, there's trouble ahead with jars containing
release identifiers and such ugly stuff.
Well, the build.bat had tis problem for ages.
In the medium term, I think some sort of protocol for provides/requires 
and versioning will have to be established for matching jars.  It has 
always galled me that everyone bundles everything to ensure that a 
particular application runs.

I'm contemplating mavenizing the build. I've got the
personal advantage of working on commons-math which
is also mavenized, and I have the repository already.
OTOH I have no idea whether and how well mave would handle
dependencies on Jimi, JAI, LotBC and other odd non-apache
stuff.
What does mavenizing entail?

Incidentally, in the alt.design build, I have separated Version.java 
into its own package, and I compile it separately at the beginning of 
the build process to obtain version information for the rest of the 
build.  A package is probably overkill.  Fop.java and Version.java 
should probably belong to org.apache.fop.

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Glen Mazza]

--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> Web Maestro Clay
> 
> p.s. I guess this means I get to add ant to my list
> of tools in my 
> toolbox... :-)
> 

Yes, highly transportable skills in CVS and Ant may be
the two biggest up-front goodies you get by working on
FOP.  

Instructions: 
1.) Download ant from ant.apache.org

2.) Set the ANT_HOME environment variable to where you
expanded the ant project.  (Similar to JAVA_HOME).

3.) Add the ant binary directory to your PATH so you
can run ant anywhere.

4.) Navigate to the fop working directory and just
type "ant".  It reads the default "target" (build
goal) in build.xml and builds the project
automatically.

I believe Ant has won several developer-productivity
awards--I don't think anyone's ever been "saddled" by
knowing it!

Glen

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Michael Reiche]

On tor, 2003-12-11 at 16:42, Clay Leeds wrote:
> I don't think ant should be removed from the maintenance branch. 
> Granted, users of HEAD should be adept enough to install and configure 
> ANT, but I think it is more important to make at least the 
> "maintenance" branch of FOP easy to use, than it is to encourage them 
> to install and configure ant. Right now, all you need to run FOP is 
> Java 1.2+. Saddling users with more requirements probably won't 
> "encourage" new users.
> 
> One of the great things I love about fop-0.20.5, is that it includes 
> everything I need to run it (xalan, xerces, etc.). It even includes a 
> xalan.bat script (not included with xalan), which one of my colleagues 
> used to transform an XML file with XSL.
> 
> I believe that one of the goals for FOP is to get more fop-users (even 
> if they're not going to be fop-devs).
> 
> Web Maestro Clay
> 
> p.s. I guess this means I get to add ant to my list of tools in my 
> toolbox... :-)

I absolutely agree, you will loose potential fop-devs. Do NOT remove
ant/build. I just recently discovered the easy all-in-one power of the
FOP src package. Download, unpack, fiddle with some .java, and run
build.sh! I know nothing about the use of ant, and would have had to do
some surfing before even getting to the point of doing a recompile. Well
I might benefit from this in other cases, but the word "build" tell a
lot more about the job than "ant", and build.sh has worked very well for
me.

I'm sure there is a lot of other things that can be done, to cure
whatever fired this idea.
 

-- 
/Reiche

RE: [PROPOSAL] Remove ant.jar and build.bat/sh

[Victor Mote]

Peter B. West wrote:

> Removing ant, fair enough, but why the build scripts?  Shouldn't they be 
> extended a little to check for the presence of an ant installation and 
> make appropriate noises if one isn't found?

I agree.

Victor Mote

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Clay Leeds]

I don't think ant should be removed from the maintenance branch. 
Granted, users of HEAD should be adept enough to install and configure 
ANT, but I think it is more important to make at least the 
"maintenance" branch of FOP easy to use, than it is to encourage them 
to install and configure ant. Right now, all you need to run FOP is 
Java 1.2+. Saddling users with more requirements probably won't 
"encourage" new users.

One of the great things I love about fop-0.20.5, is that it includes 
everything I need to run it (xalan, xerces, etc.). It even includes a 
xalan.bat script (not included with xalan), which one of my colleagues 
used to transform an XML file with XSL.

I believe that one of the goals for FOP is to get more fop-users (even 
if they're not going to be fop-devs).

Web Maestro Clay

p.s. I guess this means I get to add ant to my list of tools in my 
toolbox... :-)

On Dec 10, 2003, at 9:08 PM, Glen Mazza wrote:
+1 for HEAD, and I think it would be fine to remove it
from maintenance as well.
Glen

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[J.Pietschmann]

Glen Mazza wrote:

I disagree on this point, if we're removing ant.jar, I
don't see a need for continuing to maintain a build.sh
and build.bat.  

Given that they must install Ant, it isn't too
traumatic to next navigate to the fop working
directory and type "ant" to make the build.  (I'm not
being sarcastic--the way our build.xml is constructed,
"ant" is all you have to type!)
Hmhm. The unix version (build.sh) added *all* jars in the
lib directory to the classpath, which made the "drop into
lib and call build.dh" much easier. If this has to be done
in build.xml, there's trouble ahead with jars containing
release identifiers and such ugly stuff.
Well, the build.bat had tis problem for ages.
I'm contemplating mavenizing the build. I've got the
personal advantage of working on commons-math which
is also mavenized, and I have the repository already.
OTOH I have no idea whether and how well mave would handle
dependencies on Jimi, JAI, LotBC and other odd non-apache
stuff.
J.Pietschmann

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Glen Mazza]

I disagree on this point, if we're removing ant.jar, I
don't see a need for continuing to maintain a build.sh
and build.bat.  

Given that they must install Ant, it isn't too
traumatic to next navigate to the fop working
directory and type "ant" to make the build.  (I'm not
being sarcastic--the way our build.xml is constructed,
"ant" is all you have to type!)

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I can do that but someone will have to test the unix
> script for me.
> 
> On 11.12.2003 10:33:34 Peter B. West wrote:
> > Removing ant, fair enough, but why the build
> scripts?  Shouldn't they be 
> > extended a little to check for the presence of an
> ant installation and 
> > make appropriate noises if one isn't found?
> 
> Jeremias Maerki


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

Jeremias Maerki wrote:
I can do that but someone will have to test the unix script for me.

On 11.12.2003 10:33:34 Peter B. West wrote:

Removing ant, fair enough, but why the build scripts?  Shouldn't they be 
extended a little to check for the presence of an ant installation and 
make appropriate noises if one isn't found?
Fire when ready.  At the simplest level, we could check on unix for the 
availability of the 'ant' command.  It does it's own checking for an ant 
installation (only in /opt, I think).

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Jeremias Maerki]

I can do that but someone will have to test the unix script for me.

On 11.12.2003 10:33:34 Peter B. West wrote:
> Removing ant, fair enough, but why the build scripts?  Shouldn't they be 
> extended a little to check for the presence of an ant installation and 
> make appropriate noises if one isn't found?

Jeremias Maerki

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Peter B. West]

Jeremias Maerki wrote:
Following a problem on fop-user I'd like to propose the removal of
ant.jar and the build.bar/sh pair. I've heard that best practice is not
to bundle Ant with a project, though I can't point you to a web page.
It's reasonable to expect that everybody who wants to compile a Java
program to install Ant because it's so widely used.
I know it's convenient that you can download FOP and simply call
build.bat but removing our own ant.jar makes the distribution smaller,
removes potential error sources (such as the one uncovered on fop-user
and provided we have a version check in our build.xml).
If nobody objects I will try to find time during the weekend to do that.
Jeremias,

Removing ant, fair enough, but why the build scripts?  Shouldn't they be 
extended a little to check for the presence of an ant installation and 
make appropriate noises if one isn't found?

Peter
--
Peter B. West 

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[Glen Mazza]

Great idea!  Like CVS, Ant is highly beneficial to
learn, and it opens doors to many other open source
projects as well.  So I think this a tool we should be
encouraging others to at least load on their machine.

+1 for HEAD, and I think it would be fine to remove it
from maintenance as well.

Glen  

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Jeremias Maerki wrote:
> > Following a problem on fop-user I'd like to
> propose the removal of
> > ant.jar and the build.bar/sh pair.
> 
> +1 for HEAD.
> In the long term, this means we have to make sure we
> don't
> have to give advice like "Get the source dist,
> change XY in
> the code/add foo.jar to lib, and call
> build.{bat|sh}"
> 
> J.Pietschmann
> 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [PROPOSAL] Remove ant.jar and build.bat/sh

[J.Pietschmann]

Jeremias Maerki wrote:
Following a problem on fop-user I'd like to propose the removal of
ant.jar and the build.bar/sh pair.
+1 for HEAD.
In the long term, this means we have to make sure we don't
have to give advice like "Get the source dist, change XY in
the code/add foo.jar to lib, and call build.{bat|sh}"
J.Pietschmann

Re: [proposal] Peter Herweg as a FOP committer

[Bertrand Delacretaz]

Le Vendredi, 12 sep 2003, à 20:51 Europe/Zurich, Glen Mazza a écrit :
...Thanks for taking the time to clarify
your ideas on this issue.
You're welcome - and in retrospect mine *was* a crazy idea indeed.
This "written communication" thing again - had we been together around 
a table this would have been solved in three minutes ;-)

-Bertrand

Re: [proposal] Peter Herweg as a FOP committer

[Glen Mazza]

--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
> Sorry if I didn't explain my objectives clearly
> enough, but everyone 
> has the right to ask for clarification - and, if you
> allow me some old 
> man advice, it is usually good to do when you think
> something is wrong, 
> before getting the cannons out.

Good advice.  Thanks for taking the time to clarify
your ideas on this issue.

Glen


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [proposal] Peter Herweg as a FOP committer

[Bertrand Delacretaz]

Hi Glen,

I must say I'm very surprised at your response: not the -1 which I can 
accept, but the response below where you don't seem to have understood 
my aim, and the arrogance of which I dislike a lot.

Thanks Jeremias, Victor and J.Pietschmann for your support, you seem to 
have gotten the idea.

I feel FOP is very much in need of active committers, and my definition 
of committer goes further than someone who commits code to CVS.  Even 
though inactive codewise, I try do my best and actually lift my finger 
when I can do something for the project, in the strict limits that I 
have to impose myself due to a chronically overstuffed schedule.

I've known Peter (virtually) for a few weeks and I have a good 
impression of him and his code. Earlier this week he told me that he 
had some free time and was willing to work on the FOP RTF stuff, which 
seemed worth of encouragement to me.

What better encouragement than quickly becoming a committer?
I know perfectly that there are (largely unwritten) rules about when 
someone can be proposed as a committer, and my proposal didn't respect 
all of them. Hence a [proposal] and note a [vote]. Maybe this should 
have been called [wild idead] instead.

I'd have no problem with a "please wait for some more stuff from Peter" 
answer, but it is hard to take your aggressive tone.

I don't want to comment on all your points, they are mostly your 
opinions. I will comment on those that might make a difference for the 
project, though.

...Committership is a months-long-process, and I'll need
to see contributions from your individual named well
past those of Chris, Clay or Andreas before we
consider such a move.  FYI, he's at about 1% of them
right now
I haven't followed in detail what Chris, Clay or Andreas have done, but 
if they're contributing more or less actively to FOP, why not propose 
them as committers? Might motivate them to do even more.

...Maybe if you had decided to lift
a finger for the project and *apply* his patches your
proposal would have carried more weight...
This I can understand. My idea was that maybe Peter would be able to 
commit his own patch, as his first job.

...You just insulted the entire FOP team--committers and
contributors--with your ridiculous suggestion...
You have the right to find my suggestion ridiculous, but I don't think 
it is insulting for the entire team.
If *you* feel insulted then accept my apologies, it was not my goal in 
any way, again just trying to help the project.

Sorry if I didn't explain my objectives clearly enough, but everyone 
has the right to ask for clarification - and, if you allow me some old 
man advice, it is usually good to do when you think something is wrong, 
before getting the cannons out.

...It
would probably be best for the project for you to keep
yourself inactive
I guess this is for the "active committers" to decide .

Ciao,
Bertrand


--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
Hi FOPpers,

I'm making this a proposal instead of directly a
vote, as there are two
unusual things here: I've been recently (and
rightly) moved to inactive
committer status, and it hasn't been a long time
since Peter submitted
his patches.
The reason I'm proposing him is that Peter is
willing to work on the
RTF renderer, which he needs for his job where he's
doing reporting
stuff in RTF and PDF. He's been a committer in jfor
since this summer,
and has commited some very useful patches and
corrections.
If no one objects, I'll move this to a proper vote
so that Peter can
start working efficiently on the RTF stuff as soon
as possible.
-Bertrand



__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

--
  Bertrand Delacretaz
  independent consultant, Lausanne, Switzerland
  http://cvs.apache.org/~bdelacretaz/

Re: [proposal] Peter Herweg as a FOP committer

[J.Pietschmann]

Glen Mazza wrote:
My, such complexity!
That's a bit harsh, isn't it?
We could use every hand willing to help. There's no need
to ridicule useful contributions in public.
J.Pietschmann

RE: (Victor) Re: [proposal] Peter Herweg as a FOP committer

[Victor Mote]

Glen Mazza wrote:

> Do you have time over the next few days to look at
> Peter's patches (and apply them as appropriate)?  Some
> of this proposed code is affecting your turf
> (FOTreeBuilder), etc., the rest is primarily just the
> RTF handler--all changes are thankfully just for
> trunk.  Take a good look at the code.  If you don't
> have time, I'll happily do so this weekend.  (I'll be
> taking care of Thomas' SVG stuff this weekend myself.)

I should be able to get to them before or during this weekend.

Victor Mote

RE: [proposal] Peter Herweg as a FOP committer

[Victor Mote]

Glen Mazza wrote:

> Committership is a months-long-process, and I'll need
> to see contributions from your individual named well
> past those of Chris, Clay or Andreas before we
> consider such a move.  FYI, he's at about 1% of them
> right now.

-1 on imposing a months-long-process for committer status. Far better, IMO,
is the standard of whether the project is better off with this person as a
committer. I was roundly criticized for nominating you earlier than was
usual, but I thought your judgment and skills were sufficient that it was a
net benefit to the project to not slow you down with the patch process. I
still have high hopes that I will be proven right on this point :-) My point
is that I knew you much less well than Bertrand knows Peter.

> I'm surprised you would have us vote for a committer
> someone who just submitted this patch yesterday:
>
>  if (floatValue < 0) {
>  floatValue = 0;
>  }
> -return (int) floatValue * 255;
> +return (int) (floatValue * 255);
>  }
>
> My, such complexity!  Perhaps 1000 people have
> contributed more substantive patches--are we to make
> them committers too?  Maybe if you had decided to lift
> a finger for the project and *apply* his patches your
> proposal would have carried more weight.

-1 on blatant disrespect for Peter and Bertrand. Peter did submit a patch on
Tuesday morning (my time) which I fairly promptly applied, recognizing it as
one that I should probably handle. This was a more substantive patch than
the one mentioned above, and Bertrand would not have had time to apply it:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23022

Perhaps more importantly, I think it is a mistake to judge a patch by its
size or complexity. If it fixed a problem, I appreciate the submission. The
first million or so patches/commits that I made were to documentation,
hardly a glamorous or complex occupation (although I find it hard work), but
one that I thought needed attention. I suspect that the only reason I am a
committer is because I was a constant annoyance to Keiron (which was not my
intention).

> You just insulted the entire FOP team--committers and
> contributors--with your ridiculous suggestion.  It
> would probably be best for the project for you to keep
> yourself inactive.

-1 on blatant disrespect for Bertrand. I do not feel insulted at all. If you
see someone who needs help and you know the solution but don't have time to
implement it yourself, it is reasonable to tell someone else so that they
can do it. I don't know, but guess that is probably what Bertrand is doing
here. My first impression of Peter's work is that he knew what he was doing,
and I am grateful to have Bertrand's affirmation of that impression.

Thank you Peter for your submissions. Please keep them coming, and I
apologize in advance if I am slow in processing them. Thank you Bertrand for
the advice and comments, and for your contributions to this project. They
will weigh heavily in my thinking. I look forward to the day when you can
become active again.


The single most important thing that FOP developers can do right now is to
develop other FOP developers. All of my efforts are bent toward the shortest
path that will allow me to say (with a straight face) "FOP is a fun place to
work. Come help us." It will be fatal to gain a reputation for eating our
young or disrespecting past contributors because, for whatever reason, they
are not contributing right now. I have already addressed the issue of
disrespect for current contributors in another thread (unanswered to date).
I do not mean to discourage thoughtful, reasonable discussions -- heated
even, if necessary. We actually need quite a bit of this to get the
infrastructure built. But I hope it will always be done from the standpoint
of respect, at least until it is clear that respect cannot be given.


Victor Mote

(Victor) Re: [proposal] Peter Herweg as a FOP committer

[Glen Mazza]

Hello Victor,

Do you have time over the next few days to look at
Peter's patches (and apply them as appropriate)?  Some
of this proposed code is affecting your turf
(FOTreeBuilder), etc., the rest is primarily just the
RTF handler--all changes are thankfully just for
trunk.  Take a good look at the code.  If you don't
have time, I'll happily do so this weekend.  (I'll be
taking care of Thomas' SVG stuff this weekend myself.)

Thanks,
Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen, 
> 
> please adjust your tone. Bertrand is only proposing
> a vote, not actually
> voting. Everyone is entitled to propose new
> committers, it has nothing
> to do with the actual voting. If Betrand says Peter
> Herweg provides good
> input, then it's good enough for me to really
> consider holding such a
> vote. We're desperately in need of new committers.
> You know that, making
> about 50% of the current contributions. It may be
> true that in the past
> new FOP committer candidates needed to show stamina
> for an extended
> amount of time before being accepted. It took me
> more than 18 months.
> That's not entirely a bad thing, but FOP doesn't
> have this much reserves
> to wait so long until new people can be voted in.
> IMO we sometimes wait
> too long until new people are voted in. As you
> pointed out Chris, Clay
> and Andreas, for example, are actually good
> candidates for committers
> although they haven't contributed much/any code,
> yet. Some people
> deserve the status if only for helping out on
> fop-user and posting good
> ideas. Maybe they can be motivated to contributing
> more code by
> promoting them. And there's no hard rule making us
> wait a few months
> before we can vote someone in. So let's first see
> what others have to
> say about this before beating that proposal down
> outright.
> 
> 
> Jeremias Maerki
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [proposal] Peter Herweg as a FOP committer

[Jeremias Maerki]

Glen, 

please adjust your tone. Bertrand is only proposing a vote, not actually
voting. Everyone is entitled to propose new committers, it has nothing
to do with the actual voting. If Betrand says Peter Herweg provides good
input, then it's good enough for me to really consider holding such a
vote. We're desperately in need of new committers. You know that, making
about 50% of the current contributions. It may be true that in the past
new FOP committer candidates needed to show stamina for an extended
amount of time before being accepted. It took me more than 18 months.
That's not entirely a bad thing, but FOP doesn't have this much reserves
to wait so long until new people can be voted in. IMO we sometimes wait
too long until new people are voted in. As you pointed out Chris, Clay
and Andreas, for example, are actually good candidates for committers
although they haven't contributed much/any code, yet. Some people
deserve the status if only for helping out on fop-user and posting good
ideas. Maybe they can be motivated to contributing more code by
promoting them. And there's no hard rule making us wait a few months
before we can vote someone in. So let's first see what others have to
say about this before beating that proposal down outright.


Jeremias Maerki

Re: [proposal] Peter Herweg as a FOP committer

[Glen Mazza]

Also, Bertrand, for votes, you'll have to make
yourself active again--edit team.xml--and hopefully
for more than just submitting the names of people who
have been supplying patches for all of 24 hours.  I'm,
however, not very optimistic on that point.

Committership is a months-long-process, and I'll need
to see contributions from your individual named well
past those of Chris, Clay or Andreas before we
consider such a move.  FYI, he's at about 1% of them
right now.

I'm surprised you would have us vote for a committer
someone who just submitted this patch yesterday:

 if (floatValue < 0) {
 floatValue = 0;
 }
-return (int) floatValue * 255;
+return (int) (floatValue * 255);
 }
 
My, such complexity!  Perhaps 1000 people have
contributed more substantive patches--are we to make
them committers too?  Maybe if you had decided to lift
a finger for the project and *apply* his patches your
proposal would have carried more weight.

You just insulted the entire FOP team--committers and
contributors--with your ridiculous suggestion.  It
would probably be best for the project for you to keep
yourself inactive.

Glen


--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
> Hi FOPpers,
> 
> I'm making this a proposal instead of directly a
> vote, as there are two 
> unusual things here: I've been recently (and
> rightly) moved to inactive 
> committer status, and it hasn't been a long time
> since Peter submitted 
> his patches.
> 
> The reason I'm proposing him is that Peter is
> willing to work on the 
> RTF renderer, which he needs for his job where he's
> doing reporting 
> stuff in RTF and PDF. He's been a committer in jfor
> since this summer, 
> and has commited some very useful patches and
> corrections.
> 
> If no one objects, I'll move this to a proper vote
> so that Peter can 
> start working efficiently on the RTF stuff as soon
> as possible.
> 
> -Bertrand
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [proposal] Peter Herweg as a FOP committer

[Glen Mazza]

-1; he can supply patches and we'll apply them.

--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
> Hi FOPpers,
> 
> I'm making this a proposal instead of directly a
> vote, as there are two 
> unusual things here: I've been recently (and
> rightly) moved to inactive 
> committer status, and it hasn't been a long time
> since Peter submitted 
> his patches.
> 
> The reason I'm proposing him is that Peter is
> willing to work on the 
> RTF renderer, which he needs for his job where he's
> doing reporting 
> stuff in RTF and PDF. He's been a committer in jfor
> since this summer, 
> and has commited some very useful patches and
> corrections.
> 
> If no one objects, I'll move this to a proper vote
> so that Peter can 
> start working efficiently on the RTF stuff as soon
> as possible.
> 
> -Bertrand
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: Proposal

[Rhett Aultman]

Well, if page breaking interests you, you could help me with resolving a page breaking 
issue in the FOP maintenance branch.  Contact me privately ([EMAIL PROTECTED]) 
and I'll explain.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 9:25 AM
To: [EMAIL PROTECTED]
Subject: Re: Proposal



i thank thee Oleg... what astupid mistake, used that months ago once to :(

sleeping should help

anyway, i'm still interested in making something for FOP... would really
like to get to know the internal more... :D

Jochen Maes
ICT Development


KBC Securities (kbcsecurities.com)
Havenlaan 12 Avenue du Port SIF 8683
B-1080 Brussels
Belgium

 Tel:  +32 2 429 96 81  

 GSM:  +32 496 57 90 99 

 E-mail :  [EMAIL PROTECTED] 





This message and any attachments hereto are for the named person's use
only. It may contain confidential, proprietary or legally privileged
information. You may not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. If you have received this e-mail message without being
the intended recipient, please notify KBC Securities promptly and delete
this e-mail. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorised to state them to be the views of KBC Securities. KBC
Securities reserves the right to monitor all e-mail communications through
its networks and any messages addressed to, received or sent by KBC
Securities or its employees are deemed to be professional in nature. The
sender or recipient of any messages to or of KBC Securities agrees that
those may be read by other employees of KBC Securities than the stated
recipient or sender in order to ensure the continuity of work-related
activities and allow supervision thereof. KBC Securities does not accept
liability for the correct and complete transmission of the information, nor
for any delay or interruption of the transmission, nor for damages arising
from the use of, or reliance on, the information.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Proposal

[Jochen . Maes]

i thank thee Oleg... what astupid mistake, used that months ago once to :(

sleeping should help

anyway, i'm still interested in making something for FOP... would really
like to get to know the internal more... :D

Jochen Maes
ICT Development


KBC Securities (kbcsecurities.com)
Havenlaan 12 Avenue du Port SIF 8683
B-1080 Brussels
Belgium

 Tel:  +32 2 429 96 81  

 GSM:  +32 496 57 90 99 

 E-mail :  [EMAIL PROTECTED] 





This message and any attachments hereto are for the named person's use
only. It may contain confidential, proprietary or legally privileged
information. You may not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. If you have received this e-mail message without being
the intended recipient, please notify KBC Securities promptly and delete
this e-mail. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorised to state them to be the views of KBC Securities. KBC
Securities reserves the right to monitor all e-mail communications through
its networks and any messages addressed to, received or sent by KBC
Securities or its employees are deemed to be professional in nature. The
sender or recipient of any messages to or of KBC Securities agrees that
those may be read by other employees of KBC Securities than the stated
recipient or sender in order to ensure the continuity of work-related
activities and allow supervision thereof. KBC Securities does not accept
liability for the correct and complete transmission of the information, nor
for any delay or interruption of the transmission, nor for damages arising
from the use of, or reliance on, the information.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Proposal

[Oleg Tkachenko]

[EMAIL PROTECTED] wrote:

> I have to make a overview for each currency i get in the xml...
> this overview exists out one or multiple table-blocks.
> 
> but for each currency i must have a new page no matter how much is written
> on the page.
You can use break-before="page" on the table or table-row to enforce breaking 
page.

-- 
Oleg Tkachenko
Multiconn International, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Proposal

[Jochen . Maes]

ok here is the thing i'm busy with:

I have to make a overview for each currency i get in the xml...
this overview exists out one or multiple table-blocks.

but for each currency i must have a new page no matter how much is written
on the page.

First i thought of doing it with blockcontainers but i can't use them
because the tables can be longer then 1 page...

i don't know if i explain it correctly and if you would like me to be more
excessive i think it more interesting if you see the xml and the xsl.
because my english isn't that good :-]

thx for the response


Jochen Maes
ICT Development


KBC Securities (kbcsecurities.com)
Havenlaan 12 Avenue du Port SIF 8683
B-1080 Brussels
Belgium

 Tel:  +32 2 429 96 81  

 GSM:  +32 496 57 90 99 

 E-mail :  [EMAIL PROTECTED] 





This message and any attachments hereto are for the named person's use
only. It may contain confidential, proprietary or legally privileged
information. You may not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. If you have received this e-mail message without being
the intended recipient, please notify KBC Securities promptly and delete
this e-mail. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorised to state them to be the views of KBC Securities. KBC
Securities reserves the right to monitor all e-mail communications through
its networks and any messages addressed to, received or sent by KBC
Securities or its employees are deemed to be professional in nature. The
sender or recipient of any messages to or of KBC Securities agrees that
those may be read by other employees of KBC Securities than the stated
recipient or sender in order to ensure the continuity of work-related
activities and allow supervision thereof. KBC Securities does not accept
liability for the correct and complete transmission of the information, nor
for any delay or interruption of the transmission, nor for damages arising
from the use of, or reliance on, the information.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Proposal

[Rhett Aultman]

If you don't mind my asking, why do you need to put an event model on page breaks?  
There may be other solutions available if we knew what you were trying to achieve 
overall.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 8:42 AM
To: [EMAIL PROTECTED]
Subject: Proposal


To the projectleaders.


I need the page-break event in Fop, but i know you guyz don't have the time
for it, so i would like to try to develop it myself.
I'm not a java wizz (i know enough) but i never did something like this
before. So if someone of you huyz already started something like this, i
would gladly know about it. (would be stupid to invent the hot water twice
wouldn't it?)


Thank you


Jochen Maes
ICT Development


KBC Securities (kbcsecurities.com)
Havenlaan 12 Avenue du Port SIF 8683
B-1080 Brussels
Belgium

 Tel:  +32 2 429 96 81  

 GSM:  +32 496 57 90 99 

 E-mail :  [EMAIL PROTECTED] 





This message and any attachments hereto are for the named person's use
only. It may contain confidential, proprietary or legally privileged
information. You may not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. If you have received this e-mail message without being
the intended recipient, please notify KBC Securities promptly and delete
this e-mail. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorised to state them to be the views of KBC Securities. KBC
Securities reserves the right to monitor all e-mail communications through
its networks and any messages addressed to, received or sent by KBC
Securities or its employees are deemed to be professional in nature. The
sender or recipient of any messages to or of KBC Securities agrees that
those may be read by other employees of KBC Securities than the stated
recipient or sender in order to ensure the continuity of work-related
activities and allow supervision thereof. KBC Securities does not accept
liability for the correct and complete transmission of the information, nor
for any delay or interruption of the transmission, nor for damages arising
from the use of, or reliance on, the information.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG

[Nicola Ken Barozzi]

From: "Matthias Fischer" <[EMAIL PROTECTED]>

> In other terms: IMO, the legal dispositions of an open source software
> shouldn't be more complex than those of their commercial competitors.

You're right.
In fact, the ASF is less complex.

The ASF distributes software that can be 100% sure to be usable as the APL
license says, which basically is "do what you want but give us credit and
don't blame us".
The libraries are usable in the format they are distributed in as if they
were APL, since this is what "compatible" means.

If you have other questions regarding the license, or want to make these
suggestions to the ASF, you are welcome.
Taken from http://jakarta.apache.org/site/contact.html :
"
The Jakarta Project is an effort of the Apache Software Foundation. The
address for general ASF correspondence and licensing questions is:
[EMAIL PROTECTED]
You can find more contact information for the Apache Software Foundation on
the contact page of the main Apache site.
"

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] FOP+iText = FOP-NG

[Matthias Fischer]

Nicola,

you've been right at least to the extent that I have been well inclined to
take another glance at the ASL ;-)
at http://www.apache.org/licenses/LICENSE

My comment did not reflect my intent to ask for any approach or specific
legal "outfit" of the Apache Software in particular; it aimed at making
developers aware (where my point made any sense at all and would be
perceived as useful) of the following: do anything you consider right, but
where considered useful by you inquire up to which degree of complexity
users would be ready to study (and subject to) legal permissions.
I wasn't aware that http://www.apache.org/licenses/LICENSE contained any
dispositions on sub-licences, but if their use is as easy as that of the
ASL, no problem to me as a user; if my company felt instead that we had to
go to a lawyer to be sure of our entitlements and obligations, we'd probably
convinced ourselves that this was too much of an effort.
In other terms: IMO, the legal dispositions of an open source software
shouldn't be more complex than those of their commercial competitors.

Matthias


-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 3:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)


From: Matthias Fischer

> My company, for instance, would have to stop using FOP;
> we would not even take the time to go into studying legal
> aspects, because, as a medium-sized company, we
> don't have the time and money and personnel to do this...

I think you are exaggerating a bit.
Are you using Apache license software? And did you study it with this
scrutiny?

If you are using the Apache license and are confortable with it, then there
is no problem. If Apache can distribute it with APL code, you can do the
same. It's simple as that.
Apache admits only compatible licenses in the CVS for this reason; some
weeks ago there has been a check in the CVS to check this, and you can be
sure that there is zero tolerance on this issue, it is applied very
strictly.

Look at the descriptions on the main apache site and on Jakarta; there are
very important pages IMO that explain as clearly as possible the position
Apache has on this point.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

Hi Peter,

> Aside from my low opinion of SAX for process coupling, there should
> be no need for communication back from the renderer.  
>. . .
cool - I thought the Area Tree code needed to know about font metrics 
and the like, but if this communication is one-way all the better.

Regarding SAX events, I really meant that for structure renderers. What 
I envision (in the context of RTF rendering through jfor) is the 
possibility of using the FOP front-end only to resolve XSL-FO 
properties, like an "XSL-FO preprocessor" if you want.

That's for this "preprocessor-to-StructureRenderer" interface that I 
think using XML makes sense, for loose coupling of the 
StructureRenderers which would then not necessarily be part of the FOP 
code base.

If we agree that XML is good for this, I think generating this XML 
through SAX events allows the preprocessor component to be efficiently 
integrated in Cocoon (for example) later on, without having to 
serialize and reparse the XML.

-Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Peter B. West]

Bertrand,

Aside from my low opinion of SAX for process coupling, there should be 
no need for communication back from the renderer.  The Area Tree should 
just give orders to the renderer.  All of the layout decisions have been 
made by the time the Area Tree is constructed.  The feedback is within 
the layout process, and the particulars of that are the cause of much 
wailing and gnashing of teeth.

Peter

Bertrand Delacretaz wrote:

>On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>
>>. . .
>>I think that a SAXrenderer could be the solution. SAX is based on
>>calling a method when a tag begin-content-end is reached. It can be
>>used to communicate the Area Tree to the renderer in a clean way,
>>whith a standard interface.
>>. . .
>>
>
>Won't work I think, print-based layout (as opposed to structure-based) 
>requires two-way communication between the layout engine and the 
>renderer (to compute the width text runs, for example).
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Peter B. West]

Keiron Liddle wrote:

> On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
>
>> What I would like to see, is that FOP stops discussing about the 
>> logging,
>> resolving, pipelineing and stuff and starts to focus on the core
>> functionality.
>> IMHO, the best way to get this thing going *quick* is to use Cocoon as a
>> pipeline. Cocoon gives you all these features, and gives you a solid
>> framework to work on.
>> When it works on Cocoon, we can see if performance for stand-alone
>> processing is good enough. If not, we can *then* talk about the 
>> structure
>> around FOP, and break eventually free from Cocoon.
>
>
> Firstly the Area Tree is unavoidable.


Hear, hear.

> We must have a place to do the layout and to store the page information.
> If you want this area tree turned into sax events, it really seems 
> like an unecessary step but there is an xml renderer (admittedly 
> simply writes text at the moment but you get the idea) if you want to 
> add this extra step. 


Agree strongly.  At various times the notion of "flattening the area 
tree" has been wrestled with in these pages.  At some point the tree 
model of pages loses all relevance.  Trees are very useful to describe 
the structure of the "stuff" being squirted onto the page.  At the end 
of the day, though, the "stuff" is rendered as a series of marks on a 
flat surface, and, to the renderer of last resort, all of the data 
structures that generated the marks are irrelevant.

I am utterly ignorant of any particular page description languages, so 
imagine such a language that provides for the drawing of certain sorts 
of marks on the page at certain co-ordinates.  That, essentially, is the 
output of the area tree.

If you want to express that page definition language in xml, go right 
ahead. Xml output would indeed be loosely coupled.  It's a data stream. 
 SAX events are about as loosely coupled as tree roots.  It's an API, 
after all, and an API which is inimical to pipelining processes. 
 However, if you want to be able to feed the area tree into various 
renderers, you have to use some sort of PDL to transcribe the area tree, 
and the description is linear set of random access instructions, whether 
expressed in an xml file or an API.

>
> The FO Tree - Layout - Area Tree are the three core issues. This is 
> what needs to be done first. 

Yes.

>
> For the FOTree to structure document it is a different issue, that I 
> hope we will solve one day. Maybe sax events could be used here.
>
My own approach is an API-based pipeline.  As you say, these three, FO 
Tree - Layout (Tree?) - Area Tree, are the tightly coupled core issues.

Peter


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Nicola Ken Barozzi]

From: Matthias Fischer

> My company, for instance, would have to stop using FOP;
> we would not even take the time to go into studying legal
> aspects, because, as a medium-sized company, we
> don't have the time and money and personnel to do this...

I think you are exaggerating a bit.
Are you using Apache license software? And did you study it with this
scrutiny?

If you are using the Apache license and are confortable with it, then there
is no problem. If Apache can distribute it with APL code, you can do the
same. It's simple as that.
Apache admits only compatible licenses in the CVS for this reason; some
weeks ago there has been a check in the CVS to check this, and you can be
sure that there is zero tolerance on this issue, it is applied very
strictly.

Look at the descriptions on the main apache site and on Jakarta; there are
very important pages IMO that explain as clearly as possible the position
Apache has on this point.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Matthias Fischer]

  If n persons are using FOP now and some 
  of these can no longer use FOP 
  because a part of FOP they need has a license they can't use, then 
  I'd say this reduces FOPs usefulness for 
  these "some" persons, despite being more useful to others. Arnd Beissner --Arnd 
  Beißner IT-EngineeringBahnhofstr. 3, 71063 Sindelfingen, GermanyEmail: 
  [EMAIL PROTECTED]Phone: +49-7031-463458Mobile: 
  +49-173-3016917 
   
  My company, for instance, would have to stop 
  using FOP; we would not even take the time to go into studying legal 
  aspects, because, as a medium-sized company, we don't have the time and money 
  and personnel to do this...
   
  Matthias 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Nicola Ken Barozzi]

From: [EMAIL PROTECTED]

> Technically, it's very tempting to do what you propose. In fact,
technically,
> I'm all for it. Let's just be aware that the license problem is not only a
> philosophical issue.

Of course. I think we agree.

And as for this:

> > > This would reduce the usefulness of
> > > FOP for a (unknown, agreed) number of users while
> > > enhancing the usefulness for others
> > > (not license-concerned users).
> >
> > I fail to see how this reduces usefulness.
>
> If n persons are using FOP now and some of these can no longer
> use FOP because a part of FOP they need has a license they can't use, then
> I'd say this reduces FOPs usefulness for these "some" persons, despite
being
> more useful to others.

Apache is very clear in the licencing terms.
*GPL libraries cannot be distributed by Apache. So this rules them out. The
iText developer are maing it possible now to redistribute the jar with the
MPL license only.

AFAIK, MPL is compatible with APL. Which means that the MPL -jar- can be
used in *every* condition in which APL -code- or -jars- are used. Who cannot
use MPL jars in APL code?
Maybe I'm wrong, but I cannot come up with an example.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

[arnd . beissner]

Nicola Ken Barozzi wrote:
> > IF the integration FOP-iText is done in a way where PDF
> > output via iText is not just an option but a replacement
> > for the existing PDF output - or even for the other renderers,
> > too, then I'd say this step contradicts the intention
> > though not the letters of the Apache license.
>
> This is a strong opinoin. Remember that the Apache license is a *license*,
> not the community. Apache values the community, and the license is there to
> help the community.

Yes, I agree to all of this (including the "strong opinion"). Still, I think
you underrate the importance of the license. In marketing terms: what is it
that makes Apache and GNU a "brand", while SourceFourge is not widely seen
as a brand. I think it's the license.

If I take something from the Apache projects, I know - because of the Apache
license - that I can do most everything with it as long as I mention the
origin in an appropriate way. This makes its very simple to use Apache
projects in commercial projects in medium-size and large companies. Basically
it boils down to this: If I want to use open-source components in a customer
project, I can use Apache-licensed stuff with no problems. MPL, LGPL and GPL
licensed components give me so many headaches when used in commercial customer
projects that I no longer even try to use them (with the exception of
internal-use-only projects). I just want to design and implement software, not
fuss with legal departments, you know... 8-)

Warning: Strong opinion follows
The Apache project just would not be the same if it adopted the MPL, LGPL or GPL.
Also, a number of contributors would quit in that case. If this is true, the
Apache license is still a *license* but not *only a license*. In a sense, the
license defines what persons the community consists of.

FULL STOP

Philosopical issues aside, if the integration/collaboration is planned as you
say, then most points of my original mail become moot. Remember, my mail started
with an uppercase IF. The discussion here on fop-dev showed that it was NOT
clear that PDF via iText would only be an option, not a replacement.

And one more thing - I recite your citation:
"
The goals of the Apache XML FOP Project are to deliver an XSL FO->PDF
formatter that is compliant to at least the Basic conformance level
described in the W3C Recommendation from 15 October 2001, and that complies
with the 11 March 1999 Portable Document Format Specification (Version 1.3)
from Adobe Systems.
"

From this, it's clear that as soon as FOP no longer outputs PDF by itself, but
using a non-Apache-licensed component, then it not longer fulfills the original
goal. This may be good: it makes a lot of sense to separate formatter
and renderer if the abstraction layer is done well (this won't be an easy task,
I'm pretty sure of that).

Technically, it's very tempting to do what you propose. In fact, technically,
I'm all for it. Let's just be aware that the license problem is not only a
philosophical issue.

There is a real reason why there are different types of licenses.

And as for this:

> > This would reduce the usefulness of
> > FOP for a (unknown, agreed) number of users while
> > enhancing the usefulness for others
> > (not license-concerned users).

> I fail to see how this reduces usefulness.

If n persons are using FOP now and some of these can no longer
use FOP because a part of FOP they need has a license they can't use, then
I'd say this reduces FOPs usefulness for these "some" persons, despite being
more useful to others.

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>. . .
> I think that a SAXrenderer could be the solution. SAX is based on
> calling a method when a tag begin-content-end is reached. It can be
> used to communicate the Area Tree to the renderer in a clean way,
> whith a standard interface.
>. . .

Won't work I think, print-based layout (as opposed to structure-based) 
requires two-way communication between the layout engine and the 
renderer (to compute the width text runs, for example).

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>. . .
> Hmmm... AFAIK FO is about layout, not semantical structure.
> Bold is just Bold, and not "emphasis" or "strong".
> Maybe I don't get the point. Could you elaborate more please?
>. . .

The term "structure renderer" (as you could find by searching the list 
archive probably ;-) is used here for yet-to-be renderers that don't do 
any layout by themselves.

If you're generating RTF or MIF formats, for example, you usually don't 
need to know on which page a given FO element will go, you leave this 
to the word processor or desktop publishing program that will use the 
generated document.

So these renderers will be plugged in right after the parsing and 
property resolution stages, before the layout stage.

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

On Thursday 14 March 2002 09:19, Keiron Liddle wrote:
>. . .
> Firstly the Area Tree is unavoidable. We must have a place to do the
> layout and to store the page information.
>. . .

Unavoidable for "Layout rendering", isn't it?
I thought structure-based rendering wouldn't need the area tree.

>. . .
> For the FOTree to structure document it is a different issue, that I
> hope we will solve one day. Maybe sax events could be used here.
>. . .

How hard would it be to render the FOTree in XSL-FO (based on SAX 
events) with all possible attributes resolved? 

Speaking specifically about the jfor RTF converter, this would allow it 
to be used as a FOP renderer without needing as much code changes as an 
API-based integration. Might be a little slower but much more flexible.

This would allow the parser and property resolver (is that the right 
term?) components of FOP to be reused by jfor and future 
structure-based renderers.

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Nicola Ken Barozzi]

From: "Keiron Liddle" <[EMAIL PROTECTED]>

> On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
> > What I would like to see, is that FOP stops discussing about the
logging,
> > resolving, pipelineing and stuff and starts to focus on the core
> > functionality.
> > IMHO, the best way to get this thing going *quick* is to use Cocoon as a
> > pipeline. Cocoon gives you all these features, and gives you a solid
> > framework to work on.
> > When it works on Cocoon, we can see if performance for stand-alone
> > processing is good enough. If not, we can *then* talk about the
structure
> > around FOP, and break eventually free from Cocoon.
>
> Firstly the Area Tree is unavoidable. We must have a place to do the
> layout and to store the page information.

Right. And flush it ASAP, as FOP already tries to do now to some degree.

> If you want this area tree turned into sax events, it really seems like an
> unecessary step but there is an xml renderer (admittedly simply writes
> text at the moment but you get the idea) if you want to add this extra
> step.

I think that a SAXrenderer could be the solution. SAX is based on calling a
method when a tag begin-content-end is reached. It can be used to
communicate the Area Tree to the renderer in a clean way, whith a standard
interface.
To make a renderer use by FOP in this way, you just need to say:"We give you
this xml area tree that conforms to this schema via SAX. Render it". No
knowledge of FOP internals is needed.

> The FO Tree - Layout - Area Tree are the three core issues. This is what
> needs to be done first.

Can't agree more :-)

> For the FOTree to structure document it is a different issue, that I hope
> we will solve one day. Maybe sax events could be used here.

Hmmm... AFAIK FO is about layout, not semantical structure.
Bold is just Bold, and not "emphasis" or "strong".
Maybe I don't get the point. Could you elaborate more please?
Thank you.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote:
>. . .
> > 1. FopParser parses and validates the input XSL-FO document
> Not needed if using Cocoon as a pipeline.
>. . .

Right, but it's so easy that we might as well keep it for easier 
testing.

>. . .
> What I would like to see, is that FOP stops discussing about the
> logging, resolving, pipelineing and stuff and starts to focus on the
> core functionality.
>. . .

Yes, but IMHO resolving (in the sense of "resolving FO object 
properties" like I think is meant by FOP) is part of the core 
functionality. I'm talking about computing presentation attributes for 
child elements based on their parent's attributes. 

>. . .
> This can big opportunity also for other projects to collaborate in
> the rendering.
> JFor, for example (I don't remember who maintains it ;-P)
>. . 
That's me by the way ;-)
(but I haven't done much lately)

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Nicola Ken Barozzi]

From: [EMAIL PROTECTED]

>Nicola Ken Barozzi wrote:
>> Given the licences, nobody is prohibited to cross-collaborate. iText
>> developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>> when the time is right.
>> FOP can distribute iText jar as it's MPL, and both projects would
cross-link
>> in a clear way.
>
> Advance warning: I didn't follow possible discussions
> on the iText list regarding this issue.
>
> IF the integration FOP-iText is done in a way where PDF
> output via iText is not just an option but a replacement
> for the existing PDF output - or even for the other renderers,
> too, then I'd say this step contradicts the intention
> though not the letters of the Apache license.

This is a strong opinoin. Remember that the Apache license is a *license*,
not the community. Apache values the community, and the license is there to
help the community.

> Why? If FOP - under Apache license - can no longer be
> used for essential purposes without using an additional
> component (iText) under MPL or LGPL, then in effect FOP
> is no longer Apache licensed, though technically
> speaking it still is.

? This boils down to a question: what is FOP?

>From http://xml.apache.org/fop/:
"
FOP is the world's first print formatter driven by
XSL formatting objects and the world's first
*output independent* formatter.
"

Currently FOP is not totally output indipendent, in the sense that it
doesn't even output without going through a FOP renderer.

"
The goals of the Apache XML FOP Project are to deliver an XSL FO->PDF
formatter that is compliant to at least the Basic conformance level
described in the W3C Recommendation from 15 October 2001, and that complies
with the 11 March 1999 Portable Document Format Specification (Version 1.3)
from Adobe Systems.
"

FOP is currently two things:
-formatter
-renderer

Nobody has ever thought to ditch the current FOP renderers. It would be
illogical.
The proposal is to focus on the formatting part, that is somethind that no
other project does AFAIK, and make the rendering accessible to other
projects, like iText, jFor and POI. Fop renderers would be just another
possibility, and now there are no alternatives I see for PCL, for example.

This way different working groups could focus indipendently on different
parts. Separation of concerns can help keep working groups more focused and
productive.

> This would reduce the usefulness of
> FOP for a (unknown, agreed) number of users while
> enhancing the usefulness for others
> (not license-concerned users).

I fail to see how this reduces usefulness.

> My personal favourite would be a FOP renderer
>  implementation that makes use of iText. Then,
> time could tell whether there are enough people
> interested in keeping Apache-licensed PDF output
> alive.

Basically, this is the idea :-)

I remember that iText has already proposed to be put in the FOP codebase,
thus gaining Apache license.
But several reasons advise us to be cautious and defer it for now.
It's not codebases that would merge, but communities, and we have to avoid
stalling while in the process.

> If the decision goes toward a full replacement,
> I'd say that at least all existing FOP committers and
> possibly the major contributors to FOP should agree
> to this step as it - in one respect - decreases the
> value of their work so far.

IMO, it's the opposite.
This can give FOP another opportunity, not make it go back.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Keiron Liddle]

On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
> What I would like to see, is that FOP stops discussing about the logging,
> resolving, pipelineing and stuff and starts to focus on the core
> functionality.
> IMHO, the best way to get this thing going *quick* is to use Cocoon as a
> pipeline. Cocoon gives you all these features, and gives you a solid
> framework to work on.
> When it works on Cocoon, we can see if performance for stand-alone
> processing is good enough. If not, we can *then* talk about the structure
> around FOP, and break eventually free from Cocoon.

Firstly the Area Tree is unavoidable. We must have a place to do the 
layout and to store the page information.
If you want this area tree turned into sax events, it really seems like an 
unecessary step but there is an xml renderer (admittedly simply writes 
text at the moment but you get the idea) if you want to add this extra 
step.
The FO Tree - Layout - Area Tree are the three core issues. This is what 
needs to be done first.

For the FOTree to structure document it is a different issue, that I hope 
we will solve one day. Maybe sax events could be used here.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Nicola Ken Barozzi]

From: "Bertrand Delacretaz" <[EMAIL PROTECTED]>

> On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
> >. . .
> > -
> >  FOP uses iText as a PDF generation library
> > -
> >. . .
>
> Maybe the following scenario could help making FOP more
> "pipeline-oriented", making it easier to plug in various renderers,
> layout engines, debugging tools, etc.
>
> I'm just making up component names, hopefully understandable
>
> 1. FopParser parses and validates the input XSL-FO document

Not needed if using Cocoon as a pipeline.

> 2. FopPropertyResolver does its job, attributes inheritance, etc.
>
> Then two options:
> 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout
> and produces PDF
>
> 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the
> XSL-FO vocabulary but with all attributes explicity specified (as far
> as possible, I know there are some issues here).

3b

> After 3b, various XSLT transforms and/or XML-to-something converters
> can be plugged in using the well-defined and loosely-coupled SAX/XML
> interface.
>
> I think using XML/SAX to interface between future pipeline components
> (ParsingAndPropertyResolving -> Layout -> Serialization) opens up much
> more options than using java APIs for this, and could help keep FOP
> small and focused.
>
> If using Cocoon, being able to just resolve properties and pass the
> result on to various transforms opens up new horizons for XSL-FO
> processing.

This is the proposal I made, and I think it stands even stronger now.

If FOP is pipeline driven, any renderer can be quite easily plugged in.
AFAIK, the pipeline architecture is one of the major design differences that
in some way has been agreed on.

What I would like to see, is that FOP stops discussing about the logging,
resolving, pipelineing and stuff and starts to focus on the core
functionality.
IMHO, the best way to get this thing going *quick* is to use Cocoon as a
pipeline. Cocoon gives you all these features, and gives you a solid
framework to work on.
When it works on Cocoon, we can see if performance for stand-alone
processing is good enough. If not, we can *then* talk about the structure
around FOP, and break eventually free from Cocoon.

> At the other end of the pipeline, what about an XML-to-MIF
> converter, for example, much more generally useful than a
> tightly-coupled MIF renderer for FOP.
>
> Implementing 3b should be fairly easy (isn't that a serialization of
> the FOTree?), and we can go from here to reuse important parts of FOP
> as individual components.

I agree.
This can big opportunity also for other projects to collaborate in the
rendering.
JFor, for example (I don't remember who maintains it ;-P)
And POI. At POI, we are going to do a Word .doc format writer. It could fit
easily in this picture.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Nicola Ken Barozzi]

From: "Peter B. West" <[EMAIL PROTECTED]>

> Nicola,
>
> I think there are a few issues to be considered here.  Essentially, what
> is FOP?

Good point.

> There may be a number of requirements of an XSL-FO processor.  The basic
> one is, "Show me this on a page or screen."  Any kind of renderer, using
> any approach whatsoever, will achieve this, more or less.  The so-called
> "structure renderers", like the rtf and mif renderers, do this with a
> useful side-effect; the file they produce can be not only viewed, but
> edited.  It seems to me that what you are proposing is to use iText as a
> basic "structure renderer," mapping the fo structures into
> iText-compatible structures.

As a start, yes.

> With all of the structure renderers, however, you are at the mercy of
> the individual layout engines.  Anyone who has tried to produce a
> complex document using two versions of MS-Word will have an acute
> understanding of what it means to be at the mercy of someone else's
> renderer.

I think the POI team (http://jakarta.apache.org/poi/) would have something
to say about this, but it would not be appreciation for the MS file formats
;-)

> The spec itself defines a layout engine in the production of the area
> tree from the fo tree.  Admittedly, there are a number of grey areas in
> layout, especially when constraints conflict, in which the final
> decision is up to the User Agent.  Effectively, it's up to the
> implementation.  The area tree, though, defines the position of every
> mark on every page.  It inherently holds out the prospect of producing
> identical layouts from every renderer downstream of the area tree.

This implies AFAIK that the creation of the area tree is the crucial point,
the pivotal scope of FOP.

> I was initially skeptical about this, because of the dependency of the
> layout on the font characteristics.  It was pointed out to me, though,
> that as long as a renderer honoured the metrics of the design font then,
> even if individual glyphs were considerably different, the *layout*
> would still be identical down ot the position of individual glyphs on a
> page.
>
> It seems to me that that is what a full implementation of the spec
> implies, and that such a search for consistency in the position of marks
> on page or screen is one of the most desirable features of the spec.
>  What may not be achievable across different implementations, we may
> still seek to achieve within a single implementation.

Yes.

> With that in mind, we can probably conclude that a true structure
> renderer cannot achieve this cross-renderer consistency.

And this is taken in account for in the spec as you know, which defines many
tags as optional and hints on how to downgrade gracefully.

> That would
> also be true of iText, used in such a way.  If however, the interface to
> iText were defined such that the position and size of al marks to be put
> on the page could be rigorously determined, it could meet the
> requirement.  I, for one, would like to see such a precise and
> relatively low-level pdf library.

In the proposal, the hint to active collaboration is there to achieve this
synergy.
Itext can give FOP a boost in rendering, and the FOP community can give
iText greater precision in rendering.

The iText community has shown IMO sincere quest for an active collaboration,
and even donation of the code to FOP.
As both communities pointed out correctly, just merging two project usually
doesn't make a bigger project, but a bigger mess.

So it seems that this thing can start :-)

There is no need for a VOTE, since plain discussion and sharing of views is
free, of course.

Although I'm subscribed to this mailing list for quite some time now, I
didn't really understand the status of the works that are going on to get to
FOP2 or whatever you are going to call it.
AFAIK, changing codebase requires a notice of this, a branch in CVS (no vote
is necessary), and a final VOTE if the codebase is to switch.
This is how Tomcat, Xalan, Xerces and many other projects did it, and how
the priject guidelines advise. (http://xml.apache.org/source.html)

What's the current status?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

[Bertrand Delacretaz]

On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
>. . .
> -
>  FOP uses iText as a PDF generation library
> -
>. . .

Maybe the following scenario could help making FOP more 
"pipeline-oriented", making it easier to plug in various renderers, 
layout engines, debugging tools, etc.

I'm just making up component names, hopefully understandable

1. FopParser parses and validates the input XSL-FO document
2. FopPropertyResolver does its job, attributes inheritance, etc.

Then two options:
3a. FopLayoutEngine (existing code, API-coupled as now) computes layout 
and produces PDF 

3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the 
XSL-FO vocabulary but with all attributes explicity specified (as far 
as possible, I know there are some issues here).

After 3b, various XSLT transforms and/or XML-to-something converters 
can be plugged in using the well-defined and loosely-coupled SAX/XML 
interface.

I think using XML/SAX to interface between future pipeline components 
(ParsingAndPropertyResolving -> Layout -> Serialization) opens up much 
more options than using java APIs for this, and could help keep FOP 
small and focused.

If using Cocoon, being able to just resolve properties and pass the 
result on to various transforms opens up new horizons for XSL-FO 
processing. 

At the other end of the pipeline, what about an XML-to-MIF 
converter, for example, much more generally useful than a 
tightly-coupled MIF renderer for FOP. 

Implementing 3b should be fairly easy (isn't that a serialization of 
the FOTree?), and we can go from here to reuse important parts of FOP 
as individual components.

How does this sound?

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: mergingtwo libraries)

[Peter B. West]

Nicola,

I think there are a few issues to be considered here.  Essentially, what 
is FOP?

There may be a number of requirements of an XSL-FO processor.  The basic 
one is, "Show me this on a page or screen."  Any kind of renderer, using 
any approach whatsoever, will achieve this, more or less.  The so-called 
"structure renderers", like the rtf and mif renderers, do this with a 
useful side-effect; the file they produce can be not only viewed, but 
edited.  It seems to me that what you are proposing is to use iText as a 
basic "structure renderer," mapping the fo structures into 
iText-compatible structures.

With all of the structure renderers, however, you are at the mercy of 
the individual layout engines.  Anyone who has tried to produce a 
complex document using two versions of MS-Word will have an acute 
understanding of what it means to be at the mercy of someone else's 
renderer.

The spec itself defines a layout engine in the production of the area 
tree from the fo tree.  Admittedly, there are a number of grey areas in 
layout, especially when constraints conflict, in which the final 
decision is up to the User Agent.  Effectively, it's up to the 
implementation.  The area tree, though, defines the position of every 
mark on every page.  It inherently holds out the prospect of producing 
identical layouts from every renderer downstream of the area tree.

I was initially skeptical about this, because of the dependency of the 
layout on the font characteristics.  It was pointed out to me, though, 
that as long as a renderer honoured the metrics of the design font then, 
even if individual glyphs were considerably different, the *layout* 
would still be identical down ot the position of individual glyphs on a 
page.

It seems to me that that is what a full implementation of the spec 
implies, and that such a search for consistency in the position of marks 
on page or screen is one of the most desirable features of the spec. 
 What may not be achievable across different implementations, we may 
still seek to achieve within a single implementation.

With that in mind, we can probably conclude that a true structure 
renderer cannot achieve this cross-renderer consistency.  That wouls 
also be true of iText, used in such a way.  If however, the interface to 
iText were defined such that the position and size of al marks to be put 
on the page could be rigorously determined, it could meet the 
requirement.  I, for one, would like to see such a precise and 
relatively low-level pdf library.

Peter

Nicola Ken Barozzi wrote:

>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
>
>-
> FOP uses iText as a PDF generation library
>-
>
>This could have greater benefits than a merger and keep intact the strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>want?).
>
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would cross-link
>in a clear way.
>
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

[arnd . beissner]

Nicola Ken Barozzi wrote:
> Given the licences, nobody is prohibited to cross-collaborate. iText
> developers can send patches to FOP and viceversa, and be [VOTE]d as usual
> when the time is right.
> FOP can distribute iText jar as it's MPL, and both projects would cross-link
> in a clear way.

Advance warning: I didn't follow possible discussions on the iText list regarding this issue.

IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement
for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention
though not the letters of the Apache license.

Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional
component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically
speaking it still is. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while
enhancing the usefulness for others (not license-concerned users).

My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could
tell whether there are enough people interested in keeping Apache-licensed PDF output alive.

If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly
the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far.

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Art Welch]

I would not think that adding iText would necessarily preclude the other
renderers. My guess would be that iText could interface via a Renderer
interface as the current Renderers do. My concern would be that the current
renderers share a lot of code (either be reusing classes or by copying
source). Ideally there would be even greater reuse in the future (without
iText). In addition to saving coding effort, this helps ensure that the
output produced by the various renderers (especially PDF, PCL, and PS) is
similar. With PDF rendering in a separate project I am concerned that there
may be a reduction of code reuse in this area and more difficulty in
maintaining consistent output from different renderers. Perhaps the benefits
outweigh the costs.

Just my $0.02,
Art

-Original Message-
From: Ralph LaChance [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 1:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)


I'm wondering if marying FOP +iText would sacrifice the
-awt -print -ps options.  (Same question for -text, but i'm
personally not interested in that.)

At 10:58 AM 3/13/02, you wrote:
>
>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
>
>-
>  FOP uses iText as a PDF generation library
>-
>
>This could have greater benefits than a merger and keep intact the
strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>want?).
>
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would
cross-link
>in a clear way.
>
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.
>
>What do you think?
>Shall we pull this off?
>
>--
>Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
>-
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]


 ' Best,
 -Ralph LaChance



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[kyle koss]

I say do it.

After using FOP for a while now and always having a problem with the
embedded fonts, I thought I would try iText. The iText was able to
handle the embedded fonts without any trouble at all. It seems that at
least in this area iText is much stronger than FOP.

The use of fo, for us, is the major benefit of FOP, while it is also
important for our project to be able to use fonts other than the
defaults. So, I think a merging of the two would definitely be a major
plus.

I am all for it. I think this is a proposal we could all support.

Kyle Koss


-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] 
Sent: March 13, 2002 9:59 AM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging
two libraries)

Given what has been said on the mailing lists of FOP and iText, and
given
the current scope of the two projects, I feel reasonably sure that this
could be a proposal accepted by bot communities.

-
 FOP uses iText as a PDF generation library
-

This could have greater benefits than a merger and keep intact the
strenghts
that these two projects have (remember AOL+Time Warner? is the result we
want?).

iText could continue to be an excellent PDF (and RTF AFAIK) generation
package with a good java API.
FOP could concentrate on FO2AreaTree and use iText as the last step.

Given the licences, nobody is prohibited to cross-collaborate. iText
developers can send patches to FOP and viceversa, and be [VOTE]d as
usual
when the time is right.
FOP can distribute iText jar as it's MPL, and both projects would
cross-link
in a clear way.

AFAIK iText is already able to produce PDF using an XML file. If FOP
could
make a transformation step from FO to this format, we could get this up
running in a short time.
And IText can also output to html, which is not bad at all.

What do you think?
Shall we pull this off?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

[Ralph LaChance]

I'm wondering if marying FOP +iText would sacrifice the
-awt -print -ps options.  (Same question for -text, but i'm
personally not interested in that.)

At 10:58 AM 3/13/02, you wrote:
>
>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
>
>-
>  FOP uses iText as a PDF generation library
>-
>
>This could have greater benefits than a merger and keep intact the strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>want?).
>
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would cross-link
>in a clear way.
>
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.
>
>What do you think?
>Shall we pull this off?
>
>--
>Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
>-
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]


 ' Best,
 -Ralph LaChance



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] linebreak

[ewitness - Ben Fowler]

At 2:58 pm + 26/2/02, ewitness - Ben Fowler wrote:
> [ snip ]
> > In FO, you could write
> > 
>>   some line
>>   next line
> > 

OK I have tried the FO in the attached file, giving
the expected PDF result. Even if I haven't the facility
that I want, There is a good, and fairly logical work-around.

Ben.



line-break.fo
Description: Binary data


line-break.pdf
Description: Adobe PDF document

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] linebreak

[ewitness - Ben Fowler]

>[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote:
>[snip]
>
> [snip ]
>I meant "correct way to express the presentational aspects with
>XSLFO". There was no intention to feed this to a Pascal compiler.
>The use case was "I have some  source code and want to
>include it in my printed manual"

O.K. I was a bit harsh there, but I was trying to make the point
that some blocks in a ideal presentational system, such as
comments would flow, but others such as code statements and
expressions would not.


>If you want to have your specific (XML) data presented on a 2D area
>like paper sheets or a computer monitor screen, you probably have
>to
>1. Assign some presentational semantic to your specific data
>  elements like  or  or  or 
>2. Apply some commonly used concepts like kerning, space
>  justification, word wrapping and such stuff
>XSL, both T and FO, attempts to make this possible, and XSLFO is
>the second part: a vocabulary for describing the presentation of
>stuff on a 2D area, perhaps splitted into a page stream (disregard
>audible properties, whose inclusion is just plain silly).

(divided, or divided up rather than "splitted")

My gripe is that your (2) above should include kerning, ligatures,
justification, bidi, word wrapping, hyphenation, forced line break,
rubber space, widow/orphan control, keeps, insert space and such
stuff.

>Depending on your point of view, you can see either of the two
>steps or both together as the equivalent of typesetting.
>
>> Which is why I say [RETURN] for end of paragraph - , and
>> [SHIFT][RETURN] for end of line - ; to make the easy way
>> the right way.
>
>XSLFO does not assign semantics to FOs beyond what's necessary
>to get them layed out. It does not have a concept of "paragraph",
>and the concept of "line" is not necessarily the same as what
>for example software manual writers or java compilers use.
>Note that there is no fo:line and no fo:para, just a fo:block,
>which is *not* a paragraph.

(laid out)

And from my POV, that is a pity. I do think of a block as
a paragraph, and my enter key or ETAG ending a paragraph
and inserting the specified vertical space. 'lines' are largely
the result of layout engine working with line length against
word wrap, hyphenation and forced line break.

I don't dispute the practicality of what you describe, I
merely question the benfits of it.


>Further note that HTML  has paragraph semantics, this means
>some space before and after by default. Also, in early HTML there
>was no possibility at all to restrict the, well, lets call it
>page width. Therefore you could not simply write
> some line
> next line
>in order to get a managable line length, it would result in a
>line spacing making it unreadable. In FO, you could write
> 
>   some line
>   next line
> 
>if you want to have your content formatted this way. I can't see
>a need for a  equivalent in FO.

'Page width' is set by the user, he or she can set the width
of the browser to what suits that person, it is little to do
with HTML.

If I can use HTML as an example, (which is not in general
a good idea), then this fragment

MacHTTP
An early web server

really needs the , as

MacHTTP
An early web server

is not the same in structure or presentation, and
there is no other way (outside of CSS) of getting the
required presentation. Obviously FO does not have this problem.

Your example is interesting & might work for me. The outer
blocks represent paragraphs and the inner ones (typically
only one) lines. I will try this before posting again.

>Another note: in TeX, semantic markup and presentational aspects
>are mixed in a sometimes annoying way.

True

>Conclusion: If you want to write documents, use DocBook, not XSLFO.
>DocBook btw contains linebreak elements, probably for some reasons
>already mentioned, and apparently there are no difficulties to map
>them to FOs.

Again I will check that. I was working from a starting point
of generating/editing FO by hand. Certinly, I would recommend DocBook
for serious authoring. FO is so like WordPerfect codes, that
it seems a shame to make it gratuitously non-editable

>In order to clean up the seemingly contradiction that FO also allows
>for interpretation of LF characters: If you have already properly
>marked up text for lines, you can transform it (probably easily)
>into FO blocks. If you pull in whitespace formatted data from a file
>or DB or something, you might want to have the FO processor respect
>the existing formatting rather than to analyze and properly transform
>the whole stuff. That's a quick hack to fill a gap. I already
>experienced some times that the result is not as good as it should
>be and someone still has to wade through the data and convert it
>to properly marked up (or at least properly structured) data (usually
>leading to hot debates about "what *is* the structure behind the
>formatting?")

Which is also (I think that this is what you were saying in your
para (1) right at the top),

RE: [PROPOSAL] linebreak

[Joerg Pietschmann]

[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote:
[snip]

Well, this is drifting off topic for this list... but
see the very end of this message. And some remarks
anyway:

In the example
> >The correct way to express
> >procedure foo();
> > begin
...
> >would be something like:
> >
> > foo();
> > 
> >  begin
...
I meant "correct way to express the presentational aspects with
XSLFO". There was no intention to feed this to a Pascal compiler.
The use case was "I have some  source code and want to
include it in my printed manual"

If you want to have your specific (XML) data presented on a 2D area
like paper sheets or a computer monitor screen, you probably have
to
1. Assign some presentational semantic to your specific data
  elements like  or  or  or 
2. Apply some commonly used concepts like kerning, space
  justification, word wrapping and such stuff
XSL, both T and FO, attempts to make this possible, and XSLFO is
the second part: a vocabulary for describing the presentation of
stuff on a 2D area, perhaps splitted into a page stream (disregard
audible properties, whose inclusion is just plain silly).

Depending on your point of view, you can see either of the two
steps or both together as the equivalent of typesetting.

> Which is why I say [RETURN] for end of paragraph - , and
> [SHIFT][RETURN] for end of line - ; to make the easy way
> the right way.

XSLFO does not assign semantics to FOs beyond what's necessary
to get them layed out. It does not have a concept of "paragraph",
and the concept of "line" is not necessarily the same as what
for example software manual writers or java compilers use.
Note that there is no fo:line and no fo:para, just a fo:block,
which is *not* a paragraph.

Further note that HTML  has paragraph semantics, this means
some space before and after by default. Also, in early HTML there
was no possibility at all to restrict the, well, lets call it
page width. Therefore you could not simply write
 some line
 next line
in order to get a managable line length, it would result in a
line spacing making it unreadable. In FO, you could write
 
   some line
   next line
 
if you want to have your content formatted this way. I can't see
a need for a  equivalent in FO.

Another note: in TeX, semantic markup and presentational aspects
are mixed in a sometimes annoying way. LaTeX tried to go as pure
semantic as resonable, but, unfortunately, you have sometimes a
semantic too special to explicitely define an abstraction for it
and therefore describe it by its presentation instead. FO, on the
contrary, is as pure presentation as possible, taking only really
widely used concepts into account and leave the rest to the first
step mentioned at the beginning (no formatting of mathematical
formulas in FO, no theorem numbering ...)

Conclusion: If you want to write documents, use DocBook, not XSLFO.
DocBook btw contains linebreak elements, probably for some reasons
already mentioned, and apparently there are no difficulties to map
them to FOs.

In order to clean up the seemingly contradiction that FO also allows
for interpretation of LF characters: If you have already properly
marked up text for lines, you can transform it (probably easily)
into FO blocks. If you pull in whitespace formatted data from a file
or DB or something, you might want to have the FO processor respect
the existing formatting rather than to analyze and properly transform
the whole stuff. That's a quick hack to fill a gap. I already
experienced some times that the result is not as good as it should
be and someone still has to wade through the data and convert it
to properly marked up (or at least properly structured) data (usually
leading to hot debates about "what *is* the structure behind the
formatting?")

Having said all that, FO still lacks stuff, but mostly related to the
fact that pagination is a task of the FO processor and not known
at the time FOs are generated, like:
- elements to express conditional stuff on page breaks in other elements,
  like "continued on next page" or "continued from previous page"
- conditions like "if this element does not fit the current page, start
  it on a new page" (not decisively solved by keep-together) or "if
  NN percent of this element do not fit onto the current page, start
  a new page" (some generalization of widows/orphans)
Can one of the FOP developers comment on how easy/hard such stuff
would be to implement as extension elements?

Regards
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] linebreak

[ewitness - Ben Fowler]

>[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote:
>[snip]
>> I don't mind admitting that as an outsider to the XML standard, this
>> looks like a bad, even a really bad, idea.
>>
>> My reading of your commentary is "Whitespace is sometimes respected,
>> and only a langauge lawyer can tell you when".
>
>Well, in some sense you are right, there are a lot of "really
>bad ideas" hidden in this area. However, you have to see this
>in context.

I most certainly am looking at it in context. I was trying to
do something simple and intuitive and it turned out gnarly and
difficult. XML is meant to build on other things such as SGML,
DSSSL and HTML by avoiding their mistakes.

>A *real* typesetter doesn't care about whitespace and line feeds,
>he thinks in paragraphs and columns and pages of flowing text,
>with various indentations and margins and such.

Exactly so, and he thinks of leading and line height, and
he thinks of paragraphs with 'space before' and 'space after'.
I am prepared to argue that FO is a 'real' typesetter here,
and should 'think' the same way.

>TeX was practically written to support this view, and this is
>the default how FO processors work.

Quoting from the XML-dev list, a gentleman wanted to play space
cadets and we got unix, another gentleman wanted to distribute his
phone list and we got the WW web. Pretty much every worthwhile
advance in the computer field has come from one person with a
problem to solve. TeX came about because Professor Knuth
http://www-cs-faculty.stanford.edu/~knuth/ > knew that
computers could aid typesetting: it was written with one practical
aim, rather than supporting a view.

I don't see how you can argue that because TeX has \newline and
\par it follows that FO should not have a semantic  or
forced line-break.

>The problem: not everybody is a typesetter, many people don't
>even know about how to set indents and hanging indents and margins
>and this stuff, but they have a space and an enter key sitting
>squarely on their keyboard.

I may have misread you, but I think that you have intertwined
two, possibly three things.

1. Not everybody is a typesetter ...

Exactly, this is why there is a division of skill or labour.
Authors write and typesetters mark up and set text. This is
TeX 101, exempli gratia
http://www.ideography.co.uk/library/seybold/WYS_intro.html >,
and http://www.ecn.wfu.edu/~cottrell/wp.html >
The author of a text should, at least in the first instance,
concentrate entirely on the first of these sets of tasks.
That is the author's business. Adam Smith famously pointed
out the great benefits that flow from the division of labor.
Composition and logical structuring of text is the author's
specific contribution to the production of a printed text.
Typesetting is the typesetter's business. This division of
labour was of course fulfilled in the traditional production
of books and articles in the pre-computer age. The author
wrote, and indicated to the publisher the logical structure
of the text by means of various annotations. The typesetter
translated the author's text into a printed document,
implementing the author's logical design in a concrete
typographical design. One only has to imagine, say, Jane
Austen wondering in what font to put the chapter headings of
Pride and Prejudice to see how ridiculous the notion is.
Jane Austen was a great writer; she was not a typesetter.

You may be thinking this is beside the point. Jane Austen's
writing was publishable; professional typesetters were
interested in laying it out and printing it. You and I are
not so lucky; if we want a printed article we will have to
do it ourselves (and besides, we want it done much faster
than via traditional typesetting). Well, yes and no. We will
in a sense have to do it ourselves (on our own computers),
but we have a lot of help at our disposal. In particular we
have a professional-quality typesetting program available.
This program (or set of programs) will in effect do for us,
for free and in a few seconds or fractions of a second, the
job that traditional typesetters did for Shakespeare, Jane
Austen, Sir Walter Scott and all the rest. We just have to
supply the program with a suitably marked-up text, as the
traditional author did.

I am suggesting, therefore, that should be two distinct
``moments'' in the production of a printed text using a
computer. First one types one's text and gets its logical
structuration right, indicating this structuration in the
text via simple annotations. This is accomplished using a
text editor, a piece of software not to be confused with a
word processor. (I will explain this distinction more fully
below.) Then one

RE: [PROPOSAL] linebreak

[Joerg Pietschmann]

[EMAIL PROTECTED] (ewitness - Ben Fowler) wrote:
[snip]
> I don't mind admitting that as an outsider to the XML standard, this
> looks like a bad, even a really bad, idea.
> 
> My reading of your commentary is "Whitespace is sometimes respected,
> and only a langauge lawyer can tell you when".

Well, in some sense you are right, there are a lot of "really
bad ideas" hidden in this area. However, you have to see this
in context.

A *real* typesetter doesn't care about whitespace and line feeds,
he thinks in paragraphs and columns and pages of flowing text,
with various indentations and margins and such. TeX was practically
written to support this view, and this is the default how FO
processors work. The problem: not everybody is a typesetter, many
people don't even know about how to set indents and hanging indents
and margins and this stuff, but they have a space and an enter key
sitting squarely on their keyboard.

The correct way to express

procedure foo();
 begin
   dostuff:=false;
 end

would be something like:

 foo();
 
  begin
  
   dostuff:=false;
  
  end
 

but chances are you'll get it space- or even (shudder!) tab-indented.
(Take a postal address block for another, less IT-related example)
[If i'd get a chance to correct the past, i probably kill the
inventor of the tab character before he commits his crime :-]

There is a lot of whitespace formatted data out there, and it is
unlikely to disappear in the near future. In order to deal with
realities, you can fine-tune how FO processors handle various forms
of white space. Actually, it is encouraged to do so only locally.

You might have noted that in HTML+CSS  actually *is* redundant,
it is just heavily (ab)used because it produces predictable results
without fumbling with gnarly CSS settings. Especially if you have to
bring already whitespace formatted data online *quickly*. Typewriter
habits are hard to get rid of, regardless how enraged professionals
are about this.

Regards
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] linebreak

[ewitness - Ben Fowler]

>Comments below.
>
>[ snip ]
>
>3. Final discussion comment: XSL formatters _do_ ignore the presence of
>linefeeds (in one of several different interpretations of "ignore") by
>default. By choosing 'preserve' for linefeed-treatment you _are_ basically
>doing a  operation, with respect to linefeeds. So I don't see much of a
>difference or any grounds for objection.
>
>But I do see an argument for a semantic linebreak in the source. Relying on
>linefeeds or the lack thereof in source XML is a bit problematic.

Thank you. I don't exactly have a problem with the mechanism itself,
more that it is too complicated for most people to understand without
a tutor (as I found). This can be countered by an argument (which I
accept) that .fo files are usually machine produced, and are not
pretty printed or edited. Against that, (1) the fragments that make
up an .fo file most certainly are, and (2) there is no bar to creating
a .fo file directly of by some mechanism other than XSLT.

>4. normalize-space(): The XPath function takes tabs, spaces, carriage
>returns and linefeeds and does what you say. I think that the existing
>string functions in XPath/XSLT are not sufficiently powerful to easily do
>what you wish; OTOH the activities of the XSL people to come out with a new
>XSLT and XPath include regular expressions (see
>http://www.w3.org/TR/xquery-operators/) so this is one way in which you
>could do what you want.

Thank you. I am simply not that familiar with XPath. The issue arose,
as you might have guessed by an editor assuming that it could add any
amount of white space at the beginning or end of an element (quite
reasonable in the XML world), and I had assumed that there would be
a matching function that would remove it. Maybe I am making a mountain
out of a molehill. I feel that this is a result of trying to
standardise too early, id est without sufficient, or sufficient duration
of experience.

Ben.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] linebreak

[Arved Sandstrom]

Comments below.

-Original Message-
From: ewitness - Ben Fowler [mailto:[EMAIL PROTECTED]]
Sent: February 25, 2002 9:41 AM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] linebreak


> >
>>I guess the reason nobody thought  or  would be
> >required is because a U+000A will do the trick.
>
> [ snip ]
>
>In any case, a linefeed (LF) must be honoured, and result in a linebreak.
>_If_ the conditions are right. What that means is, the initial value for
>"linefeed-treatment" is "treat-as-space", which _does_ do a conversion of
>U+000A to U+0020 (space). So you would want to specify
>"linefeed-treatment='preserve'" on an ancestor flow object (possibly
>fo:root) and allow it to propagate to the FOs of interest, as it is
>inheritable. The "whitespace-*" properties do not affect the linefeed, and
>suppress-at-line-break can also be left as it is.
>
>But essentially the LF is there to accomplish what you want to do. The
>initial setting of "linefeed-treatment" acts to give us LaTeX-like
>behaviour, but unlike LaTeX we can switch to something different in this
>regard, rather than use new markup.

The answer that you gave is also to be found a few lines down
from the first URL I gave you

4.   Forced line-breaks are respected. Specifically, if A
is the glyph-area generated by a fo:character whose Unicode
character is U+000A, then A must be the last area in its
containing subset Si.

I don't mind admitting that as an outsider to the XML standard, this
looks like a bad, even a really bad, idea.

My reading of your commentary is "Whitespace is sometimes respected,
and only a langauge lawyer can tell you when".

How should this be interpreted?

Do you think that HTML would be improved if the  element was
replaced with a feature that said "You can get the effect of a
forced linebreak by setting 'linefeed-treatment' to 'preserve'
in the  of the page (or other container as required), which
causes all unix line feeds to be rendered" instead the  element
which is what was done?

>From my POV this has an inhibiting effect on all editors and pretty
printing utilities, which must also respect exisiting white space
(as XSL processors do) and never introduce line feeds, in case this
setting was ever turned on. From my POV, a formatter should always
ignore the formatting of the source, unless notified that it is
preformatted as in the case of  and CDATA, exempli gratia
http://archive.ncsa.uiuc.edu/SDG/IT94/Proceedings/Autools/sperberg-mcqueen/s
perberg.html >,
(1994) about half way down.

Do you happen to know whether this was ever discussed (id est objections
sought and answered) or whether this was one person's idea that
was incorporated as is.

I have a related 'issue' which is that the normalize-string( ) function
in XSL does two things. It trims leading and trailling newlines
and other whitespace, and it normalises internal white space.
I have a need for an operation that does the former, but not the latter.

(In fact I have an implementation which appears to be buggy
and replaces 'Miss A Burgrave' with Miss ABurgrave', but handles
'Miss A  Burgrave' correctly.

In short, XML processors including ones that produce XML-FO files
should pass through all whitespace, and processors such as fop
which are also XML processors, but adjusted so that they do not
produce XML, should (at least in general) normalise whitespace.
Where the output file format respects whitespace then it should
be supplied as  or as some break (as my original suggestion)
The present situation is that the latter type of processor may not
normalise whitespace, because some newlines are significant.

Incidently, you have not made (or reported) a case against my suggestion:
unless it is harmful (or confusing) there is no real reason why both
styles of indicating significant breaks could not be used, is there?

[ SNIP example ]

line-feed treatment was reported as not working in June last
year, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1998 >,
I don't know whether tit is now in.

I now have a linux installation (but not yet CVS), and so I am in a position
to
start some development work on FOP. Where should I start? Is there a list
of outstanding tasks?

I wrote that a few days ago, but delayed sending it until I could
see what bugzilla could tell me. In the meantime, bugzilla has sent
me an e-mail giving no fewer than 195 issues. My search on bugzilla
reveals 18 high priority bugs.
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSI
GNED&bug_status=REOPENED&priority=High&email1=&emailtype1=substring&emailass
igned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&
bug_id=&changedin=&votes=& >

RE: [PROPOSAL] linebreak

[ewitness - Ben Fowler]

> >
>>I guess the reason nobody thought  or  would be
> >required is because a U+000A will do the trick.
>
> [ snip ]
>
>In any case, a linefeed (LF) must be honoured, and result in a linebreak.
>_If_ the conditions are right. What that means is, the initial value for
>"linefeed-treatment" is "treat-as-space", which _does_ do a conversion of
>U+000A to U+0020 (space). So you would want to specify
>"linefeed-treatment='preserve'" on an ancestor flow object (possibly
>fo:root) and allow it to propagate to the FOs of interest, as it is
>inheritable. The "whitespace-*" properties do not affect the linefeed, and
>suppress-at-line-break can also be left as it is.
>
>But essentially the LF is there to accomplish what you want to do. The
>initial setting of "linefeed-treatment" acts to give us LaTeX-like
>behaviour, but unlike LaTeX we can switch to something different in this
>regard, rather than use new markup.

The answer that you gave is also to be found a few lines down
from the first URL I gave you

4.   Forced line-breaks are respected. Specifically, if A
is the glyph-area generated by a fo:character whose Unicode
character is U+000A, then A must be the last area in its
containing subset Si.

I don't mind admitting that as an outsider to the XML standard, this
looks like a bad, even a really bad, idea.

My reading of your commentary is "Whitespace is sometimes respected,
and only a langauge lawyer can tell you when".

How should this be interpreted?

Do you think that HTML would be improved if the  element was
replaced with a feature that said "You can get the effect of a
forced linebreak by setting 'linefeed-treatment' to 'preserve'
in the  of the page (or other container as required), which
causes all unix line feeds to be rendered" instead the  element
which is what was done?

>From my POV this has an inhibiting effect on all editors and pretty
printing utilities, which must also respect exisiting white space
(as XSL processors do) and never introduce line feeds, in case this
setting was ever turned on. From my POV, a formatter should always
ignore the formatting of the source, unless notified that it is
preformatted as in the case of  and CDATA, exempli gratia
http://archive.ncsa.uiuc.edu/SDG/IT94/Proceedings/Autools/sperberg-mcqueen/sperberg.html
 >,
(1994) about half way down.

Do you happen to know whether this was ever discussed (id est objections
sought and answered) or whether this was one person's idea that
was incorporated as is.

I have a related 'issue' which is that the normalize-string( ) function
in XSL does two things. It trims leading and trailling newlines
and other whitespace, and it normalises internal white space.
I have a need for an operation that does the former, but not the latter.

(In fact I have an implementation which appears to be buggy
and replaces 'Miss A Burgrave' with Miss ABurgrave', but handles
'Miss A  Burgrave' correctly.

In short, XML processors including ones that produce XML-FO files
should pass through all whitespace, and processors such as fop
which are also XML processors, but adjusted so that they do not
produce XML, should (at least in general) normalise whitespace.
Where the output file format respects whitespace then it should
be supplied as  or as some break (as my original suggestion)
The present situation is that the latter type of processor may not
normalise whitespace, because some newlines are significant.

Incidently, you have not made (or reported) a case against my suggestion:
unless it is harmful (or confusing) there is no real reason why both
styles of indicating significant breaks could not be used, is there?

Using FOP derived from version 0.14, I get this report when I tried
the following .fo

WARNING: property 'linefeed-treatment' ignored
WARNING: property 'linefeed-treatment' ignored
setting up fonts
formatting FOs into areas
[1]
rendering areas to PDF

(source)


http://www.w3.org/1999/XSL/Format";
text-align="justified" font-size="12pt" font-family="serif"
linefeed-treatment='preserve' >









Bilbo Baggins,
Bag End,
Underhill,
Hobbiton,
Westfarthing of the Shire.





line-feed treatment was reported as not working in June last
year, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1998 >,
I don't know whether tit is now in.

I now have a linux installation (but not yet CVS), and so I am in a position 

RE: [PROPOSAL] linebreak was Re: REDESIGN: where I have been hiding

[Arved Sandstrom]

-Original Message-
From: ewitness - Ben Fowler [mailto:[EMAIL PROTECTED]]
Sent: February 18, 2002 9:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] linebreak was Re: REDESIGN: where I have been
hiding

>This would be useful in writing addresses exempli gratia:
>
>
>
>   
>   Bilbo Baggins,
>   Bag End,
>   Underhill,
>   Hobbiton,
>   Westfarthing of the Shire.
>   
>
>
>At present, I can get the effect I want with tables.
>
>Ben.
>-end of Original Message-
>
>I guess the reason nobody thought  or  would be
>required is because a U+000A will do the trick.

Thank you. I had assumed that that character would count as white
space, and would be normalised away.

I will try it.

Ben.

-

My answer was so terse that maybe it sounded snippy, which was not my
intention.

I also can't say that FOP is up to spec with whitespace handling. I'm
thinking that it's not, but I'll have to check myself. So my comments are
related to the spec only.

In any case, a linefeed (LF) must be honoured, and result in a linebreak.
_If_ the conditions are right. What that means is, the initial value for
"linefeed-treatment" is "treat-as-space", which _does_ do a conversion of
U+000A to U+0020 (space). So you would want to specify
"linefeed-treatment='preserve'" on an ancestor flow object (possibly
fo:root) and allow it to propagate to the FOs of interest, as it is
inheritable. The "whitespace-*" properties do not affect the linefeed, and
suppress-at-line-break can also be left as it is.

But essentially the LF is there to accomplish what you want to do. The
initial setting of "linefeed-treatment" acts to give us LaTeX-like
behaviour, but unlike LaTeX we can switch to something different in this
regard, rather than use new markup.

Regards,
AHS


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]