For the archives, it looks like this is the commit [ http://svn.apache.org/viewvc?view=revision&revision=1239111
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...
On Wed, Feb 1, 2012 at 8:02 AM, Karl Wright <firstname.lastname@example.org> wrote: > FWIW, the $path has just what I hoped in it and works well.
> On Tue, Jan 31, 2012 at 9:23 PM, Karl Wright <email@example.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!