vmote 2003/06/24 10:47:15
Modified:src/java/org/apache/fop/rtf/rtflib/rtfdoc
IRtfTableContainer.java RtfAfterBeforeBase.java
RtfContainer.java RtfExtraRowSet.java
RtfPageNumber.java RtfPageNumberCitation.java
Victor Mote wrote:
Bertrand Delacretaz wrote:
They don't compile out of the box, so I disabled their compilation in
build.xml for now, didn't have time to look further.
The next step would be to get them to compile, have the RTFHandler use
them and remove jfor.jar from the lib
Jeremias Maerki wrote:
I've updated the Wiki page. The parametrization (as opposed to
configuration) is done through set/getOutputProperty (also see my
comment on the Wiki page).
Hmhm. The class you vasll FOPResult and subclasses has the same
role what I called Renderer and subclasses. Your choice
It's not only meant to be intuitive (read: JAXP-like) but also to get
that Renderer thing into the background where it belongs IMHO. You also
don't get direct access to the serializer in JAXP, I think. This helps
decoupling the API from the inner workings which is one factor towards a
stable API.
Team,
While Victor and Jeremias are discussing an input
API--I'd like to take advantage now of the relative
freeze in the codebase to move the StructureHandler
and LayoutHandler classes from the apps package to the
fo and area packages respectively (similar to what
we're doing with
Team,
While Victor and Jeremias are discussing an input
API--I'd like to take advantage now of the relative
freeze in the codebase to move the StructureHandler
and LayoutHandler classes from the apps package to the
fo and area packages respectively (similar to what
we're doing with
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21070.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
