--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > I'm just being curious: did my remarks turn out to > be helpful here? (I just > want to check to what extent I'm beginning to > understand the internals of > the application...) >
I was happy to see you going through the source code. Also welcome to the FOP-DEV list. Main issue is that we could not just switch from SVGDOMImplementation to ExtendedSVGDOMImplementation as Thomas (I believe) had thought. The latter is not really a superclass of the former--they're different sets of elements with different namespaces. (To that end, the superclass-subclass relationship of these two classes in the Batik code does not seem correct to me.) So I just added in one more ElementMapping subclass in the fo.extensions.svg package for the Batik Extension elements. > I'm not sure which of these problems are already > being worked on, and as I > most certainly do not want to end up 'spamming' > fop-dev with a bunch of > pseudo-bugs Don't kill yourself here--the majority of 1.0 is still unimplemented. I was strictly more concerned about the Batik extensions working for this particular point. (For sanity retention, I try to narrow my concerns to one or two topics for each week.) > CSS seems to silently presuppose that > if no bg-c is explicitly > defined, table-cell would inherit the value of its > parent - in this case > table-row, but as none was specified there either, > one would expect it to be > the color of table-body... ] Well, not everything is inherited in the XSL FO standard--http://www.w3.org/TR/xsl/slice7.html#background-color says bg-c is not inherited (but evidently can be if "inherit" is chosen as a value, so I'm not sure how FOP should handle this.) Glen __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
