[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] Requirement
Dear Rick, Dear ODF TC, I strongly support to extend ODF with features derived from web-technologies. ODF is currently not on-par with these technologies. See also some of my previous OOo feature requests: [which are well also ODF-limitations] http://qa.openoffice.org/issues/show_bug.cgi?id=79882 http://qa.openoffice.org/issues/show_bug.cgi?id=66169 http://qa.openoffice.org/issues/show_bug.cgi?id=79866 Please be aware, this is not purely an OOo limitation, but includes also severe ODF-limitations and major shortcomings in presentation design concepts. Also, the limitations I am talking about are not limited to the few examples I have provided. Rather, these are only some minor issues, and there are many more missing features. Sincerely, Leonard Rick Jelliffe <rjelliffe@allette.com.au> An: office-comment@lists.oasis-open.org Betreff: [office-comment] Requirement > +NAME > Rick Jelliffe > > +CONTACT > rjelliffe@allette.com.au > > +CATEGORY (select one or more from below) > formatting > > +SCOPE (select one or more from below) > text/presentation > > +USE CASE > > The dominant technology for publishing is HTML and CSS. An ODF > application user needs to > be able to generate high quality HTML and to be able to import HTML pages > and round-trip > them without loss. > > Therefore, ODF needs to support round-tripping of all HTML and CSS > features, to some level. > > > +DESCRIPTION > > ODF should be audited against both HTML 5 (or the most recent version) and > CSS2 (to pick > a reasonable base that would not burden developers), with the purpose of > identifying any > features that cannot be round-tripped with minimal information loss. (I.e. > so that the > HTML/CSS in resembles the HTML/CSS produced.) > > This is not an application issue, it is an issue of ODF having the > necessary slots for the > information. > > Once identified, ODF should have markup added to allow all these features > to be > round-tripped. If recourse is made to some generic mechanism, then an > annex to > ODF should state the method of using these, so that developers do things > in the same > way (i.e. so that if a document goes HTML -> Tool 1 -> ODF -> Tool 2 -> > HTML then the > beginning and ending HTML have highly equivalent markup, and no > information loss. > > Here are two examples: > > 1) CSS2 provides aural stylesheet properties.* I could find no equivalent > in the ODF 1.2 > draft, yet they are clearly a useful accessibility feature. > > 2) CSS2 provides a generated content features.** I could find no > equivalent in the ODF 1.2 > (though I am not certain it is not there under some name I did not search > for.) > > * http://www.w3.org/TR/CSS2/aural.html > ** http://www.w3.org/TR/CSS2/generate.html > > > -- > This publicly archived list offers a means to provide input to the > OASIS Open Document Format for Office Applications (OpenDocument) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: office-comment-subscribe@lists.oasis-open.org > Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org > List help: office-comment-help@lists.oasis-open.org > List archive: http://lists.oasis-open.org/archives/office-comment/ > Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Committee: > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]