forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: pdf plugin config locations
Date Fri, 04 Jul 2008 21:27:50 GMT
Sjur Moshagen wrote:
> Hello all,
> I'm gleaning through past discussions to try to figure out where to 
> place new config info for the pdf plugin. This relates to my recent work 
> to move font-family specifications out of the stylesheets.

the history was:

0.1 - 0.7 + cocoon.xconf for system config and 
skinconf.xml for skin config

0.8 (unofficially) introduced to prevent the need 
to edit the cocoon.xconf files when adding new configs and to allow 
plugins to provide their own skinning configs

0.9 we (pending a vote if necessary) plan to deprecate and skinconf.xml

Therefore I suggest:

> The questions are:
> 1. what is the best place to store default values for the plugin?


> 2. where should the user specify default overrides?


Use a naming convention unique to the plugin, e.g. pdfOutput.fontFamily 
to avoid naming conflicts

> Have I understood correctly that whatever the location, the config info 
> will be available in the relevant stylesheet as child elements of a 
> /config/ element on the top document level?

There are two ways of gaining access to the properties. The original way 
I implemented is by passing them in via the sitemap using 
properties:pdfOutput:fontfamily}. This technique can be seen in the 
daisy input plugin for example.

Later Thorsten implemented the o.a.f.p.output.inputModule to allow all 
properties to be pulled together into a single file. Using the 
dispatcher you can do "cocoon://" and have 
all properties returned (at leat I think that's how it works, I've never 
used it this way myself).

In the dispatcher "cocoon://skinconf.xml" returns the same as 

So, in order to make all properties available in your stylesheets 
aggregate the output of "cocoon://" with the 
  source document.

Personally, I'd add the properties using the first method as it would be 
more efficient. But if you have too many then the latter method is good 
(if worried about efficiency make it a caching pipeline and use an XSLT 
to filer out unwanted properties.


View raw message