Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Software

WebODF: JavaScript Open Document Format Editor Deemed Stable 91

Posted by Unknown Lamer from the google-docs-for-the-rest-of-us dept.
oever (233119) writes with news that WebODF (an Open Document Format editor written entirely using Javascript and natively rendering the XML document using CSS) 0.5.0 has been released, and the developers are declaring this release stable enough for every day use. TheMukt chides Google for not supporting the OpenDocument Format well and claims that the newly released WebODF 0.5.0 in combination with ownCloud is the answer to this deficiency. A WebODF developer blog highlights all the goodies in the first WebODF release where the text editor is considered stable and made available as an easy to use component. These include extensive benchmarking, unit testing, and advanced HTML5 techniques to give the editor a native feel. There's also touch screen support, and better support for real-time collaborative editing. A demo shows off a few of the features.
This discussion has been archived. No new comments can be posted.

WebODF: JavaScript Open Document Format Editor Deemed Stable More

WebODF: JavaScript Open Document Format Editor Deemed Stable

Comments Filter:

  • Wow! (Score:3)

    by davids-world.com ( 551216 ) on Wednesday July 02, 2014 @09:29AM (#47368443) Homepage
    This is fast and responsive. Does it avoid long-standing Word problems, such as figures that jump away from captions, paragraphs that adopt the adjacent style just because you're moving them around, and the like? For professional writing, I'll stick to LaTeX for now. For collaborative writing, something like this could be nice (and improve on half-baked solutions like the editor in OneDrive (very slow) or Google Doc (not word-compatible). So, I think this would have to be able to export / import Word docs seamlessly, due to business pressure everywhere...
    • No "track changes", as it seems. :-(

      • Re:Wow! (Score:4, Interesting)

        by Anonymous Coward on Wednesday July 02, 2014 @09:50AM (#47368621)

        In collaborative mode as used in ownCloud, each document edit is stored as an operation such as AddImage, AddText, MoveCursor etc. (WebODF implements Operation Transformation for editing) With this stack of operations and the original document, any intermediate state of the document can be recreated. There is currently in WebODF no method for displaying changes in a single document, but it's straightforward to show different versions of a document side-by-side in your website or application.

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      WebODF uses OpenDocument Format (ODF) as the runtime document model. That means that there is 0 (zero) data conversion when loading and saving a document. It does not support OOXML, but it could load an OOXML document if it was converted to ODF. It is not clear that the same approach (style unchanged XML with CSS) could work with OOXML. Have a look with your browsers 'Inspect Element' function in the demo. The DOM is ODF XML, not HTML.

      A lot of work was done on responsiveness. A mischievous edit bot [github.com] is used

    • This is a really impressive start. It's not done, but they don't claim it is. It's responsive and does quite a bit.

  • does it support (Score:1)

    by Anonymous Coward

    Does it support markdown?

    • Re: (Score:1)

      by Anonymous Coward

      No. But conversion from markdown to odf and back shouldn't be too hard to write. WebODF is a library so you can use it in an app where you add markdown support.

  • Very nice. I just wonder does it use fonts off the web server, fonts on the client, or both? (And are any of the font license issuers freaked out about the former?)

    .

    • Re: (Score:3, Informative)

      by Anonymous Coward

      It can use fonts embedded in the file and fonts provided via css. Fonts provided via css can be stored on the server or, when WebODF is used in a desktop or mobile application, on the local machine. There is not really anything for font license issuers to freak out about. PDF can embed fonts too as can OOXML. Providing fonts via css is common on the web these days and of course one should check the license when doing so.

  • As long as you don't use page breaks (Score:3, Interesting)

    by watermark ( 913726 ) on Wednesday July 02, 2014 @09:42AM (#47368545)

    It's stable and ready for every day use, as long as you don't need page breaks. I have a 3 page odt containing page breaks and WebODF just throws all of the text and images at the bottom of the first page.

    How is this ready for every day use without supporting something as basic as page breaks? Page breaks go back to Word 1.beforeiwasborn

    • Re: (Score:1, Informative)

      by Anonymous Coward

      Adding page breaks is on the to do list. Here is technical preview [webodf.org] of pagination. Displaying properly is part of that work. Help, code or finances, are welcome to make this work land sooner.

      • Re: (Score:1)

        by Anonymous Coward

        Then it is not ready for everyday use. This is spam and now you even tell people to give you money...

    • Page breaks in word processors existed long before Word.

    • So, page breaks broke your pages? Sounds about right!

    • Re: (Score:3, Informative)

      by VVelox ( 819695 )

      I actually would not consider this ready for every day use. It does not even play nicely with what I have at home as the following are broken.

      1: It can't handle multiple columns.
      2: No real support for index work.
      3: Can't create tables or modify number of columns/rows.
      4: No header/footer support.
      5: No footnote support.
      6: Embedded images tend to overlap text.
      7: The equation stuff is not supported.

      That said this is still bad ass and I look forward to seeing how it progresses.

  • Let's put all Knowledge into the Cloud (Score:1)

    by Anonymous Coward

    ...so that our NSA overlords have it on a silver plate. And for god's sake, don't encrypt. Only terrozists do that !!!!!!!

  • Yippie... (Score:4, Funny)

    by ericloewe ( 2129490 ) on Wednesday July 02, 2014 @10:30AM (#47368973)

    Because the general complaint about OpenOffice/LibreOffice was that Java made it too fast. /s

    Next up! A web browser written in Javascript.

    • Re: (Score:1)

      by Anonymous Coward

      webkit.js: http://trevorlinton.github.io/

      On a serious note: WebODF started as a C++ extension to Webkit. It turned out that the logic for the document editor was not the performance bottleneck and might as well be written in javascript. This sped up development a lot. Naturally, C++ has better type checking than javascript but by using closure compiler this can be partially alleviated. WebODF is 100% annotated with type information.

      • It gets better: Chrome is going to have portions of it (the DOM, notably) rewritten in JS to improve performance further. ;-)

    • Next up! A web browser written in Javascript.

      No need to wait, it's already here [google.com].

    • Neither OpenOffice or LibreOffice are written in Java though, they are mostly C++. Java is only used for the HSQLDB and some wizards and parts in Base.

    • Re: (Score:1)

      by Anonymous Coward

      In Safari the JavaScript anything running for a few seconds on a webpage is compiled with the same LLVM compiler that I use to make executable code for C, producing executable native code (google for "safari ftl"). If anything the resulting executable is faster than all but the most hand optimized C code because the higher-level non-pointer based language offers guarantees that a pointer based language doesn't offer, meaning the compiler is able to make better optimizations because it's more aware of how t

      • Re: (Score:1)

        by Anonymous Coward

        The official Webkit blog [webkit.org] has a post about it.

      • If anything the resulting executable is faster than all but the most hand optimized C code because the higher-level non-pointer based language offers guarantees that a pointer based language doesn't offer, meaning the compiler is able to make better optimizations because it's more aware of how the JavaScript code can be called than C code where suddenly the user can just do some pointer arithmetic and break encapsulation.

        That's the same claim that everyone's been making for ages. It's unlikely to be true f

  • Looking forward to see this build into web mail solutions.

    • Re: (Score:1)

      by oever ( 233119 )

      Zarafa [zarafa.com] and Kolab [mykolab.com] already use WebODF for displaying ODF attachments, but not yet for editing. There's also an android app that handles displaying ODF documents by registering to handle the ODF mimetypes.

  • I tried it (Score:1)

    by Anonymous Coward

    I couldn't figure out a way to add a table of contents. Otherwise it seemed pretty decent.

  • Potentially of interest if there was a shred of setup/implementation information, after an hour of looking, following false trails and futzing I gave up.
  • Do I open up my Galaxy Note 3's pen context to perform a Microsoft Windows function or do I just use terminal to cntrl+ click?

    • Re: (Score:1)

      by oever ( 233119 )

      Are you talking about writing text in the webodf editor demo? If you cannot input text on your Galaxy Note 3 there, we might be able to help if you file an issue [github.com].

      • Following the link to their demo provides an explanation of their product. At the bottom of their explanation it has a link to their website. To follow the link to their website they use a windows editor context to press the cntrl key to follow the link. My joke was about an OS specific context to perform a simple function.

  • zotero (Score:3)

    by spasm ( 79260 ) on Wednesday July 02, 2014 @01:41PM (#47370833) Homepage

    Link zotero to this and you'll have a solution academic collaborators have been looking for since the beginning of word processing.. Seriously, we need a collaborative writing platform which allows multiple authors to add citations.

    • To be honest, I don't think ODF is optimal for this. To me it still feels like "moderate progress within the bounds of the law". You could easily - well, more easily than many other things - make a collaborative, real-time editable "Authornet", but it wouldn't probably have much in common with local-file-based editors. It would be more like some kind of a distributed object database. (I think the VPRI people are actually heading roughly in this direction.)

    • Link zotero to this and you'll have a solution academic collaborators have been looking for since the beginning of word processing.. Seriously, we need a collaborative writing platform which allows multiple authors to add citations.

      Well, IME a good VCS and latex work remarkably well for that task. Actually, having used Zotero, I am honestly astonished how much time people are prepared to burn in order to not learn latex. You'd get parity if not payback in effort just on the first paper. After that, it's a n

      • Generally, something like Dropbox and LaTeX work fine - unless you have two people editing the same file at the same time. Then, any VCS or something like Dropbox fail miserably. I have tried https://www.writelatex.com/ [writelatex.com], but of course I'd like to keep using my local Aquamacs instead of a web-based solution. Maybe I'll write a synchronization tool for Emacs. The issue is then that we need to integrate people who don't use Emacs...

        • Generally, something like Dropbox and LaTeX work fine - unless you have two people editing the same file at the same time. Then, any VCS or something like Dropbox fail miserably.

          Not that miserably: for a VCS the diff tools can sort out a lot of conflicts. The main problem is editing the same lines within the file. At that point it at least tells you there's a conflict (as opposed to the last person wins model of dropbox). But yeah at that point someone needs to fix the mess.

          IME though this is a rare case. U

  • the developers are declaring this release stable enough for every day use

    anyone see anything wrong with that statement?

  • This thing has access to my hard drive, to fucking save files!!!!

    This thing will never, ever, be used anywhere I have a say about. This is ripe for someone to hook it from another page and write shit to anywhere on your hard disk that you have permission to write to. Drive By's were bad enough but now we have opened the flood gates. The script kiddies and the black hast are going to have a field day owning anyone who runs this.

    The Browser is bad enough as it is with "precisely formed" URL's being able t

    • Re: (Score:2)

      by oever ( 233119 )

      The WebODF developers take security very seriously. WebODF runs in a browser and web browsers are the most battle hardened sandboxes available.

      WebODF has no more access to your hard drive than any unprivileged website. If you press the icon to open a file, WebODF asks the browser to let the user pick one file. That file, and only that file that the user chose, is then passed to WebODF so it can open it. This is no different from an HTML form for uploading files. The difference is that WebODF does not need t

      • Yeah that's reassuring and all. The WC3 takes security very seriously as well as do the makers of Mozilla, IE, Chrome, Opera, Safari et al. but never the less we still have drive by's, we still have machines with AV software, anti-malware, Sand Boxing software etc installed and they still get through and steal whatever they want.

        Javascript is a language that scares the hell out of anyone who takes security seriously. You can shove text at any object and presto that is now executable code, oh yay!!! Your

  • https://github.com/kogmbh/WebO... [github.com]

    I like Dojo in part because it attempts to make all the core widgets accessible. From:
    http://dojotoolkit.org/referen... [dojotoolkit.org]
    "Dojo has made a serious commitment to creating a toolkit that allows the development of accessible Web applications for all users, regardless of physical abilities. The core widget set of Dojo, dijit, is fully accessible since the 1.0 release, making Dojo the only fully accessible open source toolkit for Web 2.0 development. This means that users who requir

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close