Sorry for not being clear. I also meant the layoutmanager package.
On 26.06.2003 00:37:25 Glen Mazza wrote:
Should LayoutHandler go into the
Layout (Jeremias) package or LayoutManager package
(Keiron)? (Personally, I don't care--99% for me is
getting them out of apps.)
Jeremias Maerki
vmote 2003/06/25 23:41:48
Modified:.build.xml
src/java/org/apache/fop/rtf/renderer RTFHandler.java
src/java/org/apache/fop/rtf/rtflib/rtfdoc RtfBookmark.java
RtfContainer.java RtfElement.java
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' block could not
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
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
From: Arnd Beißner [EMAIL PROTECTED]
snip/
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
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
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
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
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 added to
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 writing down my
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 could
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
--- 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.
Errr...I may
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
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
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 context of
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 options? Text
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 FOProcessorAPI by
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 one
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'
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
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
Devs,
I just noticed
include name=lib/jimi*/
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
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 tree, or
25 matches
Mail list logo
