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://module.properties.properties" 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://module.properties.properties".
So, in order to make all properties available in your stylesheets
aggregate the output of "cocoon://module.properties.properties" 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:
output.pdf.fontFamily.serif
output.pdf.fontFamily.sansSerif
output.pdf.fontFamily.monospace
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://
module.properties.properties" source didn't match anything).
QUESTIONS:
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).
Comments?
Best regards,
Sjur
