reverse?

[johanneswilm]

Hey,
any ideas of going the other way? Is this something you guys have been looking at? Is it something you would think should work if someone sat down to take the time to write it?

[darobin]

Hi @johanneswilm!

I'll admit that we have not given much thought to the reverse because we haven't needed it. It's not something that we plan to develop in the foreseeable future.

I see no reason that it could not be done however. There may be some constructs that don't map, but it shouldn't be that many and they are unlikely to be very important. It's possible that le-tex or pandoc may have support for that actually. It would be quite tedious work however!

[darobin]

I was reading about how you're using XSLT to do that reverse conversion — maybe that's what you should start with? I haven't seen the style sheet in question, but if it's straightforward enough you could use the same method used in this repo to eliminate the need for an XSLT processor (assuming that's what you are thinking of). The Marcheur library that this is built upon does not have great documentation (to say the least) but the core principles are pretty simple — I'm happy to help if that's something you're investigating.

[johanneswilm]

I was reading about how you're using XSLT to do that reverse conversion — maybe that's what you should start with?

Yes, that is what we are using right now in our somewhat experimental setup. My issues with that are:

A) It's not very clear what license the XSL file is under. My udnerstanding is that Microsoft distributes such a file with Word without saying anything about the license, and I'm not sure whether the various versions floating around github repositories are derivatives of versions that originally shipped with Word. I have contacted the Microsoft Word team about this, and the response has been that they are looking into the possiblity of releasing it under some OSS license. In the meantime, rewriting it as a JS library should be les sproblematic, even if the original Microsoft XSL file was consulted in the process>

B) We had a student write his master thesis about Fidus Writer and possibilities of conversion, and he said that he found lots of issues with the version of the files that were floating around github and only the ones shipped with the latest version of Word were good enough.

C) Your comments here on being tired of running into XSLT issues.

As for B and C, I guess we'll find out how problematic these issues are once we launch our next version if we end up using the browser's XSLT processor and we start getting real user data.

So I guess we will do some testing with the XSLT processor for now, and if we don't run into too many issue, we may postpone the creation of a dedicated JS library, and then reconsider the issue post-launch based on real-world data or once the legal situation becomes clearer.

[darobin]

Those are similar to the motivations that led me to create this package. The Microsoft conversion XSLT was consulted but this is not a slavish port; notably I identified some issues even with the one in the latest Word and addressed those. Running XSLT in Node has proven extremely painful, and it is continuously threatened in the browser (though Saxon's recent compile-to-JS option may be useful).

Anyway, if you build a library let me know — it would be fun to see if we can do roundtrip tests!

[johanneswilm]

I'll let you know and in case we do and if possibly build on top of your Marcheur.