OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XSL-FO/CSS


Greetings!

I wanted to start a separate thread on the potential proposal to 
re-work/extend our use of XSL-FO for the next version of ODF.

I think Rob has a good point that too rigid a standard can have adoption 
"issues" but on the other hand, a standard can be so loose that anything 
can be claimed to be an example of use of the standard.

There needs to be a "sweet spot" that offers implementers, users and 
other members of the community various advantages.

I suggested XSL-FO, in part so we can come closer to that standard as 
written but also for a *vocabulary* by which we could create more 
requirements for formatting. Mostly because the formatting of a document 
is seen by users as the test of "interoperability" and not unreasonably so.

I use the term *vocabulary* because I don't mean for ODF to require the 
use of XSL-FO or CSS (which is  used by XSL-FO by reference) or some 
other formatting technology.

What I do mean is to specify the required formatting in a common 
language that is understood and implemented by a substantial community 
so that ODF applications can *duplicate* that formatting by whatever 
means they choose.

For example, ODF formatting might become so popular that someone will 
write a LaTeX stylesheet that produces ODF formatted  text. That looks 
just like Open Office, Symphony, Word, LibreOffice, KOffice, etc. had 
produced it.

The goal is to specify the *formatting* and not the *technology* for 
getting there in the ODF standard.

True, using XSL-FO or CSS can be said to favor at least one way of 
getting there but I think it is a good idea to pick a vocabulary that is 
well known and that *we don't have to write.* That last consideration 
being uppermost in my mind. ;-)

My suggestion would be that we start with what formatting is supported 
now by vendors and where do they differ? Where would additional 
specifics in ODF make a difference in what users see and improve 
"interoperability" in that respect.

The more radical side of me wants to suggest that we look at HTML5 and 
add attributes to ODF elements to incorporate HTML 5 semantics and styles.*

There is a growing amount of vendor interest/support in that area. And 
given that most users view the world through browsers, that might be a 
familiar look.

Just a suggestion. I do think we need greater specifics on formatting 
but have no real commitment to how we do that, so long as we do it well.

Hope everyone is at the start of a great week!

Patrick

* I realize that following HTML 5 puts really sophisticated floating 
sidenote boxes out of reach but high-end typesetting really isn't the 
target market for ODF. Sigh, I really like high-end typesetting for XML 
but that is always going to be a niche market. I think releasing a 
largely HTML5 based semantic markup in two years would hit the format 
market at just about the right time.

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]