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
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
s
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
On Wed, 2002-11-06 at 09:55, Jeremias Maerki wrote:
> 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
>
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
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 t
17 matches
Mail list logo
