RE: parsing package

Glen Mazza wrote: > --- Victor Mote <[EMAIL PROTECTED]> wrote: > > Glen, what are your > > plans for > > apps/FOInputHandler? Will it be going away or get > > renamed anyway? I have > > been using "Handler" as related to SAX events, and > > it looks like we have it > > also being used as I/O in a

DO NOT REPLY [Bug 21982] - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 21982] New: - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

default value of "force" param for FOP

Team, I'm looking at the "force" parameter-- Sean's recent patch for the Ant Task. This parameter, when set to "false", will stop xslfo files from being processed if there hasn't been a timestamp change on the xslfo file compared to the output file. force="true" means always generate. A default

DO NOT REPLY [Bug 21381] - [PATCH] Ant task mod-date patch for dev branch (see #21380)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java Fop.java

gmazza 2003/07/29 15:08:54 Modified:src/java/org/apache/fop/apps CommandLineOptions.java Fop.java Log: 1.) Moved the business logic for determining which starter to create from apps.CommandLineOptions to apps.Fop; CLO is now Starter-free. 2.) Made the i

Re: parsing package

--- Victor Mote <[EMAIL PROTECTED]> wrote: > Glen, what are your > plans for > apps/FOInputHandler? Will it be going away or get > renamed anyway? I have > been using "Handler" as related to SAX events, and > it looks like we have it > also being used as I/O in a more raw form. > Here's my though

parsing package

I don't feel strongly about this, but after trying to untangle some of the relationships between classes and packages, and knowing that Glen is doing more of the same, we may find it moderately useful to create a "parse" package where classes like FOTreeBuilder (which needs to be renamed) and FOInp

cvs commit: xml-fop/src/java/org/apache/fop/fo FOInputHandler.java FOTreeBuilder.java FOTreeHandler.java

vmote 2003/07/29 12:33:30 Modified:src/java/org/apache/fop/fo FOInputHandler.java FOTreeBuilder.java FOTreeHandler.java Log: beef up the javadoc comments explaining what these classes do Revision ChangesPath 1.2 +10 -4 xml-fop/src/java/

cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LayoutHandler.java

vmote 2003/07/29 12:08:23 Modified:src/java/org/apache/fop/apps Driver.java src/java/org/apache/fop/extensions Bookmarks.java Added: src/java/org/apache/fop/fo FOTreeHandler.java Removed: src/java/org/apache/fop/layoutmgr LayoutHandler.java Log: move la

cvs commit: xml-fop/src/java/org/apache/fop/rtf/renderer RTFHandler.java

vmote 2003/07/29 11:42:32 Modified:src/java/org/apache/fop/apps Driver.java src/java/org/apache/fop/extensions Bookmarks.java src/java/org/apache/fop/fo FONode.java FOText.java FOTreeBuilder.java FObj.java FObjMixed.java

cvs commit: xml-fop/src/documentation/content/xdocs team.xml

vmote 2003/07/29 09:50:49 Modified:src/documentation/content/xdocs team.xml Log: add Chris Bowditch to list of active contributors Revision ChangesPath 1.12 +1 -0 xml-fop/src/documentation/content/xdocs/team.xml Index: team.xml =

RE: trunk config, fonts

Chris Bowditch wrote: > It would be a loss. If you could spare time to test the trunk, you could > report back on which bits of layout need attention. A sort of gap > analysis > for basic FO documents would be really useful. This in turn would help > encourage development of the layout. > > I have

Re: trunk config, fonts

From: Clay Leeds <[EMAIL PROTECTED]> It may not be too much of a loss, but I won't be able to test the trunk until either a CLI is implemented, or I learn to run Java applets... It would be a loss. If you could spare time to test the trunk, you could report back on which bits of layout need a

Re: trunk config, fonts

Jeremias Maerki wrote: Until recently, the command-line interface of the trunk was basically ignored due to other priorities. Configuration certainly has changed a bit, but is obviously unfinished (Gradual move to Avalon Configuration, inrtoduction of the Confihurable interface, work in progress).

RE: TIFF image rendering in pdf is lossy

Angus, let me know if you need any more help with this - I was the "culprit" who submitted the support for the CCFFilter to FOP. We needed it as we render lots of incoming faxes into PDF. But they are Group 4 encoded. Manuel -Original Message- From: Angus Stewart [mailto:[EMAIL PROTECTED

Re: TIFF image rendering in pdf is lossy

Thanx Manuel, The problem turned out to be a utility class using JAI that preprocesses the image and, if image format not specified, defaults to JPEG ... NASTY. For some reason, too, JAI will not read a tiff that we compress using group 3 1D or 2D encoding. For the time being will continue to us

Re: TIFF image rendering in pdf is lossy

It would seem that the real issue is that some code I was using was doing an implicit convert of the tif image to jpeg before the transformation took place. Sorry to bother. Angus Stewart wrote: > > FOP 0.20.5rc2 > > ISSUE: TIFF image rendering in pdf is lossy. > > QUESTION 1: Is this a confi

DO NOT REPLY [Bug 21946] - [ERROR] svg graphic could not be built: null when running fop embedded

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: trunk config, fonts

Until recently, the command-line interface of the trunk was basically ignored due to other priorities. Configuration certainly has changed a bit, but is obviously unfinished (Gradual move to Avalon Configuration, inrtoduction of the Confihurable interface, work in progress). IMO it's low priority t