DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
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=36935. 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=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-06 08:03 --- Yes I think the problem is Windows specific. If I can find out more, I'll let you know. -- 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.
white-space collapse across fo:inlines
Not sure if this is another of those areas in the spec which is cause for much confusion but I noticed that FOP trunk collapses white space across fo:inlines. For example (I use a . to represent a white space character): Start.fo:inline.Text./fo:inline.End is rendered as: Start.Text.End However, in 7.15.12 the white-space-collapse property definitions says for true (the default value) and I am rephrasing here(!): A space character is dropped if the immediately preceding flow object is a space character. I would read this as to mean NOT to collapse across the boundaries of a fo:inline (FWIW - neither RenderX nor AntennaHouse seem to collapse across fo:inline boundaries) although it hinges on the interpretation of the term preceding in the context of a tree structure. Manuel
Re: white-space collapse across fo:inlines
What I write next should be consumed with caution and the fact in mind that English is a foreign language to me, because I have big trouble translating 4.2.4. 4.2.4 defines preceding WRT to the area tree, but I really can't parse that section. OTOH, 7.15.12 talks about flow objects, not areas, even though we're in the area generation stage. I didn't find a definition for preceding for the FO tree, BUT! XPath defines the preceding axis so that the space after Start (in your example) is directly preceding the first space inside the inline. So if you ask me, the current behaviour of FOP is correct. D'oh! :-) On 06.10.2005 08:22:32 Manuel Mall wrote: Not sure if this is another of those areas in the spec which is cause for much confusion but I noticed that FOP trunk collapses white space across fo:inlines. For example (I use a . to represent a white space character): Start.fo:inline.Text./fo:inline.End is rendered as: Start.Text.End However, in 7.15.12 the white-space-collapse property definitions says for true (the default value) and I am rephrasing here(!): A space character is dropped if the immediately preceding flow object is a space character. I would read this as to mean NOT to collapse across the boundaries of a fo:inline (FWIW - neither RenderX nor AntennaHouse seem to collapse across fo:inline boundaries) although it hinges on the interpretation of the term preceding in the context of a tree structure. Manuel Jeremias Maerki
Re: Knuth algorithm problem
Jeremias Maerki wrote: I think I've just stumbled over a problem in the Knuth algorithm. I'm going to see what happens ... Regards Luca
Re: white-space collapse across fo:inlines
On Thu, 6 Oct 2005 03:44 pm, Jeremias Maerki wrote: What I write next should be consumed with caution and the fact in mind that English is a foreign language to me, because I have big trouble translating 4.2.4. 4.2.4 defines preceding WRT to the area tree, but I really can't parse that section. OTOH, 7.15.12 talks about flow objects, not areas, even though we're in the area generation stage. I didn't find a definition for preceding for the FO tree, BUT! XPath defines the preceding axis so that the space after Start (in your example) is directly preceding the first space inside the inline. So if you ask me, the current behaviour of FOP is correct. D'oh! :-) Yes - d'h! But my bad - I should have checked the xsl-editors list first. Karen Lease (wasn't she a 'fopper'?) asked the same question years ago and the answers is in: http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004 In summary: preceding only applies to siblings and therefore does not go across inline boundaries. This means we do it wrong at the moment. In XPath language it means we have to use the preceding-sibling axis. On 06.10.2005 08:22:32 Manuel Mall wrote: Not sure if this is another of those areas in the spec which is cause for much confusion but I noticed that FOP trunk collapses white space across fo:inlines. For example (I use a . to represent a white space character): Start.fo:inline.Text./fo:inline.End is rendered as: Start.Text.End However, in 7.15.12 the white-space-collapse property definitions says for true (the default value) and I am rephrasing here(!): A space character is dropped if the immediately preceding flow object is a space character. I would read this as to mean NOT to collapse across the boundaries of a fo:inline (FWIW - neither RenderX nor AntennaHouse seem to collapse across fo:inline boundaries) although it hinges on the interpretation of the term preceding in the context of a tree structure. Manuel Jeremias Maerki Manuel
Re: Sponsorship
On Fri, Sep 30, 2005 at 08:27:45AM +0100, Peter B. West wrote: Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. Do you mean that such a sponsorship changes the relations within the group? It certainly does. I feel that Jeremias has done an admirable job in managing the relations within the group, and in balancing his full time input in FOP with the more limited input of other group members. Simon, I've been stewing on this for quite a while, and as you, at least, seem to have missed the point, I'll vent. Some background. I've been working on the implementation of this cow of a Recommendation since early in 2001, mainly on FOP. In that time, I have had not one red cent of financial support. I'm not the only one in that situation, just the one who has been doing it the longest. Others have had employer support to devote some (or all) of their time to FOP, and Jeremias has for some time been sponsored, whatever that means. (The fact that some get paid to work on open source is not unusual, particularly at Apache. Have a look through the committers on say, Xerces or Xalan, and look for the ibm.com addresses. I could also mention Sun and BEA.) The outside observer of the FOP code base and web site could be excused for thinking that I had never existed on this project. I wrote code for a year before I got committer status, incidentally at the same time as Jeremias and Joerg. The reason it took me so long was that I was not toeing the party line - FOP HEAD. My contributions could not be incrementally added to the existing line of development, so they didn't exist. The only way I got committer status eventually was through the intervention of Nicola Ken Barozzi, who was appalled that forked code was being hosted outside Apache. That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] Does any record of any of this remain on the web site? No. All trace of alt-design has been vigorously scrubbed from the site. A bit thank you to Glen and to Jeremias. Not only does this amount to the re-writing of FOP history, but it was detrimental to the development effort. A number of observations which have been made recently were discussed in detail in the alt-design documentation, notably in respect of space-resolution and footnotes. Rewriting history is a pernicious activity at the best of times. What infuriates me about this exercise is not only its immediately detrimental effects on me, but what I perceive to be its motivation. As to the first, I cannot, for example, point anyone who is interested to the relevant parts of the web site and say, That's what I was doing for the past few years. This is important anyway, but in my case it is more important. I started work on FOP at the beginning of the tech wreck. That hit my home town particularly hard. In addition, my skills were stale. XSL-FO has been my school of Java. The bottom line was that I had almost no work in IT over that period. I lived off savings, I lived off unemployment benefits, I sold liquor at a bottle shop, I was supported by my wife. My efforts on this project, and now Folio, were, and are, critical to my prospects of employment. Jeremias has known my situation for some time. Let me repeat that. When Jeremias went about the complete purging of all traces of my work from the site, he knew my professional situation. You might say that it doesn't matter because I can simply put such things on the Folio site. But of course, the Folio site is not, for some time, at least, going to get the traffic, nor does it have the same weight. Which brings me to the motivation. I don't doubt that Jeremias does not believe in my design ideas. That makes the behaviour even more bizarre. If the ideas are no good, let them stand naked to inspection. No-one will be interested. No, that's not enough. Someone *might* be interested, and Jeremias *might* lose a potential developer to Folio. That is, someone probably working for nothing, might not contribute to FOP. And that would not be in Jeremias' personal financial interest. That's the
Re: white-space collapse across fo:inlines
On Thu, 6 Oct 2005 05:14 pm, Jeremias Maerki wrote: That helps a lot. Thanks for looking it up! Yes, Karen was a Fopper, and a good one. Now, the only thing left is to fix the bug. :-) Its a bug in the inline part of FOP so its probably me or Luca in the moment. snip/ Jeremias Maerki Manuel
Re: Knuth algorithm problem
Thank you so much for looking into it. From the sound of it I would have continued my search for a long time. On 06.10.2005 11:42:19 Luca Furini wrote: Luca Furini wrote: I'm going to see what happens ... I've found the bug! The width, stretch and shrink of the suppressed elements after a break is taken into account in BreakingAlgorithm.addBreaks(), but this method is called only if everythings goes well; in your test there is a restart (as the only created node is too short) and addBreaks() is not called, so the width (and stretch, and shrink) stored in the node is potentially wrong. I'm going to see the best way to fix this without duplicating lines of code. I think the for loop (over the elements that must be ignored) could be moved into createNode() ... In general, the restarting method is quite a critical phase: we are resurrecting a node which was not very good, and maybe not all the information stored inside it is always correct. Regards Luca Jeremias Maerki
Re: Sponsorship
[Peter B. West] ... That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] I did, before I became a committer. Back then I evaluated the different branches (0.20, alt and head) and made a decision on which one to work on. The alt-design property code was, back then, in my eyes, code written by a person who did not intuitively create object oriented design. It was, IMO, not a good fundation for further work. I have then later looked at different times, one where I made a incorrect description of how alt-design stored references from fo-object to properties, an other when I wanted to understand why you though alt-designs Property/PropertyValue was any different from head's PropertyMaker/Property. Does any record of any of this remain on the web site? No. Plagerism? Not a single line from alt-design has ever been committed to head by me! regards, finn
DO NOT REPLY [Bug 36952] New: - FopServlet.java in servlet examples
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=36952. 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=36952 Summary: FopServlet.java in servlet examples Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P4 Component: pdf renderer AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I am getting the error java.lang.NullPointerException at oracle.xml.jaxp.JXTransformer.reportXSLException(JXTransformer.java:776) at oracle.xml.jaxp.JXTransformer.transform(JXTransformer.java:343) at oracle.xml.jaxp.JXTransformerHandler.endDocument (JXTransformerHandler.java:141) at oracle.xml.parser.v2.NonValidatingParser.parseDocument (NonValidatingParser.java:286) at oracle.xml.parser.v2.XMLParser.parse (XMLParser.java:184)at oracle.xml.jaxp.JXXMLFilter.parse (JXXMLFilter.java:96) at org.apache.fop.apps.Driver.render(Driver.java:498) at servlets.printServletFOP.renderXML(printServletFOP.java:170) at servlets.printServletFOP.doGet(printServletFOP.java:114)at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)at com.evermind [Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ResourceFilterChain.doFilter (ResourceFilterChain.java:65) at oracle.security.jazn.oc4j.JAZNFilter.doFilter (Unknown Source)at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.invoke (ServletRequestDispatcher.java:649) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.forwardInternal (ServletRequestDispatcher.java:322) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.processRequest (HttpRequestHandler.java:790) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.run (HttpRequestHandler.java:270) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.run (HttpRequestHandler.java:112) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].util.ReleasableResourcePooledExecutor$MyWorker.run (ReleasableResourcePooledExecutor.java:192) at java.lang.Thread.run (Thread.java:534) while trying to deploy the servlet FopServlet.java in Examples folder -- 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: svn commit: r306656 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BreakingAlgorithm.java PageBreakingAlgorithm.java
Fixing a bug reported by Jeremias affecting the handling of glue and penalty elements after a break when the algorithm restarts. Now it should be ok. A nasty little bug, anyway ... Unfortunately, I had to duplicate a few lines (a for loop looking for glue elements after a feasible break): the point is that there are three different variables (the width, stretch and shrink) that must be modified during this loop. I'm going to see if there is some possible refactoring of this piece of code. Regards Luca
Re: svn commit: r306656 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: BreakingAlgorithm.java PageBreakingAlgorithm.java
Great! Thanks, Luca, it works fine. On 06.10.2005 17:07:01 Luca Furini wrote: Fixing a bug reported by Jeremias affecting the handling of glue and penalty elements after a break when the algorithm restarts. Now it should be ok. A nasty little bug, anyway ... Unfortunately, I had to duplicate a few lines (a for loop looking for glue elements after a feasible break): the point is that there are three different variables (the width, stretch and shrink) that must be modified during this loop. I'm going to see if there is some possible refactoring of this piece of code. Regards Luca Jeremias Maerki
Re: Sponsorship
Finn Bock wrote: [Peter B. West] ... That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] I did, before I became a committer. Back then I evaluated the different branches (0.20, alt and head) and made a decision on which one to work on. The alt-design property code was, back then, in my eyes, code written by a person who did not intuitively create object oriented design. Guilty as charged. My apologies. I'm kind-of old fashioned. I was looking to understand the problem, and solve it, especially the hard parts. For instance, parsing font. That problem was addressed in 2002 in alt-design. When did that make it into FOP? I can't say it was solved, because there may well have been bugs in it at that stage. But the code was there, as it was for a number of other hair-raising properties. I don't know the current situation in detail, but for some long time, alt-design had overall better coverage of properties than the new code. More importantly, it had been thought through. There were gaps, but all of the nasty stuff was covered, and there were no surprises, except for the issue of percentages, which is what sent me in another direction. There were no kludges, waiting for me to confess down the track. Like I said, I'm old-fashioned. When I say something is done, I mean that it is done. If there are areas that need fixing, I'll say so, up front. It was, IMO, not a good fundation for further work. Fair enough, apart from the deferred functionality, but irrelevant. We're talking here about ideas and implementation details. I have then later looked at different times, one where I made a incorrect description of how alt-design stored references from fo-object to properties, an other when I wanted to understand why you though alt-designs Property/PropertyValue was any different from head's PropertyMaker/Property. A discussion I am always willing to have, if only to learn more about your approach. I *do* like pretty code. I asked you about it, because I had plans to adopt it. But I was not persuaded that you had the thorny problems solved, so I held off. When it's completed, I'll look again. Does any record of any of this remain on the web site? No. Plagerism? Not an accusation I'm making, Finn. Not a single line from alt-design has ever been committed to head by me! Not an accusation I'm making. ...whether Finn ever looked... But thanks for the response. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Sponsorship
On Oct 6, 2005, at 1:30 AM, Peter B. West wrote: I've been stewing on this for quite a while, and as you, at least, seem to have missed the point, I'll vent. Sorry to hear that you were stewing about this. I suspect it feels better now that it's out in the open (although I'm not convinced this is the best place for it--it might be, I'm just not convinced...). I don't have a lot of emotion about this either way (although I admit I was sad to see you and Victor Mote curtail your contributions to FOP). Does any record of any of this remain on the web site? No. All trace of alt-design has been vigorously scrubbed from the site. A bit thank you to Glen and to Jeremias. Not only does this amount to the re-writing of FOP history, but it was detrimental to the development effort. A number of observations which have been made recently were discussed in detail in the alt-design documentation, notably in respect of space-resolution and footnotes. Actually there is a mention on the FOP Resources page[1]: - [software] Folio[2] a renderer for XML files containing Formatting Object elements (aka FOP Alt.Design) It may not be much comfort, but it appears that fop/design/alt.design wasn't totally removed[3]. Just the links to it were removed. That was either an oversight on my part (I thought I removed it), or perhaps the content slipped back in when we switched from CVS to SVN. I found it w a google search[4]. In any case, I for one continue to find pleasure in your continued presence on FOP-DEV. I learn a lot about FOP from your POSTs and am still feel sadness that you are no longer a member of the FOP Team (although you still post, which counts, in my book!). If you would like to talk further about this (either continuing this thread or off-line which may be more appropriate), I welcome it. [1] FOP Resources: http://xmlgraphics.apache.org/fop/resources.html#products-other [2] Folio: http://defoe.sourceforge.net/folio [3] alt.design http://xmlgraphics.apache.org/fop/design/alt.design/ [4] Google Search for 'site:xmlgraphics.apache.org alt.design alt-design' http://www.google.com/search? hl=enq=site%3Axmlgraphics.apache.org+alt.design+alt- designbtnG=Google+Search Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: script property
Manuel Mall wrote: What we also need for proper script support is a mapping from Unicode code point to script. On a second thought: isn't this what Class Character.UnicodeBlock does? J.Pietschmann
Re: white-space collapse across fo:inlines
Manuel Mall wrote: Not sure if this is another of those areas in the spec which is cause for much confusion but I noticed that FOP trunk collapses white space across fo:inlines. This isn't the correct behavior, as well as collapsing across a changed text decoration. Unfortunately, this isn't easily understandable from the spec or the errata, IIRC Peter made an inquiry on a w3c list and got a clarification. J.Pietschmann
Re: script property
On Fri, 7 Oct 2005 03:30 am, J.Pietschmann wrote: Manuel Mall wrote: What we also need for proper script support is a mapping from Unicode code point to script. On a second thought: isn't this what Class Character.UnicodeBlock does? Joerg, Thank you - I didn't even know that this class existed. It doesn't quite solve all issues though I think: a) We need a mapping from the ISO 4 letter codes to the Character.UnicodeBlock classes. b) We need a mapping from the Character.UnicodeBlock to script properties (actually at this point in time the only property I am aware off is the default baseline for the script). May be a wrapper around this class to provide that functionality? J.Pietschmann Manuel
