Re: Q: What should happen when an image is not found?
Hi, Jeremias Maerki wrote: > On 18.02.2008 17:04:52 Max Berger wrote: >> Dear Fop Devs, >> >> i think this was the original intention of a "processing instruction". > > That's another possibility, yes. > >> I >> really do not see clearly where fox:fail-on-missing-image would go in >> the fo tree. > > I think an extension property/attribute was meant, not an element. > >> A PI could mean: From this point on in the whole document. >> HOWEVER: If fop currently uses no PIs (I am not sure about this), then >> it should be a fox: extension, to make all behavior similar. > > Indeed, we don't use PIs at the moment. And I'm not sure we should. I > wonder how many people know how to work with them. Adrian made the suggestion some time ago of using the fo:declarations element to override configuration on a per-document basis: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200801.mbox/[EMAIL PROTECTED] If some mechanism were to be implemented inside the FO file, I think this approach would be a good one. It’s not as fine-grained as a PI (no means to say “from now on, do this”), but I share Jeremias’ feeling about PIs. >> As for the size: >> >> - Always use the size given if given. >> >> Either: >> - a 0.0001 x 0.0001 pt empty transparent image OR > > Would have to be at least 0.001x0.001pt as this is our minimal > resolution. ;-) Feels very HTML-like... > >> - A missing image image, about 1x1 cm: should have a border and a red >> "x" (as seen in web browsers, etc.) > > I think I'd prefer this. It's still a change in FOP's behaviour. But so > many people don't read or ignore FOP's log output, visual feedback is > probably a good idea. +1 Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Update: XML JARs
I get the same kind of errors on my Linux box. I don’t understand why the error under Java 1.4 does not occur when xercesImpl.jar is added to the classpath, since AFAIK we don’t trigger the endorsed mechanism, so the default SAX parser implementation shipped with Java should not be overridden. I guess the simplest is to keep with the status quo, or with your solution #2 if you feel like implementing it. However, I would put only serializer and xercesImpl in the endorsed/ directory, since like I explained [1] I’d consider the other two as regular dependencies (classes not available in the standard library). (That said, newbies will probably download the binaries instead of having to fiddle with the source files.) Vincent [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200801.mbox/[EMAIL PROTECTED] Jeremias Maerki wrote: > I've done some experiments based on our discussion. I removed Xerces and > serializer.jar and moved Xalan-J to a test/lib directory and made it > available only to the test code. Building FOP like this is no problem > but running the test suite on a basic Sun JDK 1.4.2_16 (with no replaced > XML JARs) fails: > > Testsuite: org.apache.fop.layoutengine.LayoutEngineTestSuite > Tests run: 7, Failures: 0, Errors: 1, Time elapsed: 3.547 sec > - Standard Error - > > - --- > > Testcase: block_hyphenation-ladder-count.xml took 1.375 sec > Testcase: block_hyphenation_kerning.xml took 0.094 sec > Testcase: block_hyphenation_no-wrap.xml took 0.031 sec > Testcase: block_uax14_linebreaking_hyph.xml took 0.016 sec > Caused an ERROR > Dokumentwurzelelement fehlt > org.xml.sax.SAXParseException: Dokumentwurzelelement fehlt > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376) > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3364) > at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:668) > at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) > at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) > at > org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:185) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151) > at > org.apache.fop.layoutengine.LayoutEngineTester.runTest(LayoutEngineTester.java:139) > at > org.apache.fop.layoutengine.LayoutEngineTestSuite$LayoutEngineTestCase.testMain(LayoutEngineTestSuite.java:214) > at > org.apache.fop.layoutengine.LayoutEngineTestSuite$1.runTest(LayoutEngineTestSuite.java:193) > > Testcase: footnote_in_inline.xml took 0.031 sec > Testcase: inline_border_padding_hyphenate.xml took 1.297 sec > Testcase: inline_border_padding_hyphenate_de.xml took 0.672 sec > > > "Dokumentwurzelelement fehlt" translates to "Document root element > is missing". Probably a bug in Crimson. > > Even worse on Sun JDK 1.5.0_14 and 6.0_03: > > [junit] Testcase: > test_fonts_directory_recursive.xconf(org.apache.fop.config.FontsDirectoryRecursiveTestCase): > Caused an ERROR > [junit] org/apache/xml/serializer/TreeWalker > [junit] java.lang.NoClassDefFoundError: > org/apache/xml/serializer/TreeWalker > [junit] at > org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:823) > [junit] at > org.apache.fop.render.pdf.BasePDFTestCase.convertFO(BasePDFTestCase.java:88) > [junit] at > org.apache.fop.config.BaseUserConfigTestCase.convertFO(BaseUserConfigTestCase.java:71) > [junit] at > org.apache.fop.config.BaseConstructiveUserConfigTestCase.testUserConfig(BaseConstructiveUserConfigTestCase.java:38) > [junit] > > and... > > junit-layout-standard: > [echo] Running standard layout engine tests > [junit] Testsuite: org.apache.fop.layoutengine.LayoutEngineTestSuite > [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec > [junit] > [junit] Null Test: Caused an ERROR > [junit] null > [junit] java.lang.reflect.InvocationTargetException > [junit] Caused by: java.lang.NoClassDefFoundError: > org/apache/xml/serializer/ExtendedContentHandler > [junit] at > org.apache.xalan.processor.XSLTSchema.build(XSLTSchema.java:325) > [junit] at > org.apache.xalan.processor.XSLTSchema.(XSLTSchema.java:72) > [junit] at > org.apache.xalan.processor.StylesheetHandler.(StylesheetHandler.java:1290) > [junit] at > org.apache.xalan.processor.TransformerFactoryImpl.newTemplatesHandler(TransformerFactoryImpl.java:376) > [junit] at > org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:867) > [junit] at > org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:776) > [junit] at > org.apache.fop.layoutengine.LayoutEngineTestSuite.readDisabledTestcases(LayoutEngineTestSuite.java:71) >
Re: Update: XML JARs
>- Oorspronkelijk bericht - >Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] > >I guess the simplest is to keep with the status quo, or with your >solution #2 if you feel like implementing it. However, I would put only >serializer and xercesImpl in the endorsed/ directory, since like >I explained [1] I’d consider the other two as regular dependencies >(classes not available in the standard library). FWIW: running FOP out-of-the-box to me is also a much more important concern than removing those JARs, so I'm in favor of keeping the status quo for now. Cheers Andreas
Re: Q: What should happen when an image is not found?
Dear Fop devs, On Mit, 2008-02-20 at 10:24 +, Vincent Hennebert wrote: > >> A PI could mean: From this point on in the whole document. > >> HOWEVER: If fop currently uses no PIs (I am not sure about this), then > >> it should be a fox: extension, to make all behavior similar. > > > > Indeed, we don't use PIs at the moment. And I'm not sure we should. I > > wonder how many people know how to work with them. Probably very few - and if fop does not use them, it is not consistent to start using them. > > Adrian made the suggestion some time ago of using the fo:declarations > element to override configuration on a per-document basis: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200801.mbox/[EMAIL > PROTECTED] This idea sounds really reasonable and consitent. Please note however, that XSL fo specified (color-profile)+ as content for fo:declarations at some point, which would make some documents non-conformant. So +1 for this one :) > >> As for the size: > >> > >> - Always use the size given if given. > >> > >> Either: > >> - a 0.0001 x 0.0001 pt empty transparent image OR > > > > Would have to be at least 0.001x0.001pt as this is our minimal > > resolution. ;-) Feels very HTML-like... > > > >> - A missing image image, about 1x1 cm: should have a border and a red > >> "x" (as seen in web browsers, etc.) > > > > I think I'd prefer this. It's still a change in FOP's behaviour. But so > > many people don't read or ignore FOP's log output, visual feedback is > > probably a good idea. > > +1 ok, sounds good. +1 > Vincent mfG Max Berger e-mail: [EMAIL PROTECTED] -- OpenPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me and my work please see http://max.berger.name signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Update: XML JARs
On Wed, Feb 20, 2008 at 11:37:42AM +, Vincent Hennebert wrote: > I get the same kind of errors on my Linux box. I don???t understand why > the error under Java 1.4 does not occur when xercesImpl.jar is added to > the classpath, since AFAIK we don???t trigger the endorsed mechanism, so > the default SAX parser implementation shipped with Java should not be > overridden. Probably due to the services directory in xercesImpl.jar, which points to Xerces as the SAXParserFactory implementation. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Update: XML JARs
[EMAIL PROTECTED] wrote: FWIW: running FOP out-of-the-box to me is also a much more important concern than removing those JARs, so I'm in favor of keeping the status quo for now. Seconded. J.Pietschmann
Re: Q: What should happen when an image is not found?
Vincent Hennebert wrote:
Adrian made the suggestion some time ago of using the fo:declarations
element to override configuration on a per-document basis:
[snip]
It’s not as fine-grained as a PI (no
means to say “from now on, do this”), but I share Jeremias’ feeling
about PIs.
From my experience, a mechanism saying “from now on, do this” is
likely to confuse a non-trivial amount of users.
I think there should be the following hierarchy (which is already
complex enough)
- config file
- overridden by command line arguments
- overridden on a per document basis by extension elements in the
fo:declarations section
- overridden on a per element basis by extension attributes on the
element
- overridden by specific "force" command line arguments ("force
all warnings/problems to be fatal" may be the only one of this kind)
J.PIetschmann
