Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
(cc'ing dev@ant.apache.org) On 16.09.2005 21:23:39 Stefan Bodewig wrote: 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 For the Ant people, links to related info: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200509.mbox/[EMAIL PROTECTED] The build.xml in question: http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2-maintain/build.xml?view=markup (the problem happens in the codegen target. Note: Constants.java is supposed to be generated by the style task, it can't be there to be deleted.) Thanks for your reply, Stefan. I think this is due to a change in Ant. I've downloaded SVN Trunk and used that and it reproduces the problem. Here's the -d output: [dependset] 2 nonexistent targets [dependset] Deleting all target files. [dependset] Deleting C:\Dev\FOP\branch\svn\build\src\org\apache\fop\fo\properties\Constants.java BUILD FAILED C:\Dev\FOP\branch\svn\build.xml:412: Unable to delete file C:\Dev\FOP\branch\svn\build\src\org\apache\fop\fo\properties\Constants.java at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:104) at org.apache.tools.ant.Task.perform(Task.java:365) at org.apache.tools.ant.taskdefs.DependSet.execute(DependSet.java:185) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:104) at org.apache.tools.ant.Task.perform(Task.java:365) at org.apache.tools.ant.Target.execute(Target.java:356) at org.apache.tools.ant.Target.performTasks(Target.java:384) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1236) at org.apache.tools.ant.Project.executeTarget(Project.java:1205) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1088) at org.apache.tools.ant.Main.runBuild(Main.java:676) at org.apache.tools.ant.Main.startAnt(Main.java:195) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:276) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:96) Looks like the dependset has a problem due to a change in Delete: http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Delete.java?rev=280944r1=278200r2=280944diff_format=h This change happened 4 days ago which seems to fit with the first occurence of the problem. Jeremias Maerki
Re: Characters and area traits
On 18.09.2005 13:10:34 Manuel Mall wrote: On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote: 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. Jeremias, seems to me we are talking about two different things here. I don't think so. I only tend to look at how to get a problem right for good as opposed to a quick change to make things work. I see that this was not fully appropriate here. Sorry for that. My initial problem simply was that I needed more data in the area tree to correctly draw border/padding/background for various inline fos (leader, page-number, page-number-citation, character). The other, only vaguely related matter, is the correct handling of all the area alignment properties in layout. IMO it is only vaguely related, and this may be contentious, because for rendering we only need to know where to place the glyph, i.e. the x/y coordinates of its alignment point. All the relative and baseline alignment stuff should have been previously resolved by layout. If you go along with that argument it would mean the fop area tree as exposed to the renderers will not carry baseline tables or related data. Not sure if this causes an issue with the plans to expose the area tree as an official external interface. No, I don't think it would. As I said, I don't know too much about the details involved here so I can't tell what the right approach would be. People who would mess around with the area will need to know what they're doing anyway. No problem if it might get a little complicated on this level. So, for the time being, I have now fop internally standardised the meaning of the fop specific offset attribute in the fop area tree as meaning the distance between the before edges of the parent area and the area to be rendered. I have also introduced a new attribute called baselineOffset which gives the point on the start-edge (distance from the before-edge) for the actual alignment line for all glyphs in that inline area, i.e. the alignment point in bpd for all the glyphs in that area will be on that line. Sounds reasonable. Did you find anything in the spec what exactly the suggested set of trait is? This seems to have worked well so far and introduced quite a bit of consistency in the handling of offsets and basic vertical alignment for all our inline areas. There is an assumption behind this that all glyphs in an inline area have the same nominal alignment line. This is certainly true in the moment and I am not aware of a font where different glyphs have different nominal alignment lines (but there probably is for fonts mixing Western and non Western glyphs). And even if so, our font interface (nor FOray's i/f I assume) does not expose this sort of detail. If the two attributes (offset and baselineOffset) are enough in the fop area tree to cover vertical writing modes I am not sure about - this is for further study. Hope this makes sense Sounds completely reasonable to me. 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
RE: txt-rendering
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: Re: txt-rendering AFAIK, there's still a open issue with a patch [2] where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name. Meanwhile, our lawer disallow ICLA using, but it's possible, soon we'll get modified ICLA.
Re: Space-resolution doesn't work
On Tue, 13 Sep 2005 04:25 pm, Jeremias Maerki wrote: FYI, I'm going to try reimplementing the whole space-resolution part on the block-progression-dimension (to start with) using the inputs from both Luca and Simon and based on my findings I've documented in the Wiki: http://wiki.apache.org/xmlgraphics-fop/SpaceResolution I've started by creating a base class UnresolvedElement (holding a Position instance) from which SpaceElement (holding SpaceProperty) and BorderOrPaddingElement (holding a CondLengthProperty) are derived. We'll see how well this turns out. Looking forward to seeing the result of this as the same/similar problem needs to be solved for the inline-progression-direction. Side note: The LineLayoutManager currently doesn't add the the half-leading trait as space-before/space-after as required by the spec (4.5). This means you won't consider these as part of your space resolution in bpd although they probably should? OTOH, I would prefer no big changes to the whole line/inline layout stuff until my batch of changes accumulated here are in Subversion. snip/ Jeremias Maerki 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 1 projects, and has been outstanding for 12 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-19092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-19092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-19092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-19092005.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:
Build error?
Hi all. I'm noticing a strange problem: fop builds correctly, but then it seems it is not working at all. I'm using it from the command line under win xp, and even if I don't get any run time exception no output file is created. Launching fop with no parameters, or with wrong parameters (missing files ...) does not create any error: simply, nothing happens. I have compiled fop on two different computers, so I don't think this is a local configuration problem. Hasn't anyone else noticed this? Regards Luca
Re: Build error?
Luca,
not sure if this is it but in CommandLineOptions we have:
if (System.getProperty(org.apache.commons.logging.Log) == null) {
logFactory.setAttribute(org.apache.commons.logging.Log,
CommandLineLogger.class.getName());
setLogLevel(info);
}
log = LogFactory.getLog(FOP);
i.e. the log instance is created after the call to setLogLevel(...). But
setLogLevel starts with:
...
if (log instanceof CommandLineLogger) {
so you are hitting a likely NPE here.
Manuel
On Mon, 19 Sep 2005 08:57 pm, Luca Furini wrote:
Hi all.
I'm noticing a strange problem: fop builds correctly, but then it
seems it is not working at all.
I'm using it from the command line under win xp, and even if I don't
get any run time exception no output file is created. Launching fop
with no parameters, or with wrong parameters (missing files ...) does
not create any error: simply, nothing happens.
I have compiled fop on two different computers, so I don't think this
is a local configuration problem.
Hasn't anyone else noticed this?
Regards
Luca
List and Item display
Hi All! I am trying to have the listitems in an orderedlist to display numerical values. The XSLFO template below that I've developed is displaying zeros 0 for all the list items. Could someone please inform me what I am doing incorrectly here, or the correct way to accomplish this task? Thanks in advance for your help! ~S.E. ===XSLFO TEMPLATE xsl:template match=orderedlist/listitem/para fo:list-block provisional-label-separation=4em provisional-distance-between-starts=4em fo:list-item fo:list-item-label start-indent=2mm end-indent=label-end() fo:block xsl:number count=orderedlist/listitem level=any from=manual/ /fo:block /fo:list-item-label fo:list-item-body fo:block start-indent=6mmxsl:apply-templates//fo:block /fo:list-item-body /fo:list-item /fo:list-block /xsl:template ===XML Snippet orderedlist listitem paraFirst list item./para /listitem listitem paraSecond list item./para /listitem listitem paraThird list item./para /listitem /orderedlist The current output (display) is like this: 0 First list item. 0 Second list item. 0 Third list item. This is the output (display) that I want: 1. First list item. 2. Second list item. 3. Third list item. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/
On Sep 19, 2005, at 11:08, Jeremias Maerki wrote: Looks ok on first glance, though I've got a request: Would you please consider installing a checkstyle plug-in into your IDE and configuring the rules file for FOP? Thanks! Dammit! And I thought I had all bases covered... :-( My apologies for this. I hope it didn't cause too much inconvenience. Cheers, Andreas
JPdfUnit
Hi all, fresh on freshmeat: http://freshmeat.net/releases/207188/ Can this be used to provide tests for the PDF renderer? J.Pietschmann
Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/
On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote: On Sep 19, 2005, at 11:08, Jeremias Maerki wrote: Looks ok on first glance, though I've got a request: Would you please consider installing a checkstyle plug-in into your IDE and configuring the rules file for FOP? Thanks! Dammit! And I thought I had all bases covered... :-( My apologies for this. I hope it didn't cause too much inconvenience. Ok, corrected most of my violations. BTW: is it necessary for the FOTree tests to have an Apache header as well? Let me know, and I'll add them too... Cheers, Andreas
rtf ignoring TableBody et al
I am using trunk code and with an input FO that produces excellent PDF output, I am seeing the following messages about lots of ignored instances. After checking RTFHandler.java, it seems they are omitted from the very large instance-switch in invokeDeferredEvent. My question is if this is in progress code or if RTFHandler has been broken like this for a while? I tried to be clever and hack support for them back in, but it went very poorly. Thanks for your time, -- /v\atthew Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] Ignored deferred event for [EMAIL PROTECTED] ... this continues for quite a while ...
DO NOT REPLY [Bug 36720] New: - erroneous cell overlap code
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=36720. 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=36720 Summary: erroneous cell overlap code Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Fop-HEAD worked on Friday, but when I refreshed this morning it would no longer render my nested table. I isolated the issue and created a fotree/testcase for it. [junit] org.apache.fop.apps.FOPException: file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38: cell overlaps in column 2 [junit] javax.xml.transform.TransformerException: org.apache.fop.apps.FOPException: file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38: cell overlaps in column 2 [junit] at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:501) [junit] at org.apache.fop.fotreetest.FOTreeTester.runTest(FOTreeTester.java:65) [junit] at org.apache.fop.fotreetest.FOTreeTestSuite$FOTreeTestCase.testMain(FOTreeTestSuite.java:121) [junit] at org.apache.fop.fotreetest.FOTreeTestSuite$1.runTest(FOTreeTestSuite.java:100) [junit] Caused by: org.apache.fop.apps.FOPException: file:///usr/src/cvs/apache/fop/test/fotree/testcases/column-number_nested.fo:29:38: cell overlaps in column 2 [junit] at org.apache.fop.fo.flow.TableCell.bind(TableCell.java:139) [junit] at org.apache.fop.fo.FObj.processNode(FObj.java:121) [junit] at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:271) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36720] - erroneous cell overlap code
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=36720. 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=36720 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |major Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-09-20 00:57 --- Sorry, I'll have a look ASAP. Is caused by my implementation for default column-numbers. Such a simple example, and yet...? Will get back on this tomorrow. -- 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.
