Calligra on Tizen and beyond

[Jos van den Oever]

On Wednesday, October 12, 2011 11:31:56 AM Jos van den Oever wrote:
> On Wednesday, October 12, 2011 10:35:40 AM Sebastian Sauer wrote:
> > On 09/30/2011 07:04 PM, Jos van den Oever wrote:
> > > On Friday, September 30, 2011 18:48:59 PM Sebastian Sauer wrote:
> > >> On 09/30/2011 06:17 PM, Boudewijn Rempt wrote:
> > >>>> Anything you do in such development is constrained by WAC unless you
> > >>>> agree to break compatibility and inject binary lib - then you'd have
> > >>>> to deploy it to other systems too (but the why to skip native Qt
> > >>>> programs?)
> > >>> 
> > >>> I don't agree. I think it's perfectly possible to write a
> > >>> full-featured office suite in html + javascript. Google has already
> > >>> done that.
> > >> 
> > >> google docs is not even close to be a full-featured office suite. It's
> > >> an extended text-editor
> > >> on top of a relational db. The gdata-API is insufficient for anything
> > >> more complex. But then
> > >> that is also an advantage. They don't try to be feature-complete with
> > >> MSOffice/OpenOffice/Calligra
> > >> but only offer an online (and since some time even offline) richtext
> > >> editor/calculator/presenter.
> > >> 
> > >> But yes, I think that it would be possible too :-)
> > > 
> > > There are things that are simply impossible or very hard even in HTML5.
> > > For exmple consider positioning of draw:frame in a brower. The anchor
> > > can be relative to paragraph, to character or to page. This distinction
> > > is not so easy to do in CSS. I give this example since I've studied
> > > that recently.
> > 
> > I did study WebOdf a bit but now I wonder why only CSS? I mean why
> > not some Javscript-magic that does the positioning?
> 
> This is done partially. Some thing cannot be solved with only css. In these
> cases, a custom attribute is added, a position calculated with css and this
> is then used. It it not possible to do positioning directly on non-html
> elements in all browsers; one needs to go via CSS. But the logic is still
> done with javascript.
> 
> > > What the best solution is, I cannot tell. I think that HTML5 layout
> > > will become more advanced and that webodf will benefit from that.
> > 
> > That would be HTML6 or 5.1 then. Taken the current speed HTML
> > and the browsers develop into account that's perfect possible.
> 
> No, it would be a newer CSS version, HTML is irrelevant. But also in CSS
> there is quite some movement, e.g.
> http://www.w3.org/TR/css3-multicol/
> http://www.w3.org/TR/css3-text/
> http://www.w3.org/TR/css3-page/
and 
http://dev.w3.org/csswg/css3-exclusions/
http://labs.adobe.com/technologies/cssregions/
These really make ODF much more mappable to HTML + CSS by introducing advanced 
wrapping and pagination and frames.
This leaves the problem of tab stops though. Some older proposal is not 
implemented, as far as i know:
http://www.w3.org/People/howcome/t/970224HTMLERB-CSS/WD-tabs-970117.html

Cheers,
Jos