For the archives, it looks like this is the commit [ http://svn.apache.org/viewvc?view=revision&revision=1239111 ]. If this is a common need, perhaps a candidate to just get rolled into Forrest itself, I dunno.
FWIW, I'm pretty sure the output.xmap is unnecessary and you could have used a project-specific locationmap to point to your custom document-to-fo.xsl but maybe I'm missing something... --tim On Wed, Feb 1, 2012 at 8:02 AM, Karl Wright <daddy...@gmail.com> wrote: > FWIW, the $path has just what I hoped in it and works well. > > Thanks! > Karl > > On Tue, Jan 31, 2012 at 9:23 PM, Karl Wright <daddy...@gmail.com> wrote: >>> Then, inside your own document-to-fo.xsl you should have access >>> to a "path" parameter. You may add an additional condition to the >>> font of interest (e.g. rootFontFamily) that uses XSL string functions >>> against your $path parameter. >>> >> >> I've set things up so that my document path includes the language code >> (e.g. 'en_US') as the first part of the path under >> src/documentation/content/xdocs. For example, >> src/documentation/content/xdocs/en_US/mydocument.xml would be the >> starting point. The question is what the $path variable will contain >> - if it's just "en_US/mydocument.xml" my job is easy. If it could be >> "en_US\mydocument.xml" on Windows and "en_US/mydocument.xml" on Unix >> it's a bit harder. But if it is the absolute path xsl expressions >> aren't going to help me and I'd better find a better solution. >> >> What I'd do (and this might even make a decent general patch) is look >> for the property with the language specifier first. For example, >> instead of looking for "output.pdf.fontFamily.sansSerif" first, I'd >> look for "output.pdf.fontFamily.sansSerif.en_US" first, and only look >> for the other if that property is not found. >> >> So, what can I expect to see for the $path parameter? >> >> Thanks again for your help! >> Karl
