DO NOT REPLY [Bug 32054] New: - Pluggable area creation: AreaFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32054 Pluggable area creation: AreaFactory Summary: Pluggable area creation: AreaFactory Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Creation of area objects was moved from LMs to classes implementing org.apache.fop.area.AreaFactory interface. This interface provides a set of create methods for different types of area objects. Default implementation of this interface is in class called DefaultAreaFactory. Additional changes: + FOUserAgent - getter setter for AreaFactory + AbstractLayoutManager - getAreaFactory() -- convenience method for accesing current area factory in layout manager + Default constructor was added to several area classes
DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32054 Pluggable area creation: AreaFactory --- Additional Comments From [EMAIL PROTECTED] 2004-11-04 11:32 --- Created an attachment (id=13325) AreaFactory patch
Tibor's AreaFactory patch (Re: AreaFactory patch)
--- Finn Bock [EMAIL PROTECTED] wrote: 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 OK, that opinion was what I was trying to get at. Someone else to second Andreas' feelings on the issue. Tibor, you may wish to try again with a Bugzilla patch but incorporate Finn's two suggestions. Also, you were completely correct as to the purpose of FOUserAgent, so if you can have the getAreaFactory() implemented somewhere else outside of that class (LM package, perhaps, or other places) that would a good idea. (FOUserAgent.*set*AreaFactory() is still fine.) Please place it in Bugzilla, and we can have the rest of the team comment on it. I see nothing vetoable myself, so it will be on how others feel. No guarantees, but hopefully another team member (Andreas?) will apply it for you. I, however, will be taking myself out of this issue. If however, you're really fine with just Pluggable LM's, another option is to modify Finn's patch on the issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30500 It's a bit out of date due to other changes in the code (namely, I moved layout code out of the former AddLMVisitor and into new LM classes after this patch was done.) But that would also be helpful for others. Thanks, Glen
AreaFactory patch (once again ;-)
Hello fopsters, so I have finished (and published in bugzilla) the patch which have aroused quite a discussion around here. Just a short description: 1) org.apache.fop.area.AreaFactory - now contains specific create method for each (used) subclass of Area. The generic Area create(FObj, LayoutManager) method was left in the interface to, although its usage in client code is not recommended. - ATM, all the create method have the same argument signature. I think, that this is a place which can undergo changes in future (TextArea creation is a good example). This will be dependent on the amount of work which might be shifted from LMs to AreaFactories... 2) org.apache.fop.area.DefaultAreaFactory - basic implementation; in most cases just default constructor of an area subtype is called 3) FOUserAgent - getAreaFactory()/setAreaFactory() method pair - same as in the example sent before 4) AbstractLayoutManager - I added convenience method getAreaFactory() to this class. So the actual area creation in LMs is usually limited to: curBlockArea = getAreaFactory().createBlock(fobj, this); 5) Default constructors - I changed several Area classes, too. In particular those which have not had a default constructor, yet. So, that's it. Thanks to those who have supported this refactoring. It's in the bugzilla now, so it's up to you what you will do with it. Anyway, please send me any comment you have. I don't say that this is a finished and non-changeable piece of code (such things don't exists in SW development, do they? ;) any further suggestions/correction i am going to implement. Greets, Tibor Vyletel ICQ# 79458455
Re: AreaFactory patch (once again ;-)
--- Tibor Vyletel [EMAIL PROTECTED] wrote: Hello fopsters, so I have finished (and published in bugzilla) the patch which have aroused quite a discussion around here. Just a short description: 1) org.apache.fop.area.AreaFactory - now contains specific create method for each (used) subclass of Area. I like the results of this change in particular. Glen
DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32054 Pluggable area creation: AreaFactory --- Additional Comments From [EMAIL PROTECTED] 2004-11-04 16:47 --- A more complete 'brief' description of this is in this POST to fop-dev: http://marc.theaimsgroup.com/?l=fop-devm=109956963917611w=2
DO NOT REPLY [Bug 32054] - Pluggable area creation: AreaFactory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32054
Pluggable area creation: AreaFactory
--- Additional Comments From [EMAIL PROTECTED] 2004-11-04 20:34 ---
In AbstractLayoutManager:
+protected AreaFactory getAreaFactory() {
+return (userAgent != null) ? userAgent.getAreaFactory() : null;
+}
BTW, we can make AreaFactory a ThreadLocal in AbstractLayoutManager, correct?
That way we can avoid .getAreaFactory() in FOUserAgent, also save the function
call.
I understand we couldn't do ThreadLocal for FOEventHandler (potentially
recursive FO documents within the same process would need a different instances
of FOEventHandler) but this may be a good use-case for ThreadLocal here.
aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor Mote
Re: commenting the Knuth code/centering issue
Glen Mazza wrote: The title centers correctly in 0.20.5, but is left-justified in 1.0. [...] Luca, are you looking at this issue of text alignment in general? Yes, this happens when the text is short and the algorithm is not able to find a set of breaking points: the fallback method can't compute the needed indent, and the text is left-aligned instead of centered. One way to solve this problem is to use, instead of the constant DEFAULT_SPACE_WIDTH, a value computed according to the line width and the maximum acceptable adjustment; this would prevent the algorithm from failing. This value should be computed by the LineLM, and the InlineLMs have to know it. Another way is to use, instead of considerLegalBreak(), a different method to evaluate a possible break point if no breakpoints are found: this alternative method would be much simpler, and would re-create the behaviour of the old getNextBreakPoss method (add content to the existing line if possible, otherwise start another line). I think this could be a much better solution: - it's simpler: it's just another private method in the LineLM - it would solve not only this issue with centered text, but also the other situations in which the Knuth's algorithm fails (for example, when there is a word larger than the line: see Simon's test file id=12494 for bug 29124) I have already done it, so if you agree I could create a patch in a short time. Also, any chance we can get the Knuth classes commented so we have a better idea what KnuthBox, KnuthPenalty, KnuthGlue, etc. are for? Sure, I should have done this before! I'll try and comment these files as soon as possible. Regards, Luca
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
I am impressed by your seemingly boundless dedication to XSL and its related fields. Glen --- Victor Mote [EMAIL PROTECTED] wrote: I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it.
Re: commenting the Knuth code/centering issue
--- Luca Furini [EMAIL PROTECTED] wrote: Another way is to use, instead of considerLegalBreak(), a different method to evaluate a possible break point if no breakpoints are found: this alternative method would be much simpler, and would re-create the behaviour of the old getNextBreakPoss method (add content to the existing line if possible, otherwise start another line). I think this could be a much better solution: - it's simpler: it's just another private method in the LineLM - it would solve not only this issue with centered text, but also the other situations in which the Knuth's algorithm fails (for example, when there is a word larger than the line: see Simon's test file id=12494 for bug 29124) I have already done it, so if you agree I could create a patch in a short time. Please do--this solution sounds great! (BTW, you have write access already, correct?) Also, any chance we can get the Knuth classes commented so we have a better idea what KnuthBox, KnuthPenalty, KnuthGlue, etc. are for? Sure, I should have done this before! I'll try and comment these files as soon as possible. Much appreciated--30 minutes or so of aggressive commenting of the Knuth classes on your part would make a *wonderful* grokkability improvement to this important area of the code. (Please do the commenting in English though, as I'm three generations removed from understanding Italian. ;) [BTW, I'm considering getting that Digital Typography book by Knuth you had mentioned earlier. Do you recommend it? (I was thinking that given all the time I spend on FOP I should start looking a little more at the scientific aspects of this work.)] Thanks, Glen
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor, Thanks, I'll keep an eye on it. I'll drop by the forum as soon as I get a chance. (Busy with Defoe atm) Peter
XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)
On Oct 9, 2004, at 1:30 AM, Jeremias Maerki wrote: snip what=wiki-stuff While we're talking about volunteers, when the resolution passes we will have some work to do, creating a charter, setting up a website for XML Graphics which will link to the two existing websites under XML and a few other things. I intent to do a good part of this but I hope I will get some help. I've placed a temporary xmlgraphics.apache.org site live on my homepage. Please take a look and provide feedback and comments: http://homepage.mac.com/webmaestro/xml-fop/xml-graphics/ A couple of things to note: - this 'site' is only one page and links to current FOP Batik sites - breadcrumb is Javascript, based on path/to/dir/ so it looks funny - I'm open to suggestions! A couple of ideas for enhancement: - tabs for Apache.org xml.apache.org (others?) - links page (although FOP Batik probably have that covered) - PMC page - other xmlgraphics-related pages? Web Maestro Clay -- Clay Leeds - [EMAIL PROTECTED] Webmaster/Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)
Very nice--I like the xmlgraphics logo, and the layout of the text is well done. I think in general having fewer pages but of higher quality is preferable. Glen Clay Leeds wrote: On Oct 9, 2004, at 1:30 AM, Jeremias Maerki wrote: snip what=wiki-stuff While we're talking about volunteers, when the resolution passes we will have some work to do, creating a charter, setting up a website for XML Graphics which will link to the two existing websites under XML and a few other things. I intent to do a good part of this but I hope I will get some help. I've placed a temporary xmlgraphics.apache.org site live on my homepage. Please take a look and provide feedback and comments: http://homepage.mac.com/webmaestro/xml-fop/xml-graphics/
DO NOT REPLY [Bug 5001] - content-width and content-height ignored?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5001 content-width and content-height ignored? --- Additional Comments From [EMAIL PROTECTED] 2004-11-05 07:06 --- We had the same problem. Using width instead of content-width seems to fix the problem...
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor, from the website I don't quite get the scope of the project. That might have to be made clearer. Anyway, I didn't want to talk about it just yet, because it's not ready, but recently I started writing a JAXP-like API for XSL-FO processors (I called in JAFOP for now). It basically implements the ideas we came up with in the API discussion over a year ago. In the next few months I will probably need to integrate several different FO-processors and want to have a common API for all. Especially having a uniform API between FOP maintenance branch and HEAD is important to me because I need to get FOP 0.20.5 set up for PDF output and I will most probably need the RTF output of FOP HEAD quite soon (all in the same VM, of course). Also, the fact that we got 4 OS-FO-processors screams for a common API so they can be used interchangeably. Can it be that we had the same idea at the same time again? :-) Of course, having standardized validation messages and such goes a bit beyond what I imagined, but that's ok. On 04.11.2004 22:58:39 Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Jeremias Maerki
Re: commenting the Knuth code/centering issue
No, I don't think Luca has write access, yet. I know by now that the CLA is recorded but the account hasn't been created, yet, although I've already sent a reminder. On 04.11.2004 23:59:52 Glen Mazza wrote: Please do--this solution sounds great! (BTW, you have write access already, correct?) Jeremias Maerki
