Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml
On Mar 23, 2007, at 13:49, Vincent Hennebert wrote: snip / We would then have two methods of iterating over tables: one fast, memory-efficient relying on columns specifications, Slight addition: ... relying on column specifications or, if those are absent, on cells in the first row. This is enough to support fixed-layout. Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
On Mar 21, 2007, at 22:06, Jeremias Maerki wrote: [Me: ] snip / Seems my proposed fix (bugzilla 41894) goes in the right direction. I agree. Only it does not take reference-orientation and/or writing-mode into account when mapping width/height to ipd/bpd... but that seems to me currently a part of a larger problem. At certain places in the code, nothing but ipd/bpd is used. Then at other places, we get explicit references to width/height. I'm thinking of moving this logic to the fo tree/property side. The layoutengine should work entirely with ipd and bpd, if only to give the /impression/ of consistency... ;-) Agreed, that part is still in need of improvement. Remember the post on fop-users of a user who wanted to rotate the column headings of a table by 90° and had to resort to SVG? That's actually something that IMO, the block-container could and should do. And it's exactly where FOP currently fails to behave. Looking further into this, I can see the difficulties. A region on one page can have a different reference-orientation/ writing-mode than on the preceding or following page, and it's precisely those that form the basis on which the mapping of height/ width should be made. From the point of view of the higher-level LM, the height of an absolute-positioned block-container is the block-progression- dimension if the block-container's reference-orientation and writing- mode are the same(*) as that of the particular region it ends up on. If not, then everything is re-evaluated. height becomes ipd, top becomes after, left may become end... In a certain sense, it even seems that one could say that the specified value for block-progression-dimension may turn out to be what the higher level LM needs to consider as the inline-progression- dimension of the child area. Correct? (*) reference-orientation could also differ by 180 for height/width; for top/right/bottom/left this would make a difference however... Analogous for the writing-mode's difference between lr-tb and rl-tb Cheers, Andreas
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831. 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=41831 --- Additional Comments From [EMAIL PROTECTED] 2007-03-24 04:07 --- Hi Adrian, Had some more time to look into this. I'm currently on a more detailed stroll through your code. Just like to know what I commit, nothing personal. ;-) The change to MacFontFinder is working as it should. In the meantime, if you make any more changes, try to post incremental patches only containing the classes you know for certain were altered since the last diff. I'll do my best to keep up. Here's already a few suggestions for change, but there's no immediate necessity to create a new patch. I've already corrected some things locally, mainly style issues. For the javadocs, we like to have the class-level doc right before the class declaration, after the import header. As you have it, Eclipse collapses them with the license header. :( In WindowsFontFinder, there's that hacky fallback you're commenting on: if shelling out is necessary, then note that 'set windir' will immediately return only the line containing 'windir=', so there's no need to iterate over all environment variables. Still looking further, but these are some things I've already stumbled upon. Stay tuned. Cheers Andreas -- 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: PDF internal links re-implementation - advice sought
Adrian and Jeremias, Thanks for your comments and advice. If you create this link class, you need to make sure it works together with the intermediate format (XMLRenderer and AreaTreeParser), the XML representation of the area tree. OK, will do. At this moment I've overridden renderInlineArea and renderBlock to get the PROD_ID and the current IP and BP positions. With the documents I've rendered so far, this is enough to resolve all the links inlineparent, text, viewport, foreign-object, image can also be targets of internal-destination. InlineParent, Text and Viewport areas pass through renderInlineArea, so they've been taken care of. I'll implement the others as well. Check out inline-level_id.xml and block-level_id.xml in the layout engine tests. If you generate [1] the Area Tree XML (intermediate format) from those file, you'll see where the prod-id can be set. [1] you can also just look in build\test-results\layoutengine after the build. Thanks for the tip, I'll have a look at it. Kind regards, Paul Vinkenoog
Can't commit
Well, I got the junit tests to work (first time, actually, once I fixed the issue with XMLUnit). However, I can't commit my changes. I get the following error message from SVN: svn: MKACTIVITY of '/repos/asf/!svn/act/8cd4ce0b-68b0-9b4f-b65f-2c1a9a53a96f': 403 Forbidden (http://svn.apache.org) I don't know if that means it doesn't like my username and password (though I can change the team page with the same login details) or if there's a conflict with someone else's file. J
Re: Can't commit
On Mar 24, 2007, at 18:44, Jay Bryant wrote: Hi Jay, Well, I got the junit tests to work (first time, actually, once I fixed the issue with XMLUnit). However, I can't commit my changes. I get the following error message from SVN: svn: MKACTIVITY of '/repos/asf/!svn/act/8cd4ce0b-68b0-9b4f- b65f-2c1a9a53a96f': 403 Forbidden (http://svn.apache.org) Weird, not sure if that's the problem, but the URL seems slightly off. Shouldn't it be https://; instead of http://;? I think the latter only allows read-only access. Cheers, Andreas
