Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48C678CD.3060505@apache.org>
Date: Tue, 09 Sep 2008 14:23:25 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: PDF Plugin: Customization approach
References: <20080909123020.9F33.60BA733C@jeremias-maerki.ch>
 <C10741E1-F70A-4704-A9B1-CEB53656A45D@mac.com>
In-Reply-To: <C10741E1-F70A-4704-A9B1-CEB53656A45D@mac.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sjur Moshagen wrote:
> Den 9. sep. 2008 kl. 13.51 skrev Jeremias Maerki:
> 
>> Just a thought: I've noticed how customization of the FO stylesheets
>> have been approached but I'm not sure it's the best way to do it. How
>> about doing it more the XSLT way using xsl:attribute-set and
>> xsl:use-attribute-sets? A default document-to-fo-styles.xsl would
>> contain the attribute sets with the default behaviour. The user could
>> then override that default styles file with his own customizations which
>> would then not be restricted to the few points that are predefined, but
>> could change font sizes, spacing, color etc.
> 
> It sounds like an excellent idea!

I'm not so sure (but I have a proposal).

At present we have two config systems forrest.properties (unnofficially 
deprecated) and forrest.properties.xml (unnofficially the future).

This proposal introduces a third way of configuring things. I don't like 
that, it leads to confusion.

As an alternative why not have the properties defeined in 
forrest.properties.xml and use a sitemap matche to generate the required 
document-to-foStyles.xsl (note the name change is important to maintain 
consistency with our naming convention).

>> I haven't prototyped it,
>> yet. I guess the tricky part is to do the override right (probably just
>> a simple xsl:import with a Cocoon-handled URI). 

If we do it the way I sugges there is no need to handle overriding as it 
is already handled in the xml properties system.

If we do go with the original suggestion then overriding is handled by 
the locationmap by default. Simply add a new location to the locationmap 
(or rely on the user to manually ovveride in the site locatinmap),

>> The nice side-effect is
>> that it will simplify the FO stylesheets, too, and improve splitting
>> structure and style.
> 
> :)

+1 - we get this benefit with my alternative approach too.

>> I'm not sure if I have time soon to do a prototype. No problem if
>> someone beats me to it. ;-)
> 
> This is beyond me, so I'm happy to wait until you get the time.

I'm not likely to do the work, but I'm happy to provide pointers if 
someone gets stuck.

Note, the work done for the first proposal will (off the top of my head) 
need to be done for the second proposal. So, implementing the initial 
proposal first and then moving to the second proposal would be 
acceptable (IMHO) as long as we either:

a) agree the initial proposal is OK for a release

or

b) do not do a release of the dev plugin until we reach my proposal (or 
a modification of it)

Ross