gmane.text.xml.forrest.user

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

David Crossley — 2012-02-02T00:56:17

For the document-to-fo.xsl part.


Yes i reckon that is correct.

-David

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

Tim Williams — 2012-02-02T00:44:35

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.com> wrote:

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

Tim Williams — 2012-02-01T13:05:59

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

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

Karl Wright — 2012-02-01T13:02:24

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.com> wrote:

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

Karl Wright — 2012-02-01T02:23:28

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

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

Karl Wright — 2012-02-01T01:48:05

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

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

Karl Wright — 2012-02-01T01:35:52

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

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

Tim Williams — 2012-01-31T13:04:58

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

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

Karl Wright — 2012-01-31T08:16:07

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.co.jp> wrote:

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

Karl Wright — 2012-01-29T16:38:27

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.co.jp> wrote:

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

Hitoshi Ozawa — 2012-01-27T04:01:47

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:

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

Karl Wright — 2012-01-27T02:38:43

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

Font not found error

Hitoshi Ozawa — 2012-01-26T06:11:27

I'm trying to specify Japanese fonts to use with Forrest 0.9 but keep
getting the following error:
WARN - Font 'IPAGothic,normal,400' not found. Substituting with
'any,normal,400'.
WARN - Font 'IPAGothic,normal,700' not found. Substituting with
'any,normal,700'.
WARN - Font 'IPAGothic,italic,400' not found. Substituting with
'any,italic,400'.

I've created the following forrest.properties.xml file:
<?xml version='1.0'?>
<properties>
<property name="output.pdf.fontFamily.serif" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.sansSerif" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.monospace" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.arial" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.TimesNewRoman" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.Courier" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.arialMT" value="IPAPGothic"/>
<property name="output.pdf.fontFamily.arial-BoldMT" value="IPAPGothic"/>
<property name="output.pdf.font

Re: Adding site documentation to project

lewis john mcgibbney — 2011-09-26T16:53:55

thank you both for the help on this one. It is greatly appreciated.

Lewis

On Mon, Sep 26, 2011 at 12:32 AM, David Crossley <crossley< at >apache.org>wrote:

Re: Adding site documentation to project

David Crossley — 2011-09-25T23:32:35

Your generated docs are committed to the "site/publish/" directory.
On the server it will be either an automated cron job by one
or more of your committers doing 'svn up' in your nutch.a.o space
(this is the old way like our Forrest project still does)
or it will be under "svnpubsub".


Sure, Thanks Tim.

Also see the orginal document that i referenced at
http://forrest.apache.org/howto-forrestbot-svn.html#follow

Nutch needs to create your own buildfile. When each committer wants
to publish their changes, they run the local forrestbot "build"
as explained. If all is well then commit their source edits
and then do the "deploy" step.

-David

Re: Adding site documentation to project

Tim Williams — 2011-09-23T20:36:37

On Fri, Sep 23, 2011 at 4:05 PM, lewis john mcgibbney
<lewis.mcgibbney< at >gmail.com> wrote:

There's another build file, typically "publish.xml"[see our example 1]
that contains the details of where to publish it.  You might find it
easier to start with a condensed version of our own publishing
instructions[2] or slightly more verbose[3] and expand your reading as
necessary from there...  There's no "trigger" to update them, but
they're periodically pulled - it looks like your latest footer change,
for example, was already pulled - sorry, I don't know the detailed
mechanics of that arrangement.

You've done plenty of research, ask away:)
--tim

[1] - http://svn.apache.org/repos/asf/forrest/trunk/site-author/publish.xml
[2] - http://svn.apache.org/repos/asf/forrest/trunk/etc/publishing_our_site.txt
[3] - http://forrest.apache.org/procedures/How_to_publish_docs.html

Re: Adding site documentation to project

lewis john mcgibbney — 2011-09-23T20:05:41

Hi again,

I'm back working on this and could do with some pointers. Please see below
for some of the keys areas.

I've looked closely at your references and read both the forrestbot "svn"
workstage and forrestbot automated build and deploying documentation. I
understand completely how I want this to work and your suggestion for the
process of editing sourc, updating the Nutch site, then an additional
forrestbot task would update the new /docs directory within our SVN
nutch/branches/branch-1.4/docs diretcory. This would then enable devs to
simply svn update and any documentation changes would be updated. It would
also provide an excellent way of shipping the generated docs with our next
release. The parts I am struggling to understand are below:


On Mon, Sep 19, 2011 at 3:27 AM, David Crossley <crossley< at >apache.org> wrote:

I 'think' this is already done. I am waiting for a reply from the more
experienced dev's to give me insight into how committed changes to the site
source are actually fed through to nutch

Re: Problem understanding broken-links.xml after making changes to site

lewis john mcgibbney — 2011-09-19T09:53:27

OK, I think this is a case of me going through this with a fine tooth comb
when I have time.

Thanks David

On Mon, Sep 19, 2011 at 3:04 AM, David Crossley <crossley< at >apache.org> wrote:

Re: Adding site documentation to project

lewis john mcgibbney — 2011-09-19T09:52:17

Thank you David, I'll work on this basis and hopefully get it sorted out.

Thanks

On Mon, Sep 19, 2011 at 3:27 AM, David Crossley <crossley< at >apache.org> wrote:

Re: Adding site documentation to project

David Crossley — 2011-09-19T02:27:15

I gather that you mean the "generated" relevant docs for that version.

You could use the "Forrestbot" as we do for our Forrest project docs.

http://forrest.apache.org/howto-forrestbot-svn.html
How to deploy documentation with the Forrestbot "svn" workstage

In our case we deploy our generated documentation to SVN forrest/site
which gets 'svn up' on people.apache.org to publish our website.

The Nutch project could do that too for your website docs.

Then have another "Forrestbot buildfile" which deploys the relevant
docs to SVN nutch/branches/branch-1.4

-David

Re: Problem understanding broken-links.xml after making changes to site

David Crossley — 2011-09-19T02:04:31

Since you referenced a remote resource, perhaps it was not
available at the forrest run-time. I see that you later
added a local copy to .../resources/images/ directory.

Regarding your subsequent error listings in this thread,
i do not know, sorry.

-David