On Wed, May 28, 2014 at 6:06 PM, Lex Trotman <[email protected]> wrote:
> On 29 May 2014 07:06, Dan Allen <[email protected]> wrote: > > Eduardo, > > > > The explicit use of the latexmath inline macro isn't technically > necessary. > > You should just be able to type the escaped sequence for MathJax and it > will > > pick up the math. Thus, there would be no reason to introduce another > set of > > delimiters to use for shorthand. > > Eduardo is also using the PDF toolchains as well as mathjax, so it > needs to be wrapped in <*equation> for them. So a simple passthrough > won't work. > It's still possible to create a custom inline macro that maps to the math delimiters so the appropriate output can be created in other backends. > > > > > Asciidoctor simplifies this even further by allowing you to associate the > > math inline macro with either latexmath or asciimath. Here's an example: > > > > :math: latexmath > > > > math:[R_x = 10.0 \times \sin(R_\phi)] > > A macro that does this can certainly be defined for both HTML and > Docbook backends. Could just as well use the @@ as the delimiter. > Agreed. > > > > > > Notice that you don't need the delimiters around the equation inside the > > macro body. That's because Asciidoctor adds them automatically. AsciiDoc > > Python could do the same thing. There's absolutely no reason AsciiDoc > Python > > should be requiring you to include the math delimiters inside the macro > > body. > > > > Instead of using the math inline macro, you can just use the escaped > round > > brackets as delimiters: > > > > \(R_x = 10.0 \times \sin(R_\phi)\) > > I'm wary about escaped parens as delimeters, are you *sure* they can't > occur elsewhere? At least @@ is likely to be more rare (except for > the guy documenting roff of course :) > That's just the default for MathJax. It's possible to change the MathJax configuration to look for different delimiters, if backlash round brackets turn out to be a problem. I can't think of a single document that ever used escaped round brackets, so it's likely an edge case situation. > > > > > The downside of this shorthand is that it's not treated as passthrough > > content, so you run the risk of getting unwanted substitutions. > Personally, > > I find the math inline macro without the math delimiters around the > equation > > (first example above) to be a reasonable compromise. > > In asciidoc you can define limit substitution in macros by capturing > content in (?P<passtext>pattern) instead of as attributes see > http://asciidoc.org/userguide.html#_macro_definitions. > +1 > > > > > > wdyt? > > > > Although Asciidoctor deviates from the AsciiDoc Python behavior, I don't > see > > any reason why AsciiDoc Python can't be enhanced to align with this > > enhancement. > > > > I guess latexmath:[] was invented for documents with occasional maths > in it. A more compact form would be good for more math heavy > documents. Pity the $$ is already used as a passthrough. > Unfortunately changing that to an <equation> now is going to break > documents that use it. With Python Asciidoc Eduardo should be able to > define his own macros and experiment with the most appropriate > delimiters. > Fortunately AsciiDoc Python leaves a lot of options open. If I were providing professional advice to someone, I would like encourage the use of the math:[] inline macro and have the backend wrap the content appropriately (delimiters for MathJax, <equation> for DocBook, etc). math:[R_x = 10.0 \times \sin(R_\phi)] If "math" is too long, another alternative is "eq" for equation. eq:[R_x = 10.0 \times \sin(R_\phi)] -Dan -- Dan Allen | http://google.com/profiles/dan.j.allen -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
