On Wed, 2008-08-20 at 14:52 +0300, Sjur Moshagen wrote: > 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?
IMO yes, since the plugin is very small and thought a infrastructure code. Like you describe the alternative to implement it in the sitemap is cumbersome to maintain. > How should it/can it be formalised? Not sure what you mean? > > 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). As I understand it you commit to the fresh-site forrest.properties files (skins/dispatcher) and the cron is doing the rest. > > Comments? > Thanks for looking into this Sjur. salu2 > Best regards, > Sjur > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
