Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Maybe but my guess is that the people who run that project disagree with the idea that "0.0" should be the version assigned to the first line of code and "1.0" should be the first version deemed stable and ready for general use.

I agree with that kind of numbering so I agree with the GP in this case. I think software statuses are easier to understand when people conform to the 0.0/1.0 convention.

Everyone gets to number their software any way they want, and everyone else gets to gripe about it if they don't l

This is actually a very bad assumption. Lots of software start off with the major version being zero as zero indexing stuff is extremely common when it comes to programming and it only gets bumped when there is a non-backwards compatible change.

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...

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.

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.

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.

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

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.

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.

Because modern browsers are the closest thing we've ever gotten to an actual cross-platform ecosystem with an efficient distribution system baked in. While not 100% by any mean, we're pretty close to a point where you write an app for Chrome, and it will just work in other browsers, including IE back a few versions. You have to make sure not to use certain features, but you don't need annoying abstraction libraries like you would in native code to support *nix vs Windows, nevermind mobile operating systems.

And because of that, the ecosystem around the language is blooming, and the code written can then be used in other environments, like server/client (node.js) and data (mongo). The language sucks, but what was made around it is blissful.

One day you will get a real job and that app you just spent a month making the CEO will like and want to run from his IPad at the airport.

You can either learn to program IOS, or just do it in javascript and it will still work when he decides next week to look at it from his Android phone. While things like Citrix can work for this, that crappy javascript works without plugins and can work better.

Are you serious? The applications exist for when you have access only to a computer and a browser. it doesn't matter what operating system it runs, it doesn't (or shouldn't) matter what browser it running. It doesn't matter that you have no admin rights. If you need to edit a document, it should just work.

You're drowning. Sorry, but reality doesn't agree with your uninformed opinions. JS has been impressively stable, and cross-browser issues have been negligible for a long time now -- none of which, I'll remind you, have been language implementation compatibility issues.

Listening to you, one would think that the web barely functioned, with users needing multiple browsers, and various versions of each, to use a handful of sites. That's clearly not the case.

Here in reality, the web is developing nicely in to a convenient application platform. JS is an impressive language, far more sophisticated and capable than the alternatives you've suggested. (New and constructor functions were the big mistakes, leading to all sorts of confusion, and later hate, for those who didn't take the time to learn the language before using it. Luckily, they're unnecessary. Try actually learning the language. I'll bet your opinion will quickly change.)

I would say your original question was answered, and relatively civilly. Saying that the respondent has no point seems a bit petty. The point was made, and quite ably. Your counterpoint is also clear enough, and readers can decide how much merit and validity it has.

I am not convinced, either, that JavaScript is an elegant language, but I am less convinced that it is crap than I was was back when it referred to nothing more than an array of incompatible pidgn dialects. The fact remains that its greatest stre

Seriously? It doesn't matter if you have admin rights? And thus no means of local storage? So we should all push our documents out 'on the cloud'? So Google or Microsoft has control of everything we do? We should push them out onto 'the cloud' running binaries on machines we don't have admin rights to, giving out passwords each time we do?

I like local storage. It goes beyond liking, actually. I expect local storage. Crap like this just makes it easier for software publishers and 'services' to elimin

ownCloud is one of the projects that uses WebODF. It is software to install a personal cloud on your own hardware. There are also native Windows applications using WebODF. There's also a Firefox OS app [firefox.com] to view ODF documents on your phone.

I own a company that builds custom web-based applications for businesses. Certainly not fortunte 100 companies, but businesses with a dozen or more users doing their job with the system 9-5, Mon-Fri.

Personally I don't use Windows at all. Not sure what the snarky comment about Windows Server was all about. I'm not the IT person for these companies, I am simply familiar with the features offered by it and have seen it in place at most of the businesses we deal with.

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.

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

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

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.

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.

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.

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

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

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