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