[odf-discuss] Native ODF support in browsers

[Pete Harlow]

I think the confusion over the native/plugin thing stems basically from the
more monolithic architecture of Firefox, and the modular architecture of
Konqueror.

Firefox can (as far as I know) render only with Gecko, so anything other
than HTML either has to be transformed to that, or rendered inside an html
document by a helper plugin.

Konqueror, it seems, can dynamically load its rendering engine to suit the
current document.

There is, I believe, a parallel in the Mozilla world. IIRC, the later
Netscape browsers load either Gecko for standards compliant HTML or the IE
rendering engine for MS HTML (TM).

I suppose at the end of the day, as long as speed and footprint remain
acceptable, the technology is not important., but the functionality is.
Certain things - pagination springs to mind - will never be easy going
through an HTML rendering agent.

So I suppose the distinction is one of either direct rendering - where the
ODF rendering agent communicates directly with the display, or indirect
rendering, where what can be displayed is limited by the capabilities of the
format being displayed downstream.

-P.

On 24/10/06, David Cartwright <odfmail at alkira.com> wrote:
>
> marbux wrote:
> > And ODF certainly has something to offer at the edge between
> > traditional word processing documents and web applications where
> > people attempt to emulate traditional document publishing on the web.
> > For example, creation of footnotes, endnotes, and tables of contents
> > is a mess of different methods now among web apps largely because CSS
> > and HTML were never designed to solve such problems, so we have
> > instead a huge mess of different and incompatible work-arounds mostly
> > implemented at the application level.
> Excellent example .... and a potential strategic benefit  to both ODF
> and browser developers.
>
> Lars D. Noodén wrote:
> > On Fri, 20 Oct 2006, Alex Hudson wrote:
> >> Plugins are fine, but they're their own little world, it's not the same
> >> as native display.
> >
> > How about plug-in support as an intermediat step to native display?
> Yes. Small steps can be a good way to move towards the final goal, as
> long as the final goal remains in view.
>
> It was mentioned that Firefox has 12% market share. Whether it is 10% or
> 20%, the point is that anybody who cares about open standards and open
> source cannot be satisfied with such a low marketshare ..... and I am
> sure the Mozilla Foundation has a goal to continue to grow that
> marketshare. I am sure the KDE Project and Opera Software (that at least
> cares about open standards) have similar goals to grow their marketshare.
>
> And what about ODF .. what marketshare would we like to see ODF achieve?
> 10% ... 20% .... What marketshare is achievable? Again I am sure that
> many of us would hope to eventually hit >80%.
>
> So how do we get there?
>
> I think there have been some good points raised about potential
> synergies between the goals of ODF and the goals of the Mozilla
> Foundation / KDE Project in addition to the goals of non-open source
> products such as Opera Software. To gain marketshare in the browser
> space, I believe there are real potential benefits for organizations
> such as the Mozilla Foundation, KDE Project, Opera Software to move
> towards native rendering of ODF.
>
> Yes, there are plenty of issues to be resolved. For example, Marbux's
> "Towards a solution of the file type association problem" precisely
> addresses the concerns raised by Thomas Zander a few days ago. Yes,
> there are challenges, but solutions can be worked out.
>
> Based on my reading of the Wikipedia articles:
> http://en.wikipedia.org/wiki/Gecko_(layout_engine)
> http://en.wikipedia.org/wiki/KHTML  and in trying to digest the
> technical aspects of the responses, would it be correct to say that
> native rendering in Firefox could be best stated as native rendering in
> the Gecko engine, while native rendering if a KDE environment means
> native rendering in the KHTML layout engine?
>
> Perhaps the KHTML terminology has caused confusion. It certainly
> confused me, because if I have correctly understood the Wikipedia
> article, KHTML could also be developed to provide 'native' rendering of
> ODF. By native rendering I have in mind that the rendering engine does
> not go through an intermediary stage of converting the ODF file into
> HTML before correctly rendering the file.
>
> Following on from the points raised by Lars, would it be appropriate to
> make a formal pitch/approach to the Mozilla Foundation, the KDE Project,
> Opera Software regarding the benefits of native support of ODF (that may
> also involve an intermediary step via a plugin)?
>
> David Cartwright
> Senior Consultant
> Alkira Australia
> _______________________________________________
> odf-discuss mailing list
> odf-discuss at opendocumentfellowship.org
> http://lists.opendocumentfellowship.org/mailman/listinfo/odf-discuss
>



-- 
Pete Harlow
Catnip Corner - Photography by Pete Harlow - http://www.catnip.co.uk/
OpenDocument Fellowship - http://opendocumentfellowship.org/
Play Ogg Vorbis on your iPod - http://www.rockbox.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20061024/654a9677/attachment-0002.html