Improved conversion from LaTeX to HTML/Unicode

[oscargus]

Now the huge list of conversion symbols is used when converting from LaTeX to HTML and Unicode. I also added a field right-click menu item to convert from LaTeX to Unicode. This sort of works except that it doesn't handle text within $$ in a good way (remove the $$ and the symbol conversion works).

The huge diff is caused by reformatting the huge list, as the newly added entries was aligned differently compared to earlier on saving...

[tobiasdiez]

Why does a HTMLChars() formatter format latex to unicode and not to HTML?
Is there something wrong with the implementation or is the naming just suboptimal?

[oscargus]

Historical reasons. Earlier the huge conversion list resided in that file, so adding a method "formatUnicode" was simple. Indeed there should (very soon) be a UnicodeToLatexConverter extracted... Doing this is steps...

[oscargus]

Ah, sorry, wrong answer. :-) The answer above holds for HTMLConverter...

I think HTMLChars format to HTML? Now, since there are named entities these are used, if not, the numerical are used.

[tobiasdiez]

Ah my mistake! Sorry....

[oscargus]

I fixed the equation issue and added support for some more LaTeX text styles. For example, \textsuperscript and \textsubscript are supported for both HTML and OO.

This also means that the preview looks quite a bit better now.

[simonharrer]

Please fix the failing tests. Then this can be merged in as well.

[simonharrer]

Converters could be added to the Save Actions under the Formatter Interface as well.

[oscargus]

Yeah, I just noted that they failed. :-) That's what you get trying to distinguish italic and emphasise... I'll correct it later and merge. Thanks!

[oscargus]

Indeed. I'll also extract the Unicode formatter from HTMLConverter now that they are not tightly connected anymore.

[simonharrer]

Ok, please add the label ready-for-review again when you are done with the other changes.

[oscargus]

It turned out that it also made sense to move the layout formatters from export.layout to logic.layout, so the final(?) commit is handling that. Some minor refactoring had to be done, but nothing controversial.

[oscargus]

I'm giving up on this PR for now... Doesn't really make sense to add a JournalAbbreviationRepository argument to PdfImporter or MoveFileAction, although that is required if it is propagated (and now I've only gone two steps back...). Will be back after a week or so of holidays (true story, nothing to do with this)...

Accessing a global variable is a single formatter or passing an argument to hundreds of non-related classes to possibly be used in a single formatter? I'm not convinced it is worth it...

[simonharrer]

The idea is that the GUI part can have globals, whereas the logic does not. With this in mind, the PdfImporter or MoveFileAction do not need to have this class, but can merely pass in the global variable if necessary. Does this make sense?

[oscargus]

It makes sense from the perspective that I understand where to start/stop. :-)

[simonharrer]

👍 LGTM (but can you remove the unused imports, please?)

[oscargus]

All(?) imports are now removed and I managed to sort out the PdfCleanup thing as well.

Feel free to merge. :-)

[tobiasdiez]

Sorry for being such a pain in the ass with this abbreviation thing...but one last remark: did you tried out the Pdf rename cleanup as a user? I think the dialog always passes a null repository to the cleanup worker which in the end would result in a NPE. Not sure through...