Re: How much work is left before we can release HEAD?
Simon Pepping wrote: snip/ My interest in FOP's layout is mostly theoretical. I cannot get enthousiastic about todo lists, time schedules and time estimates. Thats understandable. I would like to see keep and break properties implemented. They are the raison d'être of the new design. I do not think they can be implemented with the current design, because there is no arbitrator of the page length. The problem should be solved in a manner similar to the way Luca solved the inline layout problem: All possible break points should be returned to a high-level object, probably the Flow LM. This then applies a certain algorithm, keeping lengths and keeps and breaks into account, to determine the best break point. The structure for this procedure must be added to the current design. Oh I thought this was one of the key points that Keiron addressed when he wrote the layout code in HEAD. Sounds like my estimate may be a bit longer then. I am also interested in block stacking constraints. They exercise the ability to relate the layout produced by one LM with the traits of the areas produced by other LMs. Perhaps it can be done using the layout context, perhaps one should navigate the LM tree to gather the required data. Finally I hope it will be possible to make the structure of the layout module simpler. I believe it is the complexity of this module that has hindered progress the most. With my recent change to LMIter I tried to come closer to the semantics of a collection and an iterator, and make it easier to create more iterator objects for the children of an LM without disturbing the state of the one used in getNextBreakPoss. I hope more such changes are possible and will make it easier to understand the layout module. Simplifying the LMIter objects is one way Joerg identified of making layout easier to work on. I do not know if this is a lot of work or not. To me it seems a lot. Perhaps you may argue that this is not required for a 0.3 release. But to me it is rather essential to the new design. Without it we might as well remain with the maintenance layout system. keeps and breaks are essential for a 0.3 release. As you said yourself they are the whole reason the redesign was started in the first place. I'm not sure block stacking constraints are essential. I understand that the new design for renderers has been more successful, and may be a reason to want a release of the development code. This is not a good enough reason for a release. snip/ Chris
Re: How much work is left before we can release HEAD?
On Sep 28, 2004, at 2:08 AM, Chris Bowditch wrote: Simon Pepping wrote: I do not know if this is a lot of work or not. To me it seems a lot. Perhaps you may argue that this is not required for a 0.3 release. But to me it is rather essential to the new design. Without it we might as well remain with the maintenance layout system. keeps and breaks are essential for a 0.3 release. As you said yourself they are the whole reason the redesign was started in the first place. I'm not sure block stacking constraints are essential. IMO, 0.20.5 functionality should be met in a 0.3 release. In my estimation, keeps and breaks are not essential for a 0.3 release as long as keeps work for table-rows (i.e., mimics 0.20.5 functionality), and breaks work the same as 0.20.5 as well. 0.3 should not be a 'step backward'. Web Maestro Clay
Re: How much work is left before we can release HEAD?
Chris, thank you doing this. I think it's important to have a good instrument to determine our progress towards an initial release. I was a bit shocked when I summed up only the points you've marked as high priority: 20 weeks. It got me thinking and running all the example files again that I haven't run since early this year. Some still don't work, some don't work anymore. Some look surprisingly good. To your task list: Do you propose that all listed tasks should be completed prior to an initial release? I think that there is a number of tasks that are not really necessary for an 0.3, ex. floats, writing mode/BIDI, last page. It would be great if we could break down the things that need to be done into milestones. That may make it easier to communicate to the outside world what our progress is. And we would also know where we stand, because that's one of the biggest problem we currently have. Those who currently work on layout, how do you choose your work area? One big problem I currently see is testing properly. We don't have a good set of tests that we can simply run. The example document are all a big mess demonstrating several features at once. Sometimes I don't even understand how it should (!) look. Personally, I'd add one important, high priority task to the list: (Finally) creating a good test/QS environment along with several simple documents each training a single feature. Attached to this task should/could be the Java2D renderer which we can used to easily create comparable bitmaps. I don't believe in MD5 checking of PDF at this stage. That may be good as soon as we're in the maintenance phase again. Every now and then we get asked when there will be a next release. We need to have some kind of answer for them. A good answer may even make some company boss invest into FOP because he sees the end of the tunnel. I think we will never get there if we target the full feature set for the initial release. We can't but break down the whole thing into manageable parts. Food for flamesas usual. On 22.09.2004 16:35:51 Chris Bowditch wrote: Team, I have been trying to work out what is left to do be done before we can do an initial release of HEAD, 0.3, say. I know some of you will prefer to aim for a 1.0 and get everything right first time, but please bear with me. I have consolidated the layout issues from [1] and [2] The infrastructure items listed in [1] I feel are good enough for a 0.3 release. This is largely thanks to work from Glen, Finn, Simon, Luca, Peter, Jeremias and the other committers. Sorry if Ive missed anyone. Anyway, i have created a wiki containing the work items along with my opinion of priority and a finger in the air time estimates: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPWorkEstimates I would very much appreciate some feedback. Chris [1] http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectTasks [2] http://xml.apache.org/fop/design/layout.html#status-todo Jeremias Maerki
How much work is left before we can release HEAD?
Team, I have been trying to work out what is left to do be done before we can do an initial release of HEAD, 0.3, say. I know some of you will prefer to aim for a 1.0 and get everything right first time, but please bear with me. I have consolidated the layout issues from [1] and [2] The infrastructure items listed in [1] I feel are good enough for a 0.3 release. This is largely thanks to work from Glen, Finn, Simon, Luca, Peter, Jeremias and the other committers. Sorry if Ive missed anyone. Anyway, i have created a wiki containing the work items along with my opinion of priority and a finger in the air time estimates: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPWorkEstimates I would very much appreciate some feedback. Chris [1] http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectTasks [2] http://xml.apache.org/fop/design/layout.html#status-todo
Re: FOray 0.1 release
Sorry for the delay. On 16.07.2004 19:00:25 Victor Mote wrote: Jeremias Maerki wrote: Making these parts into separate components is in line with what I have in mind when can talk about a shared repository between Batik and FOP. I hope I can take a good look into Good. I think it has potential to be useful to many applications. what you did later. From a quick look, however, I wasn't very pleased that you propose to use a lot of statics in the FontServer. I would prefer to have the possibility to define multiple configurations in a heavy server environment without having to go through the pains to separate multiple environments using classloader magic. The system fonts are ok like this, of course, but not the user-defined. Just my opinion. I knew this would be controversial, and I'll be glad to consider changes. The use case that you mentioned will, I think, be handled by some of the other planned changes to configuration that are in the works. These changes will be more client-centered than server-centered. So, rather than having multiple servers configured different ways, each client will tell the server more about what it wants, and the server will react based on this. However, I may not see all of what you are thinking about here. If you can be more specific, I'll think through this some more. I'm simply thinking that adding statics is a lot easier than removing them again. I usually create non-static classes and create singletons around them if necessary or convenient. That's basically it. One of the main purposes of FontServer was to share as much of the Font overhead as possible between documents in a heavy server environment, while keeping a light footprint in the code. I actually tried to write it in a non-static way (with you in mind) in the beginning, but it just ended up being silly, at least for the purposes that it is currently designed for. Of course, it makes sense to take the easy way to get quick results. I'm just thinking about the long run. Concerning the PDF library, I suggest you start from the PDF lib in CVS HEAD instead of using the maintenance branch, even if it means that the API may be a bit different. I've invested a considerable amount of time to make the whole thing better. Things such as encryption are much more cleanly solved. First, in relation to FOP 0.20.5 (approximately FOray's starting place), the changes that you are talking about are improvements, and I don't want to be introducing changes or improvements yet. The goal here is really to make sure nothing is broken. Then we can start making improvements, releasing them, and getting user feedback. Valid approach. I'm trying to find ways to bring everyone together in places where consensus may be possible. Second, I *know* that, while in many ways HEAD is superior to the maintenance branch, there are many specific instances where the maintenance branch is superior to HEAD. I also know that there is no convenient list of such items. I have to choose between the two evils of 1) losing benefit(s) in the old code, and 2) losing benefit(s) in the new code. Of the two, I prefer the latter. The user is not going to be happy if I remove his wheels while installing the new, more powerful engine. Better IMO for us to upgrade the engine in a manner that ensures that the wheels stay on. FOP is kind of into the chasm thing, and FOray is definitely not. Right, but would you reconsider (in the long run) if we worked towards seperately released components that could be stabilized and shared between the different implementations? All in the spirit of avoiding duplicate effort where this is possible? Third, what you suggest is much easier said than done. I have made a note to specifically check the encryption stuff when I get a chance. I suppose that we can either diff the code (probably only useful to those who wrote it) or use missing feature hunt. IOW, if we get to the place where we are releasing code again, then, when issues come up on fop-user, hopefully you or someone else will say I already fixed that in HEAD, Oh, I said that a number of times already. ;-) and we can reconcile them. Ideally we want to get to the place where both branches are using the same code. I *think* that is pretty easy for Fonts and Graphics, but, as you say, probably not as easy for PDF, and probably PostScript too. If it's possible for fonts then I'm sure it's possible for PDF and PS. Jeremias Maerki
RE: FOray 0.1 release
Jeremias Maerki wrote: I'm simply thinking that adding statics is a lot easier than removing them again. I usually create non-static classes and create singletons around them if necessary or convenient. That's basically it. One of the main purposes of FontServer was to share as much of the Font overhead as possible between documents in a heavy server environment, while keeping a light footprint in the code. I actually tried to write it in a non-static way (with you in mind) in the beginning, but it just ended up being silly, at least for the purposes that it is currently designed for. Of course, it makes sense to take the easy way to get quick results. I'm just thinking about the long run. I didn't do it for the quick results, but for the lighter, cleaner effect in the client application. Consider the pro-forma FontServer static method someMethod(). Right now, using such a method is simply FontServer.someMethod(). If I convert FontServer to a singleton, I see only two choices: 1. Create a static method getInstance() to return the singleton. To use someMethod(), I now need: FontServer.getInstance().someMethod(). 2. Cache the FontServer instance somewhere in the application client and pass it around. To use someMethod(), I now need: someObject.getFontServer().someMethod(). The only reason I can think of to use a Singleton instead of statics is that I might want to change my mind later allow multiple instances. Since I have been unable to find even a potential use case for multiple instances that isn't covered by better client configuration, I didn't see the need for the extra complexity. However, I am not really opposed to using a singleton, and if it will make folks more comfortable, I'll reimplement it that way. BTW, I was under the impression that you disliked GoF singletons as much as statics. Are you OK with one here? Second, I *know* that, while in many ways HEAD is superior to the maintenance branch, there are many specific instances where the maintenance branch is superior to HEAD. I also know that there is no convenient list of such items. I have to choose between the two evils of 1) losing benefit(s) in the old code, and 2) losing benefit(s) in the new code. Of the two, I prefer the latter. The user is not going to be happy if I remove his wheels while installing the new, more powerful engine. Better IMO for us to upgrade the engine in a manner that ensures that the wheels stay on. FOP is kind of into the chasm thing, and FOray is definitely not. Right, but would you reconsider (in the long run) if we worked towards seperately released components that could be stabilized and shared between the different implementations? All in the spirit of avoiding duplicate effort where this is possible? I understand you to be asking whether I want to create components that can be used by both the maintenance branch and HEAD. The answer is an emphatic YES. And I want all of the features that are in HEAD in those components. The only thing I meant to disagree with was the suggested approach of starting with HEAD as the baseline. IMO the correct approach is to start with the maintenance branch as the baseline and try to add in the code that has been added to HEAD as we are able to identify it and port it. Neither approach is ideal. If I understood the above correctly, then you and I may be in pretty close agreement on this whole approach. And, if you extend it a bit to other parts of FOP, you can see where I was headed with the isolation of FOTree, AreaTree, etc. It should be possible to factor everything out of FOP until you are left with layout, which could be / should be / would be the only difference between the maintenance branch and HEAD. Add in the concept of LayoutStrategy, and you have everything back in one unified line of development. and we can reconcile them. Ideally we want to get to the place where both branches are using the same code. I *think* that is pretty easy for Fonts and Graphics, but, as you say, probably not as easy for PDF, and probably PostScript too. If it's possible for fonts then I'm sure it's possible for PDF and PS. My perception is that *not* many features have been added to fonts and graphics in HEAD, but that many have been for PDF and (possibly) PS. So my thinking is that if we missed a thing or two in fonts and graphics, we'll just deal with it as it comes. But with PDF and PS, we run the risk of losing some large chunks of utility if we don't have either 1) someone familiar with the changes guide the porting, or 2) someone go through some detailed diff work to try to ferret out the changes. I just want to make sure that my insistence in starting with the maintenance branch code instead of HEAD isn't perceived as underestimating the difficulty in that approach. It is ugly -- I just think it is less ugly than the alternatives. Victor Mote
RE: FOray 0.1 release
Chris, Jeremias, and anyone else looking at FOray code: I have created the following branch in FOray's CVS that you will want to use for your evaluation: rel_0_1_branch I have started some other changes in the root that should probably be evaluated separately. I apologize for the inconvenience. I really should have done this from the start. Victor Mote
RE: FOray 0.1 release
Jeremias Maerki wrote: Making these parts into separate components is in line with what I have in mind when can talk about a shared repository between Batik and FOP. I hope I can take a good look into Good. I think it has potential to be useful to many applications. what you did later. From a quick look, however, I wasn't very pleased that you propose to use a lot of statics in the FontServer. I would prefer to have the possibility to define multiple configurations in a heavy server environment without having to go through the pains to separate multiple environments using classloader magic. The system fonts are ok like this, of course, but not the user-defined. Just my opinion. I knew this would be controversial, and I'll be glad to consider changes. The use case that you mentioned will, I think, be handled by some of the other planned changes to configuration that are in the works. These changes will be more client-centered than server-centered. So, rather than having multiple servers configured different ways, each client will tell the server more about what it wants, and the server will react based on this. However, I may not see all of what you are thinking about here. If you can be more specific, I'll think through this some more. One of the main purposes of FontServer was to share as much of the Font overhead as possible between documents in a heavy server environment, while keeping a light footprint in the code. I actually tried to write it in a non-static way (with you in mind) in the beginning, but it just ended up being silly, at least for the purposes that it is currently designed for. Concerning the PDF library, I suggest you start from the PDF lib in CVS HEAD instead of using the maintenance branch, even if it means that the API may be a bit different. I've invested a considerable amount of time to make the whole thing better. Things such as encryption are much more cleanly solved. First, in relation to FOP 0.20.5 (approximately FOray's starting place), the changes that you are talking about are improvements, and I don't want to be introducing changes or improvements yet. The goal here is really to make sure nothing is broken. Then we can start making improvements, releasing them, and getting user feedback. Second, I *know* that, while in many ways HEAD is superior to the maintenance branch, there are many specific instances where the maintenance branch is superior to HEAD. I also know that there is no convenient list of such items. I have to choose between the two evils of 1) losing benefit(s) in the old code, and 2) losing benefit(s) in the new code. Of the two, I prefer the latter. The user is not going to be happy if I remove his wheels while installing the new, more powerful engine. Better IMO for us to upgrade the engine in a manner that ensures that the wheels stay on. FOP is kind of into the chasm thing, and FOray is definitely not. Third, what you suggest is much easier said than done. I have made a note to specifically check the encryption stuff when I get a chance. I suppose that we can either diff the code (probably only useful to those who wrote it) or use missing feature hunt. IOW, if we get to the place where we are releasing code again, then, when issues come up on fop-user, hopefully you or someone else will say I already fixed that in HEAD, and we can reconcile them. Ideally we want to get to the place where both branches are using the same code. I *think* that is pretty easy for Fonts and Graphics, but, as you say, probably not as easy for PDF, and probably PostScript too. Victor Mote
Re: FOray 0.1 release
Making these parts into separate components is in line with what I have in mind when can talk about a shared repository between Batik and FOP. I hope I can take a good look into what you did later. From a quick look, however, I wasn't very pleased that you propose to use a lot of statics in the FontServer. I would prefer to have the possibility to define multiple configurations in a heavy server environment without having to go through the pains to separate multiple environments using classloader magic. The system fonts are ok like this, of course, but not the user-defined. Just my opinion. Concerning the PDF library, I suggest you start from the PDF lib in CVS HEAD instead of using the maintenance branch, even if it means that the API may be a bit different. I've invested a considerable amount of time to make the whole thing better. Things such as encryption are much more cleanly solved. When the XML Graphics project is set up I hope we can soon talk about the details of my ideas. I'd love to have you with us to work on the shared components. On 13.07.2004 22:40:43 Victor Mote wrote: FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. To cleanly get Fonts isolated, I had to isolate PDF, and to isolate PDF, I had to isolate Graphics. So there are actually three FOray modules at the moment (plus Common). Please remember that this release is a no-feature release, but is intended to address architectural issues only. The main purposes of the release are 1) to try to find out whether anything has broken, and 2) to get comments on the general design. Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. Please let me know if there is anything I can do to help. Victor Mote Jeremias Maerki
Re: FOray 0.1 release
Victor Mote wrote: FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Hi Victor: Great that you've managed to create a Font API. Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. Yes, I will gladly take a look at some point over the next few days. snip/ Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. I am clear on FORay's stance with regard to FOP, and I also hope that some of your work can benefit FOP too. Thats why I dont mind evaluating what you've done so far. Chris
FOray 0.1 release
FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. To cleanly get Fonts isolated, I had to isolate PDF, and to isolate PDF, I had to isolate Graphics. So there are actually three FOray modules at the moment (plus Common). Please remember that this release is a no-feature release, but is intended to address architectural issues only. The main purposes of the release are 1) to try to find out whether anything has broken, and 2) to get comments on the general design. Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. Please let me know if there is anything I can do to help. Victor Mote
Re: Is there going to be another release of the 0.20 branch?
Clay Leeds wrote: Thanks for the respectful response. I'm aware that HEAD release is adversely affected by MAINTENANCE work (hence the I don't want to start a ware here, but... :-)), however, I posted this for a few of reasons: 1) fop-dev team might discuss this in light of the possibility of another release and/or RC; 2) aside from the table/memory issues, I wonder what other changes would be included; 3) what PATCHes to fop-0_20_2-maintain were close to completion prior to code-freeze? AFAICT there are no unfinished works lurking for maintenance branch. Progress on FOP development has been slow for well over 12 months now, and if anyone started work on new features for maintenance and left the changes on their hard disk they stayed quiet about it. Then again, even the prospect of reading and/or responding to this thread takes the good fop-dev committing team away from HEAD development, so this'll be my last post on the subject unless further discussion is warranted. Discussion is always a good thing and doesnt distract that much time from possible HEAD development. I didnt mean to imply your suggestion wasnt valid, its certainly worth discussing, but my personal opinion is to focus on HEAD development so we can do a release before the end of 2004. Chris
Re: Is there going to be another release of the 0.20 branch?
J.Pietschmann wrote: Well, we could release the current CVS as 0.20.5.1. The table memory fix is probably important to many users. THere is a slo a minor fix concerning leader expansion there. Okay, but you said yourself that the adjustments you made to tables has probably broken some other things, so we would need to go through a RC, and bug fix cycle. Chris
Re: Is there going to be another release of the 0.20 branch?
I don't want to start a war here, but if ( that's a big if) we're going to go through the hassle of doing an RC, does it make sense to insert any new functionality into FOP, like TIF output? I understand Oleg Tkachenko's work for TIF is complete (or nearly complete), but (like many PATCHes) was excluded due to code-freeze. My company just implemented some systems which use TIF output, and we have to go through hoops (XML/XSL-FO=PostScript and then from Postscript=TIF via GhostScript). It works but is clunky. Since it works, this isn't a make-or-break for me, but is more of a would be nice... I don't know what else there is out there in the way of completed PATCHes for highly desirable benefits that are ready (or almost ready) for prime time. There could certainly be other items we're missing due to the self-imposed code freeze. For me the issue is not so much what other things can we shoe-horn into FOP. It's more of an issue with what features can be added to FOP to make it even more desirable and get more users (and developers) on board. Web Maestro Clay On Jan 7, 2004, at 12:42 AM, Chris Bowditch wrote: J.Pietschmann wrote: Well, we could release the current CVS as 0.20.5.1. The table memory fix is probably important to many users. THere is a slo a minor fix concerning leader expansion there. Okay, but you said yourself that the adjustments you made to tables has probably broken some other things, so we would need to go through a RC, and bug fix cycle. Chris
Re: Is there going to be another release of the 0.20 branch?
Clay Leeds wrote: I don't want to start a war here, but if ( that's a big if) we're going to go through the hassle of doing an RC, does it make sense to insert any new functionality into FOP, like TIF output? I understand Oleg Tkachenko's work for TIF is complete (or nearly complete), but (like many PATCHes) was excluded due to code-freeze. My company just implemented some systems which use TIF output, and we have to go through hoops (XML/XSL-FO=PostScript and then from Postscript=TIF via GhostScript). It works but is clunky. Since it works, this isn't a make-or-break for me, but is more of a would be nice... I understand the desire to add new features like the Tif generator into the maintenance code. However, doing so would mean effort is distracted away from HEAD development. The sooner we can do a release from HEAD then the sooner FOP gets out of the twilight zone. Chris
Re: Is there going to be another release of the 0.20 branch?
On Jan 7, 2004, at 7:46 AM, Chris Bowditch wrote: Clay Leeds wrote: I don't want to start a war here, but if ( that's a big if) we're going to go through the hassle of doing an RC, does it make sense to insert any new functionality into FOP, like TIF output? I understand Oleg Tkachenko's work for TIF is complete (or nearly complete), but (like many PATCHes) was excluded due to code-freeze. My company just implemented some systems which use TIF output, and we have to go through hoops (XML/XSL-FO=PostScript and then from Postscript=TIF via GhostScript). It works but is clunky. Since it works, this isn't a make-or-break for me, but is more of a would be nice... I understand the desire to add new features like the Tif generator into the maintenance code. However, doing so would mean effort is distracted away from HEAD development. The sooner we can do a release from HEAD then the sooner FOP gets out of the twilight zone. Chris Thanks for the respectful response. I'm aware that HEAD release is adversely affected by MAINTENANCE work (hence the I don't want to start a ware here, but... :-)), however, I posted this for a few of reasons: 1) fop-dev team might discuss this in light of the possibility of another release and/or RC; 2) aside from the table/memory issues, I wonder what other changes would be included; 3) what PATCHes to fop-0_20_2-maintain were close to completion prior to code-freeze? Since I'm starting to get up to speed w CVS, I guess I can go and look myself for 2 3. As for #3, I guess part of that would hinge on whether the PATCH developer currently has the time to devote to adjusting the code for 0.20.51 (or whatever it'll be called). In the case of TIF output, I believe the developer wrote it for 0.20.3. Then again, even the prospect of reading and/or responding to this thread takes the good fop-dev committing team away from HEAD development, so this'll be my last post on the subject unless further discussion is warranted. Web Maestro Clay -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
RE: Is there going to be another release of the 0.20 branch?
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] snip / I understand the desire to add new features like the Tif generator into the maintenance code. However, doing so would mean effort is distracted away from HEAD development. The sooner we can do a release from HEAD then the sooner FOP gets out of the twilight zone. I tend to agree with Chris here. Maybe the current CVS code for maintenance could be just built and added to the distributions download page. Then we can put a bit of explanation on the web page for those interested ... but I'd keep the fuss rather minimal for the moment (--but maybe nothing but my lazy alter ego speaking here ;) ) There may be quite some work left on HEAD, but in the last few weeks, I'm getting the impression that things are actually moving forward (cfr. Finn's and Simon's numerous patch proposals to Layout and Properties) Apart from a committer deciding to leave (or, at least, take a step back from) FOP, we have had little or no drawbacks in dev lately, so my guess would be that all is looking quite good (for now) If a vote were being called? Hmmm... tough one... I guess one thing we mustn't forget is that --how long exactly has it been since there was talk about 'the redesigned FOP'? If judged from that side, to release another 'minor update' would be a mistake IMHO. OTOH I have currently too little info (and too much enthousiasm) to make a clear, educated guess about the time it will take to get the current HEAD ready for average use... I would refrain: 0 Clay Leeds wrote: Then again, even the prospect of reading and/or responding to this thread takes the good fop-dev committing team away from HEAD development, so this'll be my last post on the subject unless further discussion is warranted. Maestro, Jus' remember: all recipients who do not want to read, have the choice to ignore your message upon receipt. Good ideas, fella, good ideas are *always* welcome :) Cheers, Andreas
Re: Is there going to be another release of the 0.20 branch?
On Jan 7, 2004, at 12:07 PM, J.Pietschmann wrote: It works for me for generating PDF for quite some time. I get NPE when reloading a FO source in the AWT appilcation, but this maz have other reasons, I didn't try to track it down. As long as I can remember I got NPE when clicking the [Reload] button in AWT while running FOP (w fop-0.20.5 fop-0.20.4). I just took it as fact that this was something we're not supposed to do. Web Maestro Clay
Re: Is there going to be another release of the 0.20 branch?
Chris Bowditch wrote: Thus, I just wanted to know if some sort of 0.20.6 release will be upcoming in the future No, no further releases are planned from the maintenance branch, and all development is focused on CVS Head. Well, we could release the current CVS as 0.20.5.1. The table memory fix is probably important to many users. THere is a slo a minor fix concerning leader expansion there. J.Pietschmann
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
--- Thomas DeWeese [EMAIL PROTECTED] wrote: At least one of the issues is with the PDFGraphics2D. in PDFGraphics2D.java:632 in draw(shape s). There is a check for a newTransform which inexplicably decides that if the new transform is the Identity transform there is no change. IIRC that was because the transform would have no effect. A transform in PDF appends to the current transform rather than setting the transform. Thanks, Thomas, for taking a look at the code for us. Andreas added your comments to the Bugzilla report so they won't be lost. We'll get to these issues (hopefully!) soon. Glen Keiron
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Glen Mazza wrote: I'll leave the 0.20.x branch alone until others complain about this problem, however. There is no problem in the maintenance branch, because it was fixed there (and unfixed, and refixed etc...) ages ago. J.Pietschmann
RE: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Thanks, Tom, for your quick assistance. I didn't know about the AWT threading issue you brought up. Thomas, Can you perhaps have a look at bug 23883? In embedded SVG, something's going wrong with translate() when large numbers are used. Apparently this works fine for svg:text elements, but a polyline gets drawn really ugly... It seems like a very nasty one, and we may need your assistance in tracking this down. The poster mentioned the svg being properly shown in Batik Squiggle, but when the image is rendered to PDF the coordinates of the polyline get all screwed up. I've already had a look at the PDFTranscoder, but type double is being used for the translate itself, so this should pose no problems. I really hope you can shed some more light on this. TIA! Greetz, Andreas
RE: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Thomas, Can you perhaps have a look at bug 23883? In embedded SVG, something's going wrong with translate() when large numbers are used. Apparently this works fine for svg:text elements, but a polyline gets drawn really ugly... Andreas, If you're going to ask for someone's help, please *read* the bug again so you know the latest on the issue. There were changes yesterday that made your description of the problem out-of-date. Also, providing a link to the bug is indicated here--asking Thomas to hunt through Bugzilla in order to help us out--these problems are with our code, not his--is somewhat rude. Furthermore, be careful about dragging users onto the FOP-DEV list. Sometimes it can cause the priority of what we're working on to be skewed to the detriment of the project. Thanks, Glen http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883 Thomas, You needn't bother on this at this time--we have yet to find where Batik is wrong. So far, Squiggle has drawn the SVG correct *all* the time. But comments always welcome, and it's good for you to be aware of the issue. Also, there were changes to the problem yesterday that Andreas apparently didn't read--the problem is basically that the same PDF file (containing certain SVG elements such as polyline) generated by FOP renders fine in Acrobat 6.0 but not in 5.5. Adding to the fun, the user yesterday found other problems where Squiggle runs fine but FOP fails, for *all* Acrobat versions. So this will be an ongoing issue for FOP--also, given the scope of changes needed, perhaps we may be able to make just to our 1.0 branch, the one used by the transcoder. Thanks, Glen __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Good--I was concerned that this was just me having the problem. Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: Glen Mazza wrote: I'll leave the 0.20.x branch alone until others complain about this problem, however. There is no problem in the maintenance branch, because it was fixed there (and unfixed, and refixed etc...) ages ago. J.Pietschmann __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Glen Mazza wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883 Thomas, You needn't bother on this at this time--we have yet to find where Batik is wrong. So far, Squiggle has drawn the SVG correct *all* the time. But comments always welcome, and it's good for you to be aware of the issue. At least one of the issues is with the PDFGraphics2D. in PDFGraphics2D.java:632 in draw(shape s). There is a check for a newTransform which inexplicably decides that if the new transform is the Identity transform there is no change. In the second example posted you can in fact find the 'blue' rectangle as a very small open square in the lower right hand corner of the PDF. Also, there were changes to the problem yesterday that Andreas apparently didn't read--the problem is basically that the same PDF file (containing certain SVG elements such as polyline) generated by FOP renders fine in Acrobat 6.0 but not in 5.5. Don't have a clue on this one (it is possible that the 5.5 engine uses 16.16 math but the 6.0 uses FP?) Adding to the fun, the user yesterday found other problems where Squiggle runs fine but FOP fails, for *all* Acrobat versions. So this will be an ongoing issue for FOP--also, given the scope of changes needed, perhaps we may be able to make just to our 1.0 branch, the one used by the transcoder. I believe the above problem is responsible for the issue with the blue box. Why the text is 'shifted' is still a bit of a mystery to me.
RE: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Also, providing a link to the bug is indicated here--asking Thomas to hunt through Bugzilla in order to help us out--these problems are with our code, not his--is somewhat rude. Ok. I probably supposed that Thomas would be all too familiar with the bugzilla page... Just wanted to contribute a bit, get a few different eyes to look at the initial problem... If it came across somewhat rude: apologies for my brevity. Furthermore, be careful about dragging users onto the FOP-DEV list. Sometimes it can cause the priority of what we're working on to be skewed to the detriment of the project. I'll take this into consideration, certainly. Anyway, Thanks Thomas for your input (which came just rolling in). Greetz, Andreas
Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Team, Using the svg elements within an fo:instream-foreign-object is causing my work computer to having hanging threads (everything works fine at my home computer though). I'm concerned others may be getting this hanging thread problem on their machines. Results of the below FO (work computer): 0.20.5 release: works fine (1-yr. old Batik) 0.20.x nightly: hangs (Batik updated one month ago, due to API changes) 1.0 dev: hangs (Batik version of two weeks ago, also with nightly build) All three still generate a correct PDF document w/SVG, even though the app hangs (I just need to Ctrl-C to end FOP.) Here's the FO: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=simpleA4 page-height=29.7cm page-width=21cm margin-top=2cm margin-bottom=2cm margin-left=2cm margin-right=2cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simpleA4 fo:flow flow-name=xsl-region-body fo:block font-size=16pt font-weight=bold space-after=5mmTest FO w/SVG fo:instream-foreign-object svg:svg width=20 height=20 xml:space=preserve svg:g style=fill:red; stroke:#00 svg:rect x=0 y=0 width=15 height=15/ svg:rect x=5 y=5 width=15 height=15/ /svg:g /svg:svg /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root Running this at work without the svg (i.e., just an empty fo:instream-foreign-object causes this to run fine. As soon as I add any SVG elements in though, the hanging occurs. (1) Will someone please run the above FO on a recent 1.0 build and let me know whether it exits cleanly on your machine? (2) Just before FOP exits (in FOP.java) I put in some debug statements to determine the thread counts: (run without SVG--no hanging): [INFO] 1.0dev index = 0 Thread = Thread[main,5,main] (run with SVG included--hanging): index = 0 Thread = Thread[main,5,main] index = 1 Thread = Thread[AWT-EventQueue-0,6,main] index = 2 Thread = Thread[SunToolkit.PostEventQueue-0,6,main] index = 3 Thread = Thread[AWT-Windows,6,main] index = 4 Thread = Thread[EventQueueMonitor-ComponentEvtDispatch,5,main] index = 5 Thread = Thread[Thread-1,5,main] index = 6 Thread = Thread[Thread-2,5,main] In the (unlikely?) event others are getting hanging threads w/the FO above, looking at the names of the threads above, is the hanging probably occuring with Batik threads or within FOP? I don't believe we're running multithreaded here--but am unsure where the problem is. Thanks, Glen __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Hi Glen, The only thing I find surprising is that the old copies don't hang. It is a well known issue that when you touch AWT the Event Threads start and the only way to close the app is to call System.exit(0). Is it perhaps the case that older copies of FO called System.exit, but someone removed it? (probably because the application terminates cleanly when it doesn't touch SVG and hence AWT) Glen Mazza wrote: Team, Using the svg elements within an fo:instream-foreign-object is causing my work computer to having hanging threads (everything works fine at my home computer though). I'm concerned others may be getting this hanging thread problem on their machines. Results of the below FO (work computer): 0.20.5 release: works fine (1-yr. old Batik) 0.20.x nightly: hangs (Batik updated one month ago, due to API changes) 1.0 dev: hangs (Batik version of two weeks ago, also with nightly build) All three still generate a correct PDF document w/SVG, even though the app hangs (I just need to Ctrl-C to end FOP.) Here's the FO: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=simpleA4 page-height=29.7cm page-width=21cm margin-top=2cm margin-bottom=2cm margin-left=2cm margin-right=2cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simpleA4 fo:flow flow-name=xsl-region-body fo:block font-size=16pt font-weight=bold space-after=5mmTest FO w/SVG fo:instream-foreign-object svg:svg width=20 height=20 xml:space=preserve svg:g style=fill:red; stroke:#00 svg:rect x=0 y=0 width=15 height=15/ svg:rect x=5 y=5 width=15 height=15/ /svg:g /svg:svg /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root Running this at work without the svg (i.e., just an empty fo:instream-foreign-object causes this to run fine. As soon as I add any SVG elements in though, the hanging occurs. (1) Will someone please run the above FO on a recent 1.0 build and let me know whether it exits cleanly on your machine? (2) Just before FOP exits (in FOP.java) I put in some debug statements to determine the thread counts: (run without SVG--no hanging): [INFO] 1.0dev index = 0 Thread = Thread[main,5,main] (run with SVG included--hanging): index = 0 Thread = Thread[main,5,main] index = 1 Thread = Thread[AWT-EventQueue-0,6,main] index = 2 Thread = Thread[SunToolkit.PostEventQueue-0,6,main] index = 3 Thread = Thread[AWT-Windows,6,main] index = 4 Thread = Thread[EventQueueMonitor-ComponentEvtDispatch,5,main] index = 5 Thread = Thread[Thread-1,5,main] index = 6 Thread = Thread[Thread-2,5,main] In the (unlikely?) event others are getting hanging threads w/the FO above, looking at the names of the threads above, is the hanging probably occuring with Batik threads or within FOP? I don't believe we're running multithreaded here--but am unsure where the problem is. Thanks, Glen __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
Thanks, Tom, for your quick assistance. I didn't know about the AWT threading issue you brought up. I went ahead and added explicit System.exit() commands to Fop.java in 1.0. I was somewhat reluctant about this though because others haven't been complaining about this problem, and for some reason my computer at home was just listing these three threads (instead of the seven below) before exiting gracefully: Thread[main,5,main] Thread[Thread-0,5,main] Thread[Java2D Disposer,10,main] I'll leave the 0.20.x branch alone until others complain about this problem, however. Thanks again, Glen --- Thomas DeWeese [EMAIL PROTECTED] wrote: index = 0 Thread = Thread[main,5,main] index = 1 Thread = Thread[AWT-EventQueue-0,6,main] index = 2 Thread = Thread[SunToolkit.PostEventQueue-0,6,main] index = 3 Thread = Thread[AWT-Windows,6,main] index = 4 Thread = Thread[EventQueueMonitor-ComponentEvtDispatch,5,main] index = 5 Thread = Thread[Thread-1,5,main] index = 6 Thread = Thread[Thread-2,5,main] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
RE: 0.20.5 release
Hi Fopers, I can understand your requirements, but I would like to know what memory limit you are looking for and what are the filters you two are talking about. As for me, I have been using FOP for BIG reports (fromm 100 to 2000 pages) with big tables (like you, more than 500 pages long tables). I have used some iText Features to deal with forward reference (see the list archive for more details) and this has been giving me a nice solution. I can produce a 1500 pages doc on a simple machine with 256Mo in a few minutes (yes, it swaps) and we use 1 or 2 Go Ram servers for huge documents. Anyway, we all would welcome some new solution to this problem, but surely you reckon there has been loads of workarounb in this list ? Can you be more specific about the performance threshold you are looking for ? Regards Cyril At 09:02 08/07/2003 +0430, you wrote: Dear Thomas Sporbeck It's good to see someone else is using FOP for big reports. I also using tables for inventory lists near to 600 pages and my user do not accept to use filters. This FOP is killing my user business and if I could not find a solution to it, we would trough away the FOP for good, for ever. Then it would be a shame on FOP open source developers since I would go and buy none open, commercial product. I would really appreciate if you inform me of your ideas. Regards Ali Farahani -Original Message- From: Thomas Sporbeck [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: RE: 0.20.5 release I would agree to Ricardo. We're using tables for inventory lists containing about 500 pages. The memory situation in that reports is really critical and we cannot force the users to set filters. On the other hand: to us it doesn't matter if this enhancement comes with 0.20.5 or with a later version (0.20.5a ?), which has of course to be decided by the developers and will possibly delay refactoring. Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[FW:] RE: 0.20.5 release
Hi, yes, I know there are workarounds. For me it is important to use the XSL:FO-Implementation as standard as possible. At the moment we decided not to work with the sources ourselves for programming-capacity and strategical reasons (for me it makes no sense if a houndred programmers implement the same feature separately). The current pre-release needs about 1 MB RAM per page in our reports - that is indeed no problem if you have a machine with about 256 MB or more and have no other applications loaded while using FOP. But we're using FOP as add-on to some of our applications and the PCs of the users have 128 MByte maximum and we have to tune each machine carefully with the -Xmx Parameter (otherwise FOP seems to hang in some endless loops). If you do this on a stand-alone machine: 32 MB for our reporting engine which produces the .fo-File + 32 MB for Adobe Acrobat or the FOP-Preview + n MB for FOP... If there would be a way to get the same results with about 512 kByte per page, that would be a big advantage. The fact is, that we have to (and customers/users simply do) compare the need of memory to other reporting tools as Crystal Reports or commercial XSL:FO-implementations, which use much less memory and are faster. So if there's a way to implement the suggestions for lean tables without refactoring the whole thing, I'd suppose to do so. It might be a fundamental decision if FOP is a kind of toolbox for developers or if it should be an out of the box-product for nearly everyone - I think there's so much good ideas in it that everyone should be able to use it. Thomas Sporbeck Gesendet am: 08.07.2003 11:34:58 Betreff: RE: 0.20.5 release Hi Fopers, I can understand your requirements, but I would like to know what memory limit you are looking for and what are the filters you two are talking about. As for me, I have been using FOP for BIG reports (fromm 100 to 2000 pages) with big tables (like you, more than 500 pages long tables). I have used some iText Features to deal with forward reference (see the list archive for more details) and this has been giving me a nice solution. I can produce a 1500 pages doc on a simple machine with 256Mo in a few minutes (yes, it swaps) and we use 1 or 2 Go Ram servers for huge documents. Anyway, we all would welcome some new solution to this problem, but surely you reckon there has been loads of workarounb in this list ? Can you be more specific about the performance threshold you are looking for ? Regards Cyril At 09:02 08/07/2003 +0430, you wrote: Dear Thomas Sporbeck It's good to see someone else is using FOP for big reports. I also using tables for inventory lists near to 600 pages and my user do not accept to use filters. This FOP is killing my user business and if I could not find a solution to it, we would trough away the FOP for good, for ever. Then it would be a shame on FOP open source developers since I would go and buy none open, commercial product. I would really appreciate if you inform me of your ideas. Regards Ali Farahani -Original Message- From: Thomas Sporbeck [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: RE: 0.20.5 release I would agree to Ricardo. We're using tables for inventory lists containing about 500 pages. The memory situation in that reports is really critical and we cannot force the users to set filters. On the other hand: to us it doesn't matter if this enhancement comes with 0.20.5 or with a later version (0.20.5a ?), which has of course to be decided by the developers and will possibly delay refactoring. Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
Le Mardi, 8 juil 2003, à 10:14 Europe/Zurich, Thomas Sporbeck a écrit : ...It might be a fundamental decision if FOP is a kind of toolbox for developers or if it should be an out of the box-product for nearly everyone - I think there's so much good ideas in it that everyone should be able to use it I might be wrong, but I think most users of FOP are using it server-side, where resources (especially memory) are more readily available. This might explain your problems, I think little energy has been spent to optimize FOP's memory requirements. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
On Tue, 2003-07-08 at 14:31, Bertrand Delacretaz wrote: I might be wrong, but I think most users of FOP are using it server-side, where resources (especially memory) are more readily I don't know about most users, but I am using FOP client-side since I do not have a server. Felix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
I might be wrong, but I think most users of FOP are using it server-side, where resources (especially memory) are more readily available. This might explain your problems, I think little energy has been spent to optimize FOP's memory requirements. Yes, I agree. But some companies (banking, assurance etc.) have a quite high level of security on their servers - in fact that high that an external administrator has no change to install any piece of software running on a server without some months of testing (and that tests may fail because of a memory lack on the workstations...). Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5 release
ali farahani wrote: It's good to see someone else is using FOP for big reports. I always wonder what poor souls have to sift through this huge amound of paper... ;-) I also using tables for inventory lists near to 600 pages and my user do not accept to use filters. This FOP is killing my user business and if I could not find a solution to it, we would trough away the FOP for good, for ever. Then it would be a shame on FOP open source developers since I would go and buy none open, commercial product. Well, unfortunately my company has tightened my time budget which means I have to do *all* work on FOP in my spare time. However, if you have a critical bug to fix and can come up with a bunch of dollars, I'll gladly take a few days off in order to fix it (for *everyone*). In the case of the excessive memory consumption cased by tables I think I have found a fix which wont break everything else. It will certainly require some amount of testing, which means another release candidate and which is therefore quite unpopular with our release manager. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
Thomas Sporbeck wrote: It might be a fundamental decision if FOP is a kind of toolbox for developers or if it should be an out of the box-product for nearly everyone It is Open Source. If you find issues and create patches, send them in. Every contribution is welcome. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 0.20.5 release
Dear Thomas Sporbeck It's good to see someone else is using FOP for big reports. I also using tables for inventory lists near to 600 pages and my user do not accept to use filters. This FOP is killing my user business and if I could not find a solution to it, we would trough away the FOP for good, for ever. Then it would be a shame on FOP open source developers since I would go and buy none open, commercial product. I would really appreciate if you inform me of your ideas. Regards Ali Farahani -Original Message- From: Thomas Sporbeck [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: RE: 0.20.5 release I would agree to Ricardo. We're using tables for inventory lists containing about 500 pages. The memory situation in that reports is really critical and we cannot force the users to set filters. On the other hand: to us it doesn't matter if this enhancement comes with 0.20.5 or with a later version (0.20.5a ?), which has of course to be decided by the developers and will possibly delay refactoring. Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 0.20.5 release
Hi, Sorry to drop in... Just ignore me if you don't see any relevance. In any case, don't bother answering me. Considering that tables are currently the only mean to control pagination, all my documents have a tendency to include lots of tables (and they all start with a TOC). I believe I'm not alone. I would say that any improvement in the memory usage associated with tables, IMHO, is kind of critical. BTW, there are currently 8 proposed patches in Bugzilla. Most of them look to me quite simple and inoquous, and 4 of them are marked as Enhamcements for version 0.20.5 (there is also an older one for version 0.20.3). It would be nice if one of you guys could take a look at those patches and consider them before issuing the final 0.20.5 release. Congratulations to you all on an excellent job, you are doing, Ricardo Amador -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:16 PM To: [EMAIL PROTECTED] Subject: 0.20.5 release Ok, RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) (and maybe 0.20.5a later if we get more hyphenation patterns back) Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. Comments please! Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 0.20.5 release
I would agree to Ricardo. We're using tables for inventory lists containing about 500 pages. The memory situation in that reports is really critical and we cannot force the users to set filters. On the other hand: to us it doesn't matter if this enhancement comes with 0.20.5 or with a later version (0.20.5a ?), which has of course to be decided by the developers and will possibly delay refactoring. Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
0.20.5 release
Ok, RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) (and maybe 0.20.5a later if we get more hyphenation patterns back) Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. Comments please! Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5 release
On 17.06.2003 19:16:23 Christian Geisert wrote: RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) +1 (and maybe 0.20.5a later if we get more hyphenation patterns back) Don't count on that. :-( Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. Still -0. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 0.20.5 release
Christian Geisert wrote: RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) (and maybe 0.20.5a later if we get more hyphenation patterns back) Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. I'd rather close the book on the maintenance code so that something could be done on HEAD. Take the footnote space problem I analysed yesterday: while I know quite precisely what went wrong (two different approaches to account for footnote space working concurrently) I have no idea what breaks if I attempt a fix. While HEAD has a lot of technical details to fix, the overall approach seams to be much more promising. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[ANNOUNCEMENT] FOP 0.20.5 Release Candidate 2 available
Hi all, the second Release Candidate for 0.20.5 is finally available at http://www.apache.org/dist/xml/fop for downloading and testing. (New download location - please use a mirror if possible) It is planed to make the actual release on on february the 28th if no serious bugs show up. The changes from the previous release candidate includes some bugfixes (marker handling, leader with page-citation, Jimi usage and more) but also the removal of some hyphenation patterns due to licensing reasons. Changes since 0.20.4 include: - Fixed link hotspot positioning - Fixed multi-threading issues - Added autoselecting portrait/landscape on PCL Renderer - Improved AWT Font-measuring/rendering - Perfomance tuning - Added support for CCITT Group 4 encoded TIFF files - Dynamic JAI support - Fixed problem with jpegs with icc profile and acrobat reader 5 - Added a fontBaseDir property - TXTRenderer output encoding - border-spacing support For details see CHANGES file: http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.50 Please send feedback/bugreports to the mailing list or enter them in Bugzilla. Enjoy, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] FOP 0.20.5 Release Candidate 2 available
At 09:08 AM 2/18/2003, you wrote: the second Release Candidate for 0.20.5 is finally available at http://www.apache.org/dist/xml/fop for downloading and testing. (New download location - please use a mirror if possible) Cheers, and congratulations all around. This was a bumpy one (especially for the drivers, I think) ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Changes to maintenance release to support fo:marker
Ok, I worked on the patch. Some notes: Mark C. Allman wrote: These files just have a mayContainMarker() method added: I don't understand the advantage of this. Checks for proper FO structure are flaky anyway. You also canned the check that a marker can be preceded by whitespace. This is actually important. 3. In the searchPage() method I relaxed the search on the current page for the desired marker. Please correct me if I'm wrong, but the spec appears to say the is-first and is-last positional attributes are preferences and not exclusionary. So for example if we can't find a marker that's first but we can find the marker somewhere else on the page then return what we can, not null/not found. I believe that's what the XSLFO spec intends but I could very well be wrong. I left this as is was, because this is what people currently use an nobody complained yet. I'll look at it again if I'm going to implement first-including-carryover and last-ending-within-page. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
+1, but strict bugfixing only, or else we're never going to make it. On 12.02.2003 17:44:14 Christian Geisert wrote: Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Keiron Liddle wrote: This sounds great, but I have one question. We've posted a bug report (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16672) about the SVG rendering in 0.20.4 and 0.20.5. Our SVG's in the rendered PDF document(s) gets clipped. We're now using 0.20.1 and everything is fine there. The PS renderer in 0.20.4 and 0.20.5 also produces a correct rendered SVG. We use FOP at the Swedish Election Authority and consider this to be a big blocker for us, and I assume that's the case for others as well. I haven't seen any activity in this list etc on this bug report and wouldn't it be nice to dig in to this before the final release. Take a look at line 526 of PDFRenderer.java, it clips to the size of the SVG image. Is it possible that part of the SVG goes outside the SVG width and height? Try commenting it out or changing the size of your SVG and seeing if it changes. I'll happily provide the SVG file, XSL etc if this could help. I've been trying to look at the code myself but I'm not really confident with the design and the PDF spec. By the way, thank you for an awesome product ... Christer This is our SVG width and height: svg width=252.836 height=52.828 ... When I added some println() statements to PDFRenderer, both in 0.20.1 and 0.20.4, this i what I got. 0.20.1: w = 252836, h = 52828 0.20.4: w = 252000, h = 52000 The difference between those two, to me, seems to be the way you fetch the SVG size. In 0.20.4 via the BridgeContext and in 0.20.4 via SVGSVGElement. After snooping around a little bit in the Batik sources I found a line with a // FIXME or something like that (I'm at home now and dosen't have the Batik sources here, but I think it was in BridgeContext or one of the instances it uses), where the float values are casted to an int loosing the decimals. Changing the width of the SVG seem to help but this would possible break some of the layout in our reports which are made for the election of the Swedish government. I will try to see if there's an error in the size of our generated SVG files. We use Illustrator to convert from EPS, and then we're tweaking them a bit. Christer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christian Geisert wrote: in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) You right, we are not in a perfect world, anyway +1 -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christian Geisert wrote: Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? +1 Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christer, Christer Sandberg wrote: This is our SVG width and height: svg width=252.836 height=52.828 ... Up to this point, I have no experience with SVG, but I was surprised to see that there is no unit of measurement (cm, mm, pt, px) in the height width. When I added some println() statements to PDFRenderer, both in 0.20.1 and 0.20.4, this i what I got. 0.20.1: w = 252836, h = 52828 0.20.4: w = 252000, h = 52000 Interesting. It rounds down instead of up. The difference between those two, to me, seems to be the way you fetch the SVG size. In 0.20.4 via the BridgeContext and in 0.20.4 via SVGSVGElement. After snooping around a little bit in the Batik sources I found a line with a // FIXME or something like that (I'm at home now and dosen't have the Batik sources here, but I think it was in BridgeContext or one of the instances it uses), where the float values are casted to an int loosing the decimals. Changing the width of the SVG seem to help but this would possible break some of the layout in our reports which are made for the election of the Swedish government. I will try to see if there's an error in the size of our generated SVG files. We use Illustrator to convert from EPS, and then we're tweaking them a bit. Christer Good luck! -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Another release candidate ...
Christian Geisert wrote: So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? +1 Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Another release candidate ...
Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christian Geisert wrote: Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? Christian Is this the proper affirmative response?: +1 -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christian Geisert wrote: So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) +1 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
Christian Geisert wrote: Ok, in a perfect world the 0.20.5 release would have happend last year and we all were working on HEAD now but in reality we're still fixing bugs (which is ok as it will take some time till the first redesign-relase) but nevertheless we should finally finish 0.20.5. So I propose the following plan: Make another RC on february 17th and do the final 0.20.5 release on february the 28th (no delay except for very valid reasons) Comments? Christian This sounds great, but I have one question. We've posted a bug report (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16672) about the SVG rendering in 0.20.4 and 0.20.5. Our SVG's in the rendered PDF document(s) gets clipped. We're now using 0.20.1 and everything is fine there. The PS renderer in 0.20.4 and 0.20.5 also produces a correct rendered SVG. We use FOP at the Swedish Election Authority and consider this to be a big blocker for us, and I assume that's the case for others as well. I haven't seen any activity in this list etc on this bug report and wouldn't it be nice to dig in to this before the final release. I'll happily provide the SVG file, XSL etc if this could help. I've been trying to look at the code myself but I'm not really confident with the design and the PDF spec. By the way, thank you for an awesome product ... Christer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another release candidate ...
This sounds great, but I have one question. We've posted a bug report (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16672) about the SVG rendering in 0.20.4 and 0.20.5. Our SVG's in the rendered PDF document(s) gets clipped. We're now using 0.20.1 and everything is fine there. The PS renderer in 0.20.4 and 0.20.5 also produces a correct rendered SVG. We use FOP at the Swedish Election Authority and consider this to be a big blocker for us, and I assume that's the case for others as well. I haven't seen any activity in this list etc on this bug report and wouldn't it be nice to dig in to this before the final release. Take a look at line 526 of PDFRenderer.java, it clips to the size of the SVG image. Is it possible that part of the SVG goes outside the SVG width and height? Try commenting it out or changing the size of your SVG and seeing if it changes. I'll happily provide the SVG file, XSL etc if this could help. I've been trying to look at the code myself but I'm not really confident with the design and the PDF spec. By the way, thank you for an awesome product ... Christer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Changes to maintenance release to support fo:marker
Christian Geisert wrote: Thanks for contribution but as I'm planing to do the 0.20.5 release tomorrow (really ;-) it's just to late for it. I want to take a closer look at this: 1. We need to keep a list of all pages. If a marker is referenced on a later page we need to be able to retrieve the marker value. We were using the page queue for this but as pages are rendered they're removed from the queue--not good if that removes a page with a marker we'll need later. So I added an ArrayList called pagesList to hold this list. This might need to be optimized to only save markers from previous pages but we also need to know things like page sequence so for now just save the entire page. It is not necessary to store the whole page, we need just the marker list. A page eats *lots* of memory. This is the disadvantage of the current approach (which works perfectly well if you put a fo:page-number-citation ref-id=does-not-exist/ somewhere on the first page where it doesn't screw the layout completely). In order to cater for the retrieving scopes, nested lists have to be used: page-sequence-list +- page-list +- marker-list This structure is preferably built in queuePage(). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Changes to maintenance release to support fo:marker
A page eats *lots* of memory. Thought about that, which is why I mentioned the optimization. It is not necessary to store the whole page, we need just the marker list. We (appear to) need to keep track of the page sequences (as in StreamRenderer.getPreviousPage()), or change how we find markers in past PageSequences, or something. As soon as I wrote it I didn't like saving the entire page. As to getting the change into tomorrow's build: not yet. Test, test, test, ... Besides, my test file generates an extra blank page at the end and I'm working on getting rid of that also. -- Mark C. Allman -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 8:14 PM To: [EMAIL PROTECTED] Subject: Re: Changes to maintenance release to support fo:marker Christian Geisert wrote: Thanks for contribution but as I'm planing to do the 0.20.5 release tomorrow (really ;-) it's just to late for it. I want to take a closer look at this: 1. We need to keep a list of all pages. If a marker is referenced on a later page we need to be able to retrieve the marker value. We were using the page queue for this but as pages are rendered they're removed from the queue--not good if that removes a page with a marker we'll need later. So I added an ArrayList called pagesList to hold this list. This might need to be optimized to only save markers from previous pages but we also need to know things like page sequence so for now just save the entire page. It is not necessary to store the whole page, we need just the marker list. A page eats *lots* of memory. This is the disadvantage of the current approach (which works perfectly well if you put a fo:page-number-citation ref-id=does-not-exist/ somewhere on the first page where it doesn't screw the layout completely). In order to cater for the retrieving scopes, nested lists have to be used: page-sequence-list +- page-list +- marker-list This structure is preferably built in queuePage(). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Release
Miller, Iain wrote:
Hi,
Some thoughts on the problems with leader processing.
[..]
Here's some ideas:
If there's a leader in a line, then make the InlineSpaces non resizable,
and make the WordArea that was generated by the leader resizable (or
expand LeaderArea to cover all leaders, not just the rules).
Thanks for your analysis!
I managed to workaround bug #15936 with making all InlineSpaces non
resizable if a LineArea contains a leader. This renders leader.fo a bit
different (but IMHO barely recognizable).
(ugly hack attached)
I hope someone else will have a look at this, if not I will commit it
and do the release.
Christian
? lib/jimi-1.0.jar
Index: src/org/apache/fop/layout/LineArea.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/layout/Attic/LineArea.java,v
retrieving revision 1.53.2.12
diff -u -r1.53.2.12 LineArea.java
--- src/org/apache/fop/layout/LineArea.java 11 Jan 2003 18:43:04 -
1.53.2.12
+++ src/org/apache/fop/layout/LineArea.java 28 Jan 2003 20:37:29 -
@@ -100,11 +100,17 @@
protected boolean prevOlState = false;
protected boolean prevLTState = false;
+// workaround for bug #15936
+private boolean containsLeader = false;
+
public LineArea(FontState fontState, int lineHeight, int halfLeading,
int allocationWidth, int startIndent, int endIndent,
LineArea prevLineArea) {
super(fontState);
+// workaround for bug #15936
+containsLeader = false;
+
this.currentFontState = fontState;
this.lineHeight = lineHeight;
this.nominalFontSize = fontState.getFontSize();
@@ -574,6 +580,19 @@
int leaderLengthOptimum, int leaderLengthMaximum,
int ruleStyle, int ruleThickness,
int leaderPatternWidth, int leaderAlignment) {
+
+// workaround for bug #15936
+containsLeader = true;
+// make InlineSpaces non-resizeable if Linearea contains a leader
+for (int i = 0; i children.size(); i++ ) {
+Box b = (Box)children.get(i);
+if (b instanceof InlineSpace) {
+InlineSpace space = (InlineSpace)b;
+space.setResizeable(false);
+}
+}
+
+
WordArea leaderPatternArea;
int leaderLength = 0;
char dot = '.';
@@ -1065,6 +1084,13 @@
}
public void addInlineSpace(InlineSpace is, int spaceWidth) {
+
+// workaround for bug #15936
+// make InlineSpaces non-resizeable if Linearea contains a leader
+if (containsLeader) {
+is.setResizeable(false);
+}
+
addChild(is);
finalWidth += spaceWidth;
// spaceWidth = 0;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Release
Christian Geisert wrote: I managed to workaround bug #15936 with making all InlineSpaces non resizable if a LineArea contains a leader. This renders leader.fo a bit different (but IMHO barely recognizable). This is dangerous, because it overflows the line. Actually, the page number is supposed to break to the next line. The correct fix is to defer leader expansion at least until the next word break is found or the text ends, or move leader expansion to align(). While the change is relatively local and largely moving existing code around, it also requires a new inline area class and therefore a bit more work than I could afford currently. I think I'll have some time to spare this weekend and will have an extended look at it. Meanwhile, we could make a rc2. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Release
Title: RE: Release Hi, Firstly apologies for the HTML attached to the end of this message, I think it's something to do with the mail server which I don't have access to. I have asked about it, but I'm going on holiday tomorrow, and haven't got a reply yet. Some thoughts on the problems with leader processing. I have managed to reproduce the problems mentioned in the bug report, and the words actually overlap for me. These thoughts relate to a leader in a contents or index list where leader-pattern=dots, and the enclosing block has text-align-last=justify. When the leader is added to the line area, (src/org/apache/fop/layout/LineArea.java; addLeader), it becomes (in this case) a WordArea of dots, that fills up the rest of the current line. When align (in src/org/apache/fop/layout/LineArea.java) is called, the calculation for padding produces a negative number (due to the line being full). This gets applied to the InlineSpaces, and to the xOffsets in the WordArea, resulting in words overlapping. Here's some ideas: If there's a leader in a line, then make the InlineSpaces non resizable, and make the WordArea that was generated by the leader resizable (or expand LeaderArea to cover all leaders, not just the rules). Also, when the leader is added to the line, it should be set to minimum or optimum length (and then get stretched to size when align is called), so that following objects aren't pushed on to the next line. I would volunteer to do this, but I'm off on holiday tomorrow, and I return on Feb 8. Hope this helps Iain Miller -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 22:11 meep To: [EMAIL PROTECTED] Subject: Re: Release Christian Geisert wrote: Joerg has mentioned bug #15936 as showstopper to me. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936) Actually, I can't reproduce it right now. I'll give it another try tomorrow. J.Pietschmann -- The information contained in this email is confidential and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. Thomson Scientific will accept no responsibility or liability in respect to this email other than to the addressee. If you have received this communication in error, please notify us immediately via email: [EMAIL PROTECTED] --
Release
Ok, we should finally finish 0.20.5 Open issues: Remove xml-apis from Batik (Jeremias?) Joerg has mentioned bug #15936 as showstopper to me. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936) Should we try to fix this? If yes any volunteer? Anything else? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Release
On 20.01.2003 16:33:28 Christian Geisert wrote: Ok, we should finally finish 0.20.5 Open issues: Remove xml-apis from Batik (Jeremias?) done (in branch). Joerg has mentioned bug #15936 as showstopper to me. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936) Should we try to fix this? If yes any volunteer? I probably could do it but not before Wednesday if nobody else wants it. Anything else? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Release
Christian Geisert wrote: Joerg has mentioned bug #15936 as showstopper to me. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936) Actually, I can't reproduce it right now. I'll give it another try tomorrow. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tutorial for 0.20.5 release (was: File size improvements for PS renderer)
Uh, yeah. Almost forgot. I guess I can come up with a first version until Thursday. On 09.01.2003 19:42:31 Christian Geisert wrote: Jeremias Maerki wrote: [..] Christian, when do you plan to release 0.20.5? Seems like no major bugs are around, right? Yes, I'm just waiting for your tutorial ;-) Just kidding ... my plan is in the next days Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] FOP 0.20.5 Release Candidate available
Christian Geisert wrote: - Perfo[r]mance tuning Typo in CHANGES: bug number should read 14013, not 14103 (Cocoon bug)! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[ANNOUNCEMENT] FOP 0.20.5 Release Candidate available
Hi all, the Release Candidate for 0.20.5 is finally available at http://xml.apache.org/dist/fop for downloading and testing. It is planed to make the actual release in about two weeks if no serious bugs show up. Changes since 0.20.4 include: - Fixed link hotspot positioning - Fixed multi-threading issues - Added autoselecting portrait/landscape on PCL Renderer - Improved AWT Font-measuring/rendering - Perfomance tuning - Added support for CCITT Group 4 encoded TIFF files - Dynamic JAI support - Fixed problem with jpegs with icc profile and acrobat reader 5 - Added a fontBaseDir property - TXTRenderer output encoding - border-spacing support For details see CHANGES file: http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.36 Please send feedback/bugreports to the mailing list or enter them in Bugzilla. Needs to be done for the release: - check documentation (new jar versions, classpath etc.) - anything missing in Release Notes/CHANGES ? (apart from fixing my english ;-) Enjoy, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
ready for Release Candidate
Hi all, I've (finally) updated the build process to the new Forrest docs and I'm ready now for doing the Release Candidate. If this is ok for everybody I'll do it later today. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs for maintenance release
Jeremias Maerki wrote: How will we maintain the website after the copy? Change in trunk then copy over to maint branch each time something is changed? Or can we Yes, I'm not sure if automatic merging would work and I don't think there will be a lot of changes. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs for maintenance release
On Thu, 2002-11-28 at 17:33, Christian Geisert wrote: Hi, for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? The track.png in status.html needs a update. How is it done? There is an svg document in docs/xml-docs/data/. Once the svg2png works then we could use it directly. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: docs for maintenance release
Peter B. West wrote: Victor Mote wrote: Christian Geisert wrote: for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? I had a thought left over from our discussion of branching a few weeks ago that might help here. I convinced myself at the time that, when checking out the maintenance branch, using the -f option on a checkout would get the trunk version of any files that aren't on the maintenance branch. I am headed out the door or I would try it right now. I suppose that it is possible that doing so would also check out some files that would break the build or override something that we don't want overridden, but I think it would be worth a try. It should do. However, you will still have to 'cvs add' and 'cvs commit' them on the maintenance branch. Another possibility. especially for directories are not going to be merged back into the HEAD and whose content is largely the same, is to merge them out from HEAD into maint. Actually, there is no need for this. All we want here is a way to get the documentation built for the maintenance release. However, even if we wanted to use this on a regular basis in the maintenance branch, there is no need to branch these files -- they essentially are shared between the trunk and the maintenance branch. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
docs for maintenance release
Hi, for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? The track.png in status.html needs a update. How is it done? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs for maintenance release
How will we maintain the website after the copy? Change in trunk then copy over to maint branch each time something is changed? Or can we somehow keep both documentation parts separate in their branches and copy the stuff together when the website needs an update? On 28.11.2002 17:33:51 Christian Geisert wrote: for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? The track.png in status.html needs a update. How is it done? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: docs for maintenance release
Christian Geisert wrote: for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? I had a thought left over from our discussion of branching a few weeks ago that might help here. I convinced myself at the time that, when checking out the maintenance branch, using the -f option on a checkout would get the trunk version of any files that aren't on the maintenance branch. I am headed out the door or I would try it right now. I suppose that it is possible that doing so would also check out some files that would break the build or override something that we don't want overridden, but I think it would be worth a try. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs for maintenance release
Victor Mote wrote: Christian Geisert wrote: for the documentation for the maintenance release I think the best thing is to copy src/documentation over from trunk and then add a simple exec command=forrest to build.xml Comments? I had a thought left over from our discussion of branching a few weeks ago that might help here. I convinced myself at the time that, when checking out the maintenance branch, using the -f option on a checkout would get the trunk version of any files that aren't on the maintenance branch. I am headed out the door or I would try it right now. I suppose that it is possible that doing so would also check out some files that would break the build or override something that we don't want overridden, but I think it would be worth a try. It should do. However, you will still have to 'cvs add' and 'cvs commit' them on the maintenance branch. Another possibility. especially for directories are not going to be merged back into the HEAD and whose content is largely the same, is to merge them out from HEAD into maint. Not having followed the details of the proposed changes very closely, I would have to look at individual cases. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Jeremias Maerki wrote: It works in my environment. I'd be very grateful if I got feedback if it works for others as well because the changes have quite some impact. Nice feature, works like a charm for me. I believe it should be documented along with baseDir and also example of defining fontBaseDir property in userconfig.xml should be provided (btw, baseDir example in userconfig.xml still marked by NOT IMPLEMENTED note while it works for ages). -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Will do. On Sun, 10 Nov 2002 22:58:19 +0200 Oleg Tkachenko wrote: Jeremias Maerki wrote: It works in my environment. I'd be very grateful if I got feedback if it works for others as well because the changes have quite some impact. Nice feature, works like a charm for me. I believe it should be documented along with baseDir and also example of defining fontBaseDir property in userconfig.xml should be provided (btw, baseDir example in userconfig.xml still marked by NOT IMPLEMENTED note while it works for ages). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
On 08.11.2002 22:34:35 Christian Geisert wrote: [Thanks for the gratulations and now back to FOP (with permission from my wife ;-)] We hope this stays that way. :-) OK, I'm planing to do the following things for the next maintenance release Fix for bug #7587 (color problems with jpeg images and acrobat reader 5, patch seems to work, just needs a little testing) Update the following jars: Batik to 1.5beta4, Xalan to 2.4.1 and Xerces to 2.2.0 Problem with basedir and fonts metrics seems to be fixed (thanks Jeremias) It works in my environment. I'd be very grateful if I got feedback if it works for others as well because the changes have quite some impact. Work through the patch queue. If someone wants to help here please assign the bug to yourself. I'll have another 3 to 4 four days of paid time to work on the maintenance branch next week. I'm still in the process to verify all our stylesheets so we can upgrade from FOP 0.20.3cvs to 0.20.5 soon. I haven't approached the performance tuning patch, and I hope my changes didn't invalidate that patch. I don't know if I will get to it. Apart from eventually applying the patch to the maint branch, I find it important to evaluate the changes for the applicability to the redesign. I'm sure there are parts that can be taken over. Documentation: Copying the new forrest docs from trunk to the maintenance branch (and integrate into the build) sounds like the best approach. The CHANGES files needs to be updated. Best thing would be if everybody documents his own changes, if not I'll try to do it from the cvs-commit messages I'll add my own changes. And, as Oleg already suggested, it would be nice to clean up bugzilla (181 bugs at the moment). Any volunteers? Anybody else (Joerg/Rhett?) working on something with should go into this last maintenance release? I'd appreciate if the release didn't happen before the end of next week so I have time to fix what comes up when verifying my stylesheets. Anything else which should be done? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Christian Geisert wrote: [Thanks for the gratulations and now back to FOP (with permission from my wife ;-)] Welcome to the club :) The CHANGES files needs to be updated. Best thing would be if everybody documents his own changes, if not I'll try to do it from the cvs-commit messages Here are mine: o background properties for all regions + regions precedence support o TXTRenderer output encoding o border-spacing support And, as Oleg already suggested, it would be nice to clean up bugzilla (181 bugs at the moment). Any volunteers? Well, as I suggested it I probably have to take over the task. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Oleg, Thanks for that. I have noticed that there are quite a few people who do respond on dev-user, in addition to yourself and Keiron, which is why I wondered whether Joerg was making a specific request. I eventually concluded he was not. Peter Oleg Tkachenko wrote: Peter B. West wrote: If you haven't already left, which questions did you have in mind? Is it your practise to monitor dev-user for questions which nobody else picks up? Is that the role you want someone else to take over? I believe he had meant exactly that. People on fop-user seem to help ourself pretty good, except for hard or convolute questions and somebody have to answer those (last months me too got a habit to leave such ones to Joerg :) as well as to monitor the list just to keep it in order, but in general I think it's a self-organizing system as any mature mallist. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: plan for 0.20.5 release
I still think it's critical that we put some time into working on the infinite looping that seems to be happening with certain layouts. Yeah...they're often unrenderable, but an infinite loop can mean a restart of Tomcat or jBoss or a similar large server environment. I have a bug related to infinite looping assigned to me, and as soon as I'm done taking the GRE tomorrow (wishes of luck appreciated), I'll have the time to devote to it. By the way, I keep saying this, but I never get a response- I cannot find downloadable CVS snapshots of the maintenance branch on the FOP website, and the 0.20.4 src package didn't have any .java files in it the last time I tried downloading it. I could just be nuts, though. Has anyone noticed this? I can't do CVS checkouts from work. -Original Message- From: Christian Geisert [mailto:christian.geisert;isu-gmbh.de] Sent: Friday, November 08, 2002 4:35 PM To: [EMAIL PROTECTED] Subject: plan for 0.20.5 release [Thanks for the gratulations and now back to FOP (with permission from my wife ;-)] OK, I'm planing to do the following things for the next maintenance release Fix for bug #7587 (color problems with jpeg images and acrobat reader 5, patch seems to work, just needs a little testing) Update the following jars: Batik to 1.5beta4, Xalan to 2.4.1 and Xerces to 2.2.0 Problem with basedir and fonts metrics seems to be fixed (thanks Jeremias) Work through the patch queue. If someone wants to help here please assign the bug to yourself. Documentation: Copying the new forrest docs from trunk to the maintenance branch (and integrate into the build) sounds like the best approach. The CHANGES files needs to be updated. Best thing would be if everybody documents his own changes, if not I'll try to do it from the cvs-commit messages And, as Oleg already suggested, it would be nice to clean up bugzilla (181 bugs at the moment). Any volunteers? Anybody else (Joerg/Rhett?) working on something with should go into this last maintenance release? Anything else which should be done? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Christian Geisert wrote: Anybody else (Joerg/Rhett?) working on something with should go into this last maintenance release? - update ant.jar, with ant-optional.jar (for style task), or do something else. - get rid of buildtools.jar Simply move the hyph taskdef to the target and use the class from the build tree. same for the FOPtask. Delete everything else from the tools dir. I'm on vacancy from tomorrow on for a bit more than three weeks, so I can't do this myself. Who will take care of the unanswered questions while I'm offline? Oleg? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
J.Pietschmann wrote: Christian Geisert wrote: Anybody else (Joerg/Rhett?) working on something with should go into this last maintenance release? - update ant.jar, with ant-optional.jar (for style task), or do something else. Why? Who will take care of the unanswered questions while I'm offline? Oleg? That's why he became a committer ;-) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Rhett Aultman wrote: ... as soon as I'm done taking the GRE tomorrow (wishes of luck appreciated)... Consider them wished. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
Joerg, If you haven't already left, which questions did you have in mind? Is it your practise to monitor dev-user for questions which nobody else picks up? Is that the role you want someone else to take over? Enjoy the holiday. Very sensible of you to stay off-line. Peter J.Pietschmann wrote: I'm on vacancy from tomorrow on for a bit more than three weeks, so I can't do this myself. Who will take care of the unanswered questions while I'm offline? Oleg? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.5 release
J.Pietschmann wrote: I'm on vacancy from tomorrow on for a bit more than three weeks, so I can't do this myself. Who will take care of the unanswered questions while I'm offline? Oleg? Sure. Have a nice time on the vacation! -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release
Christian Geisert wrote: I haven't had much time recently to work on the next (final) maintenance release and will be on holiday the next two weeks (honeymoon ;-) Hearty congratulations! but then we really should get the release out and so I propose the end of the first week of november as target date for the release candidate. Sounds fine. What about ToDo list, some annoying bugs? btw, as it's supposed to be the last maintenance release I think we have to clean up bugzilla, it's 168 opened bugs still in there, many of them I believe obsoleted and hardly solvable, like FOP 0.17 does not work with WebSphere V3.5 OS/390 one. -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Maintenance release
Hi, I haven't had much time recently to work on the next (final) maintenance release and will be on holiday the next two weeks (honeymoon ;-) but then we really should get the release out and so I propose the end of the first week of november as target date for the release candidate. Then maybe two later the actual release and after that we can focus on the redesign Comments? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Maintenance release
That's a fair timetable. I have the GRE on Nov. 9th, but after that will have more time to think clearly (he says knowing full well that after the GRE comes writing the CV, collecting letters of recommendation, and begging for an RA). A failsafe on the infinite layout loop should be done by then. That was my only real goal for maintenance. Felicitations on your matrimony, BTW. -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:24 PM To: [EMAIL PROTECTED] Subject: Maintenance release Hi, I haven't had much time recently to work on the next (final) maintenance release and will be on holiday the next two weeks (honeymoon ;-) but then we really should get the release out and so I propose the end of the first week of november as target date for the release candidate. Then maybe two later the actual release and after that we can focus on the redesign Comments? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release
Hello, Will the maintenance release in the first week of November support the keep-together property ? Thank You! Shaifali Prakash CHT / Media Entertainment San Francisco email: [EMAIL PROTECTED] Christian Geisert christian.geisert@isu-gmbh. To: [EMAIL PROTECTED] de cc: Subject: Maintenance release 10/16/2002 10:24 AM Please respond to fop-dev Hi, I haven't had much time recently to work on the next (final) maintenance release and will be on holiday the next two weeks (honeymoon ;-) but then we really should get the release out and so I propose the end of the first week of november as target date for the release candidate. Then maybe two later the actual release and after that we can focus on the redesign Comments? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release
[EMAIL PROTECTED] wrote: Will the maintenance release in the first week of November support the keep-together property ? Yes, in exactly the same way as the current version (table rows only). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release
I'm sorry, just want to clarify, so, it will support keep-together in table rows, but not in fo blocks right? Shaifali Prakash CHT / Media Entertainment San Francisco email: [EMAIL PROTECTED] J.Pietschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 10/16/2002 12:38 PM Subject: Re: Maintenance release Please respond to fop-dev [EMAIL PROTECTED] wrote: Will the maintenance release in the first week of November support the keep-together property ? Yes, in exactly the same way as the current version (table rows only). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release
Christian Geisert wrote: Hi, I haven't had much time recently to work on the next (final) maintenance release and will be on holiday the next two weeks (honeymoon ;-) Congratulations. The first FOP wedding! but then we really should get the release out and so I propose the end of the first week of november as target date for the release candidate. Does your wife know about this? Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[ANN] FOA new release: 0.4.0
Hi, there is a new FOA release 0.4.0. Here there is a short list of new features/bug fixes: - Absolute Positioning Brick - Page Number Formats and Counting - Added US Page Formats - Fixed bugs for JDK 1.4 - Fixed page/content sequence bugs There is also a list of the currentlu supported FO/Properties: http://foa.sourceforge.net/features.html Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release: improvements to basic-link
Hi all, I haven't seen anything about the next maintenance release for about a week now, but I noticed that there had been some discussion about basic-link problems. In the meantime, I have improved the basic-link positioning and also made it work for external-graphic and foreign-inline-object, since I needed it for a project at work. It now works correctly when links are inside blocks and tables with before and/or after padding and borders; it also works inside list items in tables. The X positioning is corrected. Nothing else seems to be broken. :-) I've also changed the default behavior to make all the words into a single link rectangle; the current behavior can be forced by defining the system property links.merge to no. If there are no objections, I will commit this to the maintenance branch. -Karen J.Pietschmann wrote: Hi all, we should think about getting 0.20.5 out of the door. Yes, I know I'm behind with the doc, I really promise to get it ready this weekend... As for the Bugs to be fixed, what should get in? Choices: SNIP/ 3. Harder stuff - Links for non-text inlines(tried and failed: the link was misplaced, I think I know why but may still need some time) - Links in static content (no idea) SNIP/ J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Memory consumption was: Re: Maintenance release
[EMAIL PROTECTED] wrote: is there a way to clear the image cache in FOP 0.2.0.2? I saw some documentation suggesting a new static method on FopImageFactory org.apache.fop.images.FopImageFactory.clearCache(); has this been implemented in newer versions? Interesting question... looks like this is still on the TODO list (easy to solve though). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
release 0.20.4 - custom fonts broken
Extract from the Changes file : - BaseDir property is now used for loading custom fonts (Bug #7608) (thanks to Arnd Beissner and Brian O'Kelley) Applying this fix broke some stuff as far as I can tell. Fop ships with a config file that has this property commented out. As a result basedir appears to be null and FOP tries loading fonts with something like nullfonts/metrics/arial.xml which of course does not evaluate to a decent filename. Ok after figuring that out I set the basedir to ./ which is in my case correct for loading fonts. Doing this however breaks SVG cause it tries to set the basedir as the url of the SVGElement causing the following exception to be thrown java.net.MalformedURLException: no protocol: ./ at java.net.URL.init(URL.java:473) at java.net.URL.init(URL.java:376) at java.net.URL.init(URL.java:330) at org.apache.fop.svg.SVGElement.layout(Unknown Source) at org.apache.fop.fo.flow.InstreamForeignObject.layout(Unknown Source) at org.apache.fop.fo.flow.BlockContainer.layout(Unknown Source) at org.apache.fop.fo.flow.Flow.layout(Unknown Source) at org.apache.fop.fo.flow.Flow.layout(Unknown Source) at org.apache.fop.fo.pagination.PageSequence.format(Unknown Source) at org.apache.fop.apps.StreamRenderer.render(Unknown Source) at org.apache.fop.fo.FOTreeBuilder.endElement(Unknown Source) snip A better solution to the font loading problem would be something like a system property I think (eg. if you were to define org.apache.fop.fontbasedir and prepend it to the embedded font filename). At least this solution would allow the font base dir to be specified at runtime which is important for embedding. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: plan for 0.20.4 release
Jeremias Maerki schrieb: Hi Christian here is the plan for the 0.20.4 release [..] There is a bug that needs to be fixed IMHO (or to be documented as known issue): - fo:list-item-label at the end of line http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9864 IMHO this is no showstopper bug (what's the the point using text-align=end here?) Of course the example (list.fo) should be updated. As already discussed I'll remove ant, xml-docs, hyph and design-docs from the bin distribution and java-docs from the source distribution. After the release we (Joerg) can start with the forrest integration and then we should think about how we organize the docs (trunk and maintenance branch) Cool, and I will work on Oleg's TIFF renderer among other things. [..] I understand that bringing out the release as soon as possible is important, but the todo list seems to be quite long so I'm not so sure if this weekend is realistic for the release. Other voices? Doing another RC isn't much less work than doing a release. So my vote is to do the release now (i.e. tomorrow) and another maintenance release in the near future. Any other comments? Cheers, Jeremias Märki Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[ANN] New FOA Release: 0.3.0
Hello, there is a new FOA (Formatting Object Authoring tool) release: 0.3.0 Now there are these additional features: - Complex Table Brick (full FO table implementation with Body, Headers and Footers) - Page Number Brick - Multiple Headers/Footers for each Page Sequence - Compliant with the REC for more info: http://foa.sourceforge.net Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
plan for 0.20.4 release
Ok, here is the plan for the 0.20.4 release First there are the following uncommitted patches: - reload functionality for AWT viewer http://marc.theaimsgroup.com/?l=fop-devm=102415975220531w=2 - implementation of margin shorthand http://marc.theaimsgroup.com/?l=fop-devm=102483701915153w=2 - Fix for bug #7587 (color problem with some jpegs) http://marc.theaimsgroup.com/?l=fop-devm=102458916106538w=2 - improvements for Hyphenation http://marc.theaimsgroup.com/?l=fop-userm=102491740229924w=2 The first two patches seem to be non-critical and I will commit those but the latter two *could* cause problems and I'm reluctant to make a release after applying these without some more detailed testing. As already discussed I'll remove ant, xml-docs, hyph and design-docs from the bin distribution and java-docs from the source distribution. After the release we (Joerg) can start with the forrest integration and then we should think about how we organize the docs (trunk and maintenance branch) There are new versions of some of the included jars available (batik beta3, xerces2.0.2) but I don't think we should upgrade now. Comments? I hope to finish the release on saturday (or sunday) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
