Giving NV Sync Features With Docs

[wessleyn]

I don't know how feasible this is, but it'll definitely remove a lot of redundancy and optimize the writing workflow.

The idea is, just like how we have the export feature from the app. We can also link , at least the novel tab in NV to a single Google docs document.

How would it work?

Stage 1: NV to Docs

There's a button that compiles the novel documents into a single, scrollable document, with docs compatible header, most likely a docx document. That in turn creates a Google docs document and links to that document.

Such that changesade locally can be pushed to the online doc.

Stage 2: Docs to Nv

In turn, if the current project has a link to the Google doc. It can actively or passively look for changes (not suggestions) in the docs document and apply them to the offline NV document.

This is tricky, since the NV has to compare and infere the correct location of the changed text, but this can be done of ots just the novel documents

Stage 3: Rendering Docs Comments inside NV
Maybe this will not be necessary since, one can just comment on docs and apply edits there and then sync em back in NV. But why not, if one can do it all in NV super

Stage 4: Comments edits From NV to Docs

This is assuming that stage 3 has been implemented, but again it's feasible provided the api has proper permissions

[vkbo]

It is stated that the end goal of novelWriter is to produce a manuscript, which is meant to mean a document ready for submission to a publisher, editor, or something along those lines. In my limited experience with publisher editors, they have communicated changes through comments in the manuscript doc. novelWriter is not designed to interpret these comments and take them back into the project. While it may sound simple to do this in principle, it most certainly isn't.

DocX would be a horrible format for this exchange. Mainly because Microsoft created the OOXML standard (aka DocX) and pretty much do whatever the hell they like with it, including not following it, which makes it difficult and high maintenance to support as a format for input (reading). Writing it is fine since you can just follow the basic rules of the format and Word will be able to read it. ODT (Open Document) format would be a better candidate since it is a much stricter standard that is broadly followed.

As for what is and isn't planned for novelWriter, based on your points:

1. Cloud integration, which includes Google Docs, is out of the question. The reason is simply that it opens a whole can of worms in terms of dealing with security that the project does not have the resources for.
2. Reading DocX files, as mentioned, also has a significant maintenance cost that currently isn't possible resource wise.
3. Import features are planned though, but the ideas are pretty basic for the first step. See Add a text import tool #1980.
4. Adding text notes is a planned feature. By text notes, I mean what comes up as yellow sticky notes in LibreOffice and other applications, not the current comment formats. The text notes will consist of a marked region of text that is linked to a %-style comment, similar to how footnotes work.

One feature request that may be relevant is #1394, which proposes a way to quickly generate or update a favourited build format without having to go through the Build tool.

[peter88213]

@wessleyn: Basically, it is possible to use a script to generate an ODT document from the novelWriter project data, edit the document externally (this also works with GoogleDocs), and then save the content back to the novelWriter project. The trick is to insert markers for reimport, for example by using the handles of the novelWriter text files.

I implemented this workflow some time ago with yWriter as a proof of concept, and it worked well. The core is an ODT parser which is also included with my odt2nw Python script. Anyone who wants to can build on that. However, in its current design, it does not support the full range of novelWriter's formatting options.

The question is, however, whether this actually leads to an optimized workflow if you use novelWriter just as an organizer, and do the writing with an external word processor. It is in fact a completely different usage concept. Above all, the metadata integrated into the text would be impractical with a standard word processor.
For this, I have a leaner solution with my own novelibre application, which I use myself. However, I don't use Google Docs. That would also work, although not quite as seamlessly as with an installed LibreOffice.

[vkbo]

I think these kind of features are better handled by additional helper tools, like the ones you've written.

I would be happy to add ways to improve the way project data is imported and exported. It would be great if there were a standardised JSON format for writing projects that could be used as an intermediate between applications. I can certainly design one for novelWriter, since I do plan to add more apps as you know.

As for the current novelWriter project format, every format released is still supported for reading, so backwards compatibility for projects is retained. I also plan to work on more import options for text, including rich text. Qt can parse both ODT and HTML, so perhaps exploiting the internal readers for those formats would be an option. Any such import would be a single document import though, but keeping multiple draft versions of a novel in novelWriter is not a problem. I know people do that, and I've created functionality to support it, so a single document import with the option to split it should get you pretty far.