More than 10 years ago I wrote something similar for KDE. It was called Knapsack. It monitored all keys pressed on the X desktop, all text on the clipboard and the title of the active window. It used all that text to show files related to the users current activity.
Every time a user would click a suggested file, the system would get positive feedback about that suggestion in that context: it learned.
In ODF, hatching is allowed in pages and graphical objects, but not on table cells or paragraphs. You could ask LibreOffice to implement this and when this works well there and in one other implementation, the ODF specification could be extended with the new feature.
As a workaround, you could use images with a hatch pattern as background.
It's different: WebODF uses ODF as a file format. You can see this by going clicking on the text and doing 'inspect element'. This will show you the actual ODF xml.
You might be able to get the procedure sponsored if you choose to have a particular motif. I'm assuming that it's possible to selectively etch away the melanin. So this breakthrough opens the way to eye tatoos.
Why load a document only to have it mangled by converting it to the internal format of some online text editor?
When loading a document, any document, that you want to edit and then save back, there should be no conversion whatsoever. The question of how good support for ODF is, should not be 'how badly does it mangle my documents?'. It should be a given that the document is *not* mangled. The question on how good the support for ODF, or any file format, is, should be: 'what types of edits can this program make on this file format.'
For decades, we're accepting that documents editors save back a file that, on the binary level, is almost, but not quite, entirely unlike the original file. How weird this leniency towards document editors is, becomes apparent when looking at at how computer programmers work with documents. Computer programmers always use plain text files for everything. When the text editors they use saves their documents with tabs instead of spaces, or utf16 instead of utf8, they get quite irate and will abandon that text editor forever. Why do normal users not get angry at document editors that mangle their documents?
So instead of choosing these horrible black box online text editors, I advise you to use something like WebODF. This ODF editor, which is purely client-side javascript, can run on your private site and saves your ODF back as it found it with changes only in the places where you edited the document.
Answer: there is no schema. Validating documents seems to have gone out of fashion. Writing a parser for HTML5 is extremely difficult. Basically the broken parsing behavior of old browsers is now standardized in a crazy arcane description of how to parse HTML5 documents.
A law that forbids selling hardware and software together would increase innovation. Consumers would only be able to buy hardware and software separately. That way, hardware vendors are encouraged to document the hardware and software vendors will compete on quality. Installation procedures would become very easy very quickly due to market pressure.
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 to even pass the file to a server. It is a client-side library that can parse a file purely in the browser without any network access.
If you use WebODF with a CMS, you can let the CMS decide which files WebODF has access to. When WebODF loads a document, it checks for any JavaScript present and prevents it from being executed.
WebODF is set up such that you only need a few files to run it and all those files can be hosted on your own server or placed in your own application. There is no need for any reliance on any 3rd party.
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 to view ODF documents on your phone.
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.
Zarafa and Kolab 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 hope this will get the same following as the fairphone did. That project was a good success and has built a user base to grow from. It's especially jarring to great projects like vivaldi fail when government regularly throw away hundreds of millions on failed ict projects.
When importing an ODT into Google Docs, it is converted to a format internal to Google Docs. The blog post explains that in WebODF / ownCloud Documents, conversely, no conversion occurs.
For example, WebODF does not support displaying columns yet, but if you have loaded a document with columns, after saving, the columns will still be there.
Since the document is part of the DOM, you can edit it programmatically with JavaScript. So adding functionality for scientific citations is as easy as any website programming. You can do it the clean way and use operations, or you can change the DOM directly. (The latter is not advised in collaborative mode.) So yes, integrating with Zotero, should not be hard.
Adding WebODF into a workflow for collaboratively writing research proposals could be useful. One author adds 'fancy' stuff in e.g. LibreOffice and the other contributors make corrections and additions in a web version of the document.
The server side can be really simple. In a real-time collaboration scenario, there needs to be conflict resolution. The code for that is implemented in JavaScript as well and, in the case of ownCloud Documents, runs in the clients.
Each change to the document is sent as a numbered operation to the server. If a change with the same number has already arrived, the latest changes are sent back to the client. The client then modifies/rebases the original change on top of the new changes and send the change again.
The server stores each individual numbered change for the document as well as snapshots of the document for certain revisions. With some work, one could even store the change (audit trail) inside the document.
AbiCollab certainly precedes by many years. WebODF is newer and has two advantages of AbiCollab.net.
First, WebODF runs just in a browser with no need to install it locally. It runs completely on a webpage. That's why it can by integrated into any web-based workflow. E.g. a user could generate a document by filling in a questionnaire and edit a document afterwards with WebODF.
Second, there is no document conversion. A document that is loaded into LibreOffice, AbiWord, OpenOffice, or Microsoft Office, edited and saved again, will be significantly different from the original document. Features may be lost or saved differently. Since WebODF just loads the ODF XML into the DOM and saves back the DOM, the document is unchanged, except for the places that have been edited. This is even true when the documents contains features, e.g. xforms, that are not supported yet.
The goal is to detect the presence of low amounts of certain molecules related to criminal activity. There is no need to detect scents. So the question is: why are there no cheap and portable detectors that find low concentrations of molecules in the air?
Animal scent is based on vibrations in molecules that dock to receptors in the nose. This allows detection of very low concentrations of molecules. Similar systems can now be created artificially.
The store with apps is not available on Linux and neither is a consumer targetted downloadable driver. There's an SDK that works on Linux. By works I mean it runs. The controller itself is not very good.
You can avoid these delays by overloading the ontouchstart and ontouchend events. These are instant. onclick is not triggered until the mobile browser is certain that you are not inputting a gesture.
That's also why Stallman's solution is ridiculous. When companies are too big to fail, their single-customer suppliers are too vital to fail, regardless of which division they supply. Splitting up a big company doesn't do anything to the risk, but it makes hippies happier.
The suppliers will only fail if the single-customer fails. The single-customer will not have significant problems if one of their suppliers fail. Stallman's suggestion is excellent!: Large companies will pay a percentage of their income as tax. The percentage increases with the global gross income of the company. This will force these companies to have good long term business strategies.
Slashdot Mirror
More than 10 years ago I wrote something similar for KDE. It was called Knapsack. It monitored all keys pressed on the X desktop, all text on the clipboard and the title of the active window. It used all that text to show files related to the users current activity.
Every time a user would click a suggested file, the system would get positive feedback about that suggestion in that context: it learned.
https://mail.kde.org/pipermail...
In Konsole, you move to the tab to the left the SHIFT+LEFTARROW and to the right with SHIFT+RIGHTARROW.
You can change the order of the tabs with SHIFT+CTRL+LEFTARROW and SHIFT+CTRL+RIGHTARROW.
cogito ergo innocent
In ODF, hatching is allowed in pages and graphical objects, but not on table cells or paragraphs. You could ask LibreOffice to implement this and when this works well there and in one other implementation, the ODF specification could be extended with the new feature.
As a workaround, you could use images with a hatch pattern as background.
It's different: WebODF uses ODF as a file format. You can see this by going clicking on the text and doing 'inspect element'. This will show you the actual ODF xml.
Demo:
http://www.vandenoever.info/bl...
You might be able to get the procedure sponsored if you choose to have a particular motif. I'm assuming that it's possible to selectively etch away the melanin. So this breakthrough opens the way to eye tatoos.
Why load a document only to have it mangled by converting it to the internal format of some online text editor?
When loading a document, any document, that you want to edit and then save back, there should be no conversion whatsoever. The question of how good support for ODF is, should not be 'how badly does it mangle my documents?'. It should be a given that the document is *not* mangled. The question on how good the support for ODF, or any file format, is, should be: 'what types of edits can this program make on this file format.'
For decades, we're accepting that documents editors save back a file that, on the binary level, is almost, but not quite, entirely unlike the original file. How weird this leniency towards document editors is, becomes apparent when looking at at how computer programmers work with documents. Computer programmers always use plain text files for everything. When the text editors they use saves their documents with tabs instead of spaces, or utf16 instead of utf8, they get quite irate and will abandon that text editor forever. Why do normal users not get angry at document editors that mangle their documents?
So instead of choosing these horrible black box online text editors, I advise you to use something like WebODF. This ODF editor, which is purely client-side javascript, can run on your private site and saves your ODF back as it found it with changes only in the places where you edited the document.
Where's the schema (DTD/XML Schema/Relax NG)?
Answer: there is no schema. Validating documents seems to have gone out of fashion. Writing a parser for HTML5 is extremely difficult. Basically the broken parsing behavior of old browsers is now standardized in a crazy arcane description of how to parse HTML5 documents.
http://www.w3.org/TR/html5/syn...
Who benefits from such crazy parsing rules? The current browsers. This raises the bar for entry.
A law that forbids selling hardware and software together would increase innovation. Consumers would only be able to buy hardware and software separately. That way, hardware vendors are encouraged to document the hardware and software vendors will compete on quality. Installation procedures would become very easy very quickly due to market pressure.
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 to even pass the file to a server. It is a client-side library that can parse a file purely in the browser without any network access.
If you use WebODF with a CMS, you can let the CMS decide which files WebODF has access to. When WebODF loads a document, it checks for any JavaScript present and prevents it from being executed.
WebODF is set up such that you only need a few files to run it and all those files can be hosted on your own server or placed in your own application. There is no need for any reliance on any 3rd party.
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 to view ODF documents on your phone.
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.
Zarafa and Kolab 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 hope this will get the same following as the fairphone did. That project was a good success and has built a user base to grow from. It's especially jarring to great projects like vivaldi fail when government regularly throw away hundreds of millions on failed ict projects.
For example, WebODF does not support displaying columns yet, but if you have loaded a document with columns, after saving, the columns will still be there.
Since the document is part of the DOM, you can edit it programmatically with JavaScript. So adding functionality for scientific citations is as easy as any website programming. You can do it the clean way and use operations, or you can change the DOM directly. (The latter is not advised in collaborative mode.) So yes, integrating with Zotero, should not be hard.
Adding WebODF into a workflow for collaboratively writing research proposals could be useful. One author adds 'fancy' stuff in e.g. LibreOffice and the other contributors make corrections and additions in a web version of the document.
The server side can be really simple. In a real-time collaboration scenario, there needs to be conflict resolution. The code for that is implemented in JavaScript as well and, in the case of ownCloud Documents, runs in the clients.
Each change to the document is sent as a numbered operation to the server. If a change with the same number has already arrived, the latest changes are sent back to the client. The client then modifies/rebases the original change on top of the new changes and send the change again.
The server stores each individual numbered change for the document as well as snapshots of the document for certain revisions. With some work, one could even store the change (audit trail) inside the document.
AbiCollab certainly precedes by many years. WebODF is newer and has two advantages of AbiCollab.net.
First, WebODF runs just in a browser with no need to install it locally. It runs completely on a webpage. That's why it can by integrated into any web-based workflow. E.g. a user could generate a document by filling in a questionnaire and edit a document afterwards with WebODF.
Second, there is no document conversion. A document that is loaded into LibreOffice, AbiWord, OpenOffice, or Microsoft Office, edited and saved again, will be significantly different from the original document. Features may be lost or saved differently. Since WebODF just loads the ODF XML into the DOM and saves back the DOM, the document is unchanged, except for the places that have been edited. This is even true when the documents contains features, e.g. xforms, that are not supported yet.
The goal is to detect the presence of low amounts of certain molecules related to criminal activity. There is no need to detect scents. So the question is: why are there no cheap and portable detectors that find low concentrations of molecules in the air? Animal scent is based on vibrations in molecules that dock to receptors in the nose. This allows detection of very low concentrations of molecules. Similar systems can now be created artificially.
The store with apps is not available on Linux and neither is a consumer targetted downloadable driver.
There's an SDK that works on Linux. By works I mean it runs. The controller itself is not very good.
The dance needed to avoid an event from propagating is quite occult.
function claimEvent(evt) { .......
"use strict";
if (evt) {
if (evt.preventDefault) {
evt.preventDefault();
}
if (evt.stopImmediatePropagation) {
evt.stopImmediatePropagation();
}
if (evt.stopPropagation) {
evt.stopPropagation();
}
}
return false;
}
ontouchstart = function (event) {
return claimEvent(event);
}
You can avoid these delays by overloading the ontouchstart and ontouchend events. These are instant. onclick is not triggered until the mobile browser is certain that you are not inputting a gesture.
Management was involved but did not decide. Don Melton decided to use KHTML:
The suppliers will only fail if the single-customer fails. The single-customer will not have significant problems if one of their suppliers fail. Stallman's suggestion is excellent!: Large companies will pay a percentage of their income as tax. The percentage increases with the global gross income of the company. This will force these companies to have good long term business strategies.
And you have not even mention one.
OpenDocument Format is also a zip container with XML inside.