forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Plugin dependencies (Was: pdf plugin config locations)
Date Wed, 20 Aug 2008 11:52:03 GMT
Den 5. jul. 2008 kl. 00.27 skrev Ross Gardler:

>> 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  
> "cocoon://".
> 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.

The first implementation only included three properties:


I made these available using the first approach Ross described above,  
ie passing them in via the sitemap as xsl parameters.

But as I indicated later in this thread, one can easily imagine the  
need for more finegrained control of font family usage. I have now  
reworked my implementation to allow any of the present font-family  
specifications to be individually specified by the user on a per- 
project basis. But the list is now quite long (defaults in parenthesis):

output.pdf.fontFamily.rootFontFamily		(serif)
output.pdf.fontFamily.firstFooterFontFamily	(sans-serif)
output.pdf.fontFamily.evenHeaderFontFamily	(sans-serif)
output.pdf.fontFamily.evenFooterFontFamily	(sans-serif)
output.pdf.fontFamily.oddHeaderFontFamily	(sans-serif)
output.pdf.fontFamily.oddFooterFontFamily	(sans-serif)
output.pdf.fontFamily.documentTitleFontFamily	(sans-serif)
output.pdf.fontFamily.versionFontFamily		(sans-serif)
output.pdf.fontFamily.authorsFontFamily		(sans-serif)
output.pdf.fontFamily.TOCFontFamily		(sans-serif)
output.pdf.fontFamily.sectionTitleFontFamily	(sans-serif)
output.pdf.fontFamily.sourceFontFamily		(monospace)
output.pdf.fontFamily.codeFontFamily		(monospace)
output.pdf.fontFamily.warningTitleFontFamily	(sans-serif)
output.pdf.fontFamily.noteTitleFontFamily	(sans-serif)
output.pdf.fontFamily.fixmeTitleFontFamily	(sans-serif)

That is, 16 properties all in all (they all fall back to the indicated  
defaults, which means one can specify only the three base font  
families, and/or individually override any of the above). This makes  
the sitemap+parameter solution very clumsy, and hard to maintain. Thus  
solution two (aggregation) seems the most elegant.

BUT: this creates a dependency between the o.a.f.p.output.pdf and  
o.a.f.p.output.inputModule - no pdf files will be generated if the  
output.inputModule is not listed in the required plugins list.  
Instead, one will get an error message that the pdf file could not be  
found (really: the aggregation did not succeed because the "cocoon://" source didn't match anything).


Is this dependency acceptable?
How should it/can it be formalised?

At least we need to update the seeds to include the  
o.a.f.p.output.inputModule as well as the pdf plugin (new seeds only  
include the pdf plugin).


Best regards,

View raw message