Re: FOs and Areas
As an active FOP user I have been monitoring the fop-dev list for the last 2 years or so. The recent discussion between Victor and Peter and Jrg's comment below seem to highlight a difference in opinion where the project is headed. Based on the various discussions on this list and the web site it appeared to me that the goal for the development branch is: a) Basic level compliance to the FO spec b) Support for arbitrary sized documents plus a number of sub goals. Both of these goals appear to create really hard design problems for which even experienced FOP developers don't have solutions to. For example the issue of resolving property values, the dependency of the resolution on the layout, and the special handling required for resolution in the context of markers, seem to cause lots of design discussions without actually converging. This indicates to me it is most likely a hard problem when, given the quality of the people contributing, not even after a year or so an agreed and understood design solution is forming. And property value resolution is only a small item in the problem domain created by the XSL-FO spec. Personally I agree with Jrg that the project needs working code especially as the maintenance branch is frozen and no more releases are forthcoming until the development branch is ready. This becomes a very long time between drinks for your user base. However, to achieve the working code may be the project goals need to be revised downwards. May be the project should scrap the design goal of basic level compliance and support for large documents and aim for a smaller subset. For example: Go through the list of unsupported or incomplete supported fo elements and properties and agree on a subset to be supported in the next release. Keeps, auto table layout, bidi font support are some that come to mind but I am sure there are more (or less). Once that is agreed concentrate design and implementation discussions on these revised goals. If it turns out that this leads to design decision which will make other things (outside the stated goals) hard later - tough luck that's then left to the next refactoring effort. If it leads to certain property expressions not being supported - tough luck as well. If it leads to markers not being done perfectly - tough luck as long as the stated goals are achieved (this assumes perfect marker handling is not one of the goals). Isn't that part of the 'Extreme Programming' methodology? If it's not needed now (= not part of the project spec) don't build it in don't even waste time discussing it. Most projects go through many iterations each leading to rewrites of significant portions of the code (eg. tomcat 3.x, 4.x, 5.x). Why should FOP get away with only two iterations? Manuel - Original Message - From: J.Pietschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 3:26 AM Subject: Re: FOs and Areas Peter B. West wrote: (does Jrg work?), Not in the archive. I know you are a long-time advocate of sticking with the codebase, and have been very critical of my approach, so I don't want to draw any unwarranted conclusions here. Does the above mean that you are interested in my ideas? I've got a lot of ideas myself, perhaps too many. What the project needs is *working* *code*. J.Pietschmann
DO NOT REPLY [Bug 25272] - FNF thrown formatting test/resources/fop/image/align.fo
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=25272. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272 FNF thrown formatting test/resources/fop/image/align.fo --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 14:22 --- Is there anything more to be done for this ?
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
[Glen Mazza] It's been in that location for at least several months--it's just that we never saw it because it was autogenerated and never checked into CVS. (As for its location--it is used by the FO classes and it also has some FO constants and other enumerations in there, so it is OK remaining there, I think.) I think Peter was refering to the fact that you placed the file in the src/java/org/apache/fop/fo/ directory, but it used to be in the org.apache.fop.fo.properties. package. Indeed, the package statement in the Constants still reads package org.apache.fop.fo.properties; So you really should move the file from src/java/org/apache/fop/fo/Constants.java to src/java/org/apache/fop/fo/properties/Constants.java [...](e.g., like Finn, I have a slight preference for a constants interface--Constants.java--that classes can implement, rather than a constants class--PropNames.java.) Right, but methods that can map constants-string and string-constants is still needed and must be placed in a class somewhere. I happened to put the methods in the FOPropertyMapping class. Also, while I used fo:element constants in my experiment, it is clear to me that such an approach does not work well for extension elements. regards, finn
RE: FOs and Areas
Andreas L. Delmelle wrote: With all due respect, I think you're overreacting here. Maybe you already know this yourself, and have changed your mind about the 'adios'... Anyway, I have been following the discussions between Peter and yourself (--at least the recent ones, which may be exactly why I'm convinced this is all strongly exaggerated). Before you leave, I have a thing or two to add about one of the previous posts in this thread, where you are talking about an abstract 'team' where at first 100 percent of the committers are pro one particular design --you know, the part about 'choosing sides' and how this affects global efficiency within a project. Since the post in question was composed shortly after my 'heads up' to Peter, I can't help but feel it's somehow related to that. No. It took me several hours to draft that message. The fact that they were sent close together is a coincidence. Perhaps you would rather have seen me (or others) having a go at him as well? Yes, I think some discipline is needed here, but I don't expect it to come from you. It definitely was never my intention to occupy myself with something so mean/common as 'choosing sides'. Fact of the matter is that, for the moment I *know* too little about the workings of FOP (either HEAD or alt-design) to actually have a thoroughly reflected preference for either approach. Hey, maybe I just need to catch up on the archives, and will then suddenly discover what kind of a pest Peter really is... but right now, I lack any indication of him trying to undermine every one of your design proposals, neither have I been confronted with any evidence that he is actually trying to force anyone to see things *his* way at the cost of everything else (and these are two things you seem to be _reproaching_ him in your replies). The gist of this section seems to be ... that you don't know enough to comment on what is going on. Duly noted. Re-reading Peter's posts, on the contrary, I see someone who was daring enough at some point to say: I'm going to try it like that, regardless of what the rest of you does. Some time later, he came to the conclusion that he wouldn't solve some of the issues the others were trying to solve at the time he went his own path, and now he's here again --to see if any of the issues have already been sorted out. If what you say were true, the alt-design properties work would have been integrated into the trunk, and the alt-design branch abandoned. No, he is here, again, to sell us on the idea that you can't build an FO Tree without first building the Area Tree. He is unwilling to consider simpler alternatives. Look, I can understand your agitation stemming from the fact that you had put considerable time and effort into providing a means to be able to choose between different layout strategies, and now it turns out this wasn't really necessary after all --and Peter's shrugging his shoulders, which obviously Where do you get the idea that LayoutStrategies aren't necessary after all? IMO, they are crucial, regardless of what Peter does. would cause a lot of frustration with (and would thus come across as offending to) someone who takes the project seriously, like yourself. I don't care whether Peter uses LayoutStrategy or not. My frustration stems from the fact that design questions can be repeated ad infinitum and ad nauseam. People who take the questions seriously and try to develop answers to them have the same weight as those who flippantly say -1 or those who let the thread dangle until they can reagitate the question again. However, right now, reacting the way you do, I'm getting the impression you're taking it waaay *too* seriously --in fact, you have been doing that all along. It almost seems like you are backing out now, because you see a certain failure ahead and you want to avoid it. You just don't want to be there when it turns out your proposals were worthless to begin with. Perhaps you would be so kind as to tell me what you are talking about. Specifically what is it that you think will fail, and why? If you can answer that, then you can answer the question that I have asked Peter to answer 4 times now. I have acknowledged that my proposals may be worthless. In fact, I have asked Peter to simply show that they are. If the solution requires a complex system to coordinate parsing and layout, then that is what we need to do. I have proposed a much simpler alternative that leaves our existing code base intact, and have asked Peter to find any flaws in it. The nature of this stuff is that some days you teach and others you are taught. I can't get Peter to do either one. Your ad hominem attack on my motives is rude, arrogant, offensive, and not supported by anything that I have said. And I don't mind saying that it is false. Nowhere have I read any allusion to you as the guy everyone else wishes would go away (perhaps somewhere in the whitespace in
RE: FOs and Areas
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] Andreas L. Delmelle wrote: snip / The gist of this section seems to be ... that you don't know enough to comment on what is going on. Duly noted. Not quite. More like: I *think* I don't know enough (maybe _that_ is overreacting). Sometimes this assumption gets affirmed, and at others --for example, your announcement yesterday - I am strongly convinced there is a lot to be learned from me ;) Cheers, Andreas
RE: Going away (was: FOs and Areas)
Jeremias Maerki wrote: On 17.12.2003 15:25:37 Victor Mote wrote: I would rather go away than to be the guy that everyone wishes would go away. Ok, Victor, until that happens I'd like you to stay. I don't see *any* indication that *anyone* wishes that *anybody* should go away. Well, our moderators would surely like to get rid of all spammers. But seriously, please reconsider your decision, maybe take a break from the mailing list to clear your head. Consensus is sometimes hard to find especially over such an problematic medium such as this mailing list. Intentions are always difficult to transmit. Mails take a long time to write, time we usually don't have and would rather spend programming. I think we all share that frustration. Maybe we should all buy a webcam so we can occasionally chat together face to face as we're all a long way from each other. It is true enough that consensus is sometimes hard to find, but that is not the point. The point is that, as practiced by FOP, it is impossible to find. And not because of technical difficulty. WRT the slowness of the medium of email, I actually perceive that to be a benefit. The time it takes to draft an email is a useful cooling-off period, at least for me. Now the following is not only directed to you, Victor, but to everyone else as well. Just personal opinions: I followed the wars on the Avalon mailing list which at one time even produced a victim in form of a partial expulsion from the ASF. I would be very sad to have to see similar things here, especially in the project's present state. I told Glen this summer that it's better to fire away with changes than letting himself block by myself who, at that time, only injected his ideas and opinions but without code to back them. What this project needs is people who simply do it (tm). A good design is useful but obviously it's not so simple to find in our case. We can't live without some sort of design that gives use some direction but things like Victor's pluggable LayoutStrategy may really help, if we need to investigate different approaches. I'd rather have two or three half-completed layout approaches with lots of things learned than not a single working one with a community at total stand-still. We failed to integrate Peter's branch into HEAD but maybe that's also because it was too big a bundle at one time. Everyone should accept that another person has a different opinion. That shouldn't block us in our work. We all look forward to the same goal. That much I know or else we wouldn't be here. So, I mostly agree with Joerg's and Andreas' recent comments. Please let's focus on coding even if we may have to throw away little parts again in the process. (This doesn't mean I don't want to see anymore threads on design.) I think one of the most important points we learned since the redesign decision is to better split up the whole thing so it's easier (and less painful) to change if we run into a dead-end somewhere. The inherent problem with this suggestion is that it is not reasonable to invest in a project where the big design issues are not addressed. The best thing would be to come to an agreement in theory, then as coding progresses, change the theory if necessary. The second best thing would be to fork the project into two -- one based on the trunk, one based on alt-design. If that split were made official, I think developers would be much easier to recruit (and retain) for both. If Peter's principles prevail, it will be a permanent triumph of performance over quality, and FOP will never be useful for my purposes. I don't have a problem with that, but it is not unreasonable to try to resolve it before investing more in the project. Victor Mote
Re: FOs and Areas
Andreas L. Delmelle wrote:
Which is done by {which parser?}
Xerces 2.3.4, but it doesn't matter. The problem are the generated
Java objects.
80k? For how many fo:* approx. in the file?
8 objects. A table with some twenty odd columns and 800+ rows.
A TableCell, a Block and a FOText per cell. The rest is small change.
Problem seems to be one of nested little objects, no longer 'needed', but
still referenced by their parent, which is still 'needed' --btw: What
exactly are the criteria by means of which it is possible to decide that a
given FO object, no matter how deeply nested, can safely be 'discarded' from
the tree?
A) it has been rendered.
B) no chance to backtrack (due to keeps, widows/orphans, side-floats,
column rebalancing because of footnotes or before-floats, last page
layout and perhaps a slew of less obvious reasons)
Note that there are scenarios where a backtracking can ripple back
through an arbitrary number of pages, although 99.99% ought to affect
the current page only and even scenarios affecting the previous page
look rather artificial.
FOs not generating areas, in particular fo:table-column, could probably
discarded immediately after the interesting info has been processed into
a more amenable data structure referenced from parent FO.
[Another option (--also a very long shot maybe) would be to try and, ahem,
_steal_ a little of the PDF approach... implement a form of (binary)
compression on the FO tree storage in memory?
Yuck! Flashbacks of SoftRAM
J.Pietschmann
Re: FOs and Areas
J.Pietschmann wrote: Peter B. West wrote: (does Jrg work?), Not in the archive. I know you are a long-time advocate of sticking with the codebase, and have been very critical of my approach, so I don't want to draw any unwarranted conclusions here. Does the above mean that you are interested in my ideas? I've got a lot of ideas myself, perhaps too many. What the project needs is *working* *code*. Working code is predicated on working ideas, is it not? That's why I asked about ideas. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
cvs commit: xml-fop/src/java/org/apache/fop/fo/properties Constants.java
gmazza 2003/12/18 15:37:45
Added: src/java/org/apache/fop/fo/properties Constants.java
Removed: src/java/org/apache/fop/fo Constants.java
Log:
Place Constants.java file in wrong location.
Revision ChangesPath
1.1 xml-fop/src/java/org/apache/fop/fo/properties/Constants.java
Index: Constants.java
===
/* $Id: Constants.java,v 1.1 2003/12/18 23:37:45 gmazza Exp $
*
*The Apache Software License, Version 1.1
*
*
* Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice,
*this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
*this list of conditions and the following disclaimer in the documentation
*and/or other materials provided with the distribution.
*
* 3. The end-user documentation included with the redistribution, if any, must
*include the following acknowledgment: This product includes software
*developed by the Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself, if
*and wherever such third-party acknowledgments normally appear.
*
* 4. The names FOP and Apache Software Foundation must not be used to
*endorse or promote products derived from this software without prior
*written permission. For written permission, please contact
*[EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache, nor may
*Apache appear in their name, without prior written permission of the
*Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
* DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many individuals
* on behalf of the Apache Software Foundation and was originally created by
* James Tauber [EMAIL PROTECTED]. For more information on the Apache
* Software Foundation, please see http://www.apache.org/.
*/
package org.apache.fop.fo.properties;
public interface Constants {
// element constants
int FO_BASIC_LINK = 1;
int FO_BIDI_OVERRIDE = 2;
int FO_BLOCK = 3;
int FO_BLOCK_CONTAINER = 4;
int FO_CHARACTER = 5;
int FO_COLOR_PROFILE = 6;
int FO_CONDITIONAL_PAGE_MASTER_REFERENCE = 7;
int FO_DECLARATION = 8;
int FO_EXTERNAL_GRAPHIC = 9;
int FO_FLOAT = 10;
int FO_FLOW = 11;
int FO_FOOTNOTE = 12;
int FO_FOOTNOTE_BODY = 13;
int FO_INITIAL_PROPERTY_SET = 14;
int FO_INLINE = 15;
int FO_INLINE_CONTAINER = 16;
int FO_INSTREAM_FOREIGN_OBJECT = 17;
int FO_LAYOUT_MASTER_SET = 18;
int FO_LEADER = 19;
int FO_LIST_BLOCK = 20;
int FO_LIST_ITEM = 21;
int FO_LIST_ITEM_BODY = 22;
int FO_LIST_ITEM_LABEL = 23;
int FO_MARKER = 24;
int FO_MULTI_CASE = 25;
int FO_MULTI_PROPERTIES = 26;
int FO_MULTI_PROPERTY_SET = 27;
int FO_MULTI_SWITCH = 28;
int FO_MULTI_TOGGLE = 29;
int FO_PAGE_NUMBER = 30;
int FO_PAGE_NUMBER_CITATION = 31;
int FO_PAGE_SEQUENCE = 32;
int FO_PAGE_SEQUENCE_MASTER = 33;
int FO_REGION_AFTER = 34;
int FO_REGION_BEFORE = 35;
int FO_REGION_BODY = 36;
int FO_REGION_END = 37;
int FO_REGION_START = 38;
int FO_REPEATABLE_PAGE_MASTER_ALTERNATIVES = 39;
int FO_REPEATABLE_PAGE_MASTER_REFERENCE = 40;
int FO_RETRIEVE_MARKER = 41;
int FO_ROOT = 42;
int FO_SIMPLE_PAGE_MASTER = 43;
int FO_SINGLE_PAGE_MASTER_REFERENCE = 44;
int FO_STATIC_CONTENT = 45;
int FO_TABLE
cvs commit: xml-fop/src/documentation/content/xdocs book.xml team.xml
gmazza 2003/12/18 17:08:42 Modified:src/documentation/content/xdocs book.xml team.xml Log: Updates to team page. Revision ChangesPath 1.28 +2 -2 xml-fop/src/documentation/content/xdocs/book.xml Index: book.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/book.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- book.xml 26 Nov 2003 01:12:46 - 1.27 +++ book.xml 19 Dec 2003 01:08:42 - 1.28 @@ -47,11 +47,11 @@ menu label=Project menu-item label=News href=news.html/ - menu-item label=Logo contest href=logocontest.html/ + menu-item label=Who We Are href=team.html/ menu-item label=Status href=status.html/ + menu-item label=Logo contest href=logocontest.html/ menu-item label=Changes href=changes.html/ menu-item label=Todo href=todo.html/ - menu-item label=Team href=team.html/ /menu /book 1.21 +13 -6 xml-fop/src/documentation/content/xdocs/team.xml Index: team.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/team.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- team.xml 16 Nov 2003 19:02:51 - 1.20 +++ team.xml 19 Dec 2003 01:08:42 - 1.21 @@ -19,9 +19,12 @@ independence and is having fun working on open source projects like Apache FOP. He's also the creator of fork href=http://www.krysalis.org/barcode;Krysalis Barcode/fork. /li -li id=gmlink href=mailto:[EMAIL PROTECTED]Glen Mazza/link (GM) is an information systems analyst - with EDS in Arlington, Virginia, USA./li -li id=wvmlink href=mailto:[EMAIL PROTECTED]Victor Mote/link (WVM) is the founder and manager of jump href=http://www.outfitr.com;Enterprise Outfitters/jump, a business software company, and of jump href=http://www.portagepub.com;Portage Publications/jump, a republisher of old documents. Both are located in Colorado Springs, Colorado, USA./li +li id=gmlink href=mailto:[EMAIL PROTECTED]Glen Mazza/link (GM) is an information +systems analyst with EDS in Arlington, Virginia, USA./li +li id=wvmlink href=mailto:[EMAIL PROTECTED]Victor Mote/link (WVM) is the founder and +manager of jump href=http://www.outfitr.com;Enterprise Outfitters/jump, a business +software company, and of jump href=http://www.portagepub.com;Portage Publications/jump, +a republisher of old documents. Both are located in Colorado Springs, Colorado, USA./li li id=jplink href=mailto:[EMAIL PROTECTED]J#x00F6;rg Pietschmann/link (JP)/li li id=otlink href=mailto:[EMAIL PROTECTED]Oleg Tkachenko/link (OT)/li li id=pbwlink href=mailto:[EMAIL PROTECTED]Peter B. West/link (PBW)/li @@ -30,8 +33,12 @@ section id=contribute-active titleActive Contributors/title ul -lilink href=mailto:[EMAIL PROTECTED]Marcelo Jaccoud Amaral/link/li -lilink href=mailto:[EMAIL PROTECTED]Rhett Aultman/link/li +lilink href=mailto:[EMAIL PROTECTED]John Austin/link is an +is an independent software developer currently based in St John's, +Newfoundland. While developing a taste for good seafood, he still isn't ready +for seal flipper (even if it's fresh). He is currently assisting the FOP +project on memory and performance issues./li +lilink href=mailto:[EMAIL PROTECTED]Finn Bock/link/li lilink href=mailto:[EMAIL PROTECTED]Chris Bowditch/link/li lilink href=mailto:[EMAIL PROTECTED]Andreas Delmelle/link/li lilink href=mailto:[EMAIL PROTECTED]Peter Herweg/link is helping to - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
--- Finn Bock [EMAIL PROTECTED] wrote: I think Peter was refering to the fact that you placed the file in the src/java/org/apache/fop/fo/ directory, but it used to be in the org.apache.fop.fo.properties. package. Indeed, the package statement in the Constants still reads package org.apache.fop.fo.properties; Yes, I foolishly realized later that's what Peter meant (I'm surprised it compiled w/o error though--that was my confusion, since there was no error I assumed he was commenting on my choice of location for the package.) [...](e.g., like Finn, I have a slight preference for a constants interface--Constants.java--that classes can implement, rather than a constants class--PropNames.java.) Right, but methods that can map constants-string and string-constants is still needed and must be placed in a class somewhere. I happened to put the methods in the FOPropertyMapping class. I'll look at that--I'm currently trying to move the constants over right now. Also, while I used fo:element constants in my experiment, it is clear to me that such an approach does not work well for extension elements. regards, finn Oh no--I hope you don't mean we have to revert to strings for those? Using that logic, property constants wouldn't work either, right? (because extension elements can have different properties). At worst, I hope we can use overloaded functions (constants in some cases, strings in others.) Thanks, Glen __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
DO NOT REPLY [Bug 25272] - [PATCH] FNF thrown formatting test/resources/fop/image/align.fo
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=25272. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272 [PATCH] FNF thrown formatting test/resources/fop/image/align.fo [EMAIL PROTECTED] changed: What|Removed |Added Summary|FNF thrown formatting |[PATCH] FNF thrown |test/resources/fop/image/ali|formatting |gn.fo |test/resources/fop/image/ali ||gn.fo --- Additional Comments From [EMAIL PROTECTED] 2003-12-19 02:04 --- John, Please stop rushing the committers. This is not a trivial task. The problem domain has to be fully explored, then your work vs. what we already have in FOP's Ant Task has to be checked, then we (probably) have to compare your work vs. what is already done by Batik and Xalan to see if anything has been missed. In the meantime, you may wish to redo your code patches: use no tabs, 4 spaces only, and follow the coding conventions, particularily in spacing, given on our web site and based on the Sun guidelines. CurrentSourceManager in particular needs several changes--you should not have sent this to us in its current state. Thanks, Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
Glen Mazza wrote: There's about 10-15 differences between Alt-Design and HEAD (my unresearched guess), and getting us on to INT constants--the no-brainer--removes one of them. Peter hopefully will start to see more of the theory of Alt-Design in HEAD, if not exactly the same implementation (e.g., like Finn, I have a slight preference for a constants interface--Constants.java--that classes can implement, rather than a constants class--PropNames.java.) Joshua Bloch, in an interview about the new features in 1.5, refers to the Constant Interface anti-pattern, and briefly discusses why it's not a good idea. The discussion of Typesafe Enum pattern in association with the new Typesafe enums in 1.5 may be useful in HEAD. Alt.design needs ints because I access everything to do with properties through arrays indexed by the property int constant, but that is probably not an issue in HEAD. http://java.sun.com/features/2003/05/bloch_qa.html Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
