For all the scientific writing I do (ie, 99% of my output that isn't blather on the internet), i use LaTeX or markdown.
LaTeX primarily for peer-reviewed work, markdown for notes, informal documentation, and whitepapers. In both cases, i can use a powerful text editor (sublime or atom or emacs) with very rich and highly developed cross-platform support.
What are some compelling reasons to use this tool instead?
The scientific publishing workflow is insane, and this tool seems like it could help.
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.
It's a tool for everyone in the writing-editing-publishing pipeline. They could all use the same tool, working on the same document & document format, throughout the process.
This will remove a huge amount of reformatting/conversion work between steps in the pipeline.
The rebuttal, guaranteed to come from anyone with tenure but also from distinctly untenured folks like myself is this: "I have all my manuscripts and biosketches and workflow in LaTex/Word. All my references are in mendeley/zotero/endnote/bibtex files i've hand-massaged. Until such time as my home journal requires me to use this format i've never heard about, and gives me the tools to convert everything I've built over the last 2-20 years, I am not interested in it unless you've got something more compelling than what you've shown me so far."
Of course - that's the most obvious thing in the world. Getting traction against an entrenched workflow component - a people problem - is, almost universally, very very hard. The technical problem - writing your new tool - is trivial by comparison.
But they do seem to be coming at this from the journal/pull end of the workflow, which is a very good place to start.
And yet if you try and submit to publishers in JATS, editors tell you they have no idea what it is, and can you please send a Word document like everyone else...
Seems like a very domain specific thing. I've never heard of it in my discipline, and every article I've gone to upload supports a direct LaTeX upload.
It is domain-specific, but the domain is rather large. In the vast majority of life science fields, LaTeX is not accepted for journal articles, even in fields where you might expect it. In medical informatics, for example, direct LaTeX upload is uncommon, which you might not expect for an informatics journal.
In some senses, I share your distaste for Word. But, honestly, after having written my dissertation in LaTeX, I must say that it was a terrible experience.
I really wanted to love LaTeX. In the worst possible way. I wanted to sneer at people who used Word, looking down my nose and show them how reproducible research was really done. How much more efficient and beautiful my work would be using this software. I wanted to venerate Knuth and this beautiful example of open source software.
It took me years before I had to admit to myself how terrible it was. I remember seeing a post on HN about how LaTeX was a cargo cult for philosophy majors (the analogy being that they were using the tools of a technical discipline without a clear purpose). For me at least, a better analogy would be an abusive relationship. I would tell my labmates about how great it was, while it was obvious that I was spending hours on getting the most trivial configuration correct.
I am truly glad that some people have a good experience with LaTeX. I just wanted to say that I didn't.
LaTeX is actually pretty terrible from a usability standpoint. It has some nice ideas, but it is ripe for a refresh or replacement. I'd rather write anything involving math with it than fight with Office's equation editor, which -- in my experience -- does seemingly arbitrary things.
For starters, the compilation output is impossible to parse if you have an error. The process is also needlessly arcane. You can normally get away with using the `pdflatex' compiler, but there's some (not uncommon) features it doesn't support. I don't see how you can use the thing without a good IDE, but the only one I've enjoyed working with is a non-free OSX one. The list of complaints in this style goes on.
LaTeX does have some good ideas. It attempts to separate style / layout from a semantic description of the text in a similar manner to HTML and CSS, although this very under utilized. I've found a couple packages that use this concept for stuff like algorithm syntax, but most people end up using the default document structure or the 1/2 very common ones for their field (IEEE or ACM for me). It is way more convenient to write equations in it than using Office's editor. Finally, the rendering algorithms are normally quite good at laying out your text (an exception being if you write a long equation and pick the wrong environment for the job, but that goes back the the thing about redundant modes).
We're solving a lot of these problems with Overleaf[1] by providing a cloud-based collaborative editor with a simpler UI for those new LaTeX, whilst keeping the power of LaTeX for those that need it.
We're also working with publishers to ease the submissive process to journals and repos[2], and include things like git-sync for offline working[3].
Great to see lots of different approaches to solving these problems though, and Texture is certainly an interesting idea.
> It is way more convenient to write equations in it than using Office's editor.
Really? Unless in the middle of the document you decide to make some change in notation...
But overall, I agree with you. I think the problem is LaTeX has a really steep learning curve. To understand what is going you have to read at the very least a couple of thick books, which is definitely too much too ask to somebody who's only using LaTeX for a one-off job.
I've been using LaTeX for about 15 years, and my biggest problem is still the error messages. At least once a year I just end up deleting a maths equation entirely, and then writing it out again in tiny fragments, to figure out where the error is.
Some concrete small problems:
* Why can't I just write _, < and > in plain text mode? Why does an _ complain I'm not in maths mode?
* It's very hard to cut+paste code samples in for this reason. You can use verbatim, but then that often doesn't nest correctly inside various types of things.
I feel you. See my other comment. I've developed a good workflow with it, but it was only after using it for multiple years and developing a number of work arounds.
When I downloaded and unzipped this, I got a folder with what looked like a web site. I figured I would need to run it under a web server, but double-clicked the ‘index.html’ file anyways.
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.
by rich and highly developed, i mean things like "having a package manager that hooks me into mendeley, zotero, and github, has an integrated linter, supports build and live-preview, and lets me run custom macros with whatever keybindings i prefer". "runs everywhere because it's in javascript" doesn't necessarily get me any of that-- the editing functionalities in this tool seem rudimentary so far.
For the hooks and key bindings: it is an alpha release of the initial version. Those things may come, and will come if it becomes successful and users want it. Certainly, it has to provide a way to really store documents. The cloud then is a natural choice for this kind of tool.
Also, I think this doesn't need a linter, as the UI limits you to creating valid documents, and it has live preview because it is wysiwig (it isn't TeX and doesn't aim to be)
I would guess (but it is not my project) macros are unlikely to come soon, if at all.
As a side note, if you are already in emacs, you could write your articles in org-mode instead of LaTex.
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.
>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).
Re your last para I think "expect" is the better choice. "If you use our stuff to do your day job then we expect you to help with our finances" - they're not forcing you to but they are applying social pressure.
"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.
Not sure if I'm expecting too much, but the html in the editor is quite terrible – <span>s used for everything, including headlines, <br> to separate paragraphs etc. HTML5 has dramatically increased the potential for semantic html and I wish more people would make use of it.
If I understand correctly, the HTML is not actually published. So there are no benefits to having a better semantic structure to it - think of it as a rendering target for the sole purpose of making it look nice on the screen.
This is apparently powered by Substance, a JS library that implements a WYSIWYG editor, and which looks interesting.
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.)
Latex itself is still progressing, they've incorporated lua into Tex so that they can add new features. There are also alternatives to Latex such as ConText although I've never heard of anyone actually using it. But in general it's hard to know what's really going on without doing a lot of research.
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.
Thank you very much for your comments! A few notes from the authors:
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:
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.
40 comments
[ 1.3 ms ] story [ 86.6 ms ] threadWhat 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.
This will remove a huge amount of reformatting/conversion work between steps in the pipeline.
getting traction is going to be _very hard_.
But they do seem to be coming at this from the journal/pull end of the workflow, which is a very good place to start.
I really wanted to love LaTeX. In the worst possible way. I wanted to sneer at people who used Word, looking down my nose and show them how reproducible research was really done. How much more efficient and beautiful my work would be using this software. I wanted to venerate Knuth and this beautiful example of open source software.
It took me years before I had to admit to myself how terrible it was. I remember seeing a post on HN about how LaTeX was a cargo cult for philosophy majors (the analogy being that they were using the tools of a technical discipline without a clear purpose). For me at least, a better analogy would be an abusive relationship. I would tell my labmates about how great it was, while it was obvious that I was spending hours on getting the most trivial configuration correct.
I am truly glad that some people have a good experience with LaTeX. I just wanted to say that I didn't.
For starters, the compilation output is impossible to parse if you have an error. The process is also needlessly arcane. You can normally get away with using the `pdflatex' compiler, but there's some (not uncommon) features it doesn't support. I don't see how you can use the thing without a good IDE, but the only one I've enjoyed working with is a non-free OSX one. The list of complaints in this style goes on.
LaTeX does have some good ideas. It attempts to separate style / layout from a semantic description of the text in a similar manner to HTML and CSS, although this very under utilized. I've found a couple packages that use this concept for stuff like algorithm syntax, but most people end up using the default document structure or the 1/2 very common ones for their field (IEEE or ACM for me). It is way more convenient to write equations in it than using Office's editor. Finally, the rendering algorithms are normally quite good at laying out your text (an exception being if you write a long equation and pick the wrong environment for the job, but that goes back the the thing about redundant modes).
We're also working with publishers to ease the submissive process to journals and repos[2], and include things like git-sync for offline working[3].
Great to see lots of different approaches to solving these problems though, and Texture is certainly an interesting idea.
[1] https://www.overleaf.com
[2] https://www.overleaf.com/publishers#!publisherslist
[3] https://www.overleaf.com/blog/195
Really? Unless in the middle of the document you decide to make some change in notation...
But overall, I agree with you. I think the problem is LaTeX has a really steep learning curve. To understand what is going you have to read at the very least a couple of thick books, which is definitely too much too ask to somebody who's only using LaTeX for a one-off job.
You mean like renaming a variable from c to d? The proper things to do here is define an alias for any variables you use a lot.
Some concrete small problems:
* Why can't I just write _, < and > in plain text mode? Why does an _ complain I'm not in maths mode?
* It's very hard to cut+paste code samples in for this reason. You can use verbatim, but then that often doesn't nest correctly inside various types of things.
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.
Also, I think this doesn't need a linter, as the UI limits you to creating valid documents, and it has live preview because it is wysiwig (it isn't TeX and doesn't aim to be)
I would guess (but it is not my project) macros are unlikely to come soon, if at all.
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.
>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 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.)
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...