Calligra on Tizen and beyond

[Jos van den Oever]

On Wednesday, October 12, 2011 23:44:56 PM Jos van den Oever wrote:
> 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

You can download a demo here:
  http://labs.adobe.com/downloads/cssregions.html
I tested the windows binary with wine. It needs to run from the 'bin' 
directory in the zip.
It is very impressive. The regions and wrapping together make many ODF layouts 
possible now.
Since it's based on webkit, the source code should be available too, i did not 
see the link to that though.

Cheers,
Jos

-- 
Jos van den Oever, software architect
+49 391 25 19 15 53
074 3491911
http://kogmbh.com/legal/