This is a reminder of an old bug. From my point of view it is serious
enough, but not release critical due to its age.
&<> characters must be escaped as HTML entities when LaTeX snippets and
blocks are exported for MathJax
Form my year-old notes:
- =#+options: tex:verbatim= properly escapes s
On 12/10/2021 08:11, Nick Dokos wrote:
Rudolf Adamkovič writes:
Max Nikulin writes:
Though I am a bit surprised that Org did not replace characters to
< and > during export. Perhaps, it is possible to define a
filter.
That makes sense, and thank you for the explanation. Ignoring the dead
li
Rudolf Adamkovič writes:
> Max Nikulin writes:
>
>> Though I am a bit surprised that Org did not replace characters to
>> < and > during export. Perhaps, it is possible to define a
>> filter.
>
> That makes sense, and thank you for the explanation. Ignoring the dead
> link in the Org manual, I
Rudolf,
> I do not understand. As Max pointed out, inequalities break HTML
> export in \( and \) as well.
my apologies for not having understood where we were in the discussion!
cheers, Greg
Max Nikulin writes:
> If you submitted HTML file, you might suggest to open sources to make it
> obvious that the mistake was not intentional.
One day! The university system switches to a read-only mode at the end of every
week, and I cannot open-source anything for two years after the submiss
Timothy writes:
> […] MathJax seems to take care of it […]
>From what I understand, MathJax does nothing, for it expects to exit inside of
>valid HTML.
> […] but it looks like MathJax is also fine with < and &rt;. […]
Not that I know how ox-html works internally, but FYI, we can also use TeX'
On 07/10/2021 20:05, Timothy wrote:
Org should rewrite < and > to < and > to avoid broken HTML, or as < and
in general.
I think we’ve drifted a bit to the differences in processing (where the `\( ...
\)'
vs `$ ... $' comments are most pertinent), but as you say for valid HTML < and >
should
Hi Rudolf,
> I do not understand. As Max pointed out, inequalities break HTML export in
> and as well.
>
> Example:
>
> - a - b>a
>
> Org should rewrite < and > to < and > to avoid broken HTML, or as < and
> in general.
I think we’ve drifted a bit to the differences in processing (where the `\
Greg Minshall writes:
> oof. \(...\) is the way to go.
I do not understand. As Max pointed out, inequalities break HTML export in \(
and \) as well.
Example:
- \(aa\)
Org should rewrite < and > to < and > to avoid broken HTML, or as \lt{}
and \rt{} in general.
R+
--
"'Contrariwise,' cont
Timothy,
> I’m thinking we should perhaps update the docs to more strongly
> recommend `\( ... \)' over `$ ... $'. So that someone coming from say,
> Markdown + $-math or (not-La)TeX doesn’t just go “cool, $ works, I’ll
> keep on using that”.
i think that would be a helpful change.
cheers, Greg
Hi Greg,
> oof. ... is the way to go.
I’m thinking we should perhaps update the docs to more strongly recommend `\(
... \)'
over `$ ... $'. So that someone coming from say, Markdown + $-math or
(not-La)TeX doesn’t just go “cool, $ works, I’ll keep on using that”.
All the best,
Timothy
Rudolf,
> FYI: I have just discovered that this bug screwed up a paper I
> submitted to university this week. In the paper, I wrote the
> following: "[…] every term $t\in{}q$ with $idf(t)>c$ for some constant
> $c$ […]", and the "idf(t) > c" part got exported as "idf(t)". I cannot
> fix the paper
Rudolf Adamkovič writes:
FYI: I have just discovered that this bug screwed up a paper I submitted to
university this week. In the paper, I wrote the following: "[…] every term
$t\in{}q$ with $idf(t)>c$ for some constant $c$ […]", and the "idf(t) > c" part
got exported as "idf(t)". I cannot fix
Max Nikulin writes:
On 05/10/2021 14:55, Rudolf Adamkovič wrote:
Timothy writes:
You’re going to be much better off if you just use LaTeX math
delimiters, i.e. `\( ... \)'.
Interesting. It works, but I do not understand why!
Did you inspect HTML file? Playing with export, I do not see
Slightly off-topic but, just in case anybody is interested, here is some
code I use to allow me to easily get \(...\) by typing $:
#+begin_src emacs-lisp
;; from Nicolas Richard
;; Date: Fri, 8 Mar 2013 16:23:02 +0100
;; Message-ID: <87vc913oh5@yahoo.fr>
(defun yf/org-electric-dollar
On 05/10/2021 14:55, Rudolf Adamkovič wrote:
Timothy writes:
You’re going to be much better off if you just use LaTeX math
delimiters, i.e. `\( ... \)'.
Interesting. It works, but I do not understand why!
Did you inspect HTML file? Playing with export, I do not see real
difference. Result
Hi Rudolf,
>> You’re going to be much better off if you just use LaTeX math delimiters,
>> i.e.
>> `...’.
>
> Interesting. It works, but I do not understand why! Do we consider
> inequalities
> in $$ breaking HTML export expected behavior? Or, do we consider it a bug? I
> suppose there exists n
Timothy writes:
You’re going to be much better off if you just use LaTeX math
delimiters, i.e. `\( ... \)'.
Interesting. It works, but I do not understand why! Do we consider
inequalities in $$ breaking HTML export expected behavior? Or, do
we consider it a bug? I suppose there exists no fo
Max Nikulin writes:
Though I am a bit surprised that Org did not replace characters
to < and > during export. Perhaps, it is possible to
define a filter.
That makes sense, and thank you for the explanation. Ignoring the
dead link in the Org manual, I wonder how this bug can even exist
in
Hi Rudolf and Max,
>> Usually, it is sufficient simply to put spaces around these symbols to
>> cause the browser to avoid them, so
>> … when x < y we have …
>
> Though I am a bit surprised that Org did not replace characters to < and
> >
> during export. Perhaps, it is possible to define a filte
On 03/10/2021 18:04, Rudolf Adamkovič wrote:
The following Org markup does not render properly in HTML export:
- foo $aa$ bar
In Emacs, I see no signs of problems, such as broken math highlighting.
Further, when I export to LaTeX, the inequalities render properly. Does
one have to use \lt and
21 matches
Mail list logo
