Re: alignment-adjust property
On Wed, 28 Sep 2005 03:17 pm, Jeremias Maerki wrote: I read it like this: The areas generated by inlines are always children of line areas. Since only line areas can define the before-edge and after edge baselines, areas generated by inlines have to retrieve these two baselines from their parent line area. I believe this is some kind of implied inheritance. Disclaimer: I haven't studied the whole topic! Jeremias, this doesn't quite gel with me as I don't think inheritance can be involved. alignment-adjust is about answering the question: Where is my alignment-point within the area(s) I am generating. This question cannot (IMO) be answered relative to inherited baseline tables (some of those inherited baselines may even be well outside of the area the fo in question is generating). On 28.09.2005 06:11:40 Manuel Mall wrote: This is another of those spec interpretation questions. Sorry to populate this list with so many of these questions but this is a source of real irritation for me in the moment. I just want to get sub/superscripts working and do it properly and I am hitting all these murky (as Peter put it) things in the spec. Here we go again. In 7.13 the spec defines the various baselines. In that section it says: There are, in addition, two computed baselines that are only defined for line areas. and then goes on about those two baselines being before-edge and after-edge. We then come to 7.13.1 alignment-adjust and before-edge and after-edge are valid values. However, the alignment-adjust property applies only to inline fo's. And inline fo's don't generate line areas. As the alignment-adjust property applies to the area generated by the fo (not like the alignment-baseline property which applies to the parent area) none of the areas generated by the fo's in question will have those baselines defined. The text also implies that i-f-o and and e-g have the after-edge as their dominant baseline. For the auto setting we are allowed to use heuristics to determine where the baseline is but that option is not open to the other values. So, what's the point of having before-edge, after-edge as allowed values if those baselines are guaranteed not to be defined (and even use them as default for e-g and i-f-o)? Manuel Jeremias Maerki Manuel
Re: alignment-adjust property
Manuel Mall wrote: This is another of those spec interpretation questions. Sorry to populate this list with so many of these questions but this is a source of real irritation for me in the moment. I just want to get sub/superscripts working and do it properly and I am hitting all these murky (as Peter put it) things in the spec. Don't apologise for actually reading the Recommendation, and thinking about it. The fact is that there is not enough of that done by those who are implementing the Recommendation, as evidenced by the existence of these bugs in the document. No matter what the interpretation, 7.13.1 and 7.13.2 have editorial bugs which need to be clarified. Think about it. How many commercial implementations are out there? The same bugs are still present in the 1.1 draft. (See Section 7.14). You found it, so you get to write to the editors. If you are apprehensive about that, talk to me further off-list, or to Glen (who has communicated quite a lot with the editors, and who has popped up again) or Victor. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: alignment-adjust property
On Wed, 28 Sep 2005 06:03 pm, Peter B. West wrote: Manuel Mall wrote: This is another of those spec interpretation questions. Sorry to populate this list with so many of these questions but this is a source of real irritation for me in the moment. I just want to get sub/superscripts working and do it properly and I am hitting all these murky (as Peter put it) things in the spec. Don't apologise for actually reading the Recommendation, and thinking about it. The fact is that there is not enough of that done by those who are implementing the Recommendation, as evidenced by the existence of these bugs in the document. No matter what the interpretation, 7.13.1 and 7.13.2 have editorial bugs which need to be clarified. Think about it. How many commercial implementations are out there? The same bugs are still present in the 1.1 draft. (See Section 7.14). You found it, so you get to write to the editors. If you are apprehensive about that, talk to me further off-list, or to Glen (who has communicated quite a lot with the editors, and who has popped up again) or Victor. Peter, thanks for the encouragement. I am happy to write to the editors. And yes, as I am fairly new to this (in the sense of delving into the depth of spec) I am using this mailing list as a sounding board first because I am still apprehensive about generating noise / garbage or whatever you want to call it due to being a newbie and possibly not understanding something which to someone with more experience would be obvious. Peter Manuel
[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 4 projects, and has been outstanding for 44 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework - cocoon-block-tour : Java XML Framework - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - 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 -INFO- Failed to extract 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-28092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-28092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-28092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-28092005.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]
[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 4 projects, and has been outstanding for 44 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework - cocoon-block-tour : Java XML Framework - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - 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 -INFO- Failed to extract 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-28092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-28092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-28092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-28092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-28092005.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]
Re: Another page-related question: page-position=last
Jeremias Maerki wrote: What is the expected output? In this case it has to generate a blank page IMO. Oh, right, I did not think of an empty page! :-) The problem is with the page x of y hack that won't work like this if the last empty block ends up on the second-to-last page. [...] What about the following approach? Run the breaker without special last-page handling, then inspect the allocated BPD for the last part. If it fits into the last page, just exchange the page-master (*) and paint it there. If it doesn't fit, paint it using the non-last page-master and add a blank page with the last page-master. If there's a box w=0 at the end of the element list, force a new part and paint that on the last page to handle the page x of y case. I think this would work with my idea too: in this case, if the last empty block and the difference in page bpd (that cannot be parted) do not fit in the non-last page under construction, they would be placed in a new page; so, a page-number-citation pointing to the empty block would return the last page-number. This would avoid the need to exchange page-masters, and to have a special handling for zero-width box at the end of the sequence. Regards Luca
Funny side-effects from space-resolution
I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. I'm attaching the PDF output of my local code. Jeremias Maerki block_margin_inherit.xml.head.pdf Description: Binary data
rtf-external-graphics
Hi,
After patch of Peter Herweg, adding support of external-graphics in Rtf
(25.09.2005, revision 291449) some problems are still unresolved.
I'm talking about using url's in src attribute of fo:external-graphic tag.
Take a look at fo-file below:
...
fo:flow flow-name=xsl-region-body
fo:block start-indent=12pt space-before=3pt
fo:external-graphic src=url('01.jpg')/
/fo:block
/fo:flow
...
Rtf renderer produced file 01a.rtf (see in attach).
After changing in file RTFHandler.java string
newGraphic.setURL(eg.getSrc());
to string
newGraphic.setURL(eg.getURL());
Rtf renderer produced another file 01b.rtf (in attach too).
File 01b.rtf seems to be correct whether 01a.rtf is not.
What do you think about it?
Thanks for attention!
01.fo
Description: Binary data
attachment: 01.jpg
01a.rtf
Description: MS-Word document
01b.rtf
Description: MS-Word document
Re: svn commit: r292280 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOUserAgent.java
On Sep 28, 2005, at 22:09, Simon Pepping wrote:
Hi Simon,
On Wed, Sep 28, 2005 at 07:37:31PM -, [EMAIL PROTECTED] wrote:
+public void initUserConfig() throws ConfigurationException {
+log.info(Initializing User Agent Configuration);
+Configuration cfgUserAgent =
userConfig.getChild(userAgent);
Why do you wrap these configuration elements in a userAgent element?
Well, I didn't modify the fop.xconf file myself. The general UA config
entries were already there, and I just added the page-settings in
there...
The fact that we let the user agent object handle the configuration,
does not need to be reflected in the configuration file. I would
prefer to see these configuration elements as direct children of the
top level element, or perhaps some of them wrapped in an element like
pagesettings.
No objection from me.
Anyone with other opinions before I make this alteration?
Cheers,
Andreas
Re: rtf-external-graphics
I'll look into it tomorrow. Peter's last change for external-graphics in
RTF made me wonder if we shouldn't actually change the whole code there
and use the image library wrappers the normal renderers use. Like this
we could use the image cache, more image formats and URI resolution the
same way as for the other output formats.
On 28.09.2005 17:10:23 Sergey Simonchik wrote:
Hi,
After patch of Peter Herweg, adding support of external-graphics in Rtf
(25.09.2005, revision 291449) some problems are still unresolved.
I'm talking about using url's in src attribute of fo:external-graphic tag.
Take a look at fo-file below:
...
fo:flow flow-name=xsl-region-body
fo:block start-indent=12pt space-before=3pt
fo:external-graphic src=url('01.jpg')/
/fo:block
/fo:flow
...
Rtf renderer produced file 01a.rtf (see in attach).
After changing in file RTFHandler.java string
newGraphic.setURL(eg.getSrc());
to string
newGraphic.setURL(eg.getURL());
Rtf renderer produced another file 01b.rtf (in attach too).
File 01b.rtf seems to be correct whether 01a.rtf is not.
What do you think about it?
Thanks for attention!
Jeremias Maerki
DO NOT REPLY [Bug 1063] - fop does not handle large fo files
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=1063. 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=1063 --- Additional Comments From [EMAIL PROTECTED] 2005-09-28 22:42 --- Created an attachment (id=16545) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16545action=view) solution for FOP to handle large files -- 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.
AW: rtf-external-graphics
Jeremias Maerki wrote: I'll look into it tomorrow. Peter's last change for external-graphics in RTF made me wonder if we shouldn't actually change the whole code there and use the image library wrappers the normal renderers use. Like this we could use the image cache, more image formats and URI resolution the same way as for the other output formats. I have played around with JAI to support other file formats (e.g. GIF, BMP). This works good but it's quite slow. I did not know that there are image library wrappers. Can you point me to them? Are they contained in XML Graphics Commons? Regards, Peter Herweg
