Determine if this even interesting

[rreusser]

@Planeshifter, pinging you (though obv an open call for feedback on how to do this better) due to previous interest in avoiding explicit gulp dependencies for this. I rolled this up so you can basically just run $ npm install mdtex-cli and $ mdtex README.mdtex and it should do the rest.

The actual mechanics of the conversion are highly suspect, but ideally that'd be a matter of configuration and refinement. As-is, this could be extended to use an svg strategy or even to plugin into that webserver I can't remember the name of at the moment.

It's a little loose at the moment, but pretty much does what I need. Just a thought.

[kgryte]

What about instead of an *.mdtex file, one could just use empty links to embed comments within a normal Markdown file. For example,

[](\[\alpha = \beta + \frac{1}{2}\])

A command-line tool similar to what you have created could then, based on the LaTeX syntax used, inject the SVG/image accordingly (inline or block).

My main concern is, as with current practices for using ES2015 for small Node modules, the existence of more than 1 source of truth (raw + build files), will lead to drift. A contributor may come on board, inadvertently update the build Markdown file without updating the *.mdtex file, which later causes a bug when the same or someone else comes and updates the *.mdtex file overwriting the previous changes.

If we could have one source of truth, I could see this being more interesting. For our stuff, we use HTML elements and also include equation labels. I wonder if the inline links could contain a mini-markup language to handle this use case.

[rreusser]

That's a great suggestion. I'm thinking about quickly unpublishing and archiving this approach. Yeah the source of truth issue is a big problem.

I like the idea of an in-place transformation. Maybe just write an empty link and it gets replaced with a link containing the image. I just hadn't figured out how to make it idempotent and still trivially editable, but I guess if it preserves the latex in an alt tag, it could even relocate and reparse equations. I really like mdast for this type of thing, especially if there are references involved.

Is your current solution fully manual? If you can point to a list of features, I'd be glad to give a shot. Unfortunately, the rawgit step is still required for SVG and can't really be simplified. In fact, if that persists, then almost best just to still do it by hand.

Oh, and finally, I'd previously made a quick module for specifying inline config: https://github.com/rreusser/square-parameters It's simple and uninteresting, but worked fine for a similar thing: a markup sorta-language for compact inline metadata.

Thanks for the though! In-place could work.

[Planeshifter]

Dear Ricky, up until now, we did indeed everything manually. So moving it to an automated process would be a great benefit, and we are not tied to SVG either: If I recall correctly, we tried *.jpg images at the beginning, but encountered display problems on npm. Your modules with equations look all very nice on there, so we could reconsider. Obviously, SVG has the advantage of allowing the equations to be displayed in many different sized without sacrificing image quality, but I don't think this is necessary. Here is an example equation from one of the compute modules:

<div class="equation" align="center" data-raw-text="f(n)=\ln (n!)" data-equation="eq:factorialln_equation">
    <img src="https://cdn.rawgit.com/compute-io/factorialln/08d90469eae895608c4e2a3f14265dafb1c20083/docs/img/eqn.svg" alt="Equation of the natural logarithm of the factorial.">
    <br>
</div>

The enclosing tag of the image contains both an equation label (in form of the data-equation attribute), which we wanted to have so that equations could be referenced and the original LaTeX code in the data-raw-text attribute. We also use the alt tag to hold a text alternative for the image element.

[kgryte]

No need to unpublish and archive. The current approach is valid and, for others, may be useful/preferred.

Re: in-place. To clarify, it is probably not necessary to actually replace the empty link; instead, the equations could be injected immediately following (or before).

When rerunning the compilation, could be tricky as any existing equations would need to be removed.

For inline equations, would be nice to specify the output format. For instance, I am not particularly a fan of embedding images of rendered equations/variables within a string of text due to inconsistencies in font-size, etc, between the rendered TeX and surrounding text. So instead of images, maybe the ability to convert to unicode characters. (There is probably a lot involved with this.) The inconsistency between TeX variables and surrounding text was one reason we typically just use inline code; e.g., alpha = beta * 1/2.

[kgryte]

Re: rawgit. It is not doing anything special to the URL. For instance,

# Original URL:
https://github.com/rreusser/mdtex-cli/issues/1

and

# Rawgit:
https://cdn.rawgit.com/rreusser/mdtex-cli/issues/1

Basically, just the hostname is swapped. We also include the commit hash so that things don't accidentally break during development. This process should be capable of being fully automated.

[rreusser]

Ah, you're correct. I was confusing it with camo.github.com or whatever that is that github uses for a proxy that has a giant hash in the name.

Ricky Reusser

On Dec 13, 2015, at 4:46 PM, Athan notifications@github.com wrote:

Re: rawgit. It is not doing anything special to the URL. For instance,

Original URL:

https://github.com/rreusser/mdtex-cli/issues/1 and

Rawgit:

https://cdn.rawgit.com/rreusser/mdtex-cli/issues/1 Basically, just the hostname is swapped. We also include the commit hash so that things don't accidentally break during development. This process should be capable of being fully automated.

— Reply to this email directly or view it on GitHub.