Live data from Hacker News

A Scholarly Markdown

scholarlymarkdown.com

91–97 of 97 posts

Re: A Scholarly Markdown

#91
post #89

Earlier quoted context omitted.

I really want to address the math support, because I work with a lot of mathematicians, and one of my main goals is to support most of the latex AMS math features we're used to (as much as MathJax can support outputting on the HTML side anyways), and of course that includes aligned equations. In fact one of the first things I did was to figure out how to support multiline equations. Turns out, you just need to write…

I still think equation numbers on the left is a mistake. Ideally, for smaller screens it would split across multiple lines. Or, it could choose the positioning based on screen size. For me, MathJax can't render my equations. I use some techniques to get a vector with an arrow on the bottom. Two commands I used all throughout my thesis are: \def \rV#1{\hbox{$#1$\kern-0.38em\lower0.85em\hbox{$\vec{}\,$}}\,} and \def \V…

> Ideally, for smaller screens it would split across multiple lines.

C'mon, nobody deserves to be subject to automatic TeX expression breaking. Even careful hand-tuning with help from the breqn package can often look pretty bad.

> Two commands I used all throughout my thesis are:

At the risk of turning this into TeX StackExchange, I just want to point out that these kerning manipulations are entirely possible in MathJax. The problem is that, maddeningly, they chose to have non-math commands like kern and lower work exclusively in math mode, and not outside one like in a hbox. Therefore, if you change your second command to something like this:

  $a \kern-1em\lower0.4em\hbox{$\scriptstyle \rightarrow$}$
then it will work in MathJax. Of course, this would then break in regular TeX because you're not supposed to use kern and lower in math mode. I keep myself sober by remaining optimistic about a potential overhaul in the MathJax latex processing code.

In the meantime, I think we would benefit from a stopgap service that renders these things in an actual TeX engine running on a server into high-res PNG (easy) or SVG (doubtful). There's been quite a resurgence in effort to make latex rendering into a scaleable web service lately. I'd love to collaborate with someone from, say, ShareLaTeX on that, if possible.

Re: A Scholarly Markdown

#92
post #88

Earlier quoted context omitted.

As a thought exercise, assuming for simplicity that you can isolate the parts you're authoring, so that your changes only involve additions to other people's work: what kind of additional metainfo would you need for this workflow? All defined labels and macros? Available bib entries? What else?

I think it depends on how I'm viewing the file. If I'm just editing in SM and building the tex as usual, then I don't need anything extra. If I'm trying to convert to all sorts of other documents (which I haven't ever really done) then labels, theorem environments, one-line macros, and bib entries cover almost every tex-specific thing I use. Here is an excerpt from a typical paper's macro section [1]. As you can see…

I think a good way to build this into SM is to run an existing document thorough latex and looking at the aux file. This approach would be faster and almost certainly more robust, similar to how most latex build scripts look at the fls recorder file for the list of external includes.

The only only thing you can't get will be the user-defined macros (and of course bib entries that doesn't already exist), but there is already a consistent mechanism to define your own macros in SM via the "math_def" block. They "do the right thing" in the sense that if you render to latex snippets then it wouldn't redundantly include these macros in the output.

Re: A Scholarly Markdown

#93
post #82

Earlier quoted context omitted.

Well, I did not realize Github has had AsciiDoctor integration for two years now (I've been doing most of my scientific work in GitLab during that time). I retract that comment and regret the error. Hopefully they add it to Github pages some time soon. To be honest, there was never really any conscious decision to pick Markdown over AsciiDoc. It was just serendipity that when I was looking to convert a bunch of my ex…

Just wanted to mention that GitLab supports asciidoc https://github.com/gitlabhq/gitlabhq/pull/7569

Thanks for the heads-up. I'm going to bug our admin again to upgrade.

Re: A Scholarly Markdown

#95
post #89

Earlier quoted context omitted.

I still think equation numbers on the left is a mistake. Ideally, for smaller screens it would split across multiple lines. Or, it could choose the positioning based on screen size. For me, MathJax can't render my equations. I use some techniques to get a vector with an arrow on the bottom. Two commands I used all throughout my thesis are: \def \rV#1{\hbox{$#1$\kern-0.38em\lower0.85em\hbox{$\vec{}\,$}}\,} and \def \V…

> Ideally, for smaller screens it would split across multiple lines. C'mon, nobody deserves to be subject to automatic TeX expression breaking. Even careful hand-tuning with help from the breqn package can often look pretty bad. > Two commands I used all throughout my thesis are: At the risk of turning this into TeX StackExchange, I just want to point out that these kerning manipulations are entirely possible in Math…

That's awfully annoying of MathJax because you need two separate versions of the LaTeX, one for MathJax and another for LaTeX output.

I know that there's dvisvgm for SVG output from DVI. I think there's also a tex2svg. Also, there's LatexRender-ng. So, there's a number of tools for SVG output.

Re: A Scholarly Markdown

#96
post #19

Earlier quoted context omitted.

Thank you for the information. This raises a couple more questions for me. First, when searching I was able to find Martin Fenner's very interesting blog posts about ideas for a "Scholarly Markdown" and, as those issues and the first link on the scholarlymarkdown.com site reference, he appears to be associated with a separate "scholmd" project, also called "Scholarly Markdown," which is apparently a related project t…

Note: I'm the maintainer of this project The series of blog posts by Martin (and his efforts with John in getting citations to work in Pandoc) was the impetus of this project. I've reached out to Martin several months ago for comments, but I've not heard from him since. I guess he's very busy with his day job at PLOS. If he's willing, I'd very much like to reconcile this project with his efforts. The goal is, after a…

Scholarly Markdown is very much a group of like-minded people, and we had a workshop with lots of good discussions in June 2013 (http://blog.martinfenner.org/2013/06/17/what-is-scholarly-ma...). What it has not been until the recent effort by timtylin is a specific set of tools, or spec.

Everyone seems to have an opinion on how to do this right, and that is part of the reason why the whole concept is pretty fragmented. Some of my thoughts:

Pandoc is the markdown converter that comes closest to what most people need, so I am happy to stick with it. I personally don't think that a fork is viable, things are already hard enough as it is.

Scholarly markdown is a solution for 80% of use cases, people writing math-heavy texts are probably better of sticking with Latex.

Scholarly markdown needs to be a community effort, I don't see any other way on how this can succeed

Re: A Scholarly Markdown

#97
post #96

Earlier quoted context omitted.

Note: I'm the maintainer of this project The series of blog posts by Martin (and his efforts with John in getting citations to work in Pandoc) was the impetus of this project. I've reached out to Martin several months ago for comments, but I've not heard from him since. I guess he's very busy with his day job at PLOS. If he's willing, I'd very much like to reconcile this project with his efforts. The goal is, after a…

Scholarly Markdown is very much a group of like-minded people, and we had a workshop with lots of good discussions in June 2013 ( http://blog.martinfenner.org/2013/06/17/what-is-scholarly-ma... ). What it has not been until the recent effort by timtylin is a specific set of tools, or spec. Everyone seems to have an opinion on how to do this right, and that is part of the reason why the whole concept is pretty fragmen…

Hi Martin! Thanks for dropping by.

> I personally don't think that a fork is viable, things are already hard enough as it is.

I don't think so either. Scholdoc as a fork was always intended to be a stop-gap measure to quickly test out ideas. Pandoc's use of relatively standard Parsec is easier to hack, and lots of other subsystems like citeproc remain crucial. Scholdoc changes Pandoc's AST, so any discussion of re-integration is going to be a non-starter until at least 2.0

For this kind of workflow to be viable, 95% of the required effort is not going to be on the syntax/converter anyways. The real hard work is still ahead.

> Scholarly markdown is a solution for 80% of use cases, people writing math-heavy texts are probably better of sticking with Latex.

I agree, except I also think that there can be a 80% situation for math. I work with a lot of applied mathematicians/electrical engineers, and the math system in Scholdoc is designed with them in mind.

I really think that the ultimate goal is to arrive at many good ways (of which this may be one) to produce semantically-relavant open interchange format such as JATS. I assume this is what PLOS is trying to achieve as well? I do know that several people at PLOS is vehemently opposed to Markdown and what it stands for.

> Scholarly markdown needs to be a community effort, I don't see any other way on how this can succeed

Definitely. The best we can hope for is to occasionally stir this pot once in a while and hopefully something will spontaneously nucleate once the time is right.

Post reply on HN