Details

    • Type: Improvement Improvement
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:
      48334

      Description

      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>
      [...]

      1. b48334.diff
        12 kB
        Andreas L. Delmelle
      2. b48334.diff
        14 kB
        Andreas L. Delmelle
      3. b48334.diff
        13 kB
        Andreas L. Delmelle

        Activity

        Hide
        Glenn Adams added a comment -

        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

        Show
        Glenn Adams added a comment - 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
        Hide
        Andreas L. Delmelle added a comment -

        Patch applied as proposed in r1066190 (http://svn.apache.org/viewvc?rev=1066190&view=rev)

        Show
        Andreas L. Delmelle added a comment - Patch applied as proposed in r1066190 ( http://svn.apache.org/viewvc?rev=1066190&view=rev )
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        Attachment b48334.diff has been added with description: revised patch

        Show
        Andreas L. Delmelle added a comment - Attachment b48334.diff has been added with description: revised patch
        Hide
        Andreas L. Delmelle added a comment -

        (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.

        Show
        Andreas L. Delmelle added a comment - (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.
        Hide
        Simon Pepping added a comment -

        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.

        Show
        Simon Pepping added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        Attachment b48334.diff has been added with description: slightly revised prototype

        Show
        Andreas L. Delmelle added a comment - Attachment b48334.diff has been added with description: slightly revised prototype
        Hide
        Andreas L. Delmelle added a comment -

        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...

        Show
        Andreas L. Delmelle added a comment - 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...
        Hide
        Andreas L. Delmelle added a comment -

        Attachment b48334.diff has been added with description: prototype implementation

        Show
        Andreas L. Delmelle added a comment - Attachment b48334.diff has been added with description: prototype implementation
        Hide
        Andreas L. Delmelle added a comment -

        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).

        Show
        Andreas L. Delmelle added a comment - 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).

          People

          • Assignee:
            fop-dev
            Reporter:
            ms419
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development