You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Carl Buxbaum <cb...@bamboorose.com> on 2017/11/21 15:09:18 UTC
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.
Re: feature request
Posted by Carl Buxbaum <cb...@bamboorose.com>.
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" <si...@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:cbuxbaum@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.
>
RE: feature request
Posted by Simon Steiner <si...@gmail.com>.
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:cbuxbaum@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.