Hi,

I wonder if it is a rare enough use case (a valid URL without an actual
image specified) that it would be useful to reject that in the code?  Our
dynamic xml is built up from role based layout fields, and sometimes the
layout does not pass in the particular image field unless it is
deliberately added to the layout.

It would certainly be useful to me!

Carl
 



On 11/21/17, 10:25 AM, "Simon Steiner" <simonsteiner1...@gmail.com> wrote:

>Hi,
>
>You could add something to the xsl to fail if the param is missing. I
>guess
>a url could end with a slash and still return a image.
>
>Thanks
>
>-----Original Message-----
>From: Carl Buxbaum [mailto:cbuxb...@bamboorose.com]
>Sent: 21 November 2017 15:09
>To: fop-dev@xmlgraphics.apache.org
>Subject: feature request
>
>Hello,
>
>We have a number of use cases where an external graphic URL ends up being
>specified with a trailing forward slash (³/³), without an actual image,
>e.g., when @location is empty based upon our dynamic xml.
>
><fo:block text-align="center">
><xsl:variable name="image2">
><xsl:value-of select="attachment/@location" /> </xsl:variable>
><fo:external-graphic src="{$image2}"
>content-width="350px" content-height="350px" /> </fo:block>
>
>
>When we generate the report, the system does a File.list call, resulting
>in
>a needless and time consuming wait for the user when the file store
>contains
>millions of files.  I wonder if this change to
>ExternalGraphic.bind(PropertyList plist) would make sense:
>
>    public void bind(PropertyList pList) throws FOPException {
>        super.bind(pList);
>        src = pList.get(PR_SRC).getString();
>
>        //Additional processing: obtain the image's intrinsic size and
>baseline information
>        url = URISpecification.getURL(src);
>
>        FOUserAgent userAgent = getUserAgent();
>        ImageManager manager = userAgent.getImageManager();
>        ImageInfo info = null;
>        try {
>
>/** suggested fix */
>
>
>            // check if url ends with "/"
>            if (url.trim().endsWith("/")){
>            throw (new FileNotFoundException ("No entity specified at end
>of
>URL"));
>            }
>
>
>/** end suggested fix */
>
>
>            info = manager.getImageInfo(url,
>userAgent.getImageSessionContext());
>        } catch (ImageException e) {
>            ResourceEventProducer eventProducer =
>ResourceEventProducer.Provider.get(
>                    getUserAgent().getEventBroadcaster());
>            eventProducer.imageError(this, url, e, getLocator());
>        } catch (FileNotFoundException fnfe) {
>            ResourceEventProducer eventProducer =
>ResourceEventProducer.Provider.get(
>                    getUserAgent().getEventBroadcaster());
>            eventProducer.imageNotFound(this, url, fnfe, getLocator());
>        } catch (IOException ioe) {
>            ResourceEventProducer eventProducer =
>ResourceEventProducer.Provider.get(
>                    getUserAgent().getEventBroadcaster());
>            eventProducer.imageIOError(this, url, ioe, getLocator());
>        }
>        if (info != null) {
>            this.intrinsicWidth = info.getSize().getWidthMpt();
>            this.intrinsicHeight = info.getSize().getHeightMpt();
>            int baseline = info.getSize().getBaselinePositionFromBottom();
>            if (baseline != 0) {
>                this.intrinsicAlignmentAdjust
>                    = FixedLength.getInstance(-baseline);
>            }
>        }
>    }
>
>
>Is there any use case where it would make sense for the URL to end in a
>slash?  Or am I missing an easy fix to this that would not require a code
>change?  Currently we do some awkward tests of the presence of the
>variable,
>or suggest to our users that the file store be modified to have write and
>execute permissions, but not read permissions, resulting in a quick return
>from the call.
>
>Thanks,
>
>Carl
>
>
>
>________________________________
>DISCLAIMER:
>E-mails and attachments from Bamboo Rose, LLC are confidential.
>If you are not the intended recipient, please notify the sender
>immediately
>by replying to the e-mail, and then delete it without making copies or
>using
>it in any way.
>No representation is made that this email or any attachments are free of
>viruses. Virus scanning is recommended and is the responsibility of the
>recipient.
>

Reply via email to