DO NOT REPLY [Bug 43917] - Missing Knuth element for border-after on a block followed by a forced break
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43917 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-11-27 00:52 --- Should be fixed by: http://svn.apache.org/viewvc?rev=598558view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40230] - Invalid extra page break creates an undesired empty page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40230. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40230 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-11-27 00:52 --- Should be fixed by: http://svn.apache.org/viewvc?rev=598558view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
The intermediate format and the plan towards FOP 1.0
Dear Foppies, it has come to my attention that not everyone seems to be happy that some of us are looking into a new design for the intermediate format which on first glance only helps those who are doing mass document production. OTOH, these considerations help in a long-term improvement of our rendering infrastructure. Several features are currently not adressed: tagged PDF, z-index, accessibility (role, natural language) etc. But yes, these are mainly side-effects. The main driver is want for speed. No use pretending otherwise. And that doesn't really help towards FOP 1.0. In June 2006, some of you have listed the features they want done before a FOP 1.0: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning What remains is: - integer keep values - changing available IPD between pages (Simon is working on that) - page-number-citation improvements Only the collapsing border model is now there and I think that fo:wrapper is mostly ok now (haven't checked lately). I still consider none of these points a requirement for a 1.0 release, not for a software so widely adopted. A 1.0 is just a signal which is listened for by some but not necessarily for the reasons that caused the above list. But even so, once we're publishing 1.0 I can already hear people saying: what? It took them 9 years to come up with version 1.0? And it still only implements a subset of FO? Whether we implement all of the above features or not, the reaction will be more or less the same. Ok, maybe I'm just venting my frustration again. So, back to business: Is anyone else against Chris, Adrian and I going after a new intermediate format approach in FOP Trunk? If necessary and if it helps, we can do that in a branch. We do have a certain dilemma here: the ideal world looks different than the business world. Of course, we're all trying to pay attention to the long-term goals of the project but at times shorter term issues can become more important to those who are sponsoring my efforts, for example. With the amount of work piling up on my desk from my clients it's sometimes difficult to retain some motivation and energy to do much else for the project. Bigger things anyway. But on the other hand, much of what the sometimes silent sponsors contributed in the background brought FOP where it is today. I think it would make sense if we revised our plan towards FOP 1.0. We should make sure we are all on the same track again. We neglected that a bit in the last 18 months. After all, the project charter says we should have an up-to-date project plan. WDYT? Jeremias Maerki
DO NOT REPLY [Bug 43712] - Collapsed borders on tables in tables not considered to lie half in the before and after margins
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43712. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43712 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-11-27 03:17 --- My bad, the problem was totally unrelated... border-collapse is an inheritable property, so if it is set to separate on an outer table it will also be set to separate on inner tables. I've checked and it works properly. The problem here was due to a bug that I fixed in revision 596727: the height of some elements was counted twice, once in a glue and once in a box. The attached sample looks fine now. Vincent -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: The intermediate format and the plan towards FOP 1.0
On Tuesday 27 November 2007 19:10, Jeremias Maerki wrote: Dear Foppies, deleted most of the post - read the original / If I would be the responsible project manager who is tasked with getting a FOP 1.0 release out with the feature set as described on the wiki I would certainly strongly resist any attempt to do major design changes internally for a benefit outside the stated goal of the project. But, I am not in charge and this is not a project run with a team where the project manager has control over what the developers doing. Basically we largely do as we please and what we do is not driven by a project plan or an agreed agenda but by our own interests, desires and by what some of us get paid for to do. Yes, there is peer review and design discussions, but no control over who does what when. If and when a feature gets implemented, a bug fixed, a piece of documentation written all depends on solely if someone feels like doing it or gets paid to do it. Under these circumstances it is very hard to object to the new intermediate format. Why? On the one hand I rather see effort spend towards stabilization and feature completion aiming for a 1.0 release then a major possibly destabilizing effort towards a non core feature. On the other hand there is no control over what developers spend their efforts on. So how can I object to Jeremias doing this instead of something else? I can't, I won't and it simply doesn't work like this here. So, for the new intermediate format, by all means do it if you get paid for it, but please keep it in a branch until proven stable enough to be merged back into the mainline. WDYT? Jeremias Maerki Manuel
Re: The intermediate format and the plan towards FOP 1.0
Jeremias, Am Dienstag, den 27.11.2007, 11:10 +0100 schrieb Jeremias Maerki: it has come to my attention that not everyone seems to be happy that some of us are looking into a new design for the intermediate format exploring a new design is never a bad idea. Indeed, one of the things I dislike about fop's current design is that a lot of code is duplicated in the different renderers, and if the intermediate format can solve this, then it is another reason to use it. The only thing I am concerned with is fops stability. I use the svn version for everything, and I am happy as long as trunk compiles, and translates my documents correctly. So if you do major changes I'd actually prefer a branch. One thing that should be considered in trying a new design is that no functionality should be removed. This was one of the major drawbacks after the 0.20 - 0.9 rewrite, where at first many things which used to work before stopped working (and stopped me from using fop 0.9 for a long time). So IMO merging back the branch should only be done when all tests run without disabling them. Just my 2 cts. Max signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Property Cache: Null Pointer Exception
On Nov 26, 2007, at 12:48, Chris Bowditch wrote: Hi Chris Andreas L Delmelle wrote: Made yet another attempt to simplify/correct the design a bit (and hopefully fix the leak as well). Thanks for taking the time to revisit this problem :) Although I noticed that the diff appears to be against the previous revision of PropertyCache.java. Sorry, hadn't updated for over a week... :/ snip / Let me know if it works on your end. Bad news I'm afraid I didn't get very far at all with this change. It fails with NPE after about 8 documents! Ouch! I wasn't using the right expression to map from the stale entry's hashCode to the corresponding bucket index. Fixed in the diff in attach (which removes some more obsolete code as well, and adds one more layer of synchronization around the loop where the votes for rehash are counted) Cheers Andreas propcache.diff Description: Binary data
Re: Property Cache: Null Pointer Exception
Andreas L Delmelle wrote: snip/ Sorry, hadn't updated for over a week... :/ No problem. It was easy enough to revert to the previous revision. snip/ Ouch! I wasn't using the right expression to map from the stale entry's hashCode to the corresponding bucket index. Fixed in the diff in attach (which removes some more obsolete code as well, and adds one more layer of synchronization around the loop where the votes for rehash are counted) Bad news I'm afraid. NPE after 25 docs. This time in the while loop condition in cleanSegments: java.lang.NullPointerException at org.apache.fop.fo.properties.PropertyCache.cleanSegment(PropertyCache.java:99) at org.apache.fop.fo.properties.PropertyCache.put(PropertyCache.java:173) at org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:284) at org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:298) at org.apache.fop.fo.properties.FixedLength.getInstance(FixedLength.java:55) at org.apache.fop.fo.expr.PropertyParser.parsePrimaryExpr(PropertyParser.java:297) at org.apache.fop.fo.expr.PropertyParser.parseUnaryExpr(PropertyParser.java:211) at org.apache.fop.fo.expr.PropertyParser.parseMultiplicativeExpr(PropertyParser.java:176) Also, I'm not sure why synchronization is needed if the cleaner threads have been removed? Thanks, Chris
Re: Property Cache: Null Pointer Exception
On Nov 27, 2007, at 18:04, Chris Bowditch wrote: Andreas L Delmelle wrote: snip/ Sorry, hadn't updated for over a week... :/ No problem. It was easy enough to revert to the previous revision. snip/ Ouch! I wasn't using the right expression to map from the stale entry's hashCode to the corresponding bucket index. Fixed in the diff in attach (which removes some more obsolete code as well, and adds one more layer of synchronization around the loop where the votes for rehash are counted) Bad news I'm afraid. NPE after 25 docs. This time in the while loop condition in cleanSegments: Cannot reproduce it here... java.lang.NullPointerException at org.apache.fop.fo.properties.PropertyCache.cleanSegment (PropertyCache.java:99) ... and this line can normally not cause an NPE. Which JVM did you test it on? Do you run multiple concurrent threads, or is it just a plain single-threaded iteration? snip / Also, I'm not sure why synchronization is needed if the cleaner threads have been removed? Because the caches are shared between multiple FOP sessions in the same VM. Cheers Andreas
Re: Page Breaks Inside Tables and border-separation
Hi Jeremias, Jeremias Maerki wrote: You find that surprising? You should be used to that by now. :-) That was ironical. Looks like I still have progress to make in terms of joking in English :-\ I think the spec can be interpreted both ways. Have you checked what other implementations do? If you find only one behaviour, we've missed something. ;-) And what if each implementation does something different? ;-) I’ve sent a request for clarification on xsl-editors@ Thanks, Vincent
DO NOT REPLY [Bug 43974] - top/bottom cell borders are not painted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43974. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43974 --- Additional Comments From [EMAIL PROTECTED] 2007-11-27 10:29 --- Created an attachment (id=21194) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=21194action=view) Demonstrates the lack of borders -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: The intermediate format and the plan towards FOP 1.0
Hi, A long-term improvement of the rendering infrastructure certainly appeals to me. If the effort to obtain better performance in mass document production does not degrade the performance in other use cases, there is no problem to try and implement it in the code. If the effort may destabilize the code for a longer time, a branch would be appropriate. The considerations about our goals are more in the area of resource planning. And I have only my own resources to plan with. Regards, Simon On Tue, Nov 27, 2007 at 11:10:55AM +0100, Jeremias Maerki wrote: Dear Foppies, it has come to my attention that not everyone seems to be happy that some of us are looking into a new design for the intermediate format which on first glance only helps those who are doing mass document production. OTOH, these considerations help in a long-term improvement of our rendering infrastructure. Several features are currently not adressed: tagged PDF, z-index, accessibility (role, natural language) etc. But yes, these are mainly side-effects. The main driver is want for speed. No use pretending otherwise. And that doesn't really help towards FOP 1.0. In June 2006, some of you have listed the features they want done before a FOP 1.0: http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning What remains is: - integer keep values - changing available IPD between pages (Simon is working on that) - page-number-citation improvements Only the collapsing border model is now there and I think that fo:wrapper is mostly ok now (haven't checked lately). I still consider none of these points a requirement for a 1.0 release, not for a software so widely adopted. A 1.0 is just a signal which is listened for by some but not necessarily for the reasons that caused the above list. But even so, once we're publishing 1.0 I can already hear people saying: what? It took them 9 years to come up with version 1.0? And it still only implements a subset of FO? Whether we implement all of the above features or not, the reaction will be more or less the same. Ok, maybe I'm just venting my frustration again. So, back to business: Is anyone else against Chris, Adrian and I going after a new intermediate format approach in FOP Trunk? If necessary and if it helps, we can do that in a branch. We do have a certain dilemma here: the ideal world looks different than the business world. Of course, we're all trying to pay attention to the long-term goals of the project but at times shorter term issues can become more important to those who are sponsoring my efforts, for example. With the amount of work piling up on my desk from my clients it's sometimes difficult to retain some motivation and energy to do much else for the project. Bigger things anyway. But on the other hand, much of what the sometimes silent sponsors contributed in the background brought FOP where it is today. I think it would make sense if we revised our plan towards FOP 1.0. We should make sure we are all on the same track again. We neglected that a bit in the last 18 months. After all, the project charter says we should have an up-to-date project plan. WDYT? Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu
