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=24527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jeremias2003/11/08 06:00:03
Modified:src/java/org/apache/fop/apps Driver.java
Log:
Fix Document construction in getContentHandler() (it was done too late)
Revision ChangesPath
1.46 +14 -14xml-fop/src/java/org/apache/fop/apps/Driver.java
Index: Driver.java
jeremias2003/11/08 06:01:06
Modified:src/java/org/apache/fop/fo/flow ExternalGraphic.java
Log:
RTF: added support for fo:external-graphic
Submitted By: Peter Herweg [EMAIL PROTECTED]
Revision ChangesPath
1.11 +12 -0
jeremias2003/11/08 06:01:24
Modified:src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfTextrun.java RtfExternalGraphic.java
src/java/org/apache/fop/render/rtf RTFHandler.java
src/java/org/apache/fop/render/rtf/rtflib/tools
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=24527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jeremias2003/11/08 06:19:45
Modified:src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfExternalGraphic.java
Log:
Changed image loading to use Commons IO.
Properly close InputStream.
Revision ChangesPath
1.3 +9 -16
jeremias2003/11/08 06:30:01
Modified:src/java/org/apache/fop/apps Driver.java
Log:
Another fix, making Area Tree Renderers work again. Damn, when am I going to get it
right?
Revision ChangesPath
1.47 +7 -7 xml-fop/src/java/org/apache/fop/apps/Driver.java
jeremias2003/11/08 07:14:34
Modified:test/java/org/apache/fop BasicDriverTestCase.java
Log:
Basic functionality tests for PS and RTF besides PDF. Still no detailed output
checking, only checking that no exception is thrown.
Revision ChangesPath
1.3 +44 -2
jeremias2003/11/08 07:16:53
Modified:src/java/org/apache/fop/apps Driver.java
Log:
Now all setup code is moved from render() to getContentHandler() except for the
FOTreeListener.
Revision ChangesPath
1.48 +17 -16xml-fop/src/java/org/apache/fop/apps/Driver.java
As you may have seen in the CVS messages I have moved most of the setup
code that was in the render() method to the getContentHandler() method.
This is necessary because not everyone uses the render() methods,
sometimes you simply need to have a ContentHandler to send SAX events to.
Some of our
[EMAIL PROTECTED] wrote:
Basic functionality tests for PS and RTF besides PDF.
Can you check how this can be incorporated into
GenericFOPTestCase.java?
J.Pietschmann
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=24530.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24530.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jeremias2003/11/08 11:31:41
Modified:src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfTextrun.java ITableAttributes.java
RtfTableRow.java RtfTableCell.java
src/java/org/apache/fop/render/rtf
Hmm, you mean adding MD5 tests? I'd rather not do that. These digests
change too often. The BasicDriverTestCase's purpose is to verify that
the overall API works and that some reasonable output has been generated
and no exceptions were thrown. So instead of just checking whether
anything at all
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
As you may have seen in the CVS messages I have
moved most of the setup
code that was in the render() method to the
getContentHandler() method.
This is necessary because not everyone uses the
render() methods,
Well, what is wrong with everyone
Wow, all this work--great to have you back coding
again!
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Finally, I managed to scratch together some time and
resync my local
codebase again.
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail
Glen Mazza wrote:
Well, what is wrong with everyone using the render()
method for 1.0?
Because we sell the FOP processor as a SAX endpoint, so
that the famous
transformer.transform(source, new SAXResult(
fop.getContentHandler()));
can be used. Driving processing through SAX events
is a major
I'm not in a fighter mood today so please change getContentHandler()
to something other than public, make sure you check the test cases
regularly, adjust the example code to the new API and keep in mind that
Cocooners will want to migrate their FOPSerializer some day (They use
getContentHandler()
--- J.Pietschmann [EMAIL PROTECTED] wrote:
Glen Mazza wrote:
Well, what is wrong with everyone using the
render()
method for 1.0?
Because we sell the FOP processor as a SAX endpoint,
so
that the famous
transformer.transform(source, new SAXResult(
fop.getContentHandler()));
can
21 matches
Mail list logo
