-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
README.tex via latexml ? #898
Comments
I am working on a deconstruction of TeX as a side project so maybe I might yield something that can be used within markdown as an alternative that might will hopefully able to be deemed secure to be used as an online service which was the main stumbling block for getting TeX adopted for GitHub . I am also looking at whether I can either add TeX as a plugin or do a conversion of the Knuth's code to JavaScript or maybe Ruby. The only thing that seems to be in the way of doing that is the bitfields used in the Pascal web code. These get converted over to C seamlessly. I am thinking I might be able to replace the bitfield references with assessors that do the same job. Once I get the livetex code deconstructed into separate projects I will open it up in a separate GitHub organization. |
README.tex would be great, but also inline
image rendering would be great |
wow LaTeXML is in Perl and looks very well programmed so will most likely be secure as a web service ! |
I have found a stop gap solution :- #897 (comment) |
Closing this as we won't be adding new formats to |
This is mostly a question, and I'm asking knowing that it may be considered a fringe idea from the get go. But I'm still curious.
During a recent GitHub issue debate on what syntax to use for a project's README file, we came up with an idea to think about supporting a README.tex file rendered as HTML, just as the
.md
,.pod
and other extensions do.We've recently released a ruby wrapper for LaTeXML, which could make this possible with minimal effort. The main challenge is that there is a need to setup latexml on the rendering machine, as reimplementing that in Ruby may be too much of a hassle. Sadly reimplementing the entire renderer in Ruby would be too much work, and I would imagine that would be the biggest technical issue here.
Some benefits:
Thoughts?
The text was updated successfully, but these errors were encountered: