What are some compelling reasons to use this tool instead?
In the biomedical sciences (or any field that ends up on PubMed), articles have to be converted to JATS XML (http://jats.nlm.nih.gov/), a standard XML dialect for journal articles. It builds in citation metadata, cross-referencing, figure references, etc., and is supposed to be a stable archival format for long-term storage of articles. Individual publishers (PLOS, BMC, etc.) build their entire publication workflows around JATS, so articles can be typeset into PDF or rendered to HTML, or delivered to e-reader apps or whatever. Since it's semantic XML, you can do bibliography mining, automatic reference following, extraction of figures, or whatever you might want to make reading or text-mining easier.
But articles are often written in Word, so there's a tremendous amount of work going into manually or semi-manually converting every manuscript to semantic XML from the Word soup it arrives as. Same goes for LaTeX: a few journals just publish LaTeXed PDFs directly, but big publishers like Elsevier and Springer have semi-automated processes for converting LaTeX to in-house formats so they can provide HTML versions of pages.
So, short version: an editor supporting JATS XML can support all the features you need in a scientific document, and can dramatically simplify the publication workflow and hopefully save a bunch of money. And hopefully open-access journals pass that savings on to users.
For users, it could mean better e-reading apps (so you don't have to zoom in on tiny fonts in a PDF on your iPad), better support for cross-referencing and figures than Word has, automated formatting (journals style the XML, so you don't have to do margin and layout crap), and a simpler submission process.
This seems like a tool for journal staff and editors, then, rather than practicing scientists.
It's gotten to a point where I am starting to see Latex exclusively as a language to compile to, not something you want to write yourself.
If you haven't used a well-configured org-mode, have a look at this demo for example https://www.youtube.com/watch?v=2t925KRBbFc. There's nothing out there (open source or proprietary) that comes close for scientific work in my opinion.
That opened a simple page with 3 links to example files, and clicking either opened a working document editor, where ‘working’ seems to include the saving of changes (somewhere in browser history; edits survive closing the web page, but get lost on clearing history). (Tested on Safari, Chrome, and FireFox on Mac OS X Sierra)
I guess that means this aims to be a powerful document editor with rich and highly developed cross-platform support.
It’s not as flexible as LaTeX or markdown, but that is on purpose.
>Texture is open source, and you are legally free to use it commercially. If you are using Texture to make profit, we expect that you help fund its development and maintenance.
My first read through, I thought it was making a free as in beer/speech distinction for commercial use, but looking at the actual license on github, that doesn't appear to be the case. I think the second sentence is perhaps more often worded as 'ask' or 'hope' vs. 'expect' which I initially took as more of a contractual expectation (i.e. a requirement).
"Expect" isn't a contract-like term IMO as it's too vague. If you were demanding it then they'd offer a difference license; this is not [as it's written] instantiating a contractual obligation, it's calling on the users moral nature.
I wonder why they don't use a variant of the BSD/MIT or GPL?
I also once read about another alternative to Latex called Lout but it never seemed to go anywhere.
I just use Lyx now to write my articles. I've actually pretty much forgotten the Latex that I used to know.
Texture's first goal is its use at publishers, during their review and QC processes. Word or InDesign submissions are converted to JATS using the converter from Open Journal Systems (OJS) and from then on are treated with Texture until publication.
Once journals have adopted JATS in their editing workflow, I'm sure they are willing to switch allowing submissions in JATS. Then authors have an incentive to write their papers in Texture from the beginning.
Texture is hackable and can be extended via packages implemented in JS (think Github Atom editor). Each JATS node type is implemented as a package already, with still many of them missing (math, figgroups, ...). A package implementation looks like this:
https://github.com/substance/texture/tree/develop/lib/taggin...
We understand that publishers have different needs and allow them to configure and customize the editor to any degree. We also want to open up the editor to community contributions, e.g. one could implement an R-backed visualization content type (see https://stenci.la/), that could live right in the editor. This would require introducing custom tags in the JATS serialization format, which we think is valid, if you are aware of the implications.
Texture is at an Alpha state, but a number of organisations committed to funding it's development, so we should see stable versions in the coming months. You are invited to join the Substance Consortium, which drives the development of Texture.
http://substance.io/consortium/
See the current product brief, until we have published a public roadmap.
https://docs.google.com/document/d/1v01mfeJw0IHgN7EIKE6JtEkE...
I wonder how it stacks up against the other leading JS-based editors such as ProseMirror, Quill and Draft, which are all quite solid at this point.
(Unfortunately, some rudimentary testing shows that Texture is buggy to the point of being unusable — a lot buggier than I expect for a beta. For example, ctrl-Z to undo doesn't work in Safari and works awkwardly in Chrome; pasting doesn't preserve any formatting or semantic attributes; I can't seem to be able to modify (or even insert) any images; and it's pretty much completely non-functional on iOS.)
