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
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 i
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 situa
[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
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
> thi
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
wra
--- 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
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 co
-- "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
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 s
--- "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 ex
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 shoul
--- "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
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:
// Const
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
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
-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 proces
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 Bati
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
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.
Chri
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
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 proj
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
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
s
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
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 Maer
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
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
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 Ec
[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:
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]
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
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 f
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
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
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
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 fo
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 becaus
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 encounte
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 mavenizi
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,
--- 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.) Downl
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
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
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.
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 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
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
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
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 Jav
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
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 buil
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
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 ide
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
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
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
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 th
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
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'
-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 h
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
Joche
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
[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-
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 bu
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
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
TECTED]]
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 stu
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
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 with
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
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 u
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-Engineer
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
>
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
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 interfa
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 f
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.
>.
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
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 th
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
c
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. Cocoo
From: "Bertrand Delacretaz" <[EMAIL PROTECTED]>
> On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
> >. . .
> > -
> > FOP uses iText as a PDF generation library
> >
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,
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 FO
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.
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.
A
: [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
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, i
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 projec
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-ar
>[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.
[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();
> >
>[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
[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".
We
>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
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
> >
>>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 "tre
-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 gra
1 - 100 of 106 matches
Mail list logo
