Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

.odt support #261

Merged
merged 1 commit into from Feb 10, 2015
Merged

.odt support #261

merged 1 commit into from Feb 10, 2015

Conversation

twiss
Copy link
Collaborator

@twiss twiss commented Dec 14, 2014

WIP. This is an effort for editing odt files (#108) with designMode. I'm sending this PR early on in case you really dislike the approach re #204.

This is on top of #246, although that isn't really a requirement.

@ferndot
Copy link
Member

ferndot commented Dec 14, 2014

Yay! We have needed new format support for a while. If it is easier to work with designMode, then let's do that. I wanted to use WebODF simply because it seemed better suited to xml documents.

So, I tested, and encountered the following issues:

  • ODT files are not shown in the file browser
  • Manually loading an ODT file produces the following errors:
17:02:45.591 "Loading modules/editor/editor.html" "
    at app.modules.load (app://4c959139-b9c0-3146-adf3-1f1a7a8ef8e7/scripts/modules.js:126:3)" modules.js:126:3
17:02:48.274 "Finished loading modules/editor/editor.html" modules.js:137:8
17:02:49.532 "setSend" undefined Window → app://4c959139-b9c0-3146-adf3-1f1a7a8ef8e7/index.html docIO.js:8:51
17:02:49.533 "setRecv" undefined Window → blob:app://4c959139-b9c0-3146-adf3-1f1a7a8ef8e7/51f61524-3104-408c-837b-51cea91afa95 docIO.js:8:51
17:02:49.888 "setSend" undefined Window → blob:app://4c959139-b9c0-3146-adf3-1f1a7a8ef8e7/51f61524-3104-408c-837b-51cea91afa95 messages.js:47:2
17:02:49.888 "setRecv" undefined Window → app://4c959139-b9c0-3146-adf3-1f1a7a8ef8e7/index.html messages.js:70:2

Again, thank you for working on this 👍

@twiss
Copy link
Collaborator Author

twiss commented Dec 14, 2014

If it is easier to work with designMode, then let's do that. I wanted to use WebODF simply because it seemed better suited to xml documents.

Well, it's not easier, no. The two main reasons are that 1) a consistent editor for all formats is nice and 2) on mobile, designMode currently works slightly better than WebODF.

ODT files are not shown in the file browser

Hmm, this should've done that, shouldn't it? Maybe FFOS doesn't know about .odt files.

Manually loading an ODT file produces the following errors:

That's part of #246, which does throw a lot of errors in some cases, but those aren't errors. Are you able to load html files?

@ferndot
Copy link
Member

ferndot commented Dec 15, 2014

It appears that Firefox OS does not work with odt files. I have filed a bug at: https://bugzilla.mozilla.org/show_bug.cgi?id=1111427.

I am able to load HTML files. The ODF took a long time to load, so I jumped the gun a bit.

@twiss
Copy link
Collaborator Author

twiss commented Dec 16, 2014

Conversion from and to odt now works for very simple odt files. I'll make a list of as of yet unsupported features in #108, feel free to point out more.

In case you ever want to add features, a little explanation:

The most important thing about handling odt files is that we don't lose data or corrupt files. So while we will always attempt to display the file, we will only allow the user to edit it if we're going to generate a valid odt file, i.e., we check that odt -> html -> odt yields the original odt. Of course, this doesn't cover user-generated html.

This means that while developing, that check will complain, a lot. But as Haskellers like to say, once it runs at all, it's also probably correct.

@twiss twiss mentioned this pull request Dec 16, 2014
@@ -5,30 +5,267 @@

'use strict'

function initDocIO(doc, messageProxy, loadCallback) {
var ODTDocument = function(odt) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you put this function in a new odt.js file in /scripts/parsers?

@ferndot
Copy link
Member

ferndot commented Dec 16, 2014

Fantastic work @twiss. I just tested your patch on one of my research papers, and it displayed the ODT surprisingly well.

One idea that I had: do you think that we should split the ODT parser into its own repository, and include it as a git submodule? I feel that it would be very useful to other app developers.

var name = element.tagName;
if(name === "SCRIPT" ? element.src : element.href) {
var type = element.type;
var url = new URI(name === "SCRIPT" ? element.src : element.href, new URI(location.href)).toString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed URI.js in 89e14d8

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it won't be trivial to merge this as it is now. Though I'll split out these changes, they aren't needed for this anymore.

@ferndot
Copy link
Member

ferndot commented Dec 16, 2014

Well, it's not easier, no. The two main reasons are that 1) a consistent editor for all formats is nice and 2) on mobile, designMode currently works slightly better than WebODF.

Hmm, my concern is that designMode does not support all the features of the ODT format. How can we address that issue?

The most important thing about handling odt files is that we don't lose data or corrupt files. So while we will always attempt to display the file, we will only allow the user to edit it if we're going to generate a valid odt file, i.e., we check that odt -> html -> odt yields the original odt. Of course, this doesn't cover user-generated html.

That sounds like a very good approach.

@ferndot
Copy link
Member

ferndot commented Dec 16, 2014

As an aside, I wonder if web components will be useful for developing editors. E.g. instead of converting an XML file to HTML to use designMode, we could just use the existing tags as custom elements.

@twiss
Copy link
Collaborator Author

twiss commented Dec 16, 2014

Hmm, my concern is that designMode does not support all the features of the ODT format. How can we address that issue?

Do you have specific examples?

As an aside, I wonder if web components will be useful for developing editors. E.g. instead of converting an XML file to HTML to use designMode, we could just use the existing tags as custom elements.

WebODF does that, sort of: they keep the odt tags as they are, and implement editing themselves on top of that.

@ferndot
Copy link
Member

ferndot commented Dec 17, 2014

Do you have specific examples?

Pagination and annotations are two major features. designMode also does not support headers, footers, and page numbering, and the resizing handles are unwieldy. Do you think that we could implement those features on top of designMode?

@twiss
Copy link
Collaborator Author

twiss commented Dec 17, 2014

Pagination

is hard. It is possible with CSS Regions, but that's deprecated and only supported in Safari.

and annotations

the tricky thing with annotations and footnotes is that they are a paragraph inside a span, which is not allowed in html. That's one advantage of WebODF's approach. Other than that, and figuring out how to correctly position them, I don't see fundamental problems.

are two major features. designMode also does not support headers, footers, and page numbering,

Haven't looked into this much. There seems to be some kind of support for displaying an element on every printed page, don't know if all browsers support this though.

and the resizing handles are unwieldy.

Worse, Chrome doesn't have any resize handles at all. Yeah, if you wanted, you could probably create something in js.

@ferndot
Copy link
Member

ferndot commented Dec 27, 2014

Once we merge this, I'd like to make a new release of Firetext. Does that sound good?

@twiss
Copy link
Collaborator Author

twiss commented Dec 28, 2014

Sounds good. It'll still take a while though, as html->odt is not far along yet. If you want to merge sooner rather than later, the easiest way to do that would be to disable (html) paste (and, for even sooner, the toolbar).

@ferndot
Copy link
Member

ferndot commented Dec 28, 2014

Hmm, maybe we could implement a readonly mode and then activate it for ODT right now.

@twiss
Copy link
Collaborator Author

twiss commented Dec 28, 2014

Hmm, maybe we could implement a readonly mode and then activate it for ODT right now.

Yep, also possible.

One idea that I had: do you think that we should split the ODT parser into its own repository, and include it as a git submodule? I feel that it would be very useful to other app developers.

Done: https://github.com/twiss/odt2html2odt.

@twiss twiss force-pushed the odt branch 4 times, most recently from b0b8de1 to 99dc95f Compare January 9, 2015 03:12
@twiss
Copy link
Collaborator Author

twiss commented Jan 9, 2015

What I do now is immediately undoing every change that we don't support. Is that ok with you? It's not very friendly, but it seems to work. Also,

ODT files are not shown in the file browser

Fixed.

@ferndot
Copy link
Member

ferndot commented Jan 10, 2015

What I do now is immediately undoing every change that we don't support. Is that ok with you? It's not very friendly, but it seems to work.

Hmm, could we alert the user about it and hide the toolbar item?

@twiss
Copy link
Collaborator Author

twiss commented Jan 10, 2015

You mean in addition to undoing? We could put an error message somewhere
(maybe overlay over the document?), that wouldn't make it much less
annoying though.
Currently we hide the entire toolbar, since we don't support most of the
things in there (only maybe tables and ordered lists).
Op 10 jan. 2015 04:47 schreef "Joshua Smith" notifications@github.com:

What I do now is immediately undoing every change that we don't support.
Is that ok with you? It's not very friendly, but it seems to work.

Hmm, could we alert the user about it, and hide the toolbar item?


Reply to this email directly or view it on GitHub
#261 (comment).

@ferndot
Copy link
Member

ferndot commented Jan 10, 2015

Yup, in addition to undoing. Although, if the user cannot make any unsupported changes (the toolbar is hidden), a console.log with the error might be sufficient.

@twiss
Copy link
Collaborator Author

twiss commented Jan 10, 2015

Well, they can, through copy and paste (and drag 'n drop, ctrl-b, and bugs
in odt2html2odt, although those things should also just be fixed in
odt2html2odt).
Op 10 jan. 2015 05:13 schreef "Joshua Smith" notifications@github.com:

If the user cannot make any unsupported changes (the toolbar is hidden),
then maybe a console.log with the error is sufficient.


Reply to this email directly or view it on GitHub
#261 (comment).

@ferndot
Copy link
Member

ferndot commented Feb 10, 2015

Ready to merge?

twiss added a commit that referenced this pull request Feb 10, 2015
@twiss twiss merged commit ec6ff29 into codexa:develop Feb 10, 2015
@twiss twiss deleted the odt branch February 10, 2015 03:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants