Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <419A5963.1040801@apache.org>
Date: Tue, 16 Nov 2004 19:47:47 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Selective PDF
References: <200411141149.20071.sean@inwords.co.za>
 <200411161838.05593.sean@inwords.co.za> <419A36E0.8080103@apache.org>
 <200411162057.27547.sean@inwords.co.za>
In-Reply-To: <200411162057.27547.sean@inwords.co.za>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sean Wheller wrote:
> On Tuesday 16 November 2004 19:20, Ross Gardler wrote:
> 
>>>plugin.pdf.button.include.output=**.html, documentation/index.html
>>>plugin.pdf.button.exclude.output=**/index.html
>>>
>>>So if you have a pod plugin, then either the forrest.properties for the
>>>pod plugin will have this defined or the main forrest.properties.
>>>
>>>plugin.pod.button.include.output=**.html, documentation/index.html
>>>plugin.pod.button.exclude.output=**/index.html
>>>
>>>and so on for each target format ?
>>
>>Yes, or at least that is my thinking. We have to wait a short while to
>>make sure there are no objections from anyone. We may have missed
>>something.
> 
> 
> Ok once I know which forrest.properties I will add for each target format.

If we include them in fresh-site/forrest.properties then all new 
projects will automatically have these properties. However, they will 
only be relevant if they install the pdf plugin. Therefore, we don't 
want to add them to fresh-site.

Similarly we don't want to add them to default.forrest.properties (same 
reasoning).

They will only be added to a projects forrest.properties file if they 
are needed. This means we need to document them in the (to be built) 
pdf-output plugin.

We will use the pdf plugin as our test site, that is we will create a 
PDF plugin and test this configuration on the documentation for that 
plugin. In other words, it will go into plugins/pdf/forrest.properties.

However, you can't do this as we don't have the PDF plugin. You could 
make a start on building the PDF plugin and provide a patch for that, 
I'm just in the middle of doing the wiki plugin at the moment.

See 
http://svn.apache.org/viewcvs.cgi/forrest/trunk/docs-author/content/xdocs/howto/howto-buildPlugin.xml?view=markup 
for (incomplete instructions on how to do this).

You could start creating the basic documentation site for the plugin, 
and if you know how, you could extract the PDF functionality from 
Forrest. This will give enough time for others to comment on our 
intentions as we need to extract the PDF into a plugin anyway.

> I don't see an issue in JIRA for this so I can attach a patch (once I know 
> which file to modify :-) ), perhaps it's named something obscure?

No there is no issue that I am aware of, just create one and link to 
this thread.

>>The next stage is where do we process these properties.
> 
> 
> This is the part that has me stuck.
> 
> 
>>Lets continue to use PDF as a use case. Currently, site2xhtml.xsl has
>>the following:
>>
>><!--+
>>     |Generates the PDF link
>>     +-->
>>   <xsl:template match="div[@id='skinconf-pdflink']">
>>     <xsl:if test="not($config/disable-pdf-link) or $disable-pdf-link =
>>'false'">
>>       <div class="pdflink" title="Portable Document Format"><a
>>href="{$filename-noext}.pdf" class="dida">
>>         <img class="skin" src="{$skin-img-dir}/pdfdoc.gif" alt="PDF
>>-icon" /><br/>
>>         PDF</a>
>>       </div>
>>     </xsl:if>
>>   </xsl:template>
>>
>>We need to maintain this default behaviour (although we may want to
>>deprecate it).
> 
> 
> For now we must keep it, or it won't work. Same with the full-docbook plugin I 
> have sitting with me, it won't work until XHTML. I guess we will come across 
> this problem more often as we move more things to plugins. Personal this is 
> why I would have liked XHTML implimented first and then everything else 
> developed. At least we would not have to go back and retouch all work.

[OT] We do not need XHTML as an intermediate format to use XHTML - we 
can return to that whenever you are ready.

>>In addition, we want to consider the values of the new 
>>properties in the above template. How does this look?
>>
>>
>><!--+
>>     |Generates the PDF link
>>     +-->
> 
> <snip/> Some good logic
> 
> It looks sensible, as best I can tell. Will need to test it, but to have test 
> env we need pdf plugin. So I think we:
> 1. do pdf plugin
> 2. add to forrest.properties (whichever it is)
> 3. add your logic to site2xhtml

+1

Ross