--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> 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
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.)


Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

Reply via email to