http://thread.gmane.org/gmane.text.xml.fop.user/29778 http://thread.gmane.org/gmane.text.xml.xsl.general.mulberrytech/77602 I wish FOP supported the xml:base="" attribute, http://www.w3.org/TR/xmlbase/ e.g. I wish the following worked, [...] <fo:block xml:base="http://ica-atom.org/docs/index.php?title=File:UM-2.1.png"> <fo:external-graphic src="url(/docs/images/b/bb/UM-2.1.png)"/> </fo:block> [...]
Created attachment 26496 [details] prototype implementation Attached patch adds a rough prototype implementation of xml:base by means of a new URIProperty (+ small fotree testcase). Currently, in addition to xml:base, only the src property has been marked as a URIProperty in FOPropertyMapping, but a quick glance through the spec reveals others that might use this functionality. Nothing really changes if it is not used, except that the value of "src" is now validated against the URI syntax. I assume that, if an exception were to arise there, this would normally happen further downstream anyway. If xml:base is used, relative URIs on the element itself or its descendants will be resolved against it. The property is assumed to be inherited. If it is itself specified as a relative URI, then it will be resolved against the inherited value. If no inherited value is present, it will lead to behavior similar to a regular relative URI. That is, given: <fo:block xml:base="./resources/"> <fo:external-graphic src="images/image-1.png" /> </fo:block> The "src" property will be resolved to "resources/images/image-1.png", which will trigger the usual relative URI resolution downstream. It will be stored in resolved form only. The originally specified relative URI is not retained (although that could easily be added).
Created attachment 26500 [details] slightly revised prototype Minor corrections plus some additional tests. For backward compatibility, URIProperty works such that, without xml:base, it will the yield exactly the same value as before (including the url() function call, if present). Before the patch, the src property was just parsed as a StringProperty. This causes a slight inconsistency in the resulting values, shown in the testcase. A relative URI resolved against a relative xml:base yields a normalized string representation, while in the regular case without xml:base, no resolution happens, so there we would get the value as specified in the FO source. Strictly speaking, both are equivalent, yet not identical...
Note that, apart from fo:external-graphic, the src property also applies to fo:color-profile and fo:external-document. If xml:base is set on fo:root or fo:declarations, the prototype will work for those cases as well. With only a trivial change (untested), the same could be applied to external-destination. That would allow one to create a document with a fo:block containing images from a specific website, and in the same block, specify relative URIs as external-destinations. If xml:base is set correctly, those links will then point to locations on the website the images are hosted on. Thinking more about it, it does seem like a powerful addition to being able to set a single base URI via the user-config. That case could also easily be covered by setting xml:base on the fo:root. Benefit being that the base-uri is available in the source (instead of only in a configuration that, perhaps, only exists while the source is rendered). Implementing xml:base in the user-config itself is an entirely different story, but there might be interesting use-cases for that as well.
The idea and your implementation look good. Some code is missing: xml:base should be listed as a valid property in PropertyList.addAttributesToList. The backward compatibility case causes some complexity, but it seems to work well. I think that the class requires a better explanation of this case: when it applies and how it is handled. Having that explanation in this bug report does not suffice.
(In reply to comment #4) > The idea and your implementation look good. Some code is missing: xml:base > should be listed as a valid property in PropertyList.addAttributesToList. Oops! Forgot to add that one... :-( > The backward compatibility case causes some complexity, but it seems to work > well. I think that the class requires a better explanation of this case: when > it applies and how it is handled. Having that explanation in this bug report > does not suffice. OK, makes sense. I will post a slightly revised patch for final review. Unless anyone objects, this will find its way into FOP Trunk beginning of next week.
Created attachment 26538 [details] revised patch New patch, taking into account the feedback. Some unrelated changes to the affected classes have been committed separately, so the patch now only contains changes relevant to this issue. Change wrt previous version: the String constructor for URIProperty has been made private and marked as the alternate constructor rather than the default one. That seemed to make more sense since that constructor was actually only needed for the backward compatibility case. Come to think of it, the only compatibility issues that arose within our own code, appeared in the fotree tests... Something to take a look at later.
Patch applied as proposed in r1066190 (http://svn.apache.org/viewvc?rev=1066190&view=rev)
batch transition to closed; if someone wishes to restore one of these to resolved in order to perform a verification step, then feel free to do so