Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Forrest: User

Is there a decent way of using different PDF fonts for different parts of a Forrest site?

 

 

Forrest user RSS feed   Index | Next | Previous | View Threaded


daddywri at gmail

Jan 26, 2012, 6:38 PM

Post #1 of 12 (3694 views)
Permalink
Is there a decent way of using different PDF fonts for different parts of a Forrest site?

Hello,

I have a site which has different languages in the same site. This
works OK except when it comes to PDF generation. There seems to be no
font choice that covers all languages; I need Dejavu for latin
languages, and IPA for Japanese. The problem is that I can't figure
out how to configure Forrest to use one set of fonts for part of the
site and a different set for another, for PDF generation. Is this
even possible?

Thanks,
Karl


Ozawa_Hitoshi at ogis-ri

Jan 26, 2012, 8:01 PM

Post #2 of 12 (3556 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

Hi Karl,

It's really not just about the font. document-to-fo.xsl, language="ja"
attribute should be added to the
fo:root element when generating Japanese pdf files.

So, to put it all together, document-to-fo.xsl should be modified to
contain a when block to check lang and output
an appropriate font and language.

<xsl:choose>
<xsl:when test='lang("ja")'>IPAPGothic</xsl:when>
<xsl:otherwise>serif</xsl:otherwise>
</xsl:choose>

The question is if there is a more general way to do this than editing
the xsl file.

H.Ozawa

(2012/01/27 11:38), Karl Wright wrote:
> Hello,
>
> I have a site which has different languages in the same site. This
> works OK except when it comes to PDF generation. There seems to be no
> font choice that covers all languages; I need Dejavu for latin
> languages, and IPA for Japanese. The problem is that I can't figure
> out how to configure Forrest to use one set of fonts for part of the
> site and a different set for another, for PDF generation. Is this
> even possible?
>
> Thanks,
> Karl
>
>


daddywri at gmail

Jan 29, 2012, 8:38 AM

Post #3 of 12 (3562 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

There are so many problems here that I now think the only way to
actually get this to work is to make a copy of Forrest via ant and
modify the Forrest files, also via ant. I've set this up for the
ManifoldCF site build now and we should be able to work our way
through it a problem at a time, until we get it to work.

Karl

On Thu, Jan 26, 2012 at 11:01 PM, Hitoshi Ozawa
<Ozawa_Hitoshi [at] ogis-ri> wrote:
> Hi Karl,
>
> It's really not just about the font. document-to-fo.xsl, language="ja"
> attribute should be added to the
> fo:root element when generating Japanese pdf files.
>
> So, to put it all together, document-to-fo.xsl should be modified to contain
> a when block to check lang and output
> an appropriate font and language.
>
> <xsl:choose>
> <xsl:when test='lang("ja")'>IPAPGothic</xsl:when>
> <xsl:otherwise>serif</xsl:otherwise>
> </xsl:choose>
>
> The question is if there is a more general way to do this than editing the
> xsl file.
>
> H.Ozawa
>
>
> (2012/01/27 11:38), Karl Wright wrote:
>>
>> Hello,
>>
>> I have a site which has different languages in the same site.  This
>> works OK except when it comes to PDF generation.  There seems to be no
>> font choice that covers all languages; I need Dejavu for latin
>> languages, and IPA for Japanese.  The problem is that I can't figure
>> out how to configure Forrest to use one set of fonts for part of the
>> site and a different set for another, for PDF generation.  Is this
>> even possible?
>>
>> Thanks,
>> Karl
>>
>>
>
>
>


daddywri at gmail

Jan 31, 2012, 12:16 AM

Post #4 of 12 (3556 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

Hi Hitoshi,

plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
does seem like the right place to conditionalize things, but I'm
unclear in your example where the language specifier comes from? In
other words, I'd like the path to the current file to determine the
language, not the system settings. Do you (or does anyone else) know
how to construct a conditional within the document-to-fo.xsl file that
would (say) base a decision for a font choice on whether a file had a
name that matched a particular regular expression? That's the kind of
logic I'm looking for here.

Thanks,
Karl


On Thu, Jan 26, 2012 at 11:01 PM, Hitoshi Ozawa
<Ozawa_Hitoshi [at] ogis-ri> wrote:
> Hi Karl,
>
> It's really not just about the font. document-to-fo.xsl, language="ja"
> attribute should be added to the
> fo:root element when generating Japanese pdf files.
>
> So, to put it all together, document-to-fo.xsl should be modified to contain
> a when block to check lang and output
> an appropriate font and language.
>
> <xsl:choose>
> <xsl:when test='lang("ja")'>IPAPGothic</xsl:when>
> <xsl:otherwise>serif</xsl:otherwise>
> </xsl:choose>
>
> The question is if there is a more general way to do this than editing the
> xsl file.
>
> H.Ozawa
>
>
> (2012/01/27 11:38), Karl Wright wrote:
>>
>> Hello,
>>
>> I have a site which has different languages in the same site.  This
>> works OK except when it comes to PDF generation.  There seems to be no
>> font choice that covers all languages; I need Dejavu for latin
>> languages, and IPA for Japanese.  The problem is that I can't figure
>> out how to configure Forrest to use one set of fonts for part of the
>> site and a different set for another, for PDF generation.  Is this
>> even possible?
>>
>> Thanks,
>> Karl
>>
>>
>
>
>


williamstw at gmail

Jan 31, 2012, 5:04 AM

Post #5 of 12 (3550 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

On Tue, Jan 31, 2012 at 3:16 AM, Karl Wright <daddywri [at] gmail> wrote:
> Hi Hitoshi,
>
> plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
> does seem like the right place to conditionalize things, but I'm
> unclear in your example where the language specifier comes from?  In
> other words, I'd like the path to the current file to determine the
> language, not the system settings.  Do you (or does anyone else) know
> how to construct a conditional within the document-to-fo.xsl file that
> would (say) base a decision for a font choice on whether a file had a
> name that matched a particular regular expression?  That's the kind of
> logic I'm looking for here.

Hi Karl,
Know? Unfortunately not - this is a guess. Create a copy of
document-to-fo.xsl - using the project-specific locationmap to find
it. 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. Unfortunately, I can't verify any of
this until tonight.

Thanks,
--tim


daddywri at gmail

Jan 31, 2012, 5:35 PM

Post #6 of 12 (3564 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

On Tue, Jan 31, 2012 at 8:04 AM, Tim Williams <williamstw [at] gmail> wrote:
> On Tue, Jan 31, 2012 at 3:16 AM, Karl Wright <daddywri [at] gmail> wrote:
>> Hi Hitoshi,
>>
>> plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
>> does seem like the right place to conditionalize things, but I'm
>> unclear in your example where the language specifier comes from?  In
>> other words, I'd like the path to the current file to determine the
>> language, not the system settings.  Do you (or does anyone else) know
>> how to construct a conditional within the document-to-fo.xsl file that
>> would (say) base a decision for a font choice on whether a file had a
>> name that matched a particular regular expression?  That's the kind of
>> logic I'm looking for here.
>
> Hi Karl,
> Know?  Unfortunately not - this is a guess.  Create a copy of
> document-to-fo.xsl - using the project-specific locationmap to find
> it.  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. Unfortunately, I can't verify any of
> this until tonight.
>
> Thanks,
> --tim

Thanks, Tim, for the reply. I'll experiment to see if I can use $path
in the manner I need.

Could you elaborate on where the "project-specific locationmap" should
be found? Our site was created initially by someone else and doesn't
appear to have such a thing.

Karl


daddywri at gmail

Jan 31, 2012, 5:48 PM

Post #7 of 12 (3555 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

On Tue, Jan 31, 2012 at 8:35 PM, Karl Wright <daddywri [at] gmail> wrote:
> On Tue, Jan 31, 2012 at 8:04 AM, Tim Williams <williamstw [at] gmail> wrote:
>> On Tue, Jan 31, 2012 at 3:16 AM, Karl Wright <daddywri [at] gmail> wrote:
>>> Hi Hitoshi,
>>>
>>> plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
>>> does seem like the right place to conditionalize things, but I'm
>>> unclear in your example where the language specifier comes from?  In
>>> other words, I'd like the path to the current file to determine the
>>> language, not the system settings.  Do you (or does anyone else) know
>>> how to construct a conditional within the document-to-fo.xsl file that
>>> would (say) base a decision for a font choice on whether a file had a
>>> name that matched a particular regular expression?  That's the kind of
>>> logic I'm looking for here.
>>
>> Hi Karl,
>> Know?  Unfortunately not - this is a guess.  Create a copy of
>> document-to-fo.xsl - using the project-specific locationmap to find
>> it.  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. Unfortunately, I can't verify any of
>> this until tonight.
>>
>> Thanks,
>> --tim
>
> Thanks, Tim, for the reply.  I'll experiment to see if I can use $path
> in the manner I need.
>
> Could you elaborate on where the "project-specific locationmap" should
> be found?  Our site was created initially by someone else and doesn't
> appear to have such a thing.
>
> Karl

I generated a new site with "forrest seed", and found a
locationmap.xml file under src/documentation/content. But there's no
mention of document-to-fo.xsl in the generated stub; maybe it's
possible to override something at this level but it is not clear how.

On the other hand, I know where to find document-to-fo.xsl inside
Forrest itself, so I may just start there.

Karl


daddywri at gmail

Jan 31, 2012, 6:23 PM

Post #8 of 12 (3539 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

> 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


daddywri at gmail

Feb 1, 2012, 5:02 AM

Post #9 of 12 (3543 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

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 <daddywri [at] gmail> 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


williamstw at gmail

Feb 1, 2012, 5:05 AM

Post #10 of 12 (3551 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

On Wed, Feb 1, 2012 at 8:02 AM, Karl Wright <daddywri [at] gmail> wrote:
> FWIW, the $path has just what I hoped in it and works well.

My apologies Karl, I got busy last night and didn't have a chance to
get back to this:( I haven't confirmed but path should be the request
path (of the URL) - so the same on both systems.

--tim

> Thanks!
> Karl
>
> On Tue, Jan 31, 2012 at 9:23 PM, Karl Wright <daddywri [at] gmail> 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


williamstw at gmail

Feb 1, 2012, 4:44 PM

Post #11 of 12 (3547 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

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 <daddywri [at] gmail> 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 <daddywri [at] gmail> 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


crossley at apache

Feb 1, 2012, 4:56 PM

Post #12 of 12 (3547 views)
Permalink
Re: Is there a decent way of using different PDF fonts for different parts of a Forrest site? [In reply to]

Tim Williams wrote:
> 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.

For the document-to-fo.xsl part.

> 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...

Yes i reckon that is correct.

-David

> --tim
>
> On Wed, Feb 1, 2012 at 8:02 AM, Karl Wright <daddywri [at] gmail> 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 <daddywri [at] gmail> 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

Forrest user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.