DO NOT REPLY [Bug 31580] New: - fo:external-graphic does not work when src is an image URL which is in a jar-file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31580.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31580
fo:external-graphic does not work when src is an image URL which is in a jar-file
Summary: fo:external-graphic does not work when src is an image
URL which is in a jar-file
Product: Fop
Version: 0.20.5
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi!
I found a problem when using url instead of file for fo:external-graphic's
src paramater (FOP is 0.20.5 distribution). for example,
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcurl('/my/image/image.gif')/xsl:attribute
/fo:external-graphic
it will work with the following changes in class
org.apache.fop.image.FopImageFactory.java
...
// Try to find the image as a class-resource first (for instance in a jar-
file)...
try {
imgIS = FopImageFactory.class.getResourceAsStream(href);
absoluteURL = FopImageFactory.class.getResource(href);
} catch (Exception e) {
}
if (imgIS == null) {
try {
// try url as complete first, this can cause
// a problem with relative uri's if there is an
// image relative to where fop is run and relative
// to the base dir of the document
try {
absoluteURL = new URL(href);
} catch (MalformedURLException mue) {
// if the href contains onl a path then file is assumed
absoluteURL = new URL(file: + href);
}
imgIS = absoluteURL.openStream();
} catch (MalformedURLException e_context) {
throw new FopImageException(Error with image URL:
+ e_context.getMessage());
} catch (Exception e) {
// maybe relative
URL baseURL = Configuration.getBaseURL();
if (baseURL == null) {
throw new FopImageException(Error with image URL:
+ e.getMessage()
+ and no base URL is specified);
}
try {
/*
This piece of code is based on the following statement in
RFC2396 section 5.2:
3) If the scheme component is defined, indicating that
the reference
starts with a scheme name, then the reference is
interpreted as an
absolute URI and we are done. Otherwise, the
reference URI's
scheme is inherited from the base URI's scheme
component.
Due to a loophole in prior specifications [RFC1630],
some parsers
allow the scheme name to be present in a relative
URI if it is the
same as the base URI scheme. Unfortunately, this
can conflict
with the correct parsing of non-hierarchical URI.
For backwards
compatibility, an implementation may work around
such references
by removing the scheme if it matches that of the
base URI and the
scheme is known to always use the hier_part syntax.
The URL class does not implement this work around, so
we do.
*/
String scheme = baseURL.getProtocol() + :;
System.out.println(scheme + scheme);
if (href.startsWith(scheme)) {
href = href.substring(scheme.length());
}
System.out.println(href after + href);
absoluteURL = new URL(baseURL, href);
} catch (MalformedURLException e_context) {
throw new FopImageException(Invalid Image URL - error on
relative URL :
+ e_context.getMessage());
}
}
}
// If not, check image type
ImageReader imgReader = null;
...
DO NOT REPLY [Bug 24658] New: - fo:external-graphic does not support SVG when src is an url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24658.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24658
fo:external-graphic does not support SVG when src is an url
Summary: fo:external-graphic does not support SVG when src is an
url
Product: Fop
Version: 0.20.5
Platform: All
OS/Version: Other
Status: NEW
Severity: Critical
Priority: Other
Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi!
I found a problems when using urls instead of files for fo:external-graphic's
src paramater.
xsl:param name=imagebasehttp://localhost:8080/img/xsl:param
...
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcurl('xsl:value-of
select=$imagebase//SomePics.svg')/xsl:attribute
/fo:external-graphic
OR
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcxsl:value-of
select=$imagebase//SomePics.svg/xsl:attribute
/fo:external-graphic
does not work for IIS at all.
It works in 95% of all cases with APACHE.
It worka in 100% of all cases with files.
I get no exception(s) and - no pictures.
Any ideas?
FOP is 0.20.5 distribution.
Regards,
Joachim
DO NOT REPLY [Bug 24527] New: - [PATCH] RTF: added support for fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527 [PATCH] RTF: added support for fo:external-graphic Summary: [PATCH] RTF: added support for fo:external-graphic Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, i'd like to submit the attached patch, which adds support for fo:external- graphic. Currently there is only PNG and EMF format supported. Thanks Peter Herweg
DO NOT REPLY [Bug 24527] - [PATCH] RTF: added support for fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527 [PATCH] RTF: added support for fo:external-graphic --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 13:05 --- Created an attachment (id=8997) patch file
DO NOT REPLY [Bug 24527] - [PATCH] RTF: added support for fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24527 [PATCH] RTF: added support for fo:external-graphic [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 14:03 --- Committed. Thanks.
DO NOT REPLY [Bug 15855] - can't size the svg image in fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855 can't size the svg image in fo:external-graphic --- Additional Comments From [EMAIL PROTECTED] 2003-01-08 14:14 --- It seems it is bad but common practice! I have the same problem here with SVG images created from Adobe Illustrator 10. Even the samples of batik are without the units. Is there a workarround how th get FOP to resize such images? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15855] - can't size the svg image in fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855 can't size the svg image in fo:external-graphic [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-01-07 20:21 --- I guess you use measurements without units or measurements in pixels within your SVG. This is bad practice, user agents are not required to use any particular algorithm for mapping this into real lengths Use measurements in a real length unit, like cm or in. The height and width on the top level svg element should be the same as on the fo:external-graphics element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15855] New: - can't size the svg image in fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15855 can't size the svg image in fo:external-graphic Summary: can't size the svg image in fo:external-graphic Product: Fop Version: all Platform: Other OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: svg AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] work with PNG fo:external-graphic src=file:test.png width=10cm height=10cm/ doesn't work with SVG fo:external-graphic src=file:test.svg width=10cm height=10cm/ In java, SVG is display with 100dpi, but can convert to pdf through FOP, it use 72dpi and make the image larger than I expect. Any fix on the way? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15165] New: - SVG Renderer does not stop properly if fo includes fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15165 SVG Renderer does not stop properly if fo includes fo:external-graphic Summary: SVG Renderer does not stop properly if fo includes fo:external-graphic Product: Fop Version: 0.20.4 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The svg renderer doesn't stop properly if there are fo:external-graphic ... elements in the fo document. But FOP creates an svg document which is ok, but there is no information about the image in it. Rendering the same fo document to PDF works fine. Here is a sample xsl:fo code: ... fo:page-sequence master-reference=simple fo:flow flow-name=xsl-region-body fo:external-graphic src=bild3.gif/ fo:block The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. /fo:block .. And that the svg document FOP produces: ?xml version=1.0 encoding=ISO-8859-1? svg contentScriptType=text/ecmascript width=595.0 zoomAndPan=magnify contentStyleType=text/css height=842.0 preserveAspectRatio=xMidYMid meet xmlns=http://www.w3.org/2000/svg; version=1.0 g id=Page-1 style=font-family:sanserif;font-size:12 transform=translate(0,0.0) rect width=595.0 x=0.0 height=842.0 y=0.0 style=fill:none;stroke:black/ text x=70.866 y=171.69598 The /text text x=99.466 y=171.69598 Extensible /text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15119] New: - fo:external-graphic and border properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15119. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15119 fo:external-graphic and border properties Summary: fo:external-graphic and border properties Product: Fop Version: 0.20.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I want to render a graphic inside a box with the following properties : fo:external-graphic src=graph.png width=4in border-color=black border-width=thin border-style=solid/ the box is missing despite you mention that FOP is full compliant with these properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: [RT] Proprietary extension to fo:external-graphic
Considering PDF only, I see prefabricated image XObjects as a very powerful feature. Extracting image XObjects from PDF files and storing them for use by the renderer brings two advantages: a) saves CPU and memory at a maximum b) the user controls image representation/handling in PDFs. Writing an extract program and progamming the renderer is straightforward, caching is solved for PDF. Remains to tell FOP how to handle these external-graphics. Hansuli Anderegg Sample image XObject to be inserted into PDF file by PDF renderer 21 0 obj === adjust PDF object ID /Type /XObject /Subtype /Image /Name /Im6 /Length 89957 === original PNG file is 56KB /Width 256 === in pixels /Height 256 === in pixels /BitsPerComponent 8 /ColorSpace /DeviceRGB /Filter [ /ASCII85Decode /FlateDecode ] stream GarT@BuGTQ2\N - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
J.Pietschmann wrote: I think it would be prudent to follow the same for fo:external-graphics and fo:color-profile, on the ground that FOs may be rendered out of order and, even more important, it is not clear whether multiple renderings of an external graphic in a static content, table header/footer or a marker should result in multiple access to the source. Unfortunately, the spec doesn't even mention this issue. btw, what about raising the issue on xsl-editors? Definitely a lot of things are implied, but actually xsl spec says just nothing. - Caching images across renderings definitely is an issue too (think of the company logo in each page header in every document), but FOP shouldn't solve this. I imagine a SourceResolver interface which gets an URL and optional content type and returns a XMLReader/InputSource pair. In case of binary image formats the default implementation returns a null parser. People who want to cache images across renderings can implement their own resolver which can do the caching. The Cocoon crowd will certainly rejoice (no more memory leaks due to FOP caching, access to Cocoon caching and Cocoon internal pipelines and other advantages). Good idea, worth to be added to the feature request list in order not to be forgotten. - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. I don't get it a little bit, why error should be generated? What's wrong with reloading an image each time it's referenced? - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). This one looks dubious for me. Can we add any new functions to the core library? Extension functions in different namespace like we used to in xpath are certanly not allowed in xsl as FunctionName here is NCName in contrast to QName in xpath. One more fault in the spec I think. :( -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wed, 06 Nov 2002 23:06:53 +0100 J.Pietschmann wrote: snip/ Conclusions and ideas so far: - FOP should cache external graphics during a rendering and by default clear the cache afterwards. ok. - Caching images across renderings definitely is an issue too (think of the company logo in each page header in every document), but FOP shouldn't solve this. I imagine a SourceResolver interface which gets an URL and optional content type and returns a XMLReader/InputSource pair. In case of binary image formats the default implementation returns a null parser. People who want to cache images across renderings can implement their own resolver which can do the caching. The Cocoon crowd will certainly rejoice (no more memory leaks due to FOP caching, access to Cocoon caching and Cocoon internal pipelines and other advantages). But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. So, I may not be so far off the mark after all. - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). I believe both would be welcome by many users for other purposes too (whether that't a good idea is another matter). One of the possible concerns are usually name clashes with future XSLFO extensions. Using prefixed identifiers like fox:concat() would be a solution, I'm somewhat uneasy with using XML namespace mechanisms within values for XML attributes. In fact, I think its abuse, but I can't offer much better ideas either. I think you've got me wrong what I meant with dynamic URLs. I called the URL dynamic if the same URL can deliver a different content with each call. For example something similar to your example: http://ts.com/get-time.cgi Each time the URL gets called it returns a different image showing a clock giving the current time. It's a problematic discussion, somewhat. We're talking about image caching but there are at least two separate kinds: - Caching of images inside one processing run (which I consider the renderer's duty to a certain degree. Of course, the layout engine has to determine the extents of the image before the renderer goes into action) - Caching of images over a longer time and between processing runs. I agree that a specialized SourceResolver is a good thing but I still wonder about the decoding work. I was primarily wondering about the second kind of caching, but the discussion went stringly towards the first kind. Anyway, I'm still somewhat unsure about all this. Maybe we have to set up a new page in Betrand's Wiki to create a little specification for the image caching. This would also help as a discussion base if we have to contact the XSL:FO WG as Oleg suggests. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? I think so. But nevertheless that would be a cool feature. Consider such a real use case: one have image stored in an application jar file. At the moment I think FOP cannot handle such case, but having SourceResolver we can delegate source URI resolving to a user, like URIResolver does and one can easily return us kind of stream, e.g. new InputSource(getClass().getResourceAsStream(/path/to/foo.gif)) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: - Caching images across renderings But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? Right. Next try: provide a layered set of interfaces: - SourceResolver: resolves URI to XMLReader+InputSource. Used for, well, source resolving for graphics, color profiles, fonts, font metrics, perhaps config files, whatever. Can be hooked into for URI mapping, custom protocols, on the fly generation, simple caching. Default implementation similar to the common javax.xml.transform.URIResolver, with a few twists (must peek into the stream to check for XML unless forced by content type). - ImageResolver: resolves a URI+some properties (which?) into a FOPImage. Default implementation uses SourceResolver to get a stream and whether it is an XML stream, detects image type (unless forced by content type). Can be hooked into for advanced image caching (still call the default implementation for doing the image creation). - FontResolver: Same for fonts. - FontMetricsResolver: for completeness, or fold this into the FontResolver. - ColorProfileResolver, : Just to be complete, or use SourceResolver directly. - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. So, I may not be so far off the mark after all. Revised thoughts: Two control attributes - tentatively: fox:cache + yes (default): keep the FOPImageObject (for this rendering run) + no: discard it immediately after rendering. Use this to prevent large images which occure only once to take up memory indefinitely. Problem: how should this be handled in static content, markers, table headers/footers with omit-header-at-break=false? Perhaps discard with FO rather than discard after rendering? - tentatively: fox:access + once (default): do not access the source if it has already been accessed, if there is no cached FOPImage, raise an error + use-cached: do not access the source if there is a cached FOPImage, else reload + on-creation: access source while creating this FO unconditionally, replace cached image if there is one. + on-rendering: access source each time this FO is rendered. Don't ask me how this should work together with the resolver stuff above. Perhaps the fox:access stuff is overengineering, don't take it too serious. - Dynamic URLs. I think you've got me wrong what I meant with dynamic URLs. I got it quite right. I should have mentioned I wanted to supply a mechanism which allows the construction of different URIs in case someone wants to use images for page numbers. Maybe we have to set up a new page in Betrand's Wiki to create a little specification for the image caching. This would also help as a discussion base if we have to contact the XSL:FO WG as Oleg suggests. Neat idea. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote: - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. I don't get it a little bit, why error should be generated? What's wrong with reloading an image each time it's referenced? Because it breaks the (FOP) specified semantics that the image is always the same in case the source chooses to supply a different image on each access. But see the other post. - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). This one looks dubious for me. Can we add any new functions to the core library? Can we? Sure. Is it wise to do so? Oh well, get me an asbestos suit quickly! Extension functions in different namespace like we used to in xpath are certanly not allowed in xsl as FunctionName here is NCName in contrast to QName in xpath. One more fault in the spec I think. :( Oops! I didn't notice this. Didn't someone on the XML-DEV list recently mention they prepare for a 2.0? Seems they have to do a lot of home work for this! BTW changing NCName - QName is probably considered an incompatible change, warranting a new release... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote: I think so. But nevertheless that would be a cool feature. Consider such a real use case: one have image stored in an application jar file. At the moment I think FOP cannot handle such case, I didn't try myself, but a jar URI should work. Something like jar:file:///foo/bar.jar#com/experanto/images/logo.gif Sorry, I'm too lazy to look up details. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[RT] Proprietary extension to fo:external-graphic
While investigating the multi-threading issues in the maint-branch I came across the following: Currently, in the context of the PDF renderer, every FopImage is closed as soon as it's written to the target file. The next time the same image/url is used it has to be reloaded. This is not true for the other renderers, where the images are really being cached. The calls to FopImage.close() in PDFXObject are effectively disabling the caching mechanism. But on the other side it enables the correct working of urls that deliver dynamic content (only for PDFs), when the same URL can deliver different content over multiple invocations. Which brings me to my idea. I don't know if we had that before. Wouldn't it solve this problem if we defined a proprietary extension for fo:external-graphic to specify if a given url is not to be cached? The content-type attribute can obviously not be used for that purpose. How about this? fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ Default for disable-caching would be false. This could also be useful for the redesign, where we have the same problem: When can and should we cache an image? Currently, I'm thinking if I should just delete the FopImage.close() method, so the behaviour of image handling is the same for all renderers, but that results in a semantic change for the PDF renderer. To still be able to serve dynamic images the above would be necessary. Any thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: Currently, in the context of the PDF renderer, every FopImage is closed as soon as it's written to the target file. The next time the same image/url is used it has to be reloaded. This is not true for the other renderers, where the images are really being cached. The calls to FopImage.close() in PDFXObject are effectively disabling the caching mechanism. But on the other side it enables the correct working of urls that deliver dynamic content (only for PDFs), when the same URL can deliver different content over multiple invocations. If we are talking about one particular formatting invokation scope, I don't think anybody would rely on dynamic image generation trying to place different images (while with the same URI) on a different pages. Acually the spec says nothing about it, but I believe it's up to formatter when/in which order/how much times to load images as it follows general xsl side-effect free policy. It's probably worth to check how other formatters cache images though. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Thanks for answering. Do you have a pointer to some documentation describing that side-effect free policy? So, do I get you right that the close() calls can safely be removed because the semantic change I described is irrelevant? That would be nice because it's easy to fix. On Wed, 06 Nov 2002 12:33:11 +0200 Oleg Tkachenko wrote: If we are talking about one particular formatting invokation scope, I don't think anybody would rely on dynamic image generation trying to place different images (while with the same URI) on a different pages. Acually the spec says nothing about it, but I believe it's up to formatter when/in which order/how much times to load images as it follows general xsl side-effect free policy. It's probably worth to check how other formatters cache images though. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: Thanks for answering. Do you have a pointer to some documentation describing that side-effect free policy? Unfortunately not. xsl requirements and xsl proposal states intensions for xsl to be side-effect free language, like its dad dsssl, but as side-effect free xslt is now a separate recommendation, xsl-fo is staying in its shadow. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wed, 2002-11-06 at 12:01, Bertrand Delacretaz wrote: On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. That particular extension fox:... is for the pdf bookmarks. (ie. http://xml.apache.org/fop/extensions.pdf the pdf viewer should show the bookmarks) Currently the extension mechanism is only setup for handling xml elements and not for attributes. Anyone can add an extension and I don't really considered it an extension to FO unless you are doing some sort of fo tree/layout/areatree manipulation. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. What sort of jfor extensions are there, what do they do? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 12:31, Keiron Liddle wrote: . . . What sort of jfor extensions are there, what do they do? We have jfor:style to define RTF styles (similar to CSS classes in concept) on the generated RTF elements. A concept that does not exist in XSL-FO as it doesn't make sense when generating printable documents. And also jfor:cmd to set options for the jfor processor, currently used for special tricks/hacks for keep-with stuff. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
fo:external-graphic in PDF
This is how it used to work: o anywhere in FOP formatting - load image, if same URL was not loaded before and find out the space needed for the image. - keep list of processed files. o PDF Renderer: - generate XObject, if XObject of same URL was not generated before. Delete image buffer: partial image cleanup only? - keep list of generated XObjects. - reference/reuse the XObject as often as required in content streams, scaled to different sizes A simple design: o FOP formatting determines space needed = partial reading of image files o Renderers control image processing according to their needs. The PDF renderer does not need any caching: maximum 1 image in memory at a time. - additional attributes for external-graphic might be helpful, e.g. resolution, color model - Isolation image processing in renderers will solve SVG caching more easily. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote:
Jeremias Maerki wrote:
Thanks for answering. Do you have a pointer to some documentation
describing that side-effect free policy?
Unfortunately not. xsl requirements and xsl proposal states intensions
for xsl to be side-effect free language, like its dad dsssl, but as
side-effect free xslt is now a separate recommendation, xsl-fo is
staying in its shadow.
Well, XSLT explicitely specified that document() must always return
the same tree during a transformation run. It does not explicitely
say whether the source is only accessed once or multiple times, and,
quite predictable, Xalan accesses the referenced URL every time it
encounters a document() call (even though it seems to discard the
read tree in favor of the cached tree), while Saxon and libxslt
access the URL exactly once.
I think it would be prudent to follow the same for
fo:external-graphics and fo:color-profile, on the ground that
FOs may be rendered out of order and, even more important, it is
not clear whether multiple renderings of an external graphic in a
static content, table header/footer or a marker should result in
multiple access to the source. Unfortunately, the spec doesn't even
mention this issue.
Mind you, there was already a complaint where someone used a
fo:external-graphic in a page footer for images representing page
numbers and of course didn't get what he expected.
In XSLT, for document(), it can be argued that it should be easy to
arrange for an additional dummy parameter in order to have distinct
URLs, for example
xsl:value-of select=document('http://ts.com/get-time.cgi?start')/
xsl:call-template name=template-to-profile/
xsl:value-of select=document('http://ts.com/get-time.cgi?end')/
Of course, nothing prevents the XSLT processor from fetching both
values first and then going on with evaluating the template in between,
therefore this technique is risky at least.
A similar approach oviously wont work for fetching graphics repressenting
page numbers.
Conclusions and ideas so far:
- FOP should cache external graphics during a rendering and by default
clear the cache afterwards.
- Caching images across renderings definitely is an issue too (think of
the company logo in each page header in every document), but FOP shouldn't
solve this. I imagine a SourceResolver interface which gets an URL and
optional content type and returns a XMLReader/InputSource pair.
In case of binary image formats the default implementation returns a null
parser.
People who want to cache images across renderings can implement their
own resolver which can do the caching. The Cocoon crowd will certainly
rejoice (no more memory leaks due to FOP caching, access to Cocoon
caching and Cocoon internal pipelines and other advantages).
- Fine tuning: A single large image will block a lot of memory during
rendering. A possibility is a fox:cache=no control property. In order
to preserve semantics, a null image is cached for this URL, and an error
is generated in case it is attempted to render the image a second time.
- Dynamic URLs. In order to achive this, we can extend the functions available
in property expressions by concat() and page-number(). I believe both would
be welcome by many users for other purposes too (whether that't a good idea
is another matter). One of the possible concerns are usually name clashes
with future XSLFO extensions. Using prefixed identifiers like fox:concat()
would be a solution, I'm somewhat uneasy with using XML namespace mechanisms
within values for XML attributes. In fact, I think its abuse, but I can't
offer much better ideas either.
Regards
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8202] - fo:basic-link does not work for fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8202. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8202 fo:basic-link does not work for fo:external-graphic [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-26 21:26 --- Enabled links for external-graphic and foreign-inline-objects. Should be in 0.20.5 on the maintenance branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: size of images placed using fo:external-graphic
I look to source code, and IMHO you must modify src/org/apache/fop/images and src/org/apache/fop/images/analyzer classes to suport DPI (extract dpi from file and compute right width/height) Thanx for the info. I did modify these classes, and also ExternalGraphic.java in org/apache/fop/fo/flow. Now what I wan't to know is that the behaviour according to the xsl spec is that images have to be sized as per the size given in the image and default to something like 96/72dpi only when that is not available. But in fop (and it seems antenna house xsl formatter) seems to only render images with 72 dpi unless a size is given. Isn't this a bug in the software? Is something being done about this in the next version of FOP? Ambar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: size of images placed using fo:external-graphic
On Thu, 2002-09-19 at 11:00, Ambar Roy wrote: I look to source code, and IMHO you must modify src/org/apache/fop/images and src/org/apache/fop/images/analyzer classes to suport DPI (extract dpi from file and compute right width/height) Thanx for the info. I did modify these classes, and also ExternalGraphic.java in org/apache/fop/fo/flow. Now what I wan't to know is that the behaviour according to the xsl spec is that images have to be sized as per the size given in the image and default to something like 96/72dpi only when that is not available. But in fop (and it seems antenna house xsl formatter) seems to only render images with 72 dpi unless a size is given. Isn't this a bug in the software? Is something being done about this in the next version of FOP? If you know how to extract the dpi from the file then it should only be a matter of scaling the dimensions. How is the dpi retrieved, is it format specific. If you know how to do it then why not submit a patch and the rest of it should be easy to work out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
size of images placed using fo:external-graphic
Hi, When I place a image using external-graphic without specifying the size of the image, the image is rendered at a fixed dpi (72 dpi perhaps). This happens even if the file has a method of specifying dpi, like JPG files. Why does this happen? According to the XSL spec, the image should be placed as per the size of the image if content-width and content-height is set to auto. I suppose this is a known bug/feature of fop, or I am misinterpreting the XSL spec. Is it a difficult thing to modify the FOP source to achieve this result. I am using FOP-20.4. Can I expect to do this in a reasonable amount of time? I have experience with java and c++ programming, but I haven't really tried to hack the FOP source. Any pointers? Ambar Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: size of images placed using fo:external-graphic
There's only one pointer (i thing). Try to specify width and/or height of fo:external-graphic search list archive http://marc.theaimsgroup.com/?l=fop-devr=1w=2 I look to source code, and IMHO you must modify src/org/apache/fop/images and src/org/apache/fop/images/analyzer classes to suport DPI (extract dpi from file and compute right width/height) Michal -Original Message- From: Ambar Roy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 2:01 PM To: [EMAIL PROTECTED] Subject: size of images placed using fo:external-graphic Hi, When I place a image using external-graphic without specifying the size of the image, the image is rendered at a fixed dpi (72 dpi perhaps). This happens even if the file has a method of specifying dpi, like JPG files. Why does this happen? According to the XSL spec, the image should be placed as per the size of the image if content-width and content-height is set to auto. I suppose this is a known bug/feature of fop, or I am misinterpreting the XSL spec. Is it a difficult thing to modify the FOP source to achieve this result. I am using FOP-20.4. Can I expect to do this in a reasonable amount of time? I have experience with java and c++ programming, but I haven't really tried to hack the FOP source. Any pointers? Ambar Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
fo:external-graphic
Hello, I have to make a FOP customization for processing the fo:external-graphic statement.(Because the imges are stored in a strange way which i dont want to explain in details) What classes should i take a look at ? Whats the best entry point for that ? Thank you very much , Holger Prause - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:external-graphic
I have to make a FOP customization for processing the fo:external-graphic statement.(Because the imges are stored in a strange way which i dont want to explain in details) Are you sure that this is really necessary? It would be interesting to know what exactly makes you believe you need to do that. URLs are a pretty flexible concept and you can always put in your own way of retrieving documents/images. What classes should i take a look at ? Whats the best entry point for that ? Basically this is everything in org.apache.fop.image, especially FopImageFactory. That's were the various formats are loaded. The analyzer subpackage is responsible for parsing some attributes like height and width from the image, before the whole image is loaded during rendering time. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1474] - fo:external-graphic rendered as block level object
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1474 fo:external-graphic rendered as block level object [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 19:52 --- Fixed in 0.20.3, even the line height is adjusted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4262] - Infinite loop when using fo:external-graphic (Fop 0.20.1)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4262. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4262 Infinite loop when using fo:external-graphic (Fop 0.20.1) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 12:38 --- *** This bug has been marked as a duplicate of 3475 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problems with fo:external-graphic
Hello Michael, Do you still have the same problem ? (SVGDocument class not found ?) I've got the same problem. It heavily depends on your tomcat version you are using. A quick hack for me was to move batik.jar from my WEB-INF/lib directory to Tomcat's common/lib. It works, but it's not very cool if you wish to make a deployable archive (a WAR file), because you have to install the WAR, ANDTHEN : Batik.jar in common/lib. Ithink the problem comes from Tomcat itself, in the way it loads the jar files. The custom class loaders behaves totally differently between Tomcat 3.2 and Tomcat 4.0.x. And even between Tomcat 4.0.1, 2 and 3 I donthave the problem with Tomcat 4.0.1 (jdk1.3.1on Linux and on Windows2K) and the problem appears with Tomcat 4.0.3 on W2K. Did you find another solution to this problem ? Guillaume "Michael Schifferdecker" [EMAIL PROTECTED]wrote Hello all,I have a problem with fo:external-graphic.I use a Servlet to do PDF generation together with a test style sheet whichproduces FO-code in which the following fo:external-graphic is contained:...fo:external-graphic src="file:///c:/xml_space/lohnsteuer/fd_logo.gif"height="0.58cm" width="2.71cm"/...When I use this under jBuilder with integrated Apache Tomcat 3.2 to includethe GIF fd_logo.gif into the PDF everything works fine.But: after the whole application is distributed to my stand alone Tomcat 4.0server problems occur (see following exception).The error occurs with FOP 0.20.2RC and with 0.20.3 also.What's the cause for this?What alternatives do I have?Best regards, Michael(exception information follows)exception root cause... java.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocumentcomplete exception as follows...type Exception reportmessage Internal Server Errordescription The server encountered an internal error (Internal Server Error)that prevented it from fulfilling this request.exceptionjavax.servlet.ServletException: Servlet execution threw an exception atroot causejava.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocument atorg.apache.fop.image.analyser.ImageReaderFactory.Make(ImageReaderFactory.java:45) at org.apache.fop.image.FopImageFactory.Make(FopImageFactory.java:100) at org.apache.fop.fo.flow.ExternalGraphic.layout(ExternalGraphic.java:125) at org.apache.fop.fo.flow.Block.layout(Block.java:259) at org.apache.fop.fo.flow.TableCell.layout(TableCell.java:263) at org.apache.fop.fo.flow.TableRow.layout(TableRow.java:344) at org.apache.fop.fo.flow.TableBody.layout(TableBody.java:172) at org.apache.fop.fo.flow.Table.layout(Table.java:226) at org.apache.fop.fo.flow.Block.layout(Block.java:259) at org.apache.fop.fo.flow.StaticContent.layout(StaticContent.java:78) atorg.apache.fop.fo.pagination.PageSequence.layoutStaticContent(PageSequence.java:413) atorg.apache.fop.fo.pagination.PageSequence.formatStaticContent(PageSequence.java:362) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:302) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:191) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:178) at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1398) atorg.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1007) atorg.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1255) atorg.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:380) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:908) at org.apache.fop.apps.Driver.render(Driver.java:459) at org.apache.fop.apps.Driver.run(Driver.java:542) atformdirekt.pdfgen.POSTReceiveServlet.renderFO(POSTReceiveServlet.java:145) at formdirekt.pdfgen.POSTReceiveServlet.doPost(POSTReceiveServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at.
RE: fo:external-graphic question
Thank you, absolute file paths definitely help when using static images. However, I have servlets that produce PNG graphs. I don't think I can specify an absolute file path for dynamically generated images. -Original Message- From: Matt Savino [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 1:09 AM To: [EMAIL PROTECTED] Subject: Re: fo:external-graphic question Ours is an SSL site. Like I wrote I just sue the absolute file path below. It works for all the Unix boxes. PDF imbeds the image anyway, rather than just linking to it and letting the browser server it up like HTML does. So you shouldn't see that secure-to-insecure error. Todd McGrath wrote: Will this work for SSL sites? I have servlets that produce images (graphs) and I'm try to include them in the generated PDFs. I wasn't sure that you could use relative path for src attribute? Since I wasn't able to get it working, I needed to create a separate site in order to use absolute path to servlets (example: http://localhost/Pie, where Pie is the graph producing servlet) Obviously, I would like to use relative so users do not see pop-up message about not secure Is anyone using FOP in SSL enabled sites with external-graphic that are not static filebased? Todd -Original Message- From: Max Froumentin [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: fo:external-graphic question You wrote: If you want a relative URI, why not just use a relative URI? I.e., src=config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBi g.gif? Then the current protocol, host, and directory will be used as the base URI and the relative URI interpreted relative to that. And of course this should ideally be src=url(config/isappdev...) Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:external-graphic question
Ours is an SSL site. Like I wrote I just sue the absolute file path below. It works for all the Unix boxes. PDF imbeds the image anyway, rather than just linking to it and letting the browser server it up like HTML does. So you shouldn't see that secure-to-insecure error. Todd McGrath wrote: Will this work for SSL sites? I have servlets that produce images (graphs) and I'm try to include them in the generated PDFs. I wasn't sure that you could use relative path for src attribute? Since I wasn't able to get it working, I needed to create a separate site in order to use absolute path to servlets (example: http://localhost/Pie, where Pie is the graph producing servlet) Obviously, I would like to use relative so users do not see pop-up message about not secure Is anyone using FOP in SSL enabled sites with external-graphic that are not static filebased? Todd -Original Message- From: Max Froumentin [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: fo:external-graphic question You wrote: If you want a relative URI, why not just use a relative URI? I.e., src=config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBi g.gif? Then the current protocol, host, and directory will be used as the base URI and the relative URI interpreted relative to that. And of course this should ideally be src=url(config/isappdev...) Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:external-graphic question
You wrote: If you want a relative URI, why not just use a relative URI? I.e., src=config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBig.gif? Then the current protocol, host, and directory will be used as the base URI and the relative URI interpreted relative to that. And of course this should ideally be src=url(config/isappdev...) Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo:external-graphic question
Will this work for SSL sites? I have servlets that produce images (graphs) and I'm try to include them in the generated PDFs. I wasn't sure that you could use relative path for src attribute? Since I wasn't able to get it working, I needed to create a separate site in order to use absolute path to servlets (example: http://localhost/Pie, where Pie is the graph producing servlet) Obviously, I would like to use relative so users do not see pop-up message about not secure Is anyone using FOP in SSL enabled sites with external-graphic that are not static filebased? Todd -Original Message- From: Max Froumentin [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: fo:external-graphic question You wrote: If you want a relative URI, why not just use a relative URI? I.e., src=config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBi g.gif? Then the current protocol, host, and directory will be used as the base URI and the relative URI interpreted relative to that. And of course this should ideally be src=url(config/isappdev...) Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
fo:external-graphic question
Has anyone figured out a way to use a relative path with the file:... protocol in fo:external-graphic? The path below works on my Unix boxes. The probem is I develop in an NT box and I'm getting tired of changing my stylesheets every time I upload to the staging or porduction servers. This is the full path which works: fo:external-graphic src=file:///usr/local/weblogic/config/isappdev/applications/RVWebApp1/WEB-I NF/lib/ClinTrialLogoGreenBig.gif / But every time I try to use something like this: fo:external-graphic src=file://./config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLo goGreenBig.gif / I get this error: Error while creating area : Invalid Image URL - error on relative URL : no protocol: null/config/isap pdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBig.gif By the way I still haven't found a way to get the file protocol to work on NT. I have to use HTTP. I could use HTTP on the Unix boxes, but I'd still have to change the port every time. Any ideas, even a pointer would be greatly appreciated. Matt Savino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:external-graphic question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 10:28 30-11-2001, Savino, Matt C wrote: But every time I try to use something like this: fo:external-graphic src=file://./config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLo goGreenBig.gif / I wouldn't expect that to work; that says make a file connection to the host '.', which is the root of the entire Internet. If you want a relative URI, why not just use a relative URI? I.e., src=config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLogoGreenBig.gif? Then the current protocol, host, and directory will be used as the base URI and the relative URI interpreted relative to that. ~Chris - -- Christopher R. Maden, Principal Consultant, HMM Consulting Int'l, Inc. DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training URL: http://www.hmmci.com/ URL: http://crism.maden.org/consulting/ PGP Fingerprint: BBA6 4085 DED0 E176 D6D4 5DFC AC52 F825 AFEC 58DA -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.8 iQA/AwUBPAiLHKxS+CWv7FjaEQJr5wCdEwscbmOp7ol0fOokVKmMTAcJhwQAn0o6 ubOxz9sc2W5+AWugaMWMAbkm =BJwq -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2300] - ERROR: null with fo:external-graphic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2300. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2300 ERROR: null with fo:external-graphic [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4262] - Infinite loop when using fo:external-graphic (Fop 0.20.1)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4262. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4262 Infinite loop when using fo:external-graphic (Fop 0.20.1) --- Additional Comments From [EMAIL PROTECTED] 2001-10-31 06:23 --- I ran into this problem when using a graphic which could not be scaled to fit on the page: - The image is scaled to fit the page-width. - If the resulting image height is bigger than the page height, fop loops in page creation. Seems to me like another form of bugs no. 1773, 2170 and 3400. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Can fo:external-graphic refer to image URLs? (fwd)
Try replacing with amp; is a reserved character and the XML parser is interpreting as the start of an entity before it even reaches fop. -Original Message- From: Jocelyn Paine [mailto:[EMAIL PROTECTED]]On Behalf Of Jocelyn Paine Sent: Wednesday, September 12, 2001 12:24 PM To: [EMAIL PROTECTED] Subject: Can fo:external-graphic refer to image URLs? (fwd) I notice that in all the examples I've seen, the src attribute of fo:external-graphic points at a file. Can it refer to a URL? I wish to generate PDF pages which contain lots of graphs. These graphs are dynamically generated by a servlet which takes a URL containing the data points in its query parameters, plots the graph on the spot, and streams it back. So one of our URLs might look like http://oursite/plotter/?points=1,2;3,4;5,6caption=Growthsize=small I've just tried this with FOP 0.20.1 and get back an error message: Reference to entity points must end with the ';' delimiter. This strongly suggests that it doesn't know how to parse URLs. (The URL is a bit longer than the example above, and contains some escaped characters, but it is valid and understood by both Netscape and IE.) Of course, to be able to convert such dynamic URLs, FOP would need to make an HTTP connection with the server and download the image, but that ought to be possible. So if FOP can't handle images at the end of URLs, my easiest bet might be to amend the source so it can - Java makes that easy enough. Where in the source would I look? Jocelyn Paine http://www.ifs.org.uk/~popx/ +44 (0)7768 534 091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Can fo:external-graphic refer to image URLs? (fwd)
On Wed, 12 Sep 2001, Alistair Hopkins wrote: Thanks! That works. So FOP can handle fo:external-graphic images at the end of an HTTP URL. Try replacing with amp; is a reserved character and the XML parser is interpreting as the start of an entity before it even reaches fop. -Original Message- From: Jocelyn Paine [mailto:[EMAIL PROTECTED]]On Behalf Of Jocelyn Paine Sent: Wednesday, September 12, 2001 12:24 PM To: [EMAIL PROTECTED] Subject: Can fo:external-graphic refer to image URLs? (fwd) I notice that in all the examples I've seen, the src attribute of fo:external-graphic points at a file. Can it refer to a URL? I wish to generate PDF pages which contain lots of graphs. These graphs are dynamically generated by a servlet which takes a URL containing the data points in its query parameters, plots the graph on the spot, and streams it back. So one of our URLs might look like http://oursite/plotter/?points=1,2;3,4;5,6caption=Growthsize=small I've just tried this with FOP 0.20.1 and get back an error message: Reference to entity points must end with the ';' delimiter. This strongly suggests that it doesn't know how to parse URLs. (The URL is a bit longer than the example above, and contains some escaped characters, but it is valid and understood by both Netscape and IE.) Of course, to be able to convert such dynamic URLs, FOP would need to make an HTTP connection with the server and download the image, but that ought to be possible. So if FOP can't handle images at the end of URLs, my easiest bet might be to amend the source so it can - Java makes that easy enough. Where in the source would I look? Jocelyn Paine http://www.ifs.org.uk/~popx/ +44 (0)7768 534 091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Can fo:external-graphic refer to image URLs?
I notice that in all the examples I've seen, the src attribute of fo:external-graphic points at a file. Can it refer to a URL? I wish to generate PDF pages which contain lots of graphs. These graphs are dynamically generated by a servlet which takes a URL containing the data points in its query parameters, plots the graph on the spot, and streams it back. So one of our URLs might look like http://oursite/plotter/?points=1,2;3,4;5,6caption=Growthsize=small I've just tried this with FOP 0.20.1 and get back a dodgy looking error message: Reference to entity points must end with the ';' delimiter. This suggests quite strongly that it doesn't know how to parse URLs. (The URL is a bit longer than the example above, and contains some escaped characters, but it is valid and understood by both Netscape and IE.) Of course, to be able to convert such dynamic URLs, FOP would need to make an HTTP connection with the server and download the image, but that ought to be possible. Jocelyn Paine http://www.ifs.org.uk/~popx/ +44 (0)7768 534 091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[DO NOT REPLY: Bug 2300] ERROR: null with fo:external-graphic
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2300 *** shadow/2300 Sun Jun 24 02:59:09 2001 --- shadow/2300.tmp.29372 Tue Sep 4 14:51:09 2001 *** *** 2,8 | ERROR: null with fo:external-graphic | ++ |Bug #: 2300Product: Fop | ! | Status: NEW Version: | | Resolution:Platform: PC | | Severity: Normal OS/Version: Linux | | Priority: Other Component: images | --- 2,8 | ERROR: null with fo:external-graphic | ++ |Bug #: 2300Product: Fop | ! | Status: NEW Version: 0.15| | Resolution:Platform: PC | | Severity: Normal OS/Version: Linux | | Priority: Other Component: images | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: confusion with content-height and height properties on fo:external=graphic
At 12:14 PM 7/23/01 +0200, Petr Andrs wrote: when I want to include external image using fo:external-graphic and I want it to be scaled to specified dimension I have to use content- height and content-width properties. This is how I understand XSL FO spec and how it works in XEP and Antenna. In FOP this doesn't work. In FOP I was able to achieve required behavior by using height and width properties, which I think is not correct. Actually I don't understand how height and width should affect fo:external-graphic but I am quite sure, that specifying image's dimesions is to be done using content- height and content-width. Can anybody explain this and eventually fix FOP's behavior, plesae? height and width pertain to the viewport - fo:external-graphic produces a viewport/reference-area pair, just like regions do. From a printed (PDF) perspective this is fairly meaningless, but it's nevertheless useful to think of the viewport as being there and acting as something of a cropping area. You're right - you should be able to use content-height, content-width, and scaling, and not worry about height and width. The latter 2 are initially auto and this means that the viewport is the same size as the content. I haven't ever looked at the fo:external-graphic code that we have, but if this is the way it works right now then we definitely want to fix it. I am not sure I even understand why it wouldn't have been done that way to start with, since it isn't any more difficult. Maybe I'm missing some arcane little implementation point. :-) I'll take a look over the next couple of days unless someone beats me to it. height and width, once properly implemented, will have the effect of clipping the visible content of the image, if they are less than the corresponding scaled content-width and content-height, and overflow is 'hidden' or 'scroll'. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
