Re: AreaFactory patch
Andreas L. Delmelle wrote:
snip/
Hi fellas,
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
hinder that.
All we heard up to here is a few vague concerns about so-called increased
complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
for chrissake! It doesn't bite... or does it? Anyone?
Well, Im not trying to start a fire fight here. And its true that the
requested change is a simple Factory pattern. I agree the concept is simple.
But what I object to is people keep adding loads of pluggable this and
pluggable that to a system whose basics arent yet finished.
So all I am trying to say is lets hold off on pluggable interface A, B and C,
until the basics are finished. I dont think this is a vague arguement.
It may also be worthwhile stepping back from implementations here and consider
what are the business reasons for adding the pluggable LMs? Just because a
newbie on the list says he needs them, he doesnt say why, we have just
accepted that maybe he does. I think we should ask what the business usecase
is? Is it related to XSL-FO in anyway, we dont know. If theres a good business
case, then I wont object. But so far, no business requirements have been stated.
snip/
Chris
RE: AreaFactory patch
Finn Bock wrote: I got some minor suggestions to the patch: - It should be strict typed: createBlock(..), createInline(..) - It should be complete so that all area creation was done through the factory, not just the 3 areas that Tibor needs. Yes. Victor Mote
RE: Exceptions (was: AreaFactory patch)
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Would anyone expect that Defoe would subclass SAXException for document validation errors? If not (it doesn't), why not? Yes, if you use a SAX parser, why not? My point is that at the top-level, no SAXExceptions should be thrown (or a subclass from SAXException) since these could be caught by a higher-level catch-block for SAXExceptions, leading to all sorts of unpleasant surprises or incomprehensible error messages. Could be that the Exception really has its roots in the SAX parser, but FOP/Defoe isn't purely about SAX --FOP just happens to use SAX to parse the XML. There's also at least layout and rendering where errors can occur (esp. if we strive for pluggable layoutmanagers or renderers --could easily lead to misconfigurations that might surface only when the app actually tries to layout/render something, so when the XML parsing is already well under way...) What FOP or Defoe does within the context of their own packag(es) doesn't really matter so long as it's properly documented in the JavaDocs, but for an end-user --whether command-line or embedded-- the error should IMO definitely indicate that the error comes from within FOP/Defoe, which is not the case when you just hand off a SAXException or one of its subclasses. (Same goes for FileNotFoundExceptions... Very tempting to use this for all cases where 'a file cannot be found', but in case we use it in FOP, it should come out wrapped in a FOPException --XSL processors would also report this as i.e. a TransformerException, caused by a lower-level FNFE. Users who know their way in Java would associate an FNFE with particular types of classes and operations that clearly indicate that a reference to a File is created. With FOP or Defoe the creation of these file-references is shielded from the end-users, so it would turn out to be confusing to throw FNFEs at them...) And if someone was inclined to write an FO processor using a DOM front-end, would you expect validation errors to throw subclasses of SAXException? Very, very good point indeed! The answer, of course, is no. Should IMO be at least a form of DOMException. Greetz, Andreas
[GUMP@brutus]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-03112004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-03112004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-03112004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - junit: [javac] Compiling 31 source files to /home/gump/workspaces2/public/workspace/xml-fop/build/test-classes [javac] This version of java does not support the classic compiler; upgrading to modern [javac] /home/gump/workspaces2/public/workspace/xml-fop/test/java/org/apache/fop/util/ASCII85InputStreamTestCase.java:25: warning:
RE: AreaFactory patch
Glen Mazza wrote: I've bought it due to my work with the apps package and removing AddLMVisitor, and how reducing the complexity allowed many other changes in other areas that weren't previously apparent to occur. I also think that many of your later enhancements in properties wouldn't have become obvious if you didn't first get us out of the XSLT-generated properties classes. Even I was able to implement some (minor) property-related API changes as a result of your work in getting rid of the autogenerated code. I know better than to take this bait, but ... 1. The XSLT-generated stuff is a separate issue. Not relevant here at all. 2. It has already been pointed out that, if the Visitor stuff was so terribly complex, there were other solutions that could be applied that didn't sacrifice modularity. Also, it was never intended as a long-term solution, but rather reflected the current state of the layout design, which, after modularization, would have (or could have) changed. 3. Things should be made as simple as they can be, and no simpler. More importantly, there are tradeoffs even within simplicity. Modularization is one aspect of simplicity. It is true that modularization requires the use of interfaces, which add some incremental complexity. But the benefits of having good interfaces and clean separation of concerns reduce complexity much more on a different axis. I have said before that I am glad that Xalan is a separate module from FOP -- that was good thinking. I'm glad that FOP doesn't have to compute disk sectors or lay out pixels on a page -- somebody was smart enough to abstract out operating systems and printer drivers instead. Now, some on this list persist in the let's finish coding the project and then we'll stop and design it line of argument. I have taken it as a settled issue that this is FOP's policy, hence FOray. I won't work on a project that takes that attitude. I unwittingly tried that for about 18 months, lost a year of my life and an incalculable amount of money in both real and opportunity costs. FOP lost a good (IMO) developer and managed to create for itself unnecessary and wasteful competition where none was really needed. What a waste. So here is a promising developer that shows up with an idea. It helps him get his work done, and seems to make for a cleaner design (I haven't looked at it closely, but I haven't heard anybody argue with this). You can tell him (like you did me) we don't need no steeenking clean design. Or you can learn a lesson and try to start developing relationships with the kind of developers that you are going to need to finish this project. Makes no difference to me. But, please, if you choose the former, send that promising developer toward FOray -- I'm almost at the stage where I can drop in the new layout system there. We'll find a place for good design ideas there. Victor Mote
RE: AreaFactory patch
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] Hi Victor, I know better than to take this bait, but ... No matter... +1 for starters It has already been pointed out that, if the Visitor stuff was so terribly complex, there were other solutions that could be applied that didn't sacrifice modularity. snip / To be completely honest, I was a bit disappointed when after a couple of months absence, finally able to check out the sources again, I had to find that the whole Visitor design just got kicked out --before I even had a chance to study it more closely... but that's personal, of course. I didn't understand enough of it to see its particular (dis)advantages. All I want to say: it happens often enough --and not only in SW-development-- that ideas or proposals get turned down because those concerned with the approval don't understand it and/or don't want to make any effort to grasp it. Logic a la: Nah, looks too difficult to *me*. Let *us* not do that. 3. Things should be made as simple as they can be, and no simpler. More importantly, there are tradeoffs even within simplicity. Modularization is one aspect of simplicity. I concur, and as an addition IMO, lately, it seems as if development is focused on 'too much simplicity' --the desire to make FOP work with only a minimum number of classes/interfaces, 'just one' class being ideal from that viewpoint. Fact remains that with all the tasks we want FOP to perform, source code is *never* going to be 'easy-to-follow'. It will always take time before one is able to trace the flow of execution and actually 'see' it at work in the source. Tibor seemed to understand it well enough, so I decided to back his proposal... snip / So here is a promising developer that shows up with an idea. It helps him get his work done, and seems to make for a cleaner design (I haven't looked at it closely, but I haven't heard anybody argue with this). Not only that. The use-case he described doesn't seem at all far-fetched. Imagine FOP/FOray/Defoe having an AWT renderer that displays an editable XSL-FO in one window, the rendered result in the other, and allows for updates/modifications made in the first to be --as fast as reasonably possible-- reflected in the rendered version, without having to render the whole --possibly very large-- document anew every time. Those who are not at least a little curious about this, may now leave :-) Cheers, Andreas
RE: AreaFactory patch
Andreas L. Delmelle wrote: Not only that. The use-case he described doesn't seem at all far-fetched. Imagine FOP/FOray/Defoe having an AWT renderer that displays an editable XSL-FO in one window, the rendered result in the other, and allows for updates/modifications made in the first to be --as fast as reasonably possible-- reflected in the rendered version, without having to render the whole --possibly very large-- document anew every time. Those who are not at least a little curious about this, may now leave :-) Yes. You might be interested in: http://www.foray.org/goals.html#big Victor Mote
RE: AreaFactory patch
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: To be completely honest, I was a bit disappointed when after a couple of months absence, finally able to check out the sources again, I had to find that the whole Visitor design just got kicked out Andreas, we thoroughly discussed the issue for more than a week [1] and you were more than welcome to take part in the discussion. You opted not to. [1] http://marc.theaimsgroup.com/?t=10913138836r=1w=2 --before I even had a chance to study it more closely... You were completely silent for several months, a period several score times long enough for you to study it more closely were you so inclined...Again, you could have checked in with an email or two during the period. I disagree with you that FOP should have ceased all development during the four or five months you were off the list. Open-source doesn't work that way. Glen
RE: AreaFactory patch
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] I disagree with you that FOP should have ceased all development during the four or five months you were off the list. Open-source doesn't work that way. Hmmm... One question: Are you so bent on misinterpreting one's statements? Do you do it on purpose? :-) I have nowhere indicated anything of the above --on the contrary, I have even clearly pointed out it was a personal matter. You're reading too much in what I wrote. Greetz, Andreas
Re: AreaFactory patch
Andreas L. Delmelle schrieb: -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] I disagree with you that FOP should have ceased all development during the four or five months you were off the list. Open-source doesn't work that way. Hmmm... One question: Are you so bent on misinterpreting one's statements? Do you do it on purpose? :-) I have nowhere indicated anything of the above --on the contrary, I have even clearly pointed out it was a personal matter. Personal matter or not, this was the logical conclusion of your complaint about code changes to AddLMVisitor occurring during the several months you were gone. Glen
commenting the Knuth code/centering issue
Luca, Running our embedded.fo example in both FOP 0.20.5 and FOP 1.0 is showing a centering problem for the Embedding SVG title located at the top of the document (this text is located in the fo:block at line 31 of the .fo document.) The title centers correctly in 0.20.5, but is left-justified in 1.0. The problem may be with the new Knuth code in LineLayoutManager.java (lines 283-304). This code, as well as the Knuth classes in layout, are not commented so it is somewhat more difficult to understand where the problem may be. Luca, are you looking at this issue of text alignment in general? Also, any chance we can get the Knuth classes commented so we have a better idea what KnuthBox, KnuthPenalty, KnuthGlue, etc. are for? Thanks, Glen
Re: AreaFactory patch
[Glen] Finn, keep in mind--both you and Simon wanted pluggable LM's, and you even supplied a patch for it a few months ago. But you have been mostly silent on the matter ever since (i.e., it looks like you don't have a need for it ATM.) Or perhaps I've been working on other things, like property optimizations and exceptions. And just maybe I didn't feel that I had to be the one who implemented plugable LMs since I wasn't the one who removed the existing plugability. So sometimes it is good to have things sit in Bugzilla for a couple of months, see if others want it, or what modifications they want, or see if even the original requestor still needs it. Also, Tybor seemed to be fine with using pluggable LM's instead of pluggable Area's--i.e., not even needing them *now*--which would make his desires in sync with yours and Simon's (and mine), as well as keep our layout code in our LM's instead of moving to the Area objects. Do you still see a need then for *both* pluggable LM's and pluggable Areas in our code then? I didn't find that realistic, as I am uncertain of the additional power that it offers, but am asking your opinion here. I only see a need for plugable LMs, but the AreaFactory patch is so small that I see no problem with throwing a bone to Tibor. regards, finn
