Re: Characters and area traits
[Manuel] I am currently looking at adding the missing background and border/padding support to fo:character and have run into a co-ordinate system issue. In fop text areas and character areas are positioned in the bpd direction using the offset attribute which refers to the character baseline position. However, border/padding and backgrounds are positioned everywhere relative to the top left (or should I say before/start) corner of the area rectangle. However, in the renderer based on the area traits (for a text or character area) I cannot easily determine the before edge position of the rectangle based on the baseline offset unless I go to the font and ask for its ascender size etc.. But that is really stuff for the layout system. I see two options: a) We can wrap the character area into an inlineParent area and put the background/border/padding for the character on the inlineParent. b) We add another attribute to the generic fop area being the baseline offset called lead. The meaning of the attributes is then that offset refers to the distance between the before edge of the parent area to the before edge of the area to be rendered and lead is the distance from the before edge to the baseline for character placement. Perhaps I misunderstand, but I think it would be better if we defined an dominant-baseline on the inlines (or even better dominant-baseline-identifier on inline and actual-baseline-table on the fonts) and a baseline-start-point on the linearea. The semantics of these traits are as described in [4.2.6] and [4.5]. Together with bpd, I think that would be enough to find the rest of the different rectangles. I guess it is the same as your suggestion b), but I would rather stick with the terms used in the spec. regards, finn
Sub and super scripts
What is the correct amount of baseline shift to apply for sub and super scripts? Batik seems to use +/- 0.5 * ascender height. Is that the common way of doing it? The spec says only: The offset ... is determined using the font data for the nominal font. Thanks Manuel
DO NOT REPLY [Bug 36677] - [PATCH] ant dist does not include serializer.jar
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=36677. 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=36677 [EMAIL PROTECTED] changed: What|Removed |Added CC||fop- ||[EMAIL PROTECTED] Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 09:25 --- I'm already looking at build dist to include the docs ... -- 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. You are on the CC list for the bug, or are watching someone who is.
Re: Characters and area traits
On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote: [Manuel] I am currently looking at adding the missing background and border/padding support to fo:character and have run into a co-ordinate system issue. In fop text areas and character areas are positioned in the bpd direction using the offset attribute which refers to the character baseline position. However, border/padding and backgrounds are positioned everywhere relative to the top left (or should I say before/start) corner of the area rectangle. However, in the renderer based on the area traits (for a text or character area) I cannot easily determine the before edge position of the rectangle based on the baseline offset unless I go to the font and ask for its ascender size etc.. But that is really stuff for the layout system. I see two options: a) We can wrap the character area into an inlineParent area and put the background/border/padding for the character on the inlineParent. b) We add another attribute to the generic fop area being the baseline offset called lead. The meaning of the attributes is then that offset refers to the distance between the before edge of the parent area to the before edge of the area to be rendered and lead is the distance from the before edge to the baseline for character placement. Perhaps I misunderstand, but I think it would be better if we defined an dominant-baseline on the inlines (or even better dominant-baseline-identifier on inline and actual-baseline-table on the fonts) and a baseline-start-point on the linearea. The semantics of these traits are as described in [4.2.6] and [4.5]. Finn, you understood me correctly and your suggestions to align our naming with the spec make sense. However, the fop area tree is really an interface to the fop renderers and not an exact implementation of the XSl-FO area tree. For example at the moment it seems layout is assumed to take care of all the baseline calculations and the renderers are only told the position of THE baseline for the glyphs of the font they are suppose to render. There seems to be no need for the renderers to be aware of different baselines, baseline tables, etc. as layout resolved all that into a single vertical (I am still thinking in terms of lr-tb scripts) position for each sequence of characters to be rendered. So we may have to introduce the concepts you suggest like actual-baseline-table, dominant-baseline, ... to the fop Layout Managers so they can do their job properly with respect to all this baseline stuff but I am not so sure we need it in the area tree (= interface to the renderers). Together with bpd, I think that would be enough to find the rest of the different rectangles. I guess it is the same as your suggestion b), but I would rather stick with the terms used in the spec. regards, finn Cheers Manuel
Re: Sub and super scripts
It's probably easiest for now to do as Batik does. However, Type 1 fonts provide information about sub and super scripts (size and placement) in the PFM file. That data is currently not parsed. I assume there's something similar in TrueType. So ideally, the font would supply the information how exactly to handle super/sub script. But keeping it simple for now will certainly not hurt. On 16.09.2005 09:08:24 Manuel Mall wrote: What is the correct amount of baseline shift to apply for sub and super scripts? Batik seems to use +/- 0.5 * ascender height. Is that the common way of doing it? The spec says only: The offset ... is determined using the font data for the nominal font. Thanks Manuel Jeremias Maerki
Re: Sub and super scripts
Vincent, does FOray font expose this type of information Jeremias described below? Manuel On Fri, 16 Sep 2005 03:36 pm, Jeremias Maerki wrote: It's probably easiest for now to do as Batik does. However, Type 1 fonts provide information about sub and super scripts (size and placement) in the PFM file. That data is currently not parsed. I assume there's something similar in TrueType. So ideally, the font would supply the information how exactly to handle super/sub script. But keeping it simple for now will certainly not hurt. On 16.09.2005 09:08:24 Manuel Mall wrote: What is the correct amount of baseline shift to apply for sub and super scripts? Batik seems to use +/- 0.5 * ascender height. Is that the common way of doing it? The spec says only: The offset ... is determined using the font data for the nominal font. Thanks Manuel Jeremias Maerki
Re: Sub and super scripts
AFAICS, no, it doesn't do that, yet. On 16.09.2005 09:39:55 Manuel Mall wrote: Vincent, does FOray font expose this type of information Jeremias described below? Manuel On Fri, 16 Sep 2005 03:36 pm, Jeremias Maerki wrote: It's probably easiest for now to do as Batik does. However, Type 1 fonts provide information about sub and super scripts (size and placement) in the PFM file. That data is currently not parsed. I assume there's something similar in TrueType. So ideally, the font would supply the information how exactly to handle super/sub script. But keeping it simple for now will certainly not hurt. On 16.09.2005 09:08:24 Manuel Mall wrote: What is the correct amount of baseline shift to apply for sub and super scripts? Batik seems to use +/- 0.5 * ascender height. Is that the common way of doing it? The spec says only: The offset ... is determined using the font data for the nominal font. Thanks Manuel Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 36678] - [PATCH] Region should report the regionName on error
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=36678. 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=36678 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 10:20 --- Patch applied. Thanks for your contribution -- 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.
baseline-shift and KnuthInlineBoxes
This is probably a question for Luca. if we have a baseline-shift, eg. some Xfo:inline font-size=smaller baseline-shift=super2/fo:inline ... how is that intended to be modelled with respect to the lead,height, and middle values to be stored in the created KnuthInlineBoxes for the fo:inline? Thanks Manuel
wrap-option property
wrap-option is one of those few properties which work in 0.20.5 but are not yet available in FOP Trunk. Luca, what do you think how difficult it would be to implement it at least for, let's say, fo:block? I imagine it would suffice to trick the breaker into not choosing any break possibilities except at the end of the sequence. I think we will need something similar in the StaticContentLM and the BlockContainerLM so overflow can be handled better. At the moment, only the first part until the first break point found by the breaker is properly painted. Afterwards, the BCLM simply adds the additional parts but this can lead to unexpected results as I have seen in one document already. Eager to hear your thoughts. Jeremias Maerki
Re: Initial values for column-number (commit still pending...)
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote: Jeremias, Ok, let me then explicitely state that my previous mail contained my own interpretation and no facts. IMO there are certain gaps and inaccuracies in the spec and I tried to take my own expectations and create an interpretation that makes sense. I could be wrong about this, but I seem to be detecting a hint of resentment here. If so, and if this was caused in any way by something I said, or my unfortunate way of putting it, please note that the 'No offence' part was to be taken literally, really... As for myself, well, I'm quite used to people resenting it when they are confronted with facts that deviate from what they'd like to hear/see *sigh* Maybe it has to do with the fact that, from your POV, I'm bothering you with a minor issue, since it is already solved. True enough, it works, but IMO the place where this is dealt with is wrong. The layout-engine should be able to depend on the initial values for column-number instead of having to determine them itself. From the POV of layout, your interpretation doesn't pose much of a problem, because by that time the table's tree-structure is already fully known. I'm concerned with providing the correct initial values for the FObj *as* they are added to the tree. This has an advantage, since overlapping cells (an error according to the Rec) will be caught *before* layout begins for that page-sequence (more or less in the spirit of validation of the tree). (Besides that: providing these column-numbers in the FOTree is vital for my collapsing-border strategy, so I fear I'm not completely objective here ;-)) Let me just say that I would really, really hate to receive an error message because I didn't specify an ends-row=true on the cell preceding the one I specified a starts-row=true on. Fair enough, but I feel compelled to add that personally, I just really, really hate to receive *any* error message whatsoever. I am reasonable enough, though, not to expect FOP --or any application for that matter-- to compensate for my own deficiencies, whether it be typos, laziness or plain stupidity. The line has to be drawn somewhere. If you'd really hate to receive an error message, then don't do it. It's as simple as that. You'll receive that error message once, and you'll immediately know how to avoid it the next time, no? Still, I've postponed my commit, trying to come up with ways to accommodate you, but I'm having a bit of difficulty to reconcile determining the correct initial values for the column-number property with ignoring the initial values for other related properties (here: ends-row). Allow me to explain: For tables with cells as direct descendants of the table-body, my strategy depended on the value of the ends-row property to reset the TableBody's columnIndex to the first non-occupied column-number so that it is correct by the time the property system has to provide the default for the next TableCell. Made perfect sense to me... One idea I considered is adding a check to see whether the maximum number of columns has been exceeded when increasing the columnIndex. Things I don't really like about this: a) this would mean adding yet another instance variable to the Table or TableBody to keep track of the columnCount, since there is no guarantee that the table will have explicit columns (minor inconvenience) b) if the table doesn't have explicit columns, this could pose problems for the first row, since that's where that maximum column-number will have to be determined (so, this maximum will be exceeded for every cell) (difficult problem from the POV of the FOTree) c) even if I do get it to work, this would still break in case a given row doesn't have as many cells (including column-spans) as there are columns, and the mentioned contradiction between ends-row/starts-row occurs (difficult problem from the POV of the FOTree) So, I'm still wondering whether it wouldn't be more convenient --from the POV of the implementor, not the user-- to simply consider it an error. The question remains: how many times does that happen in reality? Do you, personally, use starts-row/ends-row very frequently? Well, I don't --since I was a 0.20.5 user, which didn't provide this functionality--, but when I do, I would tend to balance out starts-row/ends-row (because that is my interpretation of the Rec) All things considered, we definitely could be relaxing/forgiving for the case where a cell has an explicit ends-row=true and the next cell lacks an explicit starts-row=true... I see no problem with that. On the contrary, this would be dealt with automatically. If you'd really, really hate to receive an error message in *that* case, you're really, really going to love this. Cheers, Andreas
Re: Initial values for column-number (commit still pending...)
On 16.09.2005 11:43:37 Andreas L Delmelle wrote: On Sep 15, 2005, at 16:05, Jeremias Maerki wrote: Jeremias, Ok, let me then explicitely state that my previous mail contained my own interpretation and no facts. IMO there are certain gaps and inaccuracies in the spec and I tried to take my own expectations and create an interpretation that makes sense. I could be wrong about this, but I seem to be detecting a hint of resentment here. If so, and if this was caused in any way by something I said, or my unfortunate way of putting it, please note that the 'No offence' part was to be taken literally, really... Absolutely no resentment here. I'm sorry for sending the wrong signals. I simply realized that I was not clear enough that the stuff I wrote is just my opinion. Stuff like that always happens if I don't want to lose too much time. Sigh. A fact is that I'm relatively tired. I've spent a lot of time on FOP and on mailing lists lately and it can wear you out. A long time I made myself think I had to chime in everywhere to make sure things are running smoothly, but I'm quite happy to see that things have started to run by themselves lately. It looks like my mission (and that of my sponsor) to kickstart FOP again was a success. I will probably dial down my efforts on FOP just a little bit when the first release is out. Don't worry: no plans to go a away! As for myself, well, I'm quite used to people resenting it when they are confronted with facts that deviate from what they'd like to hear/see *sigh* Maybe it has to do with the fact that, from your POV, I'm bothering you with a minor issue, since it is already solved. Solved yes, but it's not clear if that interpretation was right. Maybe I'm indeed wrong. True enough, it works, but IMO the place where this is dealt with is wrong. The layout-engine should be able to depend on the initial values for column-number instead of having to determine them itself. From the POV of layout, your interpretation doesn't pose much of a problem, because by that time the table's tree-structure is already fully known. I'm concerned with providing the correct initial values for the FObj *as* they are added to the tree. This has an advantage, since overlapping cells (an error according to the Rec) will be caught *before* layout begins for that page-sequence (more or less in the spirit of validation of the tree). (Besides that: providing these column-numbers in the FOTree is vital for my collapsing-border strategy, so I fear I'm not completely objective here ;-)) :-) Let me just say that I would really, really hate to receive an error message because I didn't specify an ends-row=true on the cell preceding the one I specified a starts-row=true on. Fair enough, but I feel compelled to add that personally, I just really, really hate to receive *any* error message whatsoever. I am reasonable enough, though, not to expect FOP --or any application for that matter-- to compensate for my own deficiencies, whether it be typos, laziness or plain stupidity. The line has to be drawn somewhere. If you'd really hate to receive an error message, then don't do it. It's as simple as that. You'll receive that error message once, and you'll immediately know how to avoid it the next time, no? Yes, sure, but the problem is that in this case I think it's no error. I wonder what the others think about this. No other comments so far. :-( Everyone is probably avoiding another nasty thread. *bg* Still, I've postponed my commit, trying to come up with ways to accommodate you, but I'm having a bit of difficulty to reconcile determining the correct initial values for the column-number property with ignoring the initial values for other related properties (here: ends-row). Allow me to explain: For tables with cells as direct descendants of the table-body, my strategy depended on the value of the ends-row property to reset the TableBody's columnIndex to the first non-occupied column-number so that it is correct by the time the property system has to provide the default for the next TableCell. Made perfect sense to me... One idea I considered is adding a check to see whether the maximum number of columns has been exceeded when increasing the columnIndex. Things I don't really like about this: a) this would mean adding yet another instance variable to the Table or TableBody to keep track of the columnCount, since there is no guarantee that the table will have explicit columns (minor inconvenience) b) if the table doesn't have explicit columns, this could pose problems for the first row, since that's where that maximum column-number will have to be determined (so, this maximum will be exceeded for every cell) (difficult problem from the POV of the FOTree) c) even if I do get it to work, this would still break in case a given row doesn't have as many cells (including
Re: Initial values for column-number (commit still pending...)
[Jeremias and Andreas on starts-row ends-row] My take is that only a true value is used to determine a change in row. It makes no difference to the fo-tree or to layout if a default false or an explicit false is found. [7.26.15] The starts-row and ends-row properties with a true value are typically used when the input data does not have elements containing the cells in each row, but instead, for example, each row starts at elements of a particular type. I found no indication that a false value can be used to prevent a row change, so there is IMO no real conflict if conflicting values are used on sibling cells. regards, finn
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16092005.jar - Buildfile: build.xml init-avail: init-filters-jdk14: [echo] JDK 1.4 present. [copy] Copying 1 file to /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen init-filters-jdk13: init: [echo] --- Fop 0.20.5 [1999-2003] prepare: [echo] Preparing the build directories [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir:
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16092005.jar - Buildfile: build.xml init-avail: init-filters-jdk14: [echo] JDK 1.4 present. [copy] Copying 1 file to /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen init-filters-jdk13: init: [echo] --- Fop 0.20.5 [1999-2003] prepare: [echo] Preparing the build directories [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir:
Re: wrap-option property
Jeremias Maerki wrote: wrap-option is one of those few properties which work in 0.20.5 but are not yet available in FOP Trunk. Luca, what do you think how difficult it would be to implement it at least for, let's say, fo:block? I imagine it would suffice to trick the breaker into not choosing any break possibilities except at the end of the sequence. Yes, it seems a very good idea: just an additional boolean parameter for findBreakingPoints(), similar to hyphenationAllowed. Or we could use just a single int instead of two booleans: a parameter whose value could be set using three constants, for example ALL_BREAKS, NO_HYPHENATION, NO_WRAP. Maybe it could be even easier: a LineBreakPosition could be created without even performing the line breaking algorithm, as we alredy know we will create just a line, an which will be the indexes of the first and last element. But maybe this would prevent us from knowing useful information created by the algorithm (difference, indent, ...). I'm going to work on this immediately. I think we will need something similar in the StaticContentLM and the BlockContainerLM so overflow can be handled better. At the moment, only the first part until the first break point found by the breaker is properly painted. Afterwards, the BCLM simply adds the additional parts but this can lead to unexpected results as I have seen in one document already. Sorry, I don't quit get what you mean ... what are these unexpected results? Regards Luca
Re: baseline-shift and KnuthInlineBoxes
Manuel Mall wrote: if we have a baseline-shift, eg. some Xfo:inline font-size=smaller baseline-shift=super2/fo:inline ... how is that intended to be modelled with respect to the lead,height, and middle values to be stored in the created KnuthInlineBoxes for the fo:inline? I think that more (or different) information needs to be stored in the KnuthInlineBoxes in order to fully implement the properties concerning the vertical positioning of objects. Lead, total and middle are only enough to handle vertical-align = top, bottom or middle; anyway, maybe three attributes could be enough: one identifying the alignment baseline (alphabetic, ideographic, text-before-edge, ...) and two specifying the box heigth above and below this baseline. The LineLM should look at these values when creating the lines: each box height will be interpreted differently according to its baseline: I think this will be the tricky part of this work! HTH, even if it' not much :-) Regards Luca
Re: Initial values for column-number (commit still pending...)
On Sep 16, 2005, at 12:15, Jeremias Maerki wrote: Absolutely no resentment here. I'm sorry for sending the wrong signals. I simply realized that I was not clear enough that the stuff I wrote is just my opinion. Stuff like that always happens if I don't want to lose too much time. Sigh. Ok, I'm glad. I just tend to bring in a bit of humor at times, and sometimes that comes across totally differently (more rudely) than I intended. snip / I will probably dial down my efforts on FOP just a little bit when the first release is out. Don't worry: no plans to go a away! Phew, that's a relief as well! I noticed that you were one of the few people to actually respond to any of my questions/remarks, so far. Wouldn't like to lose that. It would be like talking to myself :-) snip / If you'd really hate to receive an error message, then don't do it. It's as simple as that. You'll receive that error message once, and you'll immediately know how to avoid it the next time, no? Yes, sure, but the problem is that in this case I think it's no error. I wonder what the others think about this. No other comments so far. :-( Everyone is probably avoiding another nasty thread. *bg* That's probably the key to the above remark. Manuel recently apologized for not being able to offer a viewpoint because he feared he was not knowledgeable enough. I don't mind, I just like to hear/consider as many viewpoints as possible. No matter if you have extensive knowledge or not, just add any comments. Even if you think they don't help much, someone else might just get the spark he needs to light the fire. snip / So, I'm still wondering whether it wouldn't be more convenient --from the POV of the implementor, not the user-- to simply consider it an error. That's always dangerous IMO. We should always be focused on the user. True enough. I'll keep trying to find a solution to it for the time being. The question remains: how many times does that happen in reality? Do you, personally, use starts-row/ends-row very frequently? No. I always use table-row. :-) snip / All things considered, we definitely could be relaxing/forgiving for the case where a cell has an explicit ends-row=true and the next cell lacks an explicit starts-row=true... I see no problem with that. On the contrary, this would be dealt with automatically. If you'd really, really hate to receive an error message in *that* case, you're really, really going to love this. Yes, please. I think the idea behind the two properties was really simplifying the task for stylesheet developers so they can easily build up tables. Nobody will ever explicitely write a false value for the two properties into his stylesheet. He will only set a true value when he knows that he needs to start (or end) a row (depending on the stylesheet logic). Glen would say we should contact the FO WG for a clarification. Good idea. FWIW: a quick Google on the topic didn't bring me any closer to clarifying this issue. Examples seem to be very rare... Cheers, Andreas
Re: wrap-option property
On 16.09.2005 13:09:05 Luca Furini wrote: Jeremias Maerki wrote: wrap-option is one of those few properties which work in 0.20.5 but are not yet available in FOP Trunk. Luca, what do you think how difficult it would be to implement it at least for, let's say, fo:block? I imagine it would suffice to trick the breaker into not choosing any break possibilities except at the end of the sequence. Yes, it seems a very good idea: just an additional boolean parameter for findBreakingPoints(), similar to hyphenationAllowed. Or we could use just a single int instead of two booleans: a parameter whose value could be set using three constants, for example ALL_BREAKS, NO_HYPHENATION, NO_WRAP. Maybe it could be even easier: a LineBreakPosition could be created without even performing the line breaking algorithm, as we alredy know we will create just a line, an which will be the indexes of the first and last element. But maybe this would prevent us from knowing useful information created by the algorithm (difference, indent, ...). I'm going to work on this immediately. Cool! I also thought about wrap-option on fo:inline etc. But I'm unsure about how to interpret. At first, I thought this could be done by handling it like a keep-together, but the spec text seems to imply that the content would not be broken in this case but will simply overlap beyond the boundaries. Shrug. I think we will need something similar in the StaticContentLM and the BlockContainerLM so overflow can be handled better. At the moment, only the first part until the first break point found by the breaker is properly painted. Afterwards, the BCLM simply adds the additional parts but this can lead to unexpected results as I have seen in one document already. Sorry, I don't quit get what you mean ... what are these unexpected results? The problem was with a table of which the first cell had a smaller font. The break point ended up inside a row which was split so that part of it landed in the second part (the one that actually causes the overflow). With page breaks that's ok, but in this case it looked like the second cell was on a different row. Instead of: |cell1 |CELL2| I got: |cell1 | | ||CELL2| Jeremias Maerki
Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
No idea what this is suddenly about. Looks like a permission problem? Strange though that it's only the maintenance branch that fails and not the trunk, too. Any ideas how to resolve? On 16.09.2005 12:51:17 Sam Ruby wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-16092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/de liverables/jars/avalon-framework-api-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16092005.jar - Buildfile: build.xml init-avail: init-filters-jdk14: [echo] JDK 1.4 present. [copy] Copying 1 file to /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen init-filters-jdk13: init: [echo] --- Fop 0.20.5 [1999-2003] prepare: [echo] Preparing the build directories [mkdir] Created dir:
Re: svn commit: r289531 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/Block.java layoutmgr/AbstractBreaker.java layoutmgr/BreakingAlgorithm.java layoutmgr/PageSequenceLayoutManager.java
[EMAIL PROTECTED] wrote: Author: lfurini Date: Fri Sep 16 06:24:16 2005 New Revision: 289531 URL: http://svn.apache.org/viewcvs?rev=289531view=rev Log: Implemented the wrap-option property. The overflow property is not yet implemented, so at the moment if wrap-option = no-wrap and the text overflows it invades the margins. Wow! That was quick. Just trying it now ;) Chris
Re: svn commit: r289531 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/Block.java layoutmgr/AbstractBreaker.java layoutmgr/BreakingAlgorithm.java layoutmgr/PageSequenceLayoutManager.java
Chris Bowditch wrote: [EMAIL PROTECTED] wrote: Author: lfurini Date: Fri Sep 16 06:24:16 2005 New Revision: 289531 URL: http://svn.apache.org/viewcvs?rev=289531view=rev Log: Implemented the wrap-option property. The overflow property is not yet implemented, so at the moment if wrap-option = no-wrap and the text overflows it invades the margins. Wow! That was quick. Just trying it now ;) Hmmm I hate to be the bearer of bad news. But it seems that the change has broken text-align=right when used on table cells. All the regression tests pass, so I guess it working when text-align=right for regular blocks. Chris
Re: Characters and area traits
Still waiting for some feedback here from others. I am reluctant to change the interface to the renderers without other committers agreeing because such a change affects every renderer out there. On the other hand it feels a bit like a kludge to treat/represent fo:character ... character=x / as fo:inline ...x/fo:inline. There are also some subtleties in the handling of some properties which are interpreted differently when specified on a fo:character to a fo:inline. Manuel On Fri, 16 Sep 2005 03:31 pm, Manuel Mall wrote: On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote: [Manuel] I am currently looking at adding the missing background and border/padding support to fo:character and have run into a co-ordinate system issue. In fop text areas and character areas are positioned in the bpd direction using the offset attribute which refers to the character baseline position. However, border/padding and backgrounds are positioned everywhere relative to the top left (or should I say before/start) corner of the area rectangle. However, in the renderer based on the area traits (for a text or character area) I cannot easily determine the before edge position of the rectangle based on the baseline offset unless I go to the font and ask for its ascender size etc.. But that is really stuff for the layout system. I see two options: a) We can wrap the character area into an inlineParent area and put the background/border/padding for the character on the inlineParent. b) We add another attribute to the generic fop area being the baseline offset called lead. The meaning of the attributes is then that offset refers to the distance between the before edge of the parent area to the before edge of the area to be rendered and lead is the distance from the before edge to the baseline for character placement. Perhaps I misunderstand, but I think it would be better if we defined an dominant-baseline on the inlines (or even better dominant-baseline-identifier on inline and actual-baseline-table on the fonts) and a baseline-start-point on the linearea. The semantics of these traits are as described in [4.2.6] and [4.5]. Finn, you understood me correctly and your suggestions to align our naming with the spec make sense. However, the fop area tree is really an interface to the fop renderers and not an exact implementation of the XSl-FO area tree. For example at the moment it seems layout is assumed to take care of all the baseline calculations and the renderers are only told the position of THE baseline for the glyphs of the font they are suppose to render. There seems to be no need for the renderers to be aware of different baselines, baseline tables, etc. as layout resolved all that into a single vertical (I am still thinking in terms of lr-tb scripts) position for each sequence of characters to be rendered. So we may have to introduce the concepts you suggest like actual-baseline-table, dominant-baseline, ... to the fop Layout Managers so they can do their job properly with respect to all this baseline stuff but I am not so sure we need it in the area tree (= interface to the renderers). Together with bpd, I think that would be enough to find the rest of the different rectangles. I guess it is the same as your suggestion b), but I would rather stick with the terms used in the spec. regards, finn Cheers Manuel
Re: Initial values for column-number (commit still pending...)
On Sep 16, 2005, at 12:26, Finn Bock wrote:
My take is that only a true value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
false or an explicit false is found.
FWIW: That was precisely my understanding too, hence my speaking of a
'contradiction'.
[7.26.15]
The starts-row and ends-row properties with a true value are
typically used when the input data does not have elements containing
the cells in each row, but instead, for example, each row starts at
elements of a particular type.
I found no indication that a false value can be used to prevent a
row change, so there is IMO no real conflict if conflicting values are
used on sibling cells.
Well, currently you both got me convinced about this. I'm working on it
--but a bit frustrated, since that was really the *only* case where it
failed. All other situations are handled nicely including row-spans...
--even when a user would only use ends-row to indicate row-changes, all
works as it should.
And now this... Aarrrghh!! :-)
Oh well, give it some time. I'm sure I'll come up with something. Have
already tried a quick hack, forcing the column-number, but then the
FOTree tests fail, because the value isn't correctly initialized in the
PropertyList itself (only the TableCell's instance variable is
altered).
Unfortunately no lookahead in the FOTree, otherwise I could just go
if( currentCell.endsRow() || nextCell.startsRow() ) {
//reset columnIndex
}
I'm beginning to see the advantages of XEP's approach to normalize
tables in a pre-processing XSL transform of the FO source document...
Anyway: thanks for your feedback.
Cheers,
Andreas
Re: svn commit: r289531 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/Block.java layoutmgr/AbstractBreaker.java layoutmgr/BreakingAlgorithm.java layoutmgr/PageSequenceLayoutManager.java
Luca Furini wrote: Chris Bowditch wrote: Hmmm I hate to be the bearer of bad news. But it seems that the change has broken text-align=right when used on table cells. All the regression tests pass, so I guess it working when text-align=right for regular blocks. D'oh! Could you please attach a file demonstrating this problem? I have just tried a simple test with right-aligned text inside a table cell, but I don't see anything strange ... The example is actually a bit more convoluted than I first realised. In my example there are two tables inside a block with margin-left=3mm The text in the 2nd column of the 2nd table are not correctly right aligned. All the text in this example was right aligned properly before you made this change. fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=a4 page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=a4 fo:flow flow-name=xsl-region-body fo:block margin-right=10mm margin-left=3mm margin-top=2mm fo:table space-before=2pt font-size=8pt table-layout=fixed width=100% border-collapse=separate start-indent=0mm fo:table-column column-width=proportional-column-width(50) column-number=1/ fo:table-column column-width=proportional-column-width(50) column-number=2/ fo:table-body start-indent=0mm end-indent=0mm fo:table-row fo:table-cell fo:block fo:block line-height=10pt font-size=8pt font-family=Arial wrap-option=no-wrapQ4 Earnings Call/fo:block /fo:block /fo:table-cell fo:table-cell fo:block fo:block line-height=10pt font-size=8pt font-family=Arial wrap-option=no-wrap text-align=right15 January 2005/fo:block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table fo:table space-before=2pt font-size=8pt table-layout=fixed width=100% border-collapse=separate start-indent=0mm fo:table-column column-width=proportional-column-width(50) column-number=1/ fo:table-column column-width=proportional-column-width(50) column-number=2/ fo:table-body fo:table-row fo:table-cell fo:block fo:block line-height=10pt font-size=8pt font-family=Arial wrap-option=no-wrapChristmas/fo:block /fo:block /fo:table-cell fo:table-cell fo:block fo:block line-height=10pt font-size=8pt font-family=Arial wrap-option=no-wrap text-align=right25 December 2004/fo:block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root Thanks, Chris
Re: Initial values for column-number (commit still pending...)
On Sep 16, 2005, at 16:00, Andreas L Delmelle wrote: Well, currently you both got me convinced about this. I'm working on it --but a bit frustrated, since that was really the *only* case where it failed. All other situations are handled nicely including row-spans... --even when a user would only use ends-row to indicate row-changes, all works as it should. And now this... Aarrrghh!! :-) Oh well, give it some time. I'm sure I'll come up with something. YES! Got it. My initial approach placed too much emphasis on the FObj.addChildNode() where it should have been handled in the custom PropertyMaker itself... Which goes to show: Talking/writing helps :-) Just a few more lines of code to shift, a few tests to run, and this can finally be committed. *deep sigh* Cheers, Andreas
Re: Characters and area traits
Manuel Mall wrote: Still waiting for some feedback here from others. I am reluctant to change the interface to the renderers without other committers agreeing because such a change affects every renderer out there. On the other hand it feels a bit like a kludge to treat/represent fo:character ... character=x / as fo:inline ...x/fo:inline. There are also some subtleties in the handling of some properties which are interpreted differently when specified on a fo:character to a fo:inline. Well I tend to agree. Treating fo:character as fo:inline just because the Renderer interface doesn't have a renderCharacter method is a nasty bodge. As you say if there are subtleties to be observed when rendering an fo:character then go ahead and change the Renderer interface. Chris
DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions
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=36625. 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=36625 [EMAIL PROTECTED] changed: What|Removed |Added CC||fop- ||[EMAIL PROTECTED] Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 16:45 --- Forgot to add fop-dev@xmlgraphics.apache.org to the Cc list when I assigned the bug to myself - still learning! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: Characters and area traits
On Fri, 16 Sep 2005 10:39 pm, Chris Bowditch wrote: Manuel Mall wrote: Still waiting for some feedback here from others. I am reluctant to change the interface to the renderers without other committers agreeing because such a change affects every renderer out there. On the other hand it feels a bit like a kludge to treat/represent fo:character ... character=x / as fo:inline ...x/fo:inline. There are also some subtleties in the handling of some properties which are interpreted differently when specified on a fo:character to a fo:inline. Well I tend to agree. Treating fo:character as fo:inline just because the Renderer interface doesn't have a renderCharacter method is a nasty bodge. As you say if there are subtleties to be observed when rendering an fo:character then go ahead and change the Renderer interface. Thanks Chris - that's not quite it. There is a renderCharacter interface. The problem is that when giving an inline area to the renderer the renderer needs to know with respect to vertical (bpd) positioning two items: 1.) Where does the area begin within the line because inlines can be taller or narrower than the line height (bpd) of the line area they belong into. The renderers need to know this so they can draw any borders correctly above and below the area. 2.) Where is the baseline within the inline area for the correct bpd positioning of the glyphs. Currently the interface (= area tree) has only one attribute related to this vertical positioning and I need two as explained above. Chris regards Manuel
Re: svn commit: r289531 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/Block.java layoutmgr/AbstractBreaker.java layoutmgr/BreakingAlgorithm.java layoutmgr/PageSequenceLayoutManager.java
On 16.09.2005 16:19:43 Chris Bowditch wrote: Luca Furini wrote: Chris Bowditch wrote: Hmmm I hate to be the bearer of bad news. But it seems that the change has broken text-align=right when used on table cells. All the regression tests pass, so I guess it working when text-align=right for regular blocks. D'oh! Could you please attach a file demonstrating this problem? I have just tried a simple test with right-aligned text inside a table cell, but I don't see anything strange ... The example is actually a bit more convoluted than I first realised. In my example there are two tables inside a block with margin-left=3mm The text in the 2nd column of the 2nd table are not correctly right aligned. All the text in this example was right aligned properly before you made this change. The problem is the margin-right which establishes an end-indent. In the first table the end-indent is reset to 0mm on the table-body. You're not doing that in the second table. Therefore you get an inherited end-indent of 10mm in the second table and that's why the text isn't properly aligned. Remember the rule of thump for tables: if you have a start-indent or end-indent outside of a table, remember to set start-indent=0mm and end-indent=0mm on the table-header, table-footer and table-body to reset all indents to 0mm. Otherwise, you'll be bitten by inheritance. See also http://wiki.apache.org/xmlgraphics-fop/IndentInheritance snip/ Jeremias Maerki
Re: svn commit: r289531 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/Block.java layoutmgr/AbstractBreaker.java layoutmgr/BreakingAlgorithm.java layoutmgr/PageSequenceLayoutManager.java
Jeremias Maerki wrote: The problem is the margin-right which establishes an end-indent. In the first table the end-indent is reset to 0mm on the table-body. You're not doing that in the second table. Therefore you get an inherited end-indent of 10mm in the second table and that's why the text isn't properly aligned. Remember the rule of thump for tables: if you have a start-indent or end-indent outside of a table, remember to set start-indent=0mm and end-indent=0mm on the table-header, table-footer and table-body to reset all indents to 0mm. Otherwise, you'll be bitten by inheritance. Yes you are right. Glad it's user error - looks like Luca's implemented the wrap-option in record time then. Thanks, Chris
Re: Characters and area traits
I'm not a specialist on typography, yet, but the character wrapping (your option a) sounds definitely like a hack. I've started reading the parts in the spec about baselines and that's not a casual read. But I think that at one point we need to handle baselines and all these little details. I'm not a big help here but I think it would be worth reading through the following sections in the spec: 4.2.6, 7.8.1, 7.13. Somewhere in there all the necessary traits and their handling should be hidden. They should at least get you some hints how to handle the problem at hand. On 16.09.2005 15:50:50 Manuel Mall wrote: Still waiting for some feedback here from others. I am reluctant to change the interface to the renderers without other committers agreeing because such a change affects every renderer out there. On the other hand it feels a bit like a kludge to treat/represent fo:character ... character=x / as fo:inline ...x/fo:inline. There are also some subtleties in the handling of some properties which are interpreted differently when specified on a fo:character to a fo:inline. Manuel On Fri, 16 Sep 2005 03:31 pm, Manuel Mall wrote: On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote: [Manuel] I am currently looking at adding the missing background and border/padding support to fo:character and have run into a co-ordinate system issue. In fop text areas and character areas are positioned in the bpd direction using the offset attribute which refers to the character baseline position. However, border/padding and backgrounds are positioned everywhere relative to the top left (or should I say before/start) corner of the area rectangle. However, in the renderer based on the area traits (for a text or character area) I cannot easily determine the before edge position of the rectangle based on the baseline offset unless I go to the font and ask for its ascender size etc.. But that is really stuff for the layout system. I see two options: a) We can wrap the character area into an inlineParent area and put the background/border/padding for the character on the inlineParent. b) We add another attribute to the generic fop area being the baseline offset called lead. The meaning of the attributes is then that offset refers to the distance between the before edge of the parent area to the before edge of the area to be rendered and lead is the distance from the before edge to the baseline for character placement. Perhaps I misunderstand, but I think it would be better if we defined an dominant-baseline on the inlines (or even better dominant-baseline-identifier on inline and actual-baseline-table on the fonts) and a baseline-start-point on the linearea. The semantics of these traits are as described in [4.2.6] and [4.5]. Finn, you understood me correctly and your suggestions to align our naming with the spec make sense. However, the fop area tree is really an interface to the fop renderers and not an exact implementation of the XSl-FO area tree. For example at the moment it seems layout is assumed to take care of all the baseline calculations and the renderers are only told the position of THE baseline for the glyphs of the font they are suppose to render. There seems to be no need for the renderers to be aware of different baselines, baseline tables, etc. as layout resolved all that into a single vertical (I am still thinking in terms of lr-tb scripts) position for each sequence of characters to be rendered. So we may have to introduce the concepts you suggest like actual-baseline-table, dominant-baseline, ... to the fop Layout Managers so they can do their job properly with respect to all this baseline stuff but I am not so sure we need it in the area tree (= interface to the renderers). Together with bpd, I think that would be enough to find the rest of the different rectangles. I guess it is the same as your suggestion b), but I would rather stick with the terms used in the spec. regards, finn Cheers Manuel Jeremias Maerki
Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
On Fri, 16 Sep 2005, Jeremias Maerki [EMAIL PROTECTED] wrote: No idea what this is suddenly about. Looks like a permission problem? No, the file simply doesn't exist. The properties directory is empty, at least after the build has finished. Stefan
Re: baseline-shift and KnuthInlineBoxes
On Fri, Sep 16, 2005 at 09:42:01PM +0800, Manuel Mall wrote: On Fri, 16 Sep 2005 07:10 pm, Luca Furini wrote: Manuel Mall wrote: Would be really nice to get some wider variety of fonts to play with. May be including some unusual scripts with strange baselines. Do we need something like OFFO for fonts, i.e. a repository of open licensed but incompatible with Apache license fonts already converted for use with fop? OFFO could easily host FOP-specific tables for such fonts. It could also maintain a list of such fonts. I am not sure it should host such fonts itself, but it could if there is a good reason. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
