Re: Inequalities in math blocks
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 symbols. - There are functions that performs such replacement in ox-html and ox-odt, but `org-format-latex` resides in org.el, so some refactoring and backward compatibility stubs are necessary. This thread was tracked at https://updates.orgmode.org for a minor fix of the manual. On 07/10/2021 22:05, Max Nikulin wrote: 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 be rewritten. I don’t think I’ve seen an issue because MathJax seems to take care of it, but it looks like MathJax is also fine with and . "<" and ">" characters are valid only markup elements in HTML (part of tags, comments). MathJax interprets text content. Normally, to add text "<" or ">", "" or "" should be used in HTML sources. Browsers may pass "<" and ">" from source to text content if they are totally confused by invalid markup that does not resemble tags or something else. I do not think, it should be abused. I cited MathJax docs just to show a temporary workaround till the bug will be fixed in Org. It is quite strange that Org properly converts "<>&" to entities in text but leaves them as is in math snippets. Unsure whether git history might clarify some reasons of such behavior.
Re: Inequalities in math blocks
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 link in the Org manual, I wonder how this bug can even exist in Org after 15+ years of development. Some people, including the author of TeX himself, write TeX without unnecessary whitespace. Strange! Either way, rearranging bullet points should never break math without any visual sign inside of Emacs. Thus, this represents a bug in Org. R+ No, it does not. Org mode just passes LaTeX directly to MathJax without changing anything. If you want to blame somebody, you can blame HTML for choosing < and > as its delimiters: see http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters Nick, I am sorry, but I do not see your point. Do you know any reason why Org properly escapes "<>&" in text but transparently passes them to HTML inside LaTeX fragment? Does escaping them everywhere lead to problems? From the referenced document (I posted this link on 2021-10-03): you need to be careful that your mathematics doesn’t look like HTML tags to the browser, which parses the page before MathJax gets to see it. ... you can use the HTML entities , and to encode these characters so that the browser will not interpret them, but MathJax will. I fail to see any reason to blame HTML. Any text markup language requires some easily typed special characters. Org has one set of them, HTML another one. Export backend should just respect delimeters of the target format. I understand expectations and thus complains of Rudolf. In my opinion he has reasons to be disappointed (and maybe even angry to some degree). It looks like a bug in Org that should be fixed. Workarounds exist but Org should be more reliable.
Re: Inequalities in math blocks
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 wonder how this bug can even exist in Org > after 15+ years of development. Some people, including the author of > TeX himself, write TeX without unnecessary whitespace. Strange! Either > way, rearranging bullet points should never break math without any > visual sign inside of Emacs. Thus, this represents a bug in Org. R+ No, it does not. Org mode just passes LaTeX directly to MathJax without changing anything. If you want to blame somebody, you can blame HTML for choosing < and > as its delimiters: see http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters -- Nick
Re: Inequalities in math blocks
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
Re: Inequalities in math blocks
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 submission. I
ended up posting an "errata" comment.
> […] "idf" typed in straight font instead of italics and to avoid additional
> space between characters.
Yes, the three letters denote a function name, not a product of three
variables. I simplified the snippet for the mailing list. In reality, I typed
$\mathrm{idf}(t)>c$, as one should. Thank you for caring!
> It is matter of taste, but "{}" after "\in" looks a bit strange for me.
> "$t\in q$ is even shorter, "$t \in q$", having the same length, is more
> readable from my point of view.
Ha-ha! Yeah, I avoid spaces because they make me think for much too long about
where to put them. Knuth would write $t\in q$, like you said, but that looks
"unbalanced" to me. Of course, $t \in q$ looks best, but that sends me to back
to the "whitespace paralysis" mode. Help wanted.
Rudy
--
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and if it
were so, it would be; but as it isn't, it ain't. That's logic.'" -- Lewis
Carroll, Through the Looking Glass
Rudolf Adamkovič
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
Re: Inequalities in math blocks
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 . […]
Not that I know how ox-html works internally, but FYI, we can also use TeX's
native \lt{} and \gt{}.
> As the maintainer for ox-html, I’ll take a look at this.
Thank you so much in advance!
Rudy
--
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel Kant,
1785
Rudolf Adamkovič
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
Re: Inequalities in math blocks
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 be rewritten. I don’t think I’ve seen an issue because MathJax seems to
take care of it, but it looks like MathJax is also fine with and .
"<" and ">" characters are valid only markup elements in HTML (part of
tags, comments). MathJax interprets text content. Normally, to add text
"<" or ">", "" or "" should be used in HTML sources. Browsers
may pass "<" and ">" from source to text content if they are totally
confused by invalid markup that does not resemble tags or something
else. I do not think, it should be abused.
I cited MathJax docs just to show a temporary workaround till the bug
will be fixed in Org. It is quite strange that Org properly converts
"<>&" to entities in text but leaves them as is in math snippets. Unsure
whether git history might clarify some reasons of such behavior.
On 06/10/2021 14:39, Rudolf Adamkovič wrote
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 at this point. Uh-oh!
If you submitted HTML file, you might suggest to open sources to make it
obvious that the mistake was not intentional.
"$idf(t)>c$" means "i*d*f(t) > c". A bit more markup required to make
"idf" typed in straight font instead of italics and to avoid additional
space between characters.
It is matter of taste, but "{}" after "\in" looks a bit strange for me.
"$t\in q$ is even shorter, "$t \in q$", having the same length, is more
readable from my point of view.
Re: Inequalities in math blocks
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 `\( ... \)' vs `$ ... $' comments are most pertinent), but as you say for valid HTML < and > should be rewritten. I don’t think I’ve seen an issue because MathJax seems to take care of it, but it looks like MathJax is also fine with and . As the maintainer for ox-html, I’ll take a look at this. I am exceptionally busy over the next few weeks though, so there may be a brief delay. All the best, Timothy
Re: Inequalities in math blocks
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,' continued Tweedledee, 'if it was so, it might be; and if it
were so, it would be; but as it isn't, it ain't. That's logic.'" -- Lewis
Carroll, Through the Looking Glass
Rudolf Adamkovič
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
Re: Inequalities in math blocks
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
Re: Inequalities in math blocks
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
Re: Inequalities in math blocks
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 at this point. Uh-oh!
oof. \(...\) is the way to go.
cheers, Greg
Re: Inequalities in math blocks
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 the paper at this point. Uh-oh!
R+
--
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel Kant,
1785
Rudolf Adamkovič
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
Re: Inequalities in math blocks
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 real difference. Result is "\(1<2\)" even for $1<2$. Oops! I spoke too soon. I re-tried \( and \) with "1" and "2" instead of "a" and "b", but that does not break HTML rendering in Firefox. When I use "a" and "b" instead, like I did in my original post, it does break rendering with both $$ and \( and \). - \(a>b\) \(bb$ $b- everywhere, but ugh. R+ -- Logic is a science of the necessary laws of thought, without which no employment of the understanding and the reason takes place. -- Immanuel Kant, 1785 Rudolf Adamkovič Studenohorská 25 84103 Bratislava Slovakia [he/him]
Re: Inequalities in math blocks
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 nil
"When called once, insert \\(\\) and leave point in between.
When called twice, replace the previously inserted \\(\\) by one $."
(interactive)
(if (and (looking-at ")") (looking-back "("))
(progn (delete-char 2)
(delete-char -2)
(insert "$"))
(insert "\\(\\)")
(backward-char 2)))
(define-key org-mode-map (kbd "$") 'yf/org-electric-dollar)
#+end_src
Typing two $ in a row inserts a single $.
--
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Inequalities in math blocks
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 is "\(1<2\)" even for $1<2$. info "(org) LaTeX fragments" https://orgmode.org/manual/LaTeX-fragments.html highlight some issues with $: To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash. For the other delimiters, there is no such restriction, so when in doubt, use ‘\(...\)’ as inline math delimiters. Do we consider inequalities in $$ breaking HTML export expected behavior? Or, do we consider it a bug? I suppose there exists no formal specification, executable or not, to answer the question? Tom Gillespie mentioned in another thread yesterday: https://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments It would introduce incompatibilities with previous Org versions, but support for $...$ (and for symmetry, $$...$$) constructs ought to be removed. They are slow to parse, fragile, redundant and imply false positives. — ngz
Re: Inequalities in math blocks
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 no formal specification, executable or not, to answer the > question? Just considering the general situation, $ is hard for Org because it needs to do “double duty” as both a currency symbol in text, and math delimiters. This means that it can’t be consistent with how LaTeX works. However, `\( ... \)' doesn’t and so Org can be much more consistent with LaTeX here. Besides which `$ ... $' is a TeX-ism and `\( ... \)' is the /proper/ way of doing inline maths in LaTeX, so really you should be reaching for those anyway. > I ask because if … breaks basic mathematics, I should either return > back to LaTeX for any serious notes or replace every … with … in all my > Org files to avoid accidental breakage of mathematics in the future. Thank > you! I’d just use `\( ... \)' in future, and that way you’ll be fine in LaTeX and Org . You might be able to use `org-element-map' to robustly convert from $ … $= to `\( ... \)'. All the best, Timothy
Re: Inequalities in math blocks
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 formal specification, executable or not, to answer the question? I ask because if $…$ breaks basic mathematics, I should either return back to LaTeX for any serious notes or replace every $…$ with \(…\) in all my Org files to avoid accidental breakage of mathematics in the future. Thank you! R+ -- Programming reliably --- must be an activity of an undeniably mathematical nature [...] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible. -- Edsger W. Dijkstra (1981) Rudolf Adamkovič Studenohorská 25 84103 Bratislava Slovakia [he/him]
Re: Inequalities in math blocks
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 Org after 15+ years of development. Some people, including the author of TeX himself, write TeX without unnecessary whitespace. Strange! Either way, rearranging bullet points should never break math without any visual sign inside of Emacs. Thus, this represents a bug in Org. R+ -- I love deadlines. I love the whooshing noise they make as they go by. -- Douglas Adams, The Salmon of Doubt Rudolf Adamkovič Studenohorská 25 84103 Bratislava Slovakia [he/him]
Re: Inequalities in math blocks
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 filter. You’re going to be much better off if you just use LaTeX math delimiters, i.e. `\( ... \)'. All the best, Timothy
Re: Inequalities in math blocks
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 \gt instead of < and all the time? If so, why allow < and > characters in math blocks? I ask because, when I reorganize my Org document, it breaks math "at random" when I use < and > and Emacs does not tell me about it. I had another reason to look into the manual today, so I noticed: https://orgmode.org/manual/Math-formatting-in-HTML-export.html (131) Please note that exported formulas are part of an HTML document, and that signs such as ‘<’, ‘>’, or ‘&’ have special meanings. See MathJax TeX and LaTeX support. The link is broken however. http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters 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 filter.
