Re: Layout transactions

2003-06-06 Thread Glen Mazza
--- Peter B. West [EMAIL PROTECTED] wrote: Such a transaction has a minimum and a maximum impact. Assuming that we must place the first line of the footnote on the same page, The line-area generator would pass this information up for the decision to be made about committing the

Re: Layout transactions

2003-06-06 Thread Glen Mazza
Peter B. West [EMAIL PROTECTED] wrote: it may be better if there is only room for a single line of a multi- line footnote, to throw the text line plaus the whole of the footnote onto the next page. I think this is the main point of what you were writing--avoiding having just one line of a

Re: Team page

2003-05-27 Thread Glen Mazza
Put me down for whining about TRAX/XSLTInputHandler ;) --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've just added something. I've also added a section Area of Expertise like the one in Batik. I already added some entries there, but please fill in some more as you find appropriate.

RE: hack to avoid memory overflow with tables

2003-05-27 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be

RE: hack to avoid memory overflow with tables

2003-05-28 Thread Glen Mazza
--- Chris Bowditch [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] snip/ 1.) Generate multiple document types accurately. 2.) Generate a high number of very large documents in a very short amount of time, with high, very large, and very short taken

RE: hack to avoid memory overflow with tables

2003-05-29 Thread Glen Mazza
--- Rhett Aultman [EMAIL PROTECTED] wrote: Moreover, is FOP really that far from, say, the HTML rendering engine in a web browser with respect to layout decisions? I see a lot of interpretations and opinions going on in those engines, which is why two browsers sometimes interpret my HTML

Re: Team page

2003-05-30 Thread Glen Mazza
German Ja! Bitte, bitte druecken Sie dieser Seite jetzt!!! Ich kann nicht warten, bis ich mein Name auf xml.apache.org sehen kann!!! /German English Yes, you may wish to wait a bit until more bios are updated on the page. I see no reason for being hasty in publishing. /English Glen Victor

Re: Fw: [GUMP] Build Failure - xml-fop

2003-05-31 Thread Glen Mazza
This doesn't appear to be Batik's fault--they're just recoding their classes, and their GraphicsNode interface has two more functions in it, one of which needs implementing in FOP's PDFJpegNode class. If Gump links to Batik's latest and greatest when building FOP, then FOP will need to update

Re: Fw: [GUMP] Build Failure - xml-fop

2003-05-31 Thread Glen Mazza
This doesn't appear to be Batik's fault--they're just recoding their classes, and their GraphicsNode interface has two more functions in it, one of which needs implementing in FOP's PDFJpegNode class. If Gump links to Batik's latest and greatest when building FOP, then FOP will need to update

Re: [GUMP] Build Failure - xml-fop

2003-05-31 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: You see, your code below could simply be added to Batik's AbstractGraphicsNode, I think, and everything would be in order again (without us having to change anything). They did that for one of the two functions that were added to the

RE: Team page

2003-05-31 Thread Glen Mazza
[EMAIL PROTECTED] wrote: Glen Mazza wrote: Yes, you may wish to wait a bit until more bios are updated on the page. I see no reason for being hasty in publishing. Well, there is no haste to publish the team page, but since the whole web site gets published together, and we have

RE: Team page

2003-06-02 Thread Glen Mazza
Looks good -- would you please update my email address to my work address on the team page: glen.mazza.at.eds.com. (.at. like all the other email addresses on that page to avoid spam concerns!) Thanks, Glen --- Victor Mote [EMAIL PROTECTED] wrote: Glen Mazza wrote: My email was meant

Area Tree vs. subsequent renderer (was Re: FO property expressions)

2003-06-02 Thread Glen Mazza
Thanks, Peter, for the explanation on the property/inheritance computations--I have one more question, perhaps anyone can answer (The Area Tree/Renderer explanations on the Design Tab is somewhat vague on this point): For those output formats requiring an area tree (i.e., non-TXT, RTF, etc.),

FOTreeBuilder/ElementMapping change ideas

2003-06-04 Thread Glen Mazza
I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: 1.) Driver explicitly adds three default element mappings (FO, SVG, FOP extension) to its FOTreeBuilder instance 2.) Driver searches

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-04 Thread Glen Mazza
, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... -- Peter B. West http

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-05 Thread Glen Mazza
at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... -- Peter B. West http://www.powerup.com.au/~pbwest

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-15 Thread Glen Mazza
parser of alt.design, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-16 Thread Glen Mazza
Peter, The decision to stop work in trunk--and to place all efforts into alt-design, should be put to a vote first by the committers. I'm quite reluctant for us to be putting all our eggs in one basket at this time. I want alt-design to win because it became the better implementation over an

Re: Nomination of Glen Mazza as committer

2003-06-16 Thread Glen Mazza
Peter--I've been *trying* to contribute to your alt.design--I respond as best I can to your postings. Many of us (but by no means all) are just not yet in your order-of-magnitude of knowledge yet... Glen --- Peter B. West [EMAIL PROTECTED] wrote: and that, should a developer happen along who

Re: Nomination of Glen Mazza as committer

2003-06-16 Thread Glen Mazza
Any committer from Chicago? A +6 or +7 would be really fantastic right now!!! ;) Thanks, virtual team, for all the endorsements. I am painfully aware that others had to contribute far more and for a longer time to become committers--I'll work on reducing that delta over the upcoming weekends!

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-16 Thread Glen Mazza
--- Peter B. West [EMAIL PROTECTED] wrote: I thought it was generally agreed some time ago that my work on properties should be integrated, for the simple reason that it is smaller and faster. Exactly! Now you're talking my language--smaller and faster--i.e., something that will

Re: startup refactoring

2003-06-16 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: 1. I am going to start committing changes, hopefully this evening. Much of the work is refactoring, but there are some substance changes as well, specifically to allow multiple output options, multiple documents, etc. I have therefore decided to

Re: startup refactoring

2003-06-17 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm a bit unhappy that you placed/left Session in the apps package. I would like to see the apps package deprecated as a whole over time. I would like a cli package that only contains the stuff needed for the command line and I'd like to have

Re: startup refactoring

2003-06-18 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: On 17.06.2003 21:28:29 Glen Mazza wrote: Instinctively, I wouldn't trust any code in the package root of org.apache.fop -- we wouldn't have a very modularized design that way (knowing FOP's current coding style, the main FOP API would

Re: [VOTE] Nomination of Glen Mazza as committer

2003-06-19 Thread Glen Mazza
Jeremias, Please forward off the following: Thanks, Glen Full Name: Glen Mazza Preferred Userid: gmazza Forwarding email address: [EMAIL PROTECTED] Karma: just xml-fop --- Jeremias Maerki [EMAIL PROTECTED] wrote: Can do. Here's the new account request form that we need to fill: New

RE: startup refactoring

2003-06-19 Thread Glen Mazza
victor quote [Responding to Jeremias here] Or, better yet IMO, into a RenderType object that is a child or grandchild of the Document, so that there can be multiple RenderTypes for the same Document. /victor quote I can understand enhancements for logging and threading, but multiple

RE: startup refactoring

2003-06-19 Thread Glen Mazza
Errr...this came across as harsher-sounding than I would have liked. If the API has some convenient ways for the user to specify multiple output types for a single xsl-fo stream, that should be fine. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: victor quote [Responding to Jeremias here

RE: startup refactoring

2003-06-20 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2 (Peter,

RE: startup refactoring

2003-06-20 Thread Glen Mazza
Previous email was sent before I was done red face/, please ignore for this one: --- Victor Mote [EMAIL PROTECTED] wrote: AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. Are you sure?

Re: startup refactoring

2003-06-20 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. Today, that is so. My idea is to

Re: startup refactoring

2003-06-20 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Even with AWT/Print an Area Tree is generated. But no area tree is generated when a StructureHandler (RTF/MIF) is active. Yes, I got confused between the two sets of weird render types: those that handle their processing with their own

RE: startup refactoring

2003-06-21 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: http://marc.theaimsgroup.com/?l=fop-devm=105270887501490w=2 I don't think that is the link you wanted -- it doesn't seem to be relevant here. That was the link--Keiron's writing appeared to indicate that the area tree needs to be created/processed

Re: Structure renderers area trees (Re: startup refactoring)

2003-06-22 Thread Glen Mazza
--- Arnd Beißner [EMAIL PROTECTED] wrote: Q If you need a clear differentiation between the renderer types, you might take this one: do I need to know the size of a glyph in a certain font/size to produce the output? If yes, the appropriate renderer goes into FOP, if not, it goes into a separate

RE: startup refactoring

2003-06-22 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. That's one helluva smart document you're planning

Re: Structure renderers area trees (Re: startup refactoring)

2003-06-22 Thread Glen Mazza
--- Arnd Beißner [EMAIL PROTECTED] wrote: Glen Mazza wrote: So the XSL-FO spec--which FOP is trying to implement for as many output types as possible--is not relevant for those output types which don't need to know glyph size? By putting it into a separate tool, that is what you

[VOTE] Move StructureHandler and LayoutHandler classes

2003-06-24 Thread Glen Mazza
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

(Jeremias, Keiron) Re: [VOTE] Move StructureHandler and LayoutHandler classes

2003-06-25 Thread Glen Mazza
in the layout package. On 25.06.2003 00:55:57 Glen Mazza wrote: 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

Re: (Jeremias, Keiron) Re: [VOTE] Move StructureHandler and LayoutHandler classes

2003-06-26 Thread Glen Mazza
Tree being used. I wasn't focusing on its function/purpose. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: 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

Re: Alternative API proposal (was: startup refactoring)

2003-06-26 Thread Glen Mazza
--- 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

Re: Alternative API proposal (was: startup refactoring)

2003-06-26 Thread Glen Mazza
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

Re: Alternative API proposal (was: startup refactoring)

2003-06-29 Thread Glen Mazza
I would judge the notion that FOP and RenderX share common goals to be somewhat sentimental; perhaps we should wait until Coke and Pepsi form such warm collaborative bonds first! At any rate, instead of FOPResult, since we already have an InputHandler class (and subclasses where needed), perhaps

Problem getting CVS changes onto FOP-CVS list.

2003-06-29 Thread Glen Mazza
Team, My last (and only) two cvs-commits--one to team.xml and the other just recently with Layout StructureHandler--are not appearing on the FOP-CVS (http://marc.theaimsgroup.com/?l=fop-cvsr=1b=200306w=2) mail list. CVS commit command outputs at the end that it is sending an email, however.

Re: Problem getting CVS changes onto FOP-CVS list.

2003-06-29 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: But as far as I remember I subscribed using my yahoo account to fop-cvs anyway. OK--just subscribed via my apache address (in my yahoo account) following the mailing list instructions: You can start a subscription for an alternate address, for

Re: ZIP distribution or installation program?

2003-06-29 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: Hi all, Given messsages like http://marc.theaimsgroup.com/?l=fop-userm=105689746128501w=2 should we provide the FOP distributions as ZIP files too? Perhaps a good idea--will Gump do this for us?--Cocoon, Axis, Xalan, and Struts are all supplying

[VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

2003-06-30 Thread Glen Mazza
Team, As mentioned earlier, I would like to pull out FOTreeBuilder's ElementMapping initialization from Apps.Driver, and instead encapsulate it within FOTreeBuilder directly. [Note: Alt-design no longer uses ElementMappings--but this change does not preclude switching to alt-design's method:

RE: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

2003-06-30 Thread Glen Mazza
Thanks for voting. --- Victor Mote [EMAIL PROTECTED] wrote: What about instream-foreign objects that get passed through? SVG is the only one I know of, and it is hard-wired in already, but I'm not sure that this capability should be lightly tossed. Agreed. But do dynamically added

Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

2003-07-01 Thread Glen Mazza
Thanks for voting--it looks like we'll continue with dynamic adding of element mappings (thanks to Joerg and Jeremias for pointing out that the functionality *does* work--which was my major concern), but I'll move the ElementMapping code out of Driver and into FOTreeBuilder. --- J.Pietschmann

white-space-collapse property in PageNumber/PageNumberCitation

2003-07-01 Thread Glen Mazza
Question: property white-space-collapse (Spec 7.15.12) is defined within both PageNumber.java and PageNumberCitation.java as an integer, but according to the spec this property is not defined for these two FO's (example: http://www.w3.org/TR/xsl/slice6.html#fo_page-number, scroll down to

Re: white-space-collapse property in PageNumber/PageNumberCitation

2003-07-01 Thread Glen Mazza
I guess we have some cleanup to do--I'll take a look at some of the FO's this weekend and report back to the team on property-removals we may need. The interesting FO's will be those which are actually utilizing invalid properties in their processing logic--hopefully there won't be many! Glen

Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

2003-07-01 Thread Glen Mazza
--- Peter B. West [EMAIL PROTECTED] wrote: That the semantics of the extensions have to be realized somewhere is tautological, even if those semantics are filter out. Tautological? Very good, Peter, you got me--it's rare when someone makes me need to look up a word in the dictionary!

RE: Tabs in eclipse

2003-07-02 Thread Glen Mazza
I've been a J-Edit (www.jedit.org) addict for over a year now (although I doubt it's as good as Eclipse), from a J-Edit text buffer: right-click, choose Soft (emulated with spaces) Tab option. But I doubt this issue warrants switching editors... Glen --- Venkata Rao Nadella [EMAIL PROTECTED]

Re: Build environment for alt.design

2003-07-04 Thread Glen Mazza
[Happy Independence Day, fellow Americans!] --- Peter B. West [EMAIL PROTECTED] wrote: The basic build principles that I will implement include: * No code generation or modification for normal builds. * All generated code and data maintained in CVS. I don't think you have to bother with

error compiling HEAD (need GraphicsConfiguration.java)

2003-07-04 Thread Glen Mazza
I can't compile the CVS - HEAD of FOP. Unless I've gotten something wrong, this file: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/svg/PDFGraphicsConfiguration.java?rev=1.1content-type=text/vnd.viewcvs-markup is extending a GraphicsConfiguration.java that apparently needs

Re: error compiling HEAD (need GraphicsConfiguration.java)

2003-07-04 Thread Glen Mazza
Never mind. xml-fop/src/java-1.4 directory needed updating. Had to do a cvs update w/ -d option first. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: I can't compile the CVS - HEAD of FOP. Unless I've gotten something wrong, this file: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org

Re: Build environment for alt.design

2003-07-05 Thread Glen Mazza
OK, if it helps you and if you suspect it will help others understand the system better, perhaps not such a bad idea. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Glen, Comments below, but to preface, let me say that alt.design has not had an Ant build system to date, so there is no

Re: Licence in build.*

2003-07-06 Thread Glen Mazza
This may need more work before proceeding---I've looked at Xalan, Cocoon, Axis--none of them are licensing their shell scripts and batch files--nor their to-do lists and related files--so if this is an oversight with us--so it is with everyone. Two (Xalan and Axis) do have a copyright statement

Re: Licence in build.*

2003-07-06 Thread Glen Mazza
-Willem van Gulik wrote: On Sun, 6 Jul 2003, Glen Mazza wrote: their to-do lists and related files--so if this is an oversight with us--so it is with everyone. Which is no reason not to fix i in fop-dev ASAP. We're an open source project; and the ASF needs every bit of help

Re: Licence in build.*

2003-07-06 Thread Glen Mazza
Oh, good--we're in agreement here. (Usually not good for one to argue too much with the President, non-profit or not ;) Glen --- Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Sun, 6 Jul 2003, Glen Mazza wrote: clarified to be any file checked into CVS for a project. Well

[VOTE] ElementMapping changes 5 FO's into pagination

2003-07-06 Thread Glen Mazza
Team, Two new changes I would next like to make to the trunk branch--These are unrelated, separate votes: (1.) I would like to remove the addToBuilder() function (and update its subclasses) from the ElementMapping interface and replace it with getNamespaceURI() and getFOTable() functions (and

Re: [RTF] jfor progress

2003-07-08 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: Question for Everyone: I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF, and the yet-unborn merely-glimmers-in-my-mind RawText and TeX renderers.

Re: [RTF] jfor progress

2003-07-08 Thread Glen Mazza
--- Glen Mazza [EMAIL PROTECTED] wrote: --- Victor Mote [EMAIL PROTECTED] wrote: Question for Everyone: I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF, and the yet-unborn merely

move the (AWT) PrintRenderer

2003-07-08 Thread Glen Mazza
Team, One of our renderers, PrintRenderer (*not* the same-named abstract base class to our PDF/PCL/TextRenderers, but the AWT-print-output renderer), is currently encapsulated within apps.PrintStarter. Apparently due to its location, its also ends up needing to be defined again in

Re: [Fwd: [Fwd: [vote] XMLBeans to enter XML incubation [was: Re: Vote for XMLBeans proposal in the XML Project (was RE: Vote for XMLBeans proposal)]]]

2003-07-10 Thread Glen Mazza
Looking at the website for XMLBeans, http://dev2dev.bea.com/technologies/xmlbeans/overview.jsp, Apache should be careful--this looks like a failed technology that doesn't have a sufficient user base for BEA to continue with. BEA appears to want to avoid a black eye it would get from its user base

Re: Contribution - anttask rendering only when source is newer than target

2003-07-10 Thread Glen Mazza
BTW, it may be good to kill two birds with one stone and have this task added directly to Apache Ant, as a new xslfo Optional Task, using what we currently have in our own codebase with Sean's improvements, and/or modeled after the Xalan xslt task already in Ant. That would have the added

Re: Naming of jars in lib

2003-07-11 Thread Glen Mazza
As we are all getting our libraries updated through CVS anyway, would it not be better to name them consistently, and include a text file detailing the current versions? Peter -- I don't think so--it is helpful to immediately see the version of the libraries when viewing the files.

Re: move Ant task to Ant project ( was Contribution - anttask)

2003-07-12 Thread Glen Mazza
Thanks for the explanation Stefan. --- Stefan Bodewig [EMAIL PROTECTED] wrote: On Thu, 10 Jul 2003, M. Sean Gilligan [EMAIL PROTECTED] wrote: Putting the Fop task directly in Ant would be great. I would really like to see that happen. I suppose we could get it in Ant 1.6 if we

Checkstyle max method length

2003-07-13 Thread Glen Mazza
Victor, I noticed we had to break up a function to satisfy Checkstyle's max method length size of 150 ( http://marc.theaimsgroup.com/?l=fop-cvsm=105806596213734w=2). That seems too constricted for our use--it's may force parameter passing of local variables where none would otherwise be needed.

RE: Checkstyle max method length

2003-07-13 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: I think it is instructive that neither of you commented on whether the changes that were made actually improved the code or not. I think you both need to either 1) show that the code was better before I changed it, If the reason you gave in CVS

Re: [VOTE] ElementMapping changes 5 FO's into pagination

2003-07-13 Thread Glen Mazza
J.Pietschmann wrote: Q Glen Mazza wrote: (1.) I would like to remove the addToBuilder() function (and update its subclasses) from the ElementMapping interface and replace it with getNamespaceURI() and getFOTable() functions +1 BTW this is not a change which requires a vote. /Q Change done

Re: Is there anybody out there?

2003-07-16 Thread Glen Mazza
Ali, Have you considered http://www.renderx.com for their commercial processor? That may be the best solution for you at this moment. Regrettably, FOP is just not ready for your needs yet. Thanks, Glen --- ali farahani [EMAIL PROTECTED] wrote: To all FOP developers The out of memory

How to apply a patch?

2003-07-20 Thread Glen Mazza
I've submitted them frequently, but, given a patch, how does one apply it to a file in a working directory? CVS has the diff command to create the patch, but I don't know what its opposite command is, to merge the patch into a file. (BTW, using Windows 2000.) Thanks, Glen

Re: How to apply a patch?

2003-07-20 Thread Glen Mazza
to be in the correct directory to apply the patch file. If you're using Eclipse as IDE you can use the patcher from there. It's pretty easy there. Good luck! On 20.07.2003 17:34:32 Glen Mazza wrote: I've submitted them frequently, but, given a patch, how does one apply it to a file

[VOTE]: Internal switch from XSLTInputHandler to JAXP

2003-07-21 Thread Glen Mazza
Team, For internal xml/xslt - fo translation, we are currently using XSLTInputHandler in three places: CommandLineOptions, FopPrintServlet and TestConverter.java. (TraxInputHandler isn't being used internally.) I would like us to switch from XSLTInputHandler to JAXP. For CommandLineOptions, I

[VOTE] Centralize parser creation/Simpler internal rendering calls

2003-07-21 Thread Glen Mazza
Team, We're currently creating equivalent XMLReaders for the FO Tree in two places, the Driver class (within the run() method) and within the InputHandler class get/createParser() methods (with an additional SetParserFeatures() within the Starter class). I'd like to centralize all this into

Re: [VOTE] Centralize parser creation/Simpler internal rendering calls

2003-07-21 Thread Glen Mazza
-- Source. But that's personal preference. On 21.07.2003 17:50:19 Glen Mazza wrote: We're currently creating equivalent XMLReaders for the FO Tree in two places, the Driver class (within the run() method) and within the InputHandler class get/createParser() methods (with an additional

[VOTE] Re: LayoutStrategy

2003-07-21 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: 1. In other words, I would like to have permission to temporarily treat Driver as either a singleton or a location for static constructs, which can be used to control the interaction between the various modules, so that I can move that logic out of

Re: [VOTE] Centralize parser creation/Simpler internal rendering calls

2003-07-21 Thread Glen Mazza
package reference the configuration package. And it's almost the same code and with the same semantics everywhere so this would actually reduce code. On 21.07.2003 18:20:30 Glen Mazza wrote: Yes, I said InputHandler is where the parser is created--I just want that moved over to Driver

Re: [VOTE] Centralize parser creation/Simpler internal rendering calls

2003-07-24 Thread Glen Mazza
, by having an render() option that will take an InputHandler and extract the parser and stream itself. I'll look into that. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: I'll look into it. Actually, I got my complaint wrong--I have less problem with something in apps referencing the rest

RE: [VOTE] Re: LayoutStrategy

2003-07-25 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: Hmmm. I'm not sure how to interpret the silence. I'm going to press on with my proposals unless I get some sort of substantive reply. Victor Mote Victor, I apologize for the silence--I did read your email on Sunday and more thoroughly

Re: parsing package

2003-07-29 Thread Glen Mazza
--- 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 thoughts on this

default value of force param for FOP

2003-07-29 Thread Glen Mazza
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 value

RE: parsing package

2003-07-30 Thread Glen Mazza
Victor-- After looking over the new design, I like it. Please keep your FOInputHandler abstract base class as-named. FOTreeHandler also is a very good name. I'd like to keep, however, at least for the time being, the naming convention in fop.apps with InputHandler as well. It's the command

Re: Change of status

2003-08-02 Thread Glen Mazza
Great--hope things work out well with your new team! Don't worry, while you're gone we'll steal liberally from your ALT-DESIGN! ;) Glen --- Peter B. West [EMAIL PROTECTED] wrote: Fopdevs, Sorry about the long silence, but my situation has undergone some dramatic changes. I have

testing DOM input

2003-08-14 Thread Glen Mazza
I created a ExampleDOM2PDF class for general testing and demonstration of FOP's DOM Document handling abilities. It's in the same examples/embedded/java/embedded directory as the other embedded examples. Going against 1.0, the code appears to work fine, so Victor's recent Document-handling

Re: rtf in trunk failing

2003-08-15 Thread Glen Mazza
No--I haven't touched RTF renderer yet, most of my changes are AWTRenderer and pre-Driver-related. However, I believe most of the non-pdf renderers in 1.0 return NPE's anyway, as they're primarily empty skeletons. (AWTRenderer did that until a week or so ago--I was able to fix that one.) Was

Re: gump build failed (trunk)

2003-08-15 Thread Glen Mazza
Yeah, I had a problem building the checkout last night--good to know its fixed. --- Victor Mote [EMAIL PROTECTED] wrote: It looks like one of the changes I made about 24-30 hours ago actually broke the build. I just committed a fix. __ Do you Yahoo!? Yahoo!

RE: rtf in trunk failing

2003-08-15 Thread Glen Mazza
oops--sorry--thanks. --- Victor Mote [EMAIL PROTECTED] wrote: The problem was in apps/Fop itself. I committed a fix just seconds ago. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Re: Status report

2003-08-15 Thread Glen Mazza
Unfortunately, progress on the main code branch is very slow, due to the absence of the main developers. Joerg, let's not divide ourselves into main developers and minor developers. Perhaps absence of many of the committers would be a better way to phrase it. Glen

Re: control/Document

2003-08-16 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: I mention this because I know that Glen is trying to get apps cleaned up. I think creation of control should help. From my perspective, apps is pretty well cleaned up now. (I'll try my luck at the properties and the AWTRenderer next.) Document

RE: control/Document

2003-08-19 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: IMO, changes to properties would seem to be low priority, since it works. However, a reasonable case can be made that cleaning it up simplifies layout, which is very, very important. At the very least, please tell us what your plans are for

Re: control/Document

2003-08-19 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: Dead wrong, properties are inherited properly, if you ask the property list manager you'll get correct values. Have a look at the code: the problem is how border definitions at different levels interfere. Suppose your table has a top-border-width

RE: control/Document

2003-08-20 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: Actually my JBuilder has a nice refactor task that does this for almost free, so, unless you have something similar at hand, perhaps I should do that. Victor Mote I use JEdit which has a pretty good global SR feature. But if you don't mind

RE: control/Document

2003-08-20 Thread Glen Mazza
Great! --- Victor Mote [EMAIL PROTECTED] wrote: Glen Mazza wrote: But if you don't mind taking care of this with JBuilder's refactor task, please do--you're anyway more familiar with Document in case something comes up. All done. Victor Mote

Re: control/Document

2003-08-20 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: Dead wrong, properties are inherited properly, if you ask the property list manager you'll get correct values. Technically speaking, if properties were *inherited* properly, setting border-width on fo:table-row would propagate to a child

Re: move extensions to fo/extensions?

2003-08-20 Thread Glen Mazza
We have currently about four sets of ElementMappings--fo, svg, extension, and MathML in examples. I'm confused about seeing Bookmarks referenced in FOTreeControl.java--I thought our pluggable ElementMappings (including the Bookmark formatting object) were designed to run with zero internal

off next few days

2003-08-20 Thread Glen Mazza
Going back home to beautiful Buffalo/Niagara Falls, NY--I'll be back next Tuesday! Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Re: control/Document

2003-08-27 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: Both collapsed and separated borders are supported, the latter actually better because collapsing depends on neighboring cells, which changes at breaks. Extreme settings may even cause layout oscillations. I updated the compliance.xml to

RE: move extensions to fo/extensions?

2003-08-27 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote: So, are we back to square one with the pluggable ElementMappers idea? Should we rip out that functionality from FOTreeBuilder that allows FOP to dynamically load brand-new ElementMappings? I still don't see its utility. IMO, no, and

import statements (RE: StaticContentLayoutManager)

2003-08-31 Thread Glen Mazza
On another issue, Victor, *please* don't forget to fully qualify the import statements -- that's one of our coding conventions and very helpful in grokking code -- a import org.apache.fop.apps.*; was added last week in the PDFRenderer.java:

Re: import statements (RE: StaticContentLayoutManager)

2003-08-31 Thread Glen Mazza
No big deal--just fixed it. --- J.Pietschmann [EMAIL PROTECTED] wrote: Glen Mazza wrote: fully qualify the import statements Eclipse's organize imports sorts this out quickly. I'm sure other IDEs have similar features. CheckStyle and PMD reports should point out these too

  1   2   3   4   5   6   7   >