Priorities for Fidus Writer 3.4

This site is best viewed in a modern browser with JavaScript enabled.

johanneswilm

Fidus Writer 3.3 looks fairly stable now. So we are starting to look toward Fidus Writer 3.4. What kinds of things should we prioritize? And would people prefer smaller releases or larger releases farther apart? There are some internal things that we need to do in the next version, but what else would you like to see? For example how about some of these:

Tracked changes
Ability to tag names and other items in the editor (auto-tagging + configurability by user)
Export to XML-formats like TEI-XML or JATS
Export to HTML formats such as Scholarly HTML, HTMLBook or RASH
Integration with X, Y or Z?

retorquere

johanneswilm track changes would be nice, although most I'd personally need is diff-between-versions. Versioning would be huge for me. But versioning could be implemented with a git backend, and I'd be happy.

The main thing holding me back, and I fully realize this is probably me being an outlier, is image/theorem numbering, and acronym handling/glossaries. If people ask me I haven't yet joined the wonderful world of Word, this is the one point where they'll usually concede. Not many people may need this perhaps, but if you do need it, any product that can't do it goes from wonderful to useless, never stopping by tolerable in between.

juca

Tracking changes sounds awesome.
I'd suggest better documentation on how to create own templates. And generally providing a better template handling.
Also better integration with LaTeX, (including the option of creating own templates)

johanneswilm

Track changes seems to be high priority. We used to have it, but decided to remove it until we achieved stability. In the meantime we exchanged a lot of the foundation of Fidus Writer, so we have to program a lot of that again, but the design for the user interface elements is there.

juca So far most users have just used the provided ODT/DOCX templates, but it should not be that difficult to add some error tolerance for user created templates as well as documentation.

Latex templating is more difficult as Latex files don't separate formatting from content in the same way. And for feature, such as bibliographies or tables, there are several competing packages that each work slightly different and that cannot always be used in all combinations. Basically, we just chose one relatively up-to-date package for each of these that seem to work together in most situations, added some glue to have those packages work together, and then sue that mix for all output. Should the user want to choose another package, for example to handle tables, this may also influence all other packages used for other features as well as the glue code.

So for Latex I cannot see how we could make a simple templating engine. But what we could do would be to put the latex exporter in its own plugin and then let people with programming skills fork it and create their own versions that use other package combinations. @juca would that be of interest to you?

breugelmans

Thanks for setting up this forum!
I also think that the ability to track changes would add tremendous value.

Raoul Breugelmans

luis

TRACKING changes can be a GREAT FEATURE to write collaborative, as well as when doing a final proofreading. In this respect, with my English proofreader he has a COLOR code wich I found very useful (i.e. Red means need to change, blue means would be nice to change and grey is not clear). I am not suggesting to implement a color code at the beginning, but you might want to have it in mind for the FUTURE.

johanneswilm

@luis The spelling and grammar checker plugin for languagetool we added in 3.3 uses color codes more or less how you describe. Are you proposing that we change it?

luis

johanneswilm I like the spelling and grammaer checker and the color underlining it uses.

About tracking changes, I belive the first priority can be to implement it as you planned or even as you already used in the pas (I think you said that) and to have in mind the possibility to use at some point (if not included in the first release) some kind of color code as I explained.

johanneswilm

Ah right. Yes, that is something I had not thought about -- track changes with priorities. Currently we have two levels of priorities for comments, but for track changes we won't have that. I think in the beginning it will just be something fairly similar to what word processors have where the color of the text gives a hint about who made the change. It's fairly complex, but thanks to a new library in the text editing engine, prosemirror, we use, I think it should be possible now.

How about preferences for tracking changes? I can basically see two models right now:

Any user with write access to the document can turn track changes on or off. When on, the changes of everyone are tracked. When off, the changes of noone are tracked.
We create a new permission called something like "write with tracked changes". It is a permission one can have to a document that is somewhere between write, read, or "comment only". Anyone with that permission will have their changes tracked, those with normal write-access will not have them tracked.

I am not 100% certain both of them will work, but if they do, which one would be better to have, @luis @juca @breugelmans?

luis

johanneswilm

Option 1: More flexible, but requires a bit more discipline for the user
Option 2: Would be better for less experienced or for one user who is only meant to revise. This open doors for language proof reader or even in the future peer reviewer.
Ideally both would be good, but it have to choose only one, I would chose option 1.

christof77

+1 for the "track changes" feature. I like model 2 better, except that people with write access should also be allowed to switch on track changes on if they want.
Also, I would very much love to see XML-TEI and/or JATS export! This would enable Fidus Writer to become integrated into publishing workflows for journals or conference submission systems.

wvonhagen

Track changes would be great! Also, export to DocBook XML, which is a "standard standard" and much more usable than DITA. Let the flame wars begin...

jobdiogenes

tracking changes
JATS
template interface (import, remove, export) so we can create new, or just change someone.
meta data - templates.

johanneswilm

jobdiogenes How would meta data templates look for you?

johanneswilm

We have had versions for a few years. Some students recently made a demo where they showed the differences between two versions. Something like that could probably go into one of the next two versions. Adding git would be a lot more code and also I'm not sure how it would/should show formatting changes.

@retorquere which latex commands are you using for the abbreviations, etc.?

xdej

Export should also add the option "temporarily accept changes while exporting".
The syntax may be based on the output of latexdiff: deleted changes in footnotes (and footnote stuck to the right of previous footnote, if possible), new text in blue.

xdej

I vote for 2.

The changes and the comment requested feature https://forum.fiduswriter.org/d/7-comment-out-text/4 could be shown and handeled the same.