Inequalities in math blocks

Inequalities in math blocks

[Rudolf Adamkovič]

The following Org markup does not render properly in HTML export:

- foo $a<b$ bar foo $b>a$ 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.

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č <salutis@me.com> 
Studenohorská 25 84103 Bratislava Slovakia  [he/him]

Re: Inequalities in math blocks

[Max Nikulin]

On 03/10/2021 18:04, Rudolf Adamkovič wrote:
> The following Org markup does not render properly in HTML export:
> 
> - foo $a<b$ bar foo $b>a$ 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 &lt; 
and &gt; during export. Perhaps, it is possible to define a filter.

Re: Inequalities in math blocks

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

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 &lt; and &gt;
> 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

[Rudolf Adamkovič]

Timothy <tecosaur@gmail.com> 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č 
<salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia 
[he/him]

Re: Inequalities in math blocks

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

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

[Eric S Fraga]

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 <theonewiththeevillook@yahoo.fr>
  ;; Date: Fri, 8 Mar 2013 16:23:02 +0100
  ;; Message-ID: <87vc913oh5.fsf@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

[Max Nikulin]

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

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> 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\) \(b<a\)  $a>b$ $b<a$  I could still use \gt and \lt 
- 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č <salutis@me.com> 
Studenohorská 25 84103 Bratislava Slovakia  [he/him]

Re: Inequalities in math blocks

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> writes:

> Though I am a bit surprised that Org did not replace characters 
> to &lt;  and &gt; 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č 
<salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia 
[he/him]

Re: Inequalities in math blocks

[Nick Dokos]

Rudolf Adamkovič <salutis@me.com> writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>> Though I am a bit surprised that Org did not replace characters to
>> &lt;  and &gt; 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

[Max Nikulin]

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 &lt;, &gt; and &amp; 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.

[PATCH] org-manual.org: Update links to MathJax docs

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On 03/10/2021 19:19, Max Nikulin wrote:
> 
> 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 &lt; 
> and &gt; during export. Perhaps, it is possible to define a filter.

Let's fix at least the link. Old one gives 404 error.

P.S. Curiously outside of math snippets "<>" are properly exported to 
"&lt;&gt;"


[-- Attachment #2: 0001-org-manual.org-Update-links-to-MathJax-docs.patch --]
[-- Type: text/x-patch, Size: 1628 bytes --]

From be815b1476b5119db6c83363e1c7b2034b692ca6 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Sun, 3 Oct 2021 23:12:11 +0700
Subject: [PATCH] org-manual.org: Update links to MathJax docs

* doc/org-manual.org (Footnotes): Fix links to particular sections in
MathJax manual.

Scheme is not changed to https: since the site prefers http:

    curl -I https://docs.mathjax.org/
    HTTP/2 302
    date: Sun, 03 Oct 2021 16:04:15 GMT
    location: http://docs.mathjax.org/en/latest/
---
 doc/org-manual.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..52306caa6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -22121,9 +22121,9 @@ semantic relevance.
 
 [fn:130] Please note that exported formulas are part of an HTML
 document, and that signs such as =<=, =>=, or =&= have special
-meanings.  See [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]].
+meanings.  See [[http://docs.mathjax.org/en/latest/input/tex/html.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX in HTML documents]].
 
-[fn:131] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
+[fn:131] See [[http://docs.mathjax.org/en/latest/input/tex/extensions.html#tex-and-latex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
 about extensions.
 
 [fn:132] If the classes on TODO keywords and tags lead to conflicts,
-- 
2.25.1

Re: [PATCH] org-manual.org: Update links to MathJax docs

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Let's fix at least the link. Old one gives 404 error.

Thanks!

> Scheme is not changed to https: since the site prefers http:
>
>     curl -I https://docs.mathjax.org/
>     HTTP/2 302

It is not erring on my side. Maybe they changed something since last year?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] org-manual.org: Update links to MathJax docs

[Max Nikulin]

On 21/08/2022 12:53, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> Let's fix at least the link. Old one gives 404 error.

curl -I 'http://docs.mathjax.org/en/latest/tex.html'
HTTP/1.1 404 Not Found

>> Scheme is not changed to https: since the site prefers http:
>>
>>      curl -I https://docs.mathjax.org/
>>      HTTP/2 302
> 
> It is not erring on my side. Maybe they changed something since last year?

curl -I https://docs.mathjax.org/
         ^^^^^^
HTTP/2 302
date: Sun, 21 Aug 2022 06:16:52 GMT
content-type: text/html; charset=utf-8
content-length: 0
location: http://docs.mathjax.org/en/latest/
           ^^^^^

response from 188.114.98.205:443

Re: [PATCH] org-manual.org: Update links to MathJax docs

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> It is not erring on my side. Maybe they changed something since last year?
>
> curl -I https://docs.mathjax.org/
>          ^^^^^^
> HTTP/2 302
> date: Sun, 21 Aug 2022 06:16:52 GMT
> content-type: text/html; charset=utf-8
> content-length: 0
> location: http://docs.mathjax.org/en/latest/
>            ^^^^^

Hmm. I actually missed that 302 it is not actual error.

Applied onto main via 8d93f9b6b.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9

Feel free to bump any other patch you that did not get a response. While
I did track the new patches recently, the ones introduced more than a
few months ago and those not being tracked at updates.orgmode.org have
likely slipped through the cracks.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] org-manual.org: Update links to MathJax docs

[Max Nikulin]

On 22/08/2022 09:39, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> Hmm. I actually missed that 302 it is not actual error.
> 
> Applied onto main via 8d93f9b6b.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9

Let's try to convince Woof! that it is really

Applied

Update Woof! version at updates.orgmode.org? (was: [PATCH] org-manual.org: Update links to MathJax docs)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Applied onto main via 8d93f9b6b.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9
>
> Let's try to convince Woof! that it is really
>
> Applied

Ain't working...

Bastien, is there any chance that Woof! version used in
updates.orgmode.org can be updated?


-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Update Woof! version at updates.orgmode.org?

[Max Nikulin]

On 23/08/2022 09:32, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>>> Applied onto main via 8d93f9b6b.
>>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9
>>
>> Let's try to convince Woof! that it is really
>>
>> Applied
> 
> Ain't working...
> 
> Bastien, is there any chance that Woof! version used in
> updates.orgmode.org can be updated?

Or at least, please, clarify which version of 
https://github.com/bzg/woof/blob/master/resources/md/howto.md should be 
used for the currently deployed version.

Cited message in addition to the "Applied" keyword (no period) had 
"X-Woof-Patch: applied" header. The complication is that the patch did 
not start the thread. If I remember correctly, I did not confirmed a bug 
to not mix a bug and a patch within the single thread.

I am confused because just "Applied" with no X-Woof header worked in

Max Nikulin to emacs-orgmode.
Re: [PATCH] org-protocol.org: updated Linux setup (Gnome) section.
Sat, 12 Mar 2022 19:07:53 +0700. 
https://list.orgmode.org/t0i2er$12l9$1@ciao.gmane.io

but neither "Applied" not "Canceled." worked that day in another thread. 
I did not tried X-Woof-Patch as well, but second message were sent as 
direct response to the original post:

Max Nikulin to emacs-orgmode.
Re: [PATCH v3] Fix FAQ entry about mailto links.
Sat, 12 Mar 2022 21:35:02 +0700. 
https://list.orgmode.org/t0ib2n$13f0$1@ciao.gmane.io
- sent "Applied" in the body in response to my last message

Max Nikulin to emacs-orgmode.
Re: [PATCH] Fix FAQ entry about mailto links.
Sat, 12 Mar 2022 22:50:25 +0700. 
https://list.orgmode.org/t0ifg2$l3p$1@ciao.gmane.io

Re: Update Woof! version at updates.orgmode.org?

[Bastien]

Hi Max,

Max Nikulin <manikulin@gmail.com> writes:

> Or at least, please, clarify which version of
> https://github.com/bzg/woof/blob/master/resources/md/howto.md should
> be used for the currently deployed version.

This is the documentation of the work-in-progress Woof! rewrite, not
the documentation for the old Woof! version on updates.orgmode.org,
for which the "doc" was just a section in the README.org :

https://github.com/bzg/woof/tree/e40e927b361ca5c7561cc98a02f9b81e519356ad#basic-usage

> The complication is that the patch did
> not start the thread. 

The next Woof! version does not suffer from this limitation.

-- 
 Bastien

Re: Update Woof! version at updates.orgmode.org?

[Bastien]

Hi,

Ihor Radchenko <yantar92@gmail.com> writes:

> Ain't working...

Sorry, the Woof! version on updates.orgmode.org is buggy.

> Bastien, is there any chance that Woof! version used in
> updates.orgmode.org can be updated?

It's on the top of my TODO list: I need to finish Woof! rewrite and
deploy it on updates.orgmode.org.  Ideally, the current database of 
confirmed bugs and patches would go down to zero before I make the
switch.  I'll let the list know how things go.

-- 
 Bastien

Re: Inequalities in math blocks

[Rudolf Adamkovič]

Rudolf Adamkovič <salutis@me.com> 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č <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

Re: Inequalities in math blocks

[Greg Minshall]

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

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

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

[Greg Minshall]

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

[Rudolf Adamkovič]

Greg Minshall <minshall@umich.edu> writes:

> oof.  \(...\) is the way to go.

I do not understand. As Max pointed out, inequalities break HTML export in \( and \) as well.

Example:

- \(a<b\)
- \(b>a\)

Org should rewrite < and > to &lt; and &gt; 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č <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

Re: Inequalities in math blocks

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Hi Rudolf,

> I do not understand. As Max pointed out, inequalities break HTML export in and as well.
>
> Example:
>
> - a<b
> - b>a
>
> Org should rewrite < and > to &lt; and &gt; 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 &lt; and &rt;.

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

[Max Nikulin]

On 07/10/2021 20:05, Timothy wrote:
>> Org should rewrite < and > to &lt; and &gt; 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 &lt; and &rt;.

"<" and ">" characters are valid only markup elements in HTML (part of 
tags, comments). MathJax interprets text content. Normally, to add text 
"<" or ">", "&lt;" or "&gt;" 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

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> 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č <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

Re: Inequalities in math blocks

[Max Nikulin]

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 &lt; and &gt; 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 &lt; and 
>> &rt;.
> 
> "<" and ">" characters are valid only markup elements in HTML (part of 
> tags, comments). MathJax interprets text content. Normally, to add text 
> "<" or ">", "&lt;" or "&gt;" 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.

[BUG] Escaping "<" and ">" inside math blocks when exporting to HTML/MathJax (was: Inequalities in math blocks)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> 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.

From my understanding, all we need is to fix `org-format-latex' by
calling `org-html-encode-plain-text'.

Could you please elaborate about refactoring and backward compatibility?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Inequalities in math blocks

[Rudolf Adamkovič]

Timothy <tecosaur@gmail.com> 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 &lt; and &rt;. […]

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č <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

Re: Inequalities in math blocks

[Greg Minshall]

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