gzilla/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:
gzilla/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
gzilla/show_bug.cgi?id=24527
[PATCH] RTF: added support for fo:external-graphic
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/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
gzilla/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:
gzilla/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:
J.Pietschmann 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://
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
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/
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 ima
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 interface
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 c
On Wed, 06 Nov 2002 23:06:53 +0100 J.Pietschmann wrote:
> 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
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/foo
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 additi
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: partia
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
On Wed, 2002-11-06 at 12:01, Bertrand Delacretaz wrote:
> On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote:
> >. . .
> > http://localhost/mydynamicimage)"
> > xmlns:fop="http://xml.apache.org/fop"; fop:disable-caching="true"/>
> >. . .
>
> There are some fox: extensions already IIRC (nev
er uses of the image should only insert the reference to the image.
> 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? T
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
On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote:
>. . .
> 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 sa
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
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
liver 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
gzilla/show_bug.cgi?id=8202
fo:basic-link does not work for fo:external-graphic
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
Looks like I'm too lazy sometimes. :-) Thanks, Jörg, for posting the
link. And Holger, implementing such a protocol handler was actually what
I wanted to propose. It's easy to do and very flexible. Sometimes I
don't express myself too well. I'm working on it.
> > Holger Prause wrote:
> > > So i m
> Holger Prause wrote:
> > So i must customize the processing of the src attribute.Whats the
> fastest
> > way to do so ?
>
Hello
> Depending on the JVM, introducing a custom protocol and
> an associated URL handler.
Sounds very good, that could be a solution as far as i can see.
>There is a
Holger Prause wrote:
> So i must customize the processing of the src attribute.Whats the fastest
> way to do so ?
Depending on the JVM, introducing a custom protocol and
an associated URL handler. There is a tutorial, usually
Jeremias posts the URL:
http://developer.java.sun.com/developer/onlin
Hi
> 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 be
> 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 yo
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
gzilla/show_bug.cgi?id=1474
fo:external-graphic rendered as block level object
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=4262
Infinite loop when using fo:external-graphic (Fop 0.20.1)
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
]Ämne: 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-IN
r" <[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:...height="0.58cm"
width="2
esday, 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
e 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-gr
hat 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.,
>
sr
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 th
-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:
>src="file://./config/isappdev/applications/RVWebApp1/WEB-INF/lib/ClinTrialLo
>goGreenBig.gif" />
I wouldn't expect that to work; that says make a file conn
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 ser
gzilla/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
gzilla/show_bug.cgi?id=2300
"ERROR: null" with fo:external-graphic
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
gzilla/show_bug.cgi?id=4262
Infinite loop when using fo:external-graphic (Fop 0.20.1)
Summary: Infinite loop when using fo:external-graphic (Fop
0.20.1)
Product: Fop
Version: all
Platform: PC
OS/Version: Linux
Statu
October 2001 17:17
> To: '[EMAIL PROTECTED]'
> Subject: FOP - Optimising the image caching mechanism for
> fo:external-graphic
>
>
> Hi,
>
> We're using FOP version 0.20.1 here, and we were encountering
> a wierd little problem with fo:external-graph
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
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 &
> & is a reserved character and the XML parser is interpreting as the start of
> an entity befor
M
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
dynamical
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
=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:extern
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
Hi,
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
null" with fo:external-graphic |
+ ++
+ |Bug #: 2300Product: Fop |
+ | Status: NEW
53 matches
Mail list logo
