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 Andreas Delmelle <an...@telenet.be> on 2008/02/26 22:17:59 UTC
More ideas for configuration/extension?
Hi all
Some time ago, Adrian posted an interesting suggestion on fop-users@
for an extension that would basically allow a configuration to be
bound to a single document: a fox:configuration node that could be
specified as a descendant of the fo:declarations.
Now, I just wondered about the following: instead of making it an
extension, maybe we could dedicate a special namespace to FOP's
configuration. The nodes that are now present in the sample fop.xconf
could then appear anywhere in the document. For some options the
appearances should probably best be restricted, but imagine something
like:
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:cfg="http://xmlgraphics.apache.org/fop/config"
...
<fo:block>
<cfg:fop>
<cfg:strict-validation>false</cfg:strict-validation>
<cfg:base>file://absolute/path</cfg:base>
</cfg:fop>
...
<fo:external-graphic src="relative/path/to/image.png" />
<fo:external-graphic src="relative/path/to/another/image.png" />
</fo:block> <!-- end of scope for the cfg:* settings -->
An author would be able to override default configuration settings on
a per-FO basis, with an implied scope of the entire document if the
settings are specified as direct descendants of the fo:root.
Just a thought...
Cheers
Andreas
Re: More ideas for configuration/extension?
Posted by Andreas Delmelle <an...@telenet.be>.
On Feb 27, 2008, at 16:21, Adrian Cumiskey wrote:
> For either my suggestion or Andreas' further proposal we would
> certainly need to do a little bit of refactoring, abstracting out
> all those member config variables in FopFactory into a base
> configuration object. This base configuration object would be a
> singleton and *unmodifiable* and would only serve the function of
> providing the default fallback configuration settings
Yep, that's what I meant. The configuration of the FopFactory would
only be used if there is no override at the level of the UserAgent/
Document (or even elsewhere?). It would indeed be immutable. The
intention is not to mess with the settings here, but more to keep
those settings, and *if* a user specifies overriding config-settings,
to create a temporary config that provides the overrides.
> A second user agent configuration object would be created per user
> agent, this configuration would be modifiable. The user agent
> configuration would derive configuration values from the base
> configuration when values were not provided programmatically
> through API on the fly. A third configuration object could
> represent the document level configuration. This would be created
> on construction of the FO tree and it would derive its default
> values from the user agent configuration which in turn would derive
> its values (in their absence) from the base configuration. Hope I
> explained how that would work clearly enough, does that make sense?
Yes it does, more or less. I hadn't really considered details yet,
but I guess I'd see it as a stack of configurations, where the top of
the stack is always consulted first. The FopFactory config would be
the bottom.
> This scoping seems a little bit too clever for me ;-).
Heh, I get that a lot... :-)
> I'm not sure how useful this use case would be. I think its useful
> enough to just have a document level configuration defined within
> the fo:declarations.
Well, it could be handy if the user knows in advance, for example,
that there is one block in the entire document where he has a table
that does not adhere 100% to the XSL-FO Rec. Of course, we're all
inclined to say that the stylesheet should be adapted in that case,
but that is not always as easily said as it is done... Being able to
override strict-validation for just one block would offer immediate
relief, where changing the stylesheet could take multiple days or
weeks, depending on who is the owner/maintainer.
Being able to override the base-url would probably at most be neat
for the page-sequence level.
Bummer about the fo:declarations is that it always appears after the
fo:layout-master-set, and some settings apply to the latter (page-
width or -height fallback).
Cheers
Andreas
Re: More ideas for configuration/extension?
Posted by Adrian Cumiskey <ad...@gmail.com>.
For either my suggestion or Andreas' further proposal we would certainly need to do a little bit of
refactoring, abstracting out all those member config variables in FopFactory into a base
configuration object. This base configuration object would be a singleton and *unmodifiable* and
would only serve the function of providing the default fallback configuration settings A second
user agent configuration object would be created per user agent, this configuration would be
modifiable. The user agent configuration would derive configuration values from the base
configuration when values were not provided programmatically through API on the fly. A third
configuration object could represent the document level configuration. This would be created on
construction of the FO tree and it would derive its default values from the user agent configuration
which in turn would derive its values (in their absence) from the base configuration. Hope I
explained how that would work clearly enough, does that make sense?
Adrian.
Jeremias Maerki wrote:
> I'm not sure I like this whole thing, yet. Of course, your suggestion is
> fine. But there's one thing that needs to be figured out: The
> configuration is applied to the FopFactory. Having the configuration on
> this level provides a multi-threading problem as multiple rendering runs
> might simultaneously modify the configuration of the shared FopFactory.
>
>
> On 26.02.2008 22:17:59 Andreas Delmelle wrote:
>> Hi all
>>
>> Some time ago, Adrian posted an interesting suggestion on fop-users@
>> for an extension that would basically allow a configuration to be
>> bound to a single document: a fox:configuration node that could be
>> specified as a descendant of the fo:declarations.
>>
>> Now, I just wondered about the following: instead of making it an
>> extension, maybe we could dedicate a special namespace to FOP's
>> configuration. The nodes that are now present in the sample fop.xconf
>> could then appear anywhere in the document. For some options the
>> appearances should probably best be restricted, but imagine something
>> like:
>>
>> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
>> xmlns:cfg="http://xmlgraphics.apache.org/fop/config"
>> ...
>> <fo:block>
>> <cfg:fop>
>> <cfg:strict-validation>false</cfg:strict-validation>
>> <cfg:base>file://absolute/path</cfg:base>
>> </cfg:fop>
>> ...
>> <fo:external-graphic src="relative/path/to/image.png" />
>> <fo:external-graphic src="relative/path/to/another/image.png" />
>> </fo:block> <!-- end of scope for the cfg:* settings -->
>>
>> An author would be able to override default configuration settings on
>> a per-FO basis, with an implied scope of the entire document if the
>> settings are specified as direct descendants of the fo:root.
>>
>>
>> Just a thought...
>>
>>
>> Cheers
>>
>> Andreas
>
>
>
>
> Jeremias Maerki
>
>
Re: More ideas for configuration/extension?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I'm not sure I like this whole thing, yet. Of course, your suggestion is
fine. But there's one thing that needs to be figured out: The
configuration is applied to the FopFactory. Having the configuration on
this level provides a multi-threading problem as multiple rendering runs
might simultaneously modify the configuration of the shared FopFactory.
On 26.02.2008 22:17:59 Andreas Delmelle wrote:
>
> Hi all
>
> Some time ago, Adrian posted an interesting suggestion on fop-users@
> for an extension that would basically allow a configuration to be
> bound to a single document: a fox:configuration node that could be
> specified as a descendant of the fo:declarations.
>
> Now, I just wondered about the following: instead of making it an
> extension, maybe we could dedicate a special namespace to FOP's
> configuration. The nodes that are now present in the sample fop.xconf
> could then appear anywhere in the document. For some options the
> appearances should probably best be restricted, but imagine something
> like:
>
> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
> xmlns:cfg="http://xmlgraphics.apache.org/fop/config"
> ...
> <fo:block>
> <cfg:fop>
> <cfg:strict-validation>false</cfg:strict-validation>
> <cfg:base>file://absolute/path</cfg:base>
> </cfg:fop>
> ...
> <fo:external-graphic src="relative/path/to/image.png" />
> <fo:external-graphic src="relative/path/to/another/image.png" />
> </fo:block> <!-- end of scope for the cfg:* settings -->
>
> An author would be able to override default configuration settings on
> a per-FO basis, with an implied scope of the entire document if the
> settings are specified as direct descendants of the fo:root.
>
>
> Just a thought...
>
>
> Cheers
>
> Andreas
Jeremias Maerki
Re: More ideas for configuration/extension?
Posted by Adrian Cumiskey <ad...@gmail.com>.
This scoping seems a little bit too clever for me ;-). I'm not sure how useful this use case would
be. I think its useful enough to just have a document level configuration defined within the
fo:declarations.
Adrian.
Andreas Delmelle wrote:
>
> Hi all
>
> Some time ago, Adrian posted an interesting suggestion on fop-users@ for
> an extension that would basically allow a configuration to be bound to a
> single document: a fox:configuration node that could be specified as a
> descendant of the fo:declarations.
>
> Now, I just wondered about the following: instead of making it an
> extension, maybe we could dedicate a special namespace to FOP's
> configuration. The nodes that are now present in the sample fop.xconf
> could then appear anywhere in the document. For some options the
> appearances should probably best be restricted, but imagine something like:
>
> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
> xmlns:cfg="http://xmlgraphics.apache.org/fop/config"
> ...
> <fo:block>
> <cfg:fop>
> <cfg:strict-validation>false</cfg:strict-validation>
> <cfg:base>file://absolute/path</cfg:base>
> </cfg:fop>
> ...
> <fo:external-graphic src="relative/path/to/image.png" />
> <fo:external-graphic src="relative/path/to/another/image.png" />
> </fo:block> <!-- end of scope for the cfg:* settings -->
>
> An author would be able to override default configuration settings on a
> per-FO basis, with an implied scope of the entire document if the
> settings are specified as direct descendants of the fo:root.
>
>
> Just a thought...
>
>
> Cheers
>
> Andreas
>