J.Pietschmann wrote:
> Victor Mote wrote:
> > I don't see why you
> > would suggest that my proposal would use more memory. I am quite sure it
> > would use less, but not enough to even mention.
>
> Well, your approach to "decoupling layout and rendering" seems
> to include building a full area tr
Devs,
I just noticed
in the dist.bin.lib fileset of build.xml in HEAD. Is that supposed to be
there?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
pietsch 2003/06/26 17:16:28
Modified:src/java/org/apache/fop/fo/pagination Root.java
Log:
Test commit from Eclipse: removed unused import.
Revision ChangesPath
1.3 +3 -5 xml-fop/src/java/org/apache/fop/fo/pagination/Root.java
Index: Root.java
===
Victor,
Definitely a w.i.p. It throws up too many exceptions at the moment, and
needs to be pruned back by those with a better grasp of the style
requirements.
Btw, are you using JBuilder with FOP? If so, could you add some notes
to the IDE Wiki when you get some "spare time"?
Peter
Victor
Arnd Beißner wrote:
Peter,
thanks for the answer.
I have always *assumed* that column balancing is implied whenever
top-level block children of a flow have different "span" attributes,
because it's the only approach that makes sense. If your second
scenario were intended, then the 'span="all
> J.Pietschmann wrote
> I think we have a few slightly more pressing problems:
> - improving the API to ease embedding (including Java2D embedding)
What has to be embedded?
> Adding multiple output streams is certainly fun but I suspect the
> bulk of the current users would be more interested in
Victor Mote wrote:
I don't see why you
would suggest that my proposal would use more memory. I am quite sure it
would use less, but not enough to even mention.
Well, your approach to "decoupling layout and rendering" seems
to include building a full area tree, or something equivalent.
FOP was imple
Forgive my newbie-ness here, but I'm having problems figuring out how
to send this [patch] in. I'm sending it here... Please enlighten me
(gently ;-p) so that next time I'm doing it as efficiently as possible.
Thanks!
PATCH INFO:
The info for XPath is missing the fact that it's pretty much Wind
J.Pietschmann wrote:
> Victor Mote wrote:
> > I guess I don't
> > understand the need for FOProcessorFactory, which seems to be
> an unnecessary
> > complication for the user.
>
> It has something to do with the GoF Factory pattern. This means you can
> choose the implementation of the FOProcessor
OK, thanks for the enlightenment.
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > Shouldn't we be leery of "render options" where
> one
> > specifies properties of how the output should look
> > outside of what is specified by the XSL-FO file?
>
> PDF encryption? Printer op
Jeremias Maerki wrote:
> > That is not reuse. The metadata example is a trivial one. A
> Collection of
> > Fonts used and Fonts to be embedded would be a more important
> one. However,
> > I don't care. You are correct that we aren't talking about the
> same thing.
>
> Then you mean reuse in the c
Glen Mazza wrote:
Shouldn't we be leery of "render options" where one
specifies properties of how the output should look
outside of what is specified by the XSL-FO file?
PDF encryption? Printer options? Text encoding? MIF version?
(If
there are output properties that cannot be specified
sufficie
Victor Mote wrote:
I guess I don't
understand the need for FOProcessorFactory, which seems to be an unnecessary
complication for the user.
It has something to do with the GoF Factory pattern. This means you can
choose the implementation of the FOProcessorAPI by setting a Java property,
or some simi
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
> > I don't understand your last statement, but I
> agree that FOPResult is a
> > better name than RenderType.
>
> Let's try different wording: The name "RenderType"
> suggests that it is a
> enumeration or a parameter, but it's more than that.
>
On 26.06.2003 20:13:06 Victor Mote wrote:
> Well, its a whole lot more than an API and there are some implementing
> classes in your spec. However, thanks for clarifying.
Only two classes (DefaultFOProcessorFactory and AvalonFOProcessorFactory)
to show how the two world can be made more or less c
Jeremias Maerki wrote:
> > I think your name is fine. I am confused about whether it is an
> interface
> > (as written) or a class (I don't see any implementations).
>
> It's an API. You don't necessarily see implementing classes in the
> specification. Compare to JAXP. Theoretically, RenderX coul
On 26.06.2003 18:40:58 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > I have done so now. I've added a new (sub)page to the Wiki to avoid
> > making the FOPAvalonization page even longer.
> >
> > http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA
> PIProposalJM
> >
> > While wr
Victor Mote wrote:
> J.Pietschmann wrote:
>
> > Could you outline your API ideas on the Wiki?
>
> Sure (give me a couple of days). Again, my point is not to push for a
> particular API or framework, but only to show that the control
> concepts (PDF
> encryption was the example given IIRC) can be a
Peter B. West wrote:
> pbwest 2003/06/25 10:01:01
>
> Removed: .checkstyle1.3.0-head
> Log:
> Name changed to checkstyle3.1.1-head
Thanks for all of your efforts here. Is this file reliable, or is it a work
in progress?
Victor Mote
---
Jeremias Maerki wrote:
> I have done so now. I've added a new (sub)page to the Wiki to avoid
> making the FOPAvalonization page even longer.
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA
PIProposalJM
>
> While writing down my thought about the API I have come to the
> real
Good--that's where it will go then (barring an
onslaught of -1's between now and this weekend)
BTW, I believe my original rationale for placing in
the Area package was by looking at the imports in
LayoutHandler--it seemed to be very heavily dependent
on the particular implementation of the Area Tr
From: "Arnd Beißner" <[EMAIL PROTECTED]>
Since the default behaviour really seems to be unspecified, and since
there's no property to specify it,
I believe overall less harm is done if you don't balance at the end of the
flow. This is because then you
can always trick the renderer into balancing
Bertrand Delacretaz wrote:
> obviously these are needed - sorry about that, I have added them now.
> I'm just fixing the licenses now, but the files are there already.
No apology needed. Thanks for adding them. I have just committed the changes
needed to compile, and have also removed the jfor li
vmote 2003/06/26 00:03:52
Modified:.build.xml
Removed: lib jfor-0.7.1.jar jfor.LICENSE.txt
Log:
Remove jfor libs and references.
Revision ChangesPath
1.84 +0 -1 xml-fop/build.xml
Index: build.xml
==
24 matches
Mail list logo
