Re: svn commit: r585167 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/PrintRendererConfigurator.java
Well, that's just the way it is implemented right now (with my fix or without). I know exactly how expensive the operation is. Adrian has done a good job with the new functionality but it's only half the way to the ultimate goal. The whole font system has grown over the years and is now just less than optimal. PrintRendererConfigurator.buildFontListFromConfiguration() is called each time a Renderer is instantiated and configured. That means the whole font list is recreated each time. If we had the FontSource idea/concept in place, this data could be attached to the FopFactory and reused. This way, each Renderer has its own configuration and due to the dynamic registration that is possible with Renderers, it's difficult to attach the gathered information to the FopFactory for later reuse. I don't remember exactly but maybe Adrian actually tried to do something like that with statics and I told him I didn't want statics. Not Adrian's fault at any rate. The only optimization right now is the FontCache which saves us from reparsing all the font files each time. And that's the major part in all that. Still, 60ms on my machine each time for setting up the fonts is a lot. That's currently the price to pay if you want to use auto-detect/. My change really just fixed a bug. That static variable didn't work at all. It would have had to work in concert with something else that kept the gathered information but it didn't, so I removed it. I've stumbled over it while testing SVG painting. I was running multiple SVGs through the PDFTransformer and just couldn't explain why my Verdana text was always painted as Times. When I found that it works the first time, but not afterwards, I retested with XSL-FO and the same problem appeared. The whole font refresh is less of a concern to me. Once we can properly attach the data to the FopFactory it is easy to just forget it there and let FOP recreate it. The problem lies deeper as I hope I was able to show. Jeremias Maerki On 16.10.2007 17:33:17 Chris Bowditch wrote: [EMAIL PROTECTED] wrote: Author: jeremias Date: Tue Oct 16 08:12:45 2007 New Revision: 585167 URL: http://svn.apache.org/viewvc?rev=585167view=rev Log: Bugfix: If auto-detection is enabled, auto-detection didn't get done starting with the second rendering run in the same JVM. Static variables are dangerous! Hi Jeremias, auto detecting the Fonts is a very expensive operation. I'm not sure I want it to happen everytime I create an instance of a Renderer object. The way Adrian implemented it avoided calling this expensive operation each time a Renderer was implemented. The drawback is that if the Fonts are changing on a regular basis on the system then theres no way to tell FOP to refresh its auto-detected Fonts without restarting the JVM. Perhaps we need some sort of method which allows the auto-detected Fonts to be refreshed. Chris
Re: [Xmlgraphics-fop Wiki] Update of TableLayout/KnownProblems by VincentHennebert
Hi, The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems The comment on the change is: Documenting a problem with the merging algorithm for tables I was planning to send a mail to fop-dev but since this is quite technical and requires some drawings to help understanding I thought I’d write a wiki page. The discussion can continue here. Right now I have no solution in mind but I’m hoping to find one. In any case I’m afraid we will have to make choices among the set of layout possibilities, as it may be impossible to code them all in just one Knuth sequence. More on this later, Vincent
DO NOT REPLY [Bug 43405] - fo:table-row not rendered when cells begin with an empty block
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=43405. 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=43405 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-10-17 04:26 --- Hi Pascal, Thanks for reporting the bug. It appears to be fixed in the latest version of the Trunk, probably thanks to revision 584699. Please re-open this bug if you still have issues with real-life documents. Thanks, 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.
DO NOT REPLY [Bug 43633] - table-cell don't render when using number-rows-spanned
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=43633. 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=43633 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Component|pdf |page-master/layout OS/Version|Windows 2000|All Version|0.94|1.0dev --- Additional Comments From [EMAIL PROTECTED] 2007-10-17 08:16 --- Hi Guillaume, Thanks for reporting the bug. Although your test table is a bit odd since it contains an empty row (row 2). You can work around the problem by adding an empty cell in the row that contains the spanning cell: fo:table-cell fo:block/ /fo:table-cell That way you will get the expected result. For devs: at least this test is a showcase for the strange loop in RowPainter.addAreasForCell ;-) Since row 2 is empty (contains no cell ending on this row), no TableContentPosition is created for this row. Thus, in RowPainter.handleTableContentPosition, the first test is never triggered for row 2. So in addAreasAndFlushRow, the yoffset of row 2 is not recorded. And in addAreasForCell, when the offset of the first row spanned by the spanning cell is searched, it's not found so the while loop is triggered and the offset of the previous row is returned instead. As a consequence, the spanning cell, starting on row 2, gets the same offset as cell 1.1, and overrides it. I'll have a look at this later on, since the whole code handling empty/missing cells needs some touch-up anyway. 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.
DO NOT REPLY [Bug 43633] - table-cell don't render when using number-rows-spanned
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=43633. 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=43633 --- Additional Comments From [EMAIL PROTECTED] 2007-10-17 08:20 --- Created an attachment (id=20998) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20998action=view) A minimal file to reproduce the problem -- 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.
