Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. Right now I just have to replace AddLMVisitor (and the XXXLayoutManager classes). As far as I understand your proposal, I would have to replace FOElementMapping and subclass the FO tree classes in order to plug in a new set of XXXLayoutManager classes. I'm all for simpler code, as long as it does eliminate too many of the features that I use wink. BTW, thanks again for dropping the HEAD code base from 900 to 600 classes and getting rid of all that autogenerated code. You have definitely made FOP more accessible to the programming masses! Curiously, that was never my goal. I just wanted to reduce the amount of mailing list discussions on the topic of generated code. regards, finn
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
--- Finn Bock [EMAIL PROTECTED] wrote: Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is somewhat more difficult--it's not insurmountable--and compared to the vast complexity of creating a layout subsystem--almost noise level. It will be a few more headaches, but you'll have a better LS in HEAD to base your code off of as a result. Right now I just have to replace AddLMVisitor (and the XXXLayoutManager classes). As far as I understand your proposal, I would have to replace FOElementMapping and subclass the FO tree classes in order to plug in a new set of XXXLayoutManager classes. Yes, but all this is not one-half percent the complexity or difficulty of developing a brand new alternative strategy to begin with (assuming it will take at least 201 days, and one day for these headaches). I'm seeing the increase in patches to FOP that will result in this change as a greater benefit*, because (1) only the severe minority of FOP users create their own layout strategies while the majority benefits from a faster-created 1.0, and (2) more patches give alternative LS people more and better code for them to base their work on, and in some cases may even remove the need to have an alternative LS at all. *You are a good example, because if it's more difficult for you to create an alternative, you'll be more likely to come back to FOP and start making improvements to HEAD's layout strategy! GOOD! (Please do!) I would rather you work on FOP than on a competitor for it. Glen
(partial retreat) Re: Switch from AddLMVisitor to FObj.addLayoutManager()
I have just noticed another issue. For perhaps 5-10 of the FO's, there actually *was* a lot of layout-specific code within the FO's that probably shouldn't have been there. Mostly this was because of the use of anonymous subclasses. (See [1] for an example of what Victor was able to remove--especially note the area-specific import statements that had to be included under the old method.) I agree with Victor--indeed everyone--in its removal from the FO's, at least to this extent, but would rather create new LM classes--subclassing others as appropriate--in the LM package in order to get this logic out. (I'm surprised this wasn't done in the original code, so I may still be missing something here.) When addLayoutManager() is called, have the FO check its internal state to see if it needs an LM, if so, have it choose one and initialize its constructor, but it should stop there--there shouldn't be layout/formatting code within the FO. Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumberCitation.java?r1=1.12r2=1.8diff_format=h --- Glen Mazza [EMAIL PROTECTED] wrote: --- Finn Bock [EMAIL PROTECTED] wrote: Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem.
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
[Glen Mazza] I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. [Glen Mazza] Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is somewhat more difficult--it's not insurmountable--and compared to the vast complexity of creating a layout subsystem--almost noise level. It will be a few more headaches, but you'll have a better LS in HEAD to base your code off of as a result. IMHO the closer integrated FO tree and LM tree classes is a worse starting point. Victor had the right intentions on this. [...]. I'm seeing the increase in patches to FOP that will result in this change as a greater benefit*, because (1) only the severe minority of FOP users create their own layout strategies while the majority benefits from a faster-created 1.0, and (2) more patches give alternative LS people more and better code for them to base their work on, and in some cases may even remove the need to have an alternative LS at all. You seems to assume that the one default layout system in FOP can satisfy all requirements. I doubt that. The default layout system should be good but it shouldn't try solve everything perfectly IMO. Perhaps Jörg disagree wink. *You are a good example, because if it's more difficult for you to create an alternative, you'll be more likely to come back to FOP and start making improvements to HEAD's layout strategy! GOOD! (Please do!) I would rather you work on FOP than on a competitor for it. My alternative layout subsystem isn't an alternative to FOP but an alternative way of implementing the getNextBreakPoss() code. I do not yet know if anything will come of it but it looks quite promising. If it works, I'll post it as a patch for discussion. regards, finn
New XML Apache ( Graphics) logos
I've been playing a bit with The Apache XML Project logo (I wanted a narrower logo for the updated FOP web site), and I've come up with something to look at [1] [2] [3] [4] [5] [6]. I'm still playing with the XML Graphics logo [3] [4] [5] [6]... but it's a start! Part of this is an exercise in hand-coding SVG to suit my/our needs... Pretty neat! I've included JPG versions of these. Also, you can see how the site is progressing as well[7]. Enjoy! Web Maestro Clay [1] Apache XML Project (JPG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml.jpg [2] Apache XML Project (SVG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml.svg [3] Apache XML Graphics Project (JPG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml- graphics_001.jpg [4] Apache XML Graphics Project (SVG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml- graphics_001.svg [5] Apache XML Graphics Project (JPG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml- graphics.jpg [6] Apache XML Graphics Project (SVG) http://homepage.mac.com/webmaestro/xml-fop/images/apache-xml- graphics.svg [7] http://homepage.mac.com/webmaestro/xml-fop/
generating PDFs in non-english
Hello, I was trying to make some PDFs of the PHP manual when I got some problems. The manual is written in docbook and then I have a XSL sheet. I can generate the manual in english, portuguese, french,... but not in russian. When I open the file I only get #. What am I doing wrong? I've tried using FOP directly with XML, and with a FOP file generated by xsltproc, but noone works. Can anybody help me, please? Thanks, Nuno
