forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Tue, 01 Mar 2005 16:39:11 GMT
Johannes Schaefer wrote:
> Thorsten Scherler wrote:
>> On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
>>> Johannes Schaefer wrote:
>>>> With what is proposed now would I have to define a
>>>> lot of classes like class="color_ff00ff" and define
>>>> these classes in the file-specific config?
>>> Take a look at the OOo plugin. It does exactly this with a similar 
>>> file format, although it places the style stiff in the xdoc so this 
>>> is only a partial solution, but at least it uses classes. Perhaps you 
>>> can try and replicate for the Excel sheet to see if it works. Here's 
>>> a where to start looking:
>>> In the root template we have
>>>       <header>
>>>         <title>
>>>         ....
>>>         </title>
>>>         <xsl:call-template name="style"/>
>>>       </header>
>>> The style template looks like this:
>>>   <xsl:template name="style">
>>>     <style>
>>>       <xsl:apply-templates select="//office:styles/style:style"/>
>>>       <xsl:apply-templates 
>>> select="//office:automatic-styles/style:style"/>
>>>     </style>
>>>   </xsl:template>
>>> The rest of the templates you can easily trace from here. We match 
>>> all the style information that we want to allow through to the 
>>> skinning stage, therefore it would be possible to configure which 
>>> style information we allow and which we disallow on a per document 
>>> basis.
> In the OOo plugin the style information is available
> *before* writing the output. In the Excel plugin the cell
> content determins the style (i.e. color) of it. I would have
> to do a pre-processing step to create all the classes
> (styles) and put them into the header
> (anybody to suggest how?).

I'm not following you, how is this different to the OOo plugin? In the 
OOo plugin the OOo style information is aggregated with the content in 
the first stage of the pipeline so it is all processed at the same time.
In the Excel document this is also the case isn't it?

Perhaps a more complete example will help (please make it another thread 
as this is getting off topic here)

 > But this is not where the discussion is heading ... the
 > style information should be neither in-line nor in-header.


>>> With this RT this style information would be extracted with the 
>>> request for the plugin config stuff rather than embedded in head.
> If it was to write a separate file (like a template), this
> could be done I think (again: how?).

No need to actually write a file, we would need a second pipeline that 
processed the request for the CSS and generated it on the fly. Cocoon 
will handle the caching for us. SO the process would be:

- browser requests page (say myPage.html)

- generate XDoc from XML (with class attributes)

- generate HTML from XDoc (adding a link to a virtual CSS stylesheet, 
say myPage.excelStylesheet.css)

- generate the CSS from the XML source in response to browser request 
for myPage.excelStylesheet.css

>> The problem that I see is that if you have a table with many colored
>> fields and all have different colors that can be pretty soon overkill. I
>> understand that the intermediate format should be clean of style
>> information but I reckon it will be pretty hard to achieve.
> Right, putting each color into a class/ft could explode
> the style section.
> We now have about 25 basic colors but I don't know what
> others will come up with (or other projects).

Let us suppose we have 25 cells, 24 have a different colour, but one has 
a duplicate colour. Embedding the colour definition in the TD element 
means 25 definitions, using classes means 24 definitions.

What I am trying to say is that whilst it may explode, it will never be 
bigger than the original source.

>> Now to the promised example, I would place the style information into a
>> forrest:view like:
>> ...
>> <forrest:hook name="color_ff0000">
>>  <css>
>>   <background-color value="#ff0000"/>
>>  </css>
>> </forrest:hook>
>> ...
>> Then I would add this to fileSpecific.ft (ft = forrest template) add it
>> to an aggregation and match it in the xsl.
>> In the document I would recommend to add an attribute <td
>> ft="color_ff0000"/> that will be matched in the xsl.
> For me it would be sufficient to have @class. No new
> attribute @ft needed. The question is, how and where
> can I define the classes? They need to make it into
> CSS-classes at the skinning stage (like Excel-CSS).

My original proposal in this thread was that we provide defaults in a 
"excel-input.conf.xml" file, which is augmented by a pipeline in the 
plugin that defines some information (like embedded styles) on the fly.

> I still cannot see a big difference between a
>       class=" background_color__ff0000  "
> and a style="{background-color=#ff0000;}"
> Both look to me like style information ;-)

The two differences are subtle, but very important:

- class promotes reuse (i.e. we don't want to allow style in the 
intermediate docs as they are used for many other purposes, including as 
source documents)

- class can be overridden by external stylesheets, style cannot.

> This is different in the OOo where styles are used
> consistently throughout the document.
> In the Excel plugin it's basically a one-time use.

You know you may like to consider an alternative support for MS Office 
files. It is, IMHO, a better solution to the whole MS Office document 
problem. One that does not require the user to save in a different 
format and does not require Forrest to maintain two input plugins.

OOo can be run as a headless server. If we create a generator that uses 
OOo to convert from the MS formats to OOo then we only need to maintain 
the OOo plugin and an MS conversion plugin (and any other OOo supported 
formats). This will give us full support of all the MS office formats we 
support currently support in the OOo plugin (currently not Excel/Calc 
I'm afraid, that's why I never said anything sooner).

If you are interested we have some code that does this in another 
project, it just needs packaging as a generator (requires Java skills 
though). Start another thread if you'd like to have a go.


View raw message