Svante, I thought you had us Americans convinced "Vacation" is a default value :)
When would you anticipate the switch-over to XSLT 2.0 ? Does the free Saxon handle that or is the warning just to nag you to upgrade? Dr. Kay might not admire my, um, frugality, as much as I do his work. The <head> meta data needs quite a bit of work. I do not think that the itemprop mechanism in HTML 5 is going to make the modeling issues (SKOS, OWL) with Linked Data any clearer. I am working on an OpenOffice to Linked Data "Home Page" scheme for small scale Government Work. With 5-6 small steps I can switch to an XSD Schema and tag the meta data and citations important for linking, yet preserve the layout style which is easy to read. The idea is that if you had a pile of forms (raw data) you could first redact out the private data then make a "Home Page" for the rest of the data, linked with deri's voiD or something similar. The hardest part is to convince *yourself* that commercial branding and style tricks behind the scenes are counter-productive. As I am fond of saying, everybody lives near "Berlin", but only some of those Berlins are in Germany. --Gannon --- On Fri, 4/9/10, Svante Schubert - Sun Germany - Software Engineer <[email protected]> wrote: > From: Svante Schubert - Sun Germany - Software Engineer > <[email protected]> > Subject: Re: [xml-dev] odf2xhtml > To: [email protected] > Cc: [email protected] > Date: Friday, April 9, 2010, 8:31 AM > Hi guys, > > sorry for the belayed response. Coincidently I had been > working on the > XHTML filter lately, fixing some image alignment problem > (using CSS > float to get a similar layout as in OOO). When I bring in > this changes > into OOO, we can work together on the filter. > > I like the idea of keeping the inheritance via multiple > styles, it will > lower the burden of resolving inheritance from ODF to HTML. > Years ago it > did not work in the main browsers, did you tested it if it > is now > working in the latest common browsers? > > Regarding the switch from XSLT 1.0 to XSLT 2.0, we would > drop the > possibility to use XSLT 1.0 processors. > For instance, I once wrote a prototype of a Firefox viewer > using the on > board Mozilla XSLT processor. > What are the advantages of XSLT 2.0? > > Note: When we upgrade Saxon - what I thinking over to do as > there are > some bugs lately fixed, that causes problem in some filter > - there will > no longer Java method access being supported by the free > Saxon Home edition. > As this Java method Access is a none standardized feature I > am willing > to switch to the latest version and dropping this > undocumented feature. > > Going to be next week on vacation, soon after that I plan > to start a CWS > where we can work together on the HTML filter. > Martynas could you write please write an issue, that we > might use in the > CWS? Otherwise the QA might oversee your patch. > > Thanks in advance, > Svante > > > On 03/21/10 16:56, Martynas Jusevicius wrote: > > I forgot I'm running it on XSLT 2.0 processor... > > <xsl:apply-templates select="$parentStyle"> will > probably not work in > > XSLT 1.0, but you get the general idea. > > > > On Sun, Mar 21, 2010 at 4:29 PM, Martynas Jusevicius > > <[email protected]> > wrote: > >> Here's a partial fix for this issue, I don't know > if I should try > >> submitting it somewhere. > >> > >> It requires modification of > /export/xhtml/body.xhtml stylesheet: > >> http://framework.openoffice.org/source/browse/*checkout*/framework/filter/source/xslt/odf2xhtml/export/xhtml/body.xsl?content-type=text%2Fplain&rev=1.3.16.3 > >> > >> @text:style-name template needs to be modified and > one recursive > >> template (inherited-classes) needs to be added: > >> > >> <xsl:template match="style:style" > mode="inherited-classes"> > >> <xsl:param name="globalData"/> > >> <xsl:variable name="styleFamily" > select="@style:family" /> > >> <xsl:variable > name="parentStyleName" select="@style:parent-style-name" > /> > >> <xsl:variable name="parentStyle" > >> > select="$globalData/office:styles/style:sty...@style:family > = > >> $styleFamily and @style:name = > $parentStyleName]"/> > >> > >> <xsl:value-of > select="translate(@style:name, '.,;: %()[]/\+', > >> '_____________')"/> > >> <xsl:text> </xsl:text> > >> <xsl:apply-templates > select="$parentStyle" mode="inherited-classes"> > >> <xsl:with-param > name="globalData" select="$globalData"/> > >> </xsl:apply-templates> > >> </xsl:template> > >> > >> <xsl:template match="@text:style-name | > @draw:style-name | > >> @draw:text-style-name | > @table:style-name"><!-- | > >> @presentation:style-name--> > >> <xsl:param > name="globalData"/> > >> <xsl:variable > name="style" > >> > select="$globalData/office:automatic-styles/style:sty...@style:name > = > >> current()]"/> > >> <xsl:variable > name="styleFamily" select="$style/@style:family" /> > >> <xsl:variable > name="parentStyleName" > >> select="$style/@style:parent-style-name" /> > >> <xsl:variable > name="parentStyle" > >> > select="$globalData/office:styles/style:sty...@style:family > = > >> $styleFamily and @style:name = > $parentStyleName]"/> > >> > >> <xsl:attribute > name="class"> > >> > <xsl:value-of select="translate(., '.,;: > %()[]/\+', > >> '_____________')"/> > >> > <xsl:text> </xsl:text> > >> > <xsl:apply-templates select="$parentStyle" > >> mode="inherited-classes"> > >> > <xsl:with-param name="globalData" > select="$globalData"/> > >> > </xsl:apply-templates> > >> </xsl:attribute> > >> </xsl:template> > >> > >> There is also at least one other place in body.xsl > (in the text:h > >> template) where @text:style-name template needs to > be called (with the > >> $globalData param) for the fix to have effect > instead of simply > >> outputting style name to the @class attribute. > >> > >> The full fix would be to prevent excessive > (overlapping in parent and > >> children) CSS properties from bein generated. > >> > >> Martynas > >> odt2epub.com > >> > >> On Fri, Mar 19, 2010 at 5:55 PM, Vyacheslav Sedov > >> <[email protected]> > wrote: > >>> good idea - i can help with XSLT 2.0 - our > project have some odf2xhtml > >>> code - our code is XSLT 2.0 - not XSLT 1.0 > from OpenOffice > >>> > >>> with best wishes, > >>> Slav > >>> > >>> 2010/3/19 Martynas Jusevicius <[email protected]>: > >>>> Hey list, > >>>> > >>>> I've been working with odf2xhtml XSLT > filter a lot lately, in relation > >>>> to ePub e-books. It does its job but it's > really showing its age. I > >>>> wonder if there are plans for a new > version? It could really benefit > >>>> from many of XSLT 2 features. > >>>> > >>>> One of the most annoying things is the > generated CSS. If style A > >>>> defines bold text and style B is inherited > from A and additionally > >>>> defines right alignment, odf2xhtml > generates such code: > >>>> > >>>> .A { font-weight: bold; } > >>>> .B { font-weight: bold; text-align: right; > } > >>>> > >>>> <p class="A"> ... <p > class="B"> > >>>> > >>>> That shows up OK in the browser, but > removes the relationship between > >>>> A and B in the XHTML/CSS output. For > example, if I need to select all > >>>> elements with style inherited from A, I > cannot do that without looking > >>>> into the original ODT and examining the > styles. > >>>> > >>>> I think much better output could be > achieved using multiple classes in XHTML: > >>>> > >>>> .A { font-weight: bold; } > >>>> .B { text-align: right; } > >>>> > >>>> <p class="A"> ... <p class="A > B"> > >>>> > >>>> What do you think? > >>>> > >>>> Martynas > >>>> odt2epub.com > >>>> > >>>> > --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
