[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
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
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
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
--- 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
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
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
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
-- 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
--- 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
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:
//
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
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
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
-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
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
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.
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
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.
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
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.
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
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
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
[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
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
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
[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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
--- 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
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,
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.
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
--- 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
-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
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
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
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
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
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
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
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
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
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
[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
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
, 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
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
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
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
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
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
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.
. . .
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
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.
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
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
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
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
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
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
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
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
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.
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.
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
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
From: Bertrand Delacretaz [EMAIL PROTECTED]
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
. . .
-
FOP uses iText as a PDF generation library
-
. . .
At 2:58 pm + 26/2/02, ewitness - Ben Fowler wrote:
[ snip ]
In FO, you could write
fo:block space-before=3pt
fo:block space-before=0some line/fo:block
fo:block space-before=0next line/fo:block
/fo:block
OK I have tried the FO in the attached file, giving
the expected PDF result.
[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
[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:
fo:block
[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 Foo source code and want to
include it in my printed manual
O.K. I was a
I guess the reason nobody thought fo:br/ or fo:newline/ 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
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 fo:br/ or fo:newline/ would be
required is because a U+000A will do
[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
-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:
?xml version=1.0
This would be useful in writing addresses exempli gratia:
?xml version=1.0 encoding=UTF-8?
fo:root text-align=justified font-size=12pt font-family=serif
fo:block
Bilbo Baggins,fo: newline /
Bag End,fo: newline /
Underhill,fo: newline /
Hi Jeremias,
The code looks fine. Putting the new classes under apps might not be the
best place, it's already confusing enough.
There is a problem that it doesn't actually compile due to a missing
method on PageSequence.
I also think it should be put in the main branch, possibly in a
Hi Keiron
On Thu, 3 Jan 2002 09:44:50 +0100 Keiron Liddle wrote:
Hi Jeremias,
The code looks fine. Putting the new classes under apps might not be the
best place, it's already confusing enough.
I guessed that could be a problem. I wasn't that happy with it, either.
But since it has to do
On 2002.01.03 10:01 Jeremias Maerki wrote:
There is a problem that it doesn't actually compile due to a missing
method on PageSequence.
Oops. Which method?
int getPageCount()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
On Thu, 3 Jan 2002 10:06:47 +0100 Keiron Liddle wrote:
On 2002.01.03 10:01 Jeremias Maerki wrote:
There is a problem that it doesn't actually compile due to a missing
method on PageSequence.
Oops. Which method?
int getPageCount()
Oh, now I understand. I forgot to include the
96 matches
Mail list logo
