Andreas,as said previously: All this is currently "future" discussion, as the last patch is sufficient for now, and I'll probably not revisit this for a while. So this mail is just for the archive, for me to come back to it later :)
Am 08.07.2007 um 22:45 schrieb Andreas L Delmelle:
Now the second issue (and this requires further investigation first, so it will be for post-0.94) is that the "image" should have access to its surrounding context, in particular attributes like foreground-color, font-size, etc.. This is of lower priority, as these can be set explicitly within MathML context.How do you mean this precisely? Currently, MathML is used in the context of an fo:instream-foreign-object or fo:external-graphic, correct?
Correct.
Isn't it already possible then, for the extension object to get a reference to its parent or grandparent node in the document and get the properties from there?
For instream-foreign-object: correct. For external-object: No, since here I am extending the standard Image mechanism (XMLReader, based on ImageReader), which IMO does not have a reference to the enclosing external-graphic node (it does to FOUserAgent). Although it seems like this would already solve the problem, which would make a (future) patch to support this very small (Image Readers would then have access to their external-object)
Admitted, with the current state of property access --through specific accessors on the FONode subclasses-- this could turn out to be a bit cumbersome, as you would first have to test whether it's a Block, Inline... then explicitly cast it to the right type, and use the public accessors to get the desired information (?) For the information that is available on instream-foreign-object or external-graphic itself, like background-color, your root extension element could do something like: ((AbstractGraphics) getParent()).getCommonBorderPaddingBackground ().backgroundColor;
This looks like it would sove the problem. It doesn't look nice, but that's ok. Having a mechanism like this and having access to the external-object node in the reader could indeed solve this problem. When I revisit this i will explorer this mechanism further - as this could be done without patching FOP here is the plan: a) Provide context support for instream objects first, which allows testing, and investigating how certain properties are inherited within fop. This will also allow me to see if having access to the enclosing element is enough, or if more is needed. b) When this is ready, provide a patch allowing for image-readers to have access to their enclosing as well.
Target for b) is before fop 1.0 comes out :)
Cheers Andreas
Thanks! Max Berger e-mail: [EMAIL PROTECTED] --PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name
PGP.sig
Description: Signierter Teil der Nachricht
