Re: custom properties on xsl:fo element possible?
Just did. :-) Thanks for the patch, Nils. I'll have a go at implementing my more extensive proposal on foreign namespaces a little later. On 21.02.2006 14:19:42 Nils Meier wrote: Hi Andreas, Your point is definitely valid, and I think I'm going to apply this change. If no other devs object to this, that is... (Later we may add an 'else' to that 'if', to deal with possible extension properties.) sounds good to me - other devs is that o.k. to put in? Jeremias Maerki
Re: custom properties on xsl:fo element possible?
Hi Andreas, Your point is definitely valid, and I think I'm going to apply this change. If no other devs object to this, that is... (Later we may add an 'else' to that 'if', to deal with possible extension properties.) sounds good to me - other devs is that o.k. to put in? Thanks Nils Die wohlfeilste Art des Stolzes hingegen ist der Nationalstolz. Denn er verrät in dem damit Behafteten den Mangel an individuellen Eigenschaften, auf die er stolz sein könnte ... Aber jeder erbärmliche Tropf ... ergreift das letzte Mittel, auf die Nation, der er gerade angehört, stolz zu sein ... Arthur Schopenhauer
Handling foreign content (was: Re: custom properties on xsl:fo element possible?)
As I hinted at on fop-users, I'd like to look at this in a more general way. Nils raises a valid point. FOP should not complain so loudly about foreign properties. The same applies to elements. With my recent changes we got rid of complaints inside SVG sub-documents as they, too, can contain elements and attributes from arbitrary namespaces that FOP doesn't know anything about. Still, we get complaints from FOP if we have elements in a foreign namespace somewhere in the middle of FO content. Nils' patch is fine as a simple non-final solution. Still, we need some kind of extension mechanism on attribute level at some point and hopefully one that can make use of the property features defined by XSL-FO (inheritance, functions etc.). I have some desire for extension properties on external-graphic and instream-foreign-object: cache hints, rendering hints for extensions. FOP should also stop to complain about certain foreign elements. The complaints are fine as a debugging aid, for example if someone makes a mistake with the namespace URI or the name of an element in a particular namespace. Here's where I got the idea that we could provide for a list of namespace URIs which are simply silently ignored (instead of having to write a FOP extension for each namespace). If someone has a reference to a namespace URI in his documents that FOP doesn't know about he could add that namespace URI to that list and FOP will fall silent over it. The same list could be used for handling foreign attributes. This way you still get important feedback if you've done anything wrong, but can tell FOP to shut up where necessary. WDYT? On 18.02.2006 10:21:36 Andreas L Delmelle wrote: On Feb 18, 2006, at 07:45, Nils Meier wrote: Hi Nils, I looked into this some more and it seems to me that if PropertyList would check attribute namespaces before trying to convert them this would be handled nicely (i figured out that fobj has a reference to the responsible element so accessing its namespace is easy). I might be going out on a limb - maybe logging unknown attributes is the right thing to do(?) But why would FOP even consider attributes out of a non-fo namespace? well, here's a patch that does the namespace check just FYI. Looking forward to hear what you guys think. Your point is definitely valid, and I think I'm going to apply this change. If no other devs object to this, that is... (Later we may add an 'else' to that 'if', to deal with possible extension properties.) Thanks for the feedback! Cheers, Andreas Jeremias Maerki
Re: custom properties on xsl:fo element possible?
On Feb 18, 2006, at 07:45, Nils Meier wrote: Hi Nils, I looked into this some more and it seems to me that if PropertyList would check attribute namespaces before trying to convert them this would be handled nicely (i figured out that fobj has a reference to the responsible element so accessing its namespace is easy). I might be going out on a limb - maybe logging unknown attributes is the right thing to do(?) But why would FOP even consider attributes out of a non-fo namespace? well, here's a patch that does the namespace check just FYI. Looking forward to hear what you guys think. Your point is definitely valid, and I think I'm going to apply this change. If no other devs object to this, that is... (Later we may add an 'else' to that 'if', to deal with possible extension properties.) Thanks for the feedback! Cheers, Andreas
Re: custom properties on xsl:fo element possible?
hi, me again I looked into this some more and it seems to me that if PropertyList would check attribute namespaces before trying to convert them this would be handled nicely (i figured out that fobj has a reference to the responsible element so accessing its namespace is easy). I might be going out on a limb - maybe logging unknown attributes is the right thing to do(?) But why would FOP even consider attributes out of a non-fo namespace? well, here's a patch that does the namespace check just FYI. Looking forward to hear what you guys think. Regards! Nils attribute-namespace-check.patch Description: 2848370949-attribute-namespace-check.patch