The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option? ---- lualatex ---- \documentclass[leqno]{article} \usepackage[colon=literal]{unicode-math} \begin{document} The function $f: A → B$. \end{document} --------
Well, you can make the colon active in math mode and then let it output \colon.
This is a TeX way, I don't know if there's a ConTeXt way for this:
\begingroup\lccode`\~=`\:\lowercase{\endgroup
\let~}\colon
\mathcode`\:="8000 %
2015-07-20 16:40 GMT+02:00, Aditya Mahajan
On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
Aditya ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
A little bit more of intelligence can be given with \begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\futurelet\tmptoken\docolon} \unexpanded\def\docolon{\ifx=\tmptoken\mathrel{\mathop{\mathchar`\:}}\else\colon\fi} \mathcode`\:="8000 % That lets you do $f: A \to B$ and $f(x) := x^2$
On 20 Jul 2015, at 17:50, Manuel Blanco
wrote: A little bit more of intelligence can be given with
\begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\futurelet\tmptoken\docolon} \unexpanded\def\docolon{\ifx=\tmptoken\mathrel{\mathop{\mathchar`\:}}\else\colon\fi} \mathcode`\:="8000 %
That lets you do $f: A \to B$ and $f(x) := x^2$
For the second, one can use ≔ COLON EQUALS U+2254. But it is a good point, though.
On 7/20/2015 6:09 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:50, Manuel Blanco
wrote: A little bit more of intelligence can be given with
\begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\futurelet\tmptoken\docolon} \unexpanded\def\docolon{\ifx=\tmptoken\mathrel{\mathop{\mathchar`\:}}\else\colon\fi} \mathcode`\:="8000 %
That lets you do $f: A \to B$ and $f(x) := x^2$
For the second, one can use ≔ COLON EQUALS U+2254. But it is a good point, though.
there is actually a more modern trick: \starttext \startluacode characters.mathpairs[0x3A] = { [0x3D] = 0x2254 } characters.mathpairs[0x3E] = { [0x3D] = 0x2265 } characters.mathpairs[0x3C] = { [0x3D] = 0x2264 } characters.mathpairs[0x3D] = { [0x3A] = 0x2255 } \stopluacode \startTEXpage $a := b <= =< c =: d >= e$ \stopTEXpage \stoptext i uploaded a beta with these predefined (in char-def.lua) but we can add more (if someone provides me the list) negations and a few more already were present Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 11:40, Hans Hagen
wrote: On 7/20/2015 6:09 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:50, Manuel Blanco
wrote: A little bit more of intelligence can be given with
\begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\futurelet\tmptoken\docolon} \unexpanded\def\docolon{\ifx=\tmptoken\mathrel{\mathop{\mathchar`\:}}\else\colon\fi} \mathcode`\:="8000 %
That lets you do $f: A \to B$ and $f(x) := x^2$
For the second, one can use ≔ COLON EQUALS U+2254. But it is a good point, though.
there is actually a more modern trick:
\starttext
\startluacode characters.mathpairs[0x3A] = { [0x3D] = 0x2254 } characters.mathpairs[0x3E] = { [0x3D] = 0x2265 } characters.mathpairs[0x3C] = { [0x3D] = 0x2264 } characters.mathpairs[0x3D] = { [0x3A] = 0x2255 } \stopluacode
\startTEXpage $a := b <= =< c =: d >= e$ \stopTEXpage
\stoptext
I have experimented with a theorem proof assistant that admitted parallel ASCII and Unicode symbol names, but it turns out to be complicated. Think of C/C++ trigraphs, a chore to implement, only to be removed in the latest standards. So I think one should only focus on UTF-8, and add TeX ASCII “\” commands as a complement. One problem with this approach is the lack of Unicode input methods. But that may coming. For example, instead having “:=“ in the input file and let Lua translate it, one can merely type it and let the text editor translate it ≔ COLON EQUALS U+2254. It will save a lot of programming time, at least on the ConTEXt project. :-)
On 7/24/2015 2:40 PM, Hans Aberg wrote:
On 24 Jul 2015, at 11:40, Hans Hagen
wrote: On 7/20/2015 6:09 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:50, Manuel Blanco
wrote: A little bit more of intelligence can be given with
\begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\futurelet\tmptoken\docolon} \unexpanded\def\docolon{\ifx=\tmptoken\mathrel{\mathop{\mathchar`\:}}\else\colon\fi} \mathcode`\:="8000 %
That lets you do $f: A \to B$ and $f(x) := x^2$
For the second, one can use ≔ COLON EQUALS U+2254. But it is a good point, though.
there is actually a more modern trick:
\starttext
\startluacode characters.mathpairs[0x3A] = { [0x3D] = 0x2254 } characters.mathpairs[0x3E] = { [0x3D] = 0x2265 } characters.mathpairs[0x3C] = { [0x3D] = 0x2264 } characters.mathpairs[0x3D] = { [0x3A] = 0x2255 } \stopluacode
\startTEXpage $a := b <= =< c =: d >= e$ \stopTEXpage
\stoptext
I have experimented with a theorem proof assistant that admitted parallel ASCII and Unicode symbol names, but it turns out to be complicated. Think of C/C++ trigraphs, a chore to implement, only to be removed in the latest standards.
So I think one should only focus on UTF-8, and add TeX ASCII “\” commands as a complement.
One problem with this approach is the lack of Unicode input methods. But that may coming.
For example, instead having “:=“ in the input file and let Lua translate it, one can merely type it and let the text editor translate it ≔ COLON EQUALS U+2254.
that is ok for some input sequences (this kind of input translation happens for accented characters and some math like negated symbols) but replacing <= in the input is bad as it is only meaningful in math and not all input is math (and unicode lacks script/language tagging); keep in mind that 'verbatim' in tex really means verbatim and input translation contradicts that
It will save a lot of programming time, at least on the ConTEXt project. :-)
not really as that code is already in place for years; in this case it mainly boils down to adding some extra entries in the character database (and this code is simple compared to other code so not much to save here) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 15:34, Hans Hagen
wrote:
I have experimented with a theorem proof assistant that admitted parallel ASCII and Unicode symbol names, but it turns out to be complicated. Think of C/C++ trigraphs, a chore to implement, only to be removed in the latest standards.
So I think one should only focus on UTF-8, and add TeX ASCII “\” commands as a complement.
One problem with this approach is the lack of Unicode input methods. But that may coming.
For example, instead having “:=“ in the input file and let Lua translate it, one can merely type it and let the text editor translate it ≔ COLON EQUALS U+2254.
that is ok for some input sequences (this kind of input translation happens for accented characters and some math like negated symbols) but replacing <= in the input is bad as it is only meaningful in math and not all input is math (and unicode lacks script/language tagging); keep in mind that 'verbatim' in tex really means verbatim and input translation contradicts that
I have only the part that is used to produce math character output here, and it would be better to have it in the key map. But somehow, it would be possible to produce those Unicode characters. Right, there is a lot copy and paste, but it is slow.
It will save a lot of programming time, at least on the ConTEXt project. :-)
not really as that code is already in place for years; in this case it mainly boils down to adding some extra entries in the character database
(and this code is simple compared to other code so not much to save here)
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
On 7/24/2015 4:13 PM, Hans Aberg wrote:
On 24 Jul 2015, at 15:34, Hans Hagen
wrote: I have experimented with a theorem proof assistant that admitted parallel ASCII and Unicode symbol names, but it turns out to be complicated. Think of C/C++ trigraphs, a chore to implement, only to be removed in the latest standards.
So I think one should only focus on UTF-8, and add TeX ASCII “\” commands as a complement.
One problem with this approach is the lack of Unicode input methods. But that may coming.
For example, instead having “:=“ in the input file and let Lua translate it, one can merely type it and let the text editor translate it ≔ COLON EQUALS U+2254.
that is ok for some input sequences (this kind of input translation happens for accented characters and some math like negated symbols) but replacing <= in the input is bad as it is only meaningful in math and not all input is math (and unicode lacks script/language tagging); keep in mind that 'verbatim' in tex really means verbatim and input translation contradicts that
I have only the part that is used to produce math character output here, and it would be better to have it in the key map. But somehow, it would be possible to produce those Unicode characters. Right, there is a lot copy and paste, but it is slow.
It will save a lot of programming time, at least on the ConTEXt project. :-)
not really as that code is already in place for years; in this case it mainly boils down to adding some extra entries in the character database
(and this code is simple compared to other code so not much to save here)
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
fyi, on the agenda for the gyre font project is to have a monospaced font that has most of unicode math so that we can have decent editing (once we have the funding covered) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 16:28, Hans Hagen
wrote: On 7/24/2015 4:13 PM, Hans Aberg wrote:
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
fyi, on the agenda for the gyre font project is to have a monospaced font that has most of unicode math so that we can have decent editing (once we have the funding covered)
The Unicode monospace characters were added by mistake, because in computer science, style does not affect semantics, as it does math. Looking into old computer science books, they do not have monospace, and a I recall a Pascal compiler on Mac OS 9 that used styled, non-monospace fonts. So a monospace font may not be strictly necessary, though current UTF-8 plain text does not look good. In Xcode, part of the reason is that one cannot choose font per Unicode code point segments.
On 7/24/2015 6:18 PM, Hans Aberg wrote:
On 24 Jul 2015, at 16:28, Hans Hagen
wrote: On 7/24/2015 4:13 PM, Hans Aberg wrote:
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
fyi, on the agenda for the gyre font project is to have a monospaced font that has most of unicode math so that we can have decent editing (once we have the funding covered)
The Unicode monospace characters were added by mistake, because in computer science, style does not affect semantics, as it does math. Looking into old computer science books, they do not have monospace, and a I recall a Pascal compiler on Mac OS 9 that used styled, non-monospace fonts. So a monospace font may not be strictly necessary, though current UTF-8 plain text does not look good. In Xcode, part of the reason is that one cannot choose font per Unicode code point segments.
we're not talking of the monospace math alphabet (those are already covered but the fonts) but about a monospaced font for editing and verbatim (handy for manuals explaining math typesetting) in a similar fashion a bold math font is not about math bold alphabets but about a whole bold font with a couple of heavy bold alphabets (handy for typesetting section heads in bold that have math) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 18:34, Hans Hagen
wrote: On 7/24/2015 6:18 PM, Hans Aberg wrote:
On 24 Jul 2015, at 16:28, Hans Hagen
wrote: On 7/24/2015 4:13 PM, Hans Aberg wrote:
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
fyi, on the agenda for the gyre font project is to have a monospaced font that has most of unicode math so that we can have decent editing (once we have the funding covered)
The Unicode monospace characters were added by mistake, because in computer science, style does not affect semantics, as it does math. Looking into old computer science books, they do not have monospace, and a I recall a Pascal compiler on Mac OS 9 that used styled, non-monospace fonts. So a monospace font may not be strictly necessary, though current UTF-8 plain text does not look good. In Xcode, part of the reason is that one cannot choose font per Unicode code point segments.
we're not talking of the monospace math alphabet (those are already covered but the fonts) but about a monospaced font for editing and verbatim (handy for manuals explaining math typesetting)
Right. But it was added because it is popular in computer science to use a monospace font, though not strictly necessary from the semantic point of view. So it makes me think that, instead of a monospace font for all the math characters, one might switch to a variable-width font in the input code, as actuallye been the case in the past. All that monospace tabbing will break, that is for sure.
On 7/24/2015 6:57 PM, Hans Aberg wrote:
On 24 Jul 2015, at 18:34, Hans Hagen
wrote: On 7/24/2015 6:18 PM, Hans Aberg wrote:
On 24 Jul 2015, at 16:28, Hans Hagen
wrote: On 7/24/2015 4:13 PM, Hans Aberg wrote:
You can add it if you think it is no problem. Proper Unicode characters in the input help the readability, so putting them at high priority seems good.
fyi, on the agenda for the gyre font project is to have a monospaced font that has most of unicode math so that we can have decent editing (once we have the funding covered)
The Unicode monospace characters were added by mistake, because in computer science, style does not affect semantics, as it does math. Looking into old computer science books, they do not have monospace, and a I recall a Pascal compiler on Mac OS 9 that used styled, non-monospace fonts. So a monospace font may not be strictly necessary, though current UTF-8 plain text does not look good. In Xcode, part of the reason is that one cannot choose font per Unicode code point segments.
we're not talking of the monospace math alphabet (those are already covered but the fonts) but about a monospaced font for editing and verbatim (handy for manuals explaining math typesetting)
Right. But it was added because it is popular in computer science to use a monospace font, though not strictly necessary from the semantic point of view.
one extra alphabet is not putting that much of a burden on tex; let's hope math coders don't start using the many emoticons and alike that unicode provides
So it makes me think that, instead of a monospace font for all the math characters, one might switch to a variable-width font in the input code, as actuallye been the case in the past.
which is actually rather inconvenient for entering tables (and i'd also never use it for programming)
All that monospace tabbing will break, that is for sure.
right and proportial makes debugging hard (and how about blockwise copying) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 21:58, Hans Hagen
wrote: On 7/24/2015 6:57 PM, Hans Aberg wrote:
The Unicode monospace characters were added by mistake, because in computer science, style does not affect semantics, as it does math. Looking into old computer science books, they do not have monospace, and a I recall a Pascal compiler on Mac OS 9 that used styled, non-monospace fonts. So a monospace font may not be strictly necessary, though current UTF-8 plain text does not look good. In Xcode, part of the reason is that one cannot choose font per Unicode code point segments.
we're not talking of the monospace math alphabet (those are already covered but the fonts) but about a monospaced font for editing and verbatim (handy for manuals explaining math typesetting)
Right. But it was added because it is popular in computer science to use a monospace font, though not strictly necessary from the semantic point of view.
one extra alphabet is not putting that much of a burden on tex;
It is more a curiosity, the reason they were added. It might be useful some day, say using bold monospace for keywords in programming languages. It reminds me, in math one can use the idea that upright for constants, italic for variables. But I think in LaTeX packages mathtools and/or unicode-math, it is difficult to do that in UTF-8, because the somehow translates them to italic. And the Unicode sans-serif mathematical styles aren’t really semantic either from the mathematical point of view, but there is a technical standard to set tensors in sans-serif, and perhaps were added because of that. Physics books seem to be bit chaotic here. In pure math, it is all serif.
let's hope math coders don't start using the many emoticons and alike that unicode provides
From the Unicode list discussion, I think there was a fairly large number of additional symbols the poster wanted to be added. But it took a long time, via STIX, the get the current ones usable. But as you note, any character could be in principle be used. That is how many started off.
So it makes me think that, instead of a monospace font for all the math characters, one might switch to a variable-width font in the input code, as actuallye been the case in the past.
which is actually rather inconvenient for entering tables (and i'd also never use it for programming)
Indeed, but that is the only use. The obsession in computer code to align vertically.
All that monospace tabbing will break, that is for sure.
right and proportial makes debugging hard (and how about blockwise copying)
So possibly, there should be some replacement when using a variable width font. For the ASCII tabbing, the tab character was originally typically interpreted as being 8 spaces wide, but that is too much for computer code with higher indentation levels. So people switched using spaces instead, successively shrinking down to 2 spaces instead of tab, which is what I use. Unicode has a number of tab characters, but haven’t seen them in use.
On 20 Jul 2015, at 17:43, Manuel Blanco
wrote: Well, you can make the colon active in math mode and then let it output \colon.
This is a TeX way, I don't know if there's a ConTeXt way for this:
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
For some reason, the colon in ConTeXt is larger relative LuaTeX. Also, it seems that “\:” is not used for anything - error in luatex, and empty in context. So it might be used for the infix operator. — context — \setupbodyfont[xits,10pt] \setupformulas[location=left] \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 % \starttext The function $f: A → B$, $g\colon A → B$. \stoptext — — luatex — \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 % The function $f: A → B$. —
I'm not sure I understand what you mean. It's true that the colon used in \colon differs from the one used if you input : directly by default (it's smaller). In any case, I don't see where your discussion is going, so I will write here a few definitions. This is the definition of amsmath in LaTeX. (Used like $f\amscolon A \to B$) \def\amscolon{\nobreak\mskip2mu\mathpunct{}\nonscript\mkern-\thinmuskip \mathord{\mathchar`\:}\mskip6muplus1mu\relax} The definition of a coordinate separator should be with \mathpunct, although it doesn't look particularly good, so may be better to use no space at all (as commented in other mails). (Used like $(x\projsep y\projsep z)$) \def\projsep{\mathpunct{\mathchar`\:}} % if no space is wanted, the definition should be % {\mathpunct{\mathchar`\:}\nonscript\mkern-\thinmuskip} In the case of \ratio, since it's a binary operator, it should be \mathbin; but may be that's too much space and tighter spacing would be better. (Used like $A \ratio B \quad 3\ratio2\ratio1$) \def\ratio{\mathbin{\mathchar`\∶}} % may be tighter spacing playing with other atom types and \mkern And also the relation : which is the spacing that comes by default and is the same as if a macro contained \mathrel{\mathchar`\:}. That said, if you want to define the normal : character in _input_ to give you one of the above in _output_, just change the definition (in this case I define : to give \amscolon) \begingroup\lccode`\~=`\:\lowercase{\endgroup \unexpanded\def~}{\amscolon} \mathcode`\:="8000 % In any case, if this message is out of place, sorry, but I really didn't understand where your question/discussion was going.
On 20 Jul 2015, at 21:34, Manuel Blanco
wrote: I'm not sure I understand what you mean. It's true that the colon used in \colon differs from the one used if you input : directly by default (it's smaller).
Right. For some reason, your code gives the right, smaller, colon when used with luatex, but not with context. (As in the examples I gave.)
On 20 Jul 2015, at 21:34, Manuel Blanco
wrote:
The definition of a coordinate separator should be with \mathpunct, although it doesn't look particularly good, so may be better to use no space at all (as commented in other mails).
In the case of \ratio, since it's a binary operator, it should be \mathbin; but may be that's too much space and tighter spacing would be better.
Strictly speaking, the coordinate separator : for homogeneous coordinates is a ration symbol, and a book in algebraic used that. So may be simplest to only do the operator : along with the function and set :.
On 7/20/2015 6:22 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:43, Manuel Blanco
wrote: Well, you can make the colon active in math mode and then let it output \colon.
This is a TeX way, I don't know if there's a ConTeXt way for this:
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
For some reason, the colon in ConTeXt is larger relative LuaTeX.
you probably mean latex (macro package) here as luatex (engine) itself doesn't do anything keep in mind that context implements much of math in a complete different way, so solutions for problems or wishes are done differently too; in this case we try to use unicode and some lua magic instead of character juggling at the tex end we also need to keep in mind that characters have to behave well in tagged pdf and exports and so
Also, it seems that “\:” is not used for anything - error in luatex, and empty in context. So it might be used for the infix operator.
— context — \setupbodyfont[xits,10pt]
\setupformulas[location=left]
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
\starttext
The function $f: A → B$, $g\colon A → B$.
\stoptext —
— luatex — \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
The function $f: A → B$. —
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 11:43, Hans Hagen
wrote: On 7/20/2015 6:22 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:43, Manuel Blanco
wrote: Well, you can make the colon active in math mode and then let it output \colon.
This is a TeX way, I don't know if there's a ConTeXt way for this:
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
For some reason, the colon in ConTeXt is larger relative LuaTeX.
you probably mean latex (macro package) here as luatex (engine) itself doesn't do anything
keep in mind that context implements much of math in a complete different way, so solutions for problems or wishes are done differently too; in this case we try to use unicode and some lua magic instead of character juggling at the tex end
we also need to keep in mind that characters have to behave well in tagged pdf and exports and so
In the examples I mentioned (below), running ‘context’ on the first produces large colons, whereas ‘luatex’ on the second does not. The latter looks right to me. There is a similar issue with integral symbols, where somehow ConTeXt add additional spacing after it. http://www.ntg.nl/pipermail/ntg-context/2015/082541.html — context — \setupbodyfont[xits,10pt] \setupformulas[location=left] \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 % \starttext The function $f: A → B$, $g\colon A → B$. \stoptext — — luatex — \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 % The function $f: A \to B$. \end —
On 7/24/2015 3:00 PM, Hans Aberg wrote:
On 24 Jul 2015, at 11:43, Hans Hagen
wrote: On 7/20/2015 6:22 PM, Hans Aberg wrote:
On 20 Jul 2015, at 17:43, Manuel Blanco
wrote: Well, you can make the colon active in math mode and then let it output \colon.
This is a TeX way, I don't know if there's a ConTeXt way for this:
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
For some reason, the colon in ConTeXt is larger relative LuaTeX.
you probably mean latex (macro package) here as luatex (engine) itself doesn't do anything
keep in mind that context implements much of math in a complete different way, so solutions for problems or wishes are done differently too; in this case we try to use unicode and some lua magic instead of character juggling at the tex end
we also need to keep in mind that characters have to behave well in tagged pdf and exports and so
In the examples I mentioned (below), running ‘context’ on the first produces large colons, whereas ‘luatex’ on the second does not. The latter looks right to me.
define 'luatex' ... it's all about choices that macro packages make (or made in the past)
There is a similar issue with integral symbols, where somehow ConTeXt add additional spacing after it. http://www.ntg.nl/pipermail/ntg-context/2015/082541.html
— context — \setupbodyfont[xits,10pt]
\setupformulas[location=left]
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
\starttext
The function $f: A → B$, $g\colon A → B$.
we could add a mathsymbol entry but I leave that to Aditya to decide { adobename="colon", category="po", cjkwd="na", description="COLON", direction="cs", linebreak="is", mathclass="relation", --mathsymbol=0x2236, unicodeslot=0x3A, },
\stoptext —
— luatex — \begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
The function $f: A \to B$.
\end —
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 15:48, Hans Hagen
wrote:
In the examples I mentioned (below), running ‘context’ on the first produces large colons, whereas ‘luatex’ on the second does not. The latter looks right to me.
define 'luatex' ... it's all about choices that macro packages make (or made in the past)
I use Tex Live 2015 that came last month. $ luatex --version This is LuaTeX, Version beta-0.80.0 (TeX Live 2015) (rev 5238)
There is a similar issue with integral symbols, where somehow ConTeXt add additional spacing after it. http://www.ntg.nl/pipermail/ntg-context/2015/082541.html
— context — \setupbodyfont[xits,10pt]
\setupformulas[location=left]
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
\starttext
The function $f: A → B$, $g\colon A → B$.
we could add a mathsymbol entry but I leave that to Aditya to decide
{ adobename="colon", category="po", cjkwd="na", description="COLON", direction="cs", linebreak="is", mathclass="relation", --mathsymbol=0x2236, unicodeslot=0x3A, },
Should it be 'mathclass=“relation”’? Mathematically, relations have extra space at both sides, whereas in the function $f: A → B$, there should not be much space before the “:”.
On 7/24/2015 4:19 PM, Hans Aberg wrote:
On 24 Jul 2015, at 15:48, Hans Hagen
wrote: In the examples I mentioned (below), running ‘context’ on the first produces large colons, whereas ‘luatex’ on the second does not. The latter looks right to me.
define 'luatex' ... it's all about choices that macro packages make (or made in the past)
I use Tex Live 2015 that came last month.
$ luatex --version This is LuaTeX, Version beta-0.80.0 (TeX Live 2015) (rev 5238)
There is a similar issue with integral symbols, where somehow ConTeXt add additional spacing after it. http://www.ntg.nl/pipermail/ntg-context/2015/082541.html
— context — \setupbodyfont[xits,10pt]
\setupformulas[location=left]
\begingroup\lccode`\~=`\:\lowercase{\endgroup \let~}\colon \mathcode`\:="8000 %
\starttext
The function $f: A → B$, $g\colon A → B$.
we could add a mathsymbol entry but I leave that to Aditya to decide
{ adobename="colon", category="po", cjkwd="na", description="COLON", direction="cs", linebreak="is", mathclass="relation", --mathsymbol=0x2236, unicodeslot=0x3A, },
Should it be 'mathclass=“relation”’? Mathematically, relations have extra space at both sides, whereas in the function $f: A → B$, there should not be much space before the “:”.
that's where the domain would kick in .. it can control that kind of spacing issues Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 16:29, Hans Hagen
wrote: On 7/24/2015 4:19 PM, Hans Aberg wrote:
The function $f: A → B$, $g\colon A → B$.
we could add a mathsymbol entry but I leave that to Aditya to decide
{ adobename="colon", category="po", cjkwd="na", description="COLON", direction="cs", linebreak="is", mathclass="relation", --mathsymbol=0x2236, unicodeslot=0x3A, },
Should it be 'mathclass=“relation”’? Mathematically, relations have extra space at both sides, whereas in the function $f: A → B$, there should not be much space before the “:”.
that's where the domain would kick in .. it can control that kind of spacing issues
OK. The word “relation” makes me think of math relations. :-)
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
On Mon, 20 Jul 2015, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
There are two uses of colon in math, as a relation (in sets \{ x : f(x) = 0 \} and in ratios A:B, etc) and as a punctuation ($f \colon A -> B, etc.[1]). Only one of them can be mapped to the literal :, the other must use a macro name. Knuth chose to map : to the relation and mapped \colon to a punctuation and every other macro package follows that convention. It is easy to change the mapping, but if the mapping is reversed, is there is standard name for : as a relation? Aditya [1]: Amsmath redefines \colon so that the spacing is different from math punctuation. So, that is what you see in most published papers.
On 20 Jul 2015, at 18:37, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote: The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option? No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
There are two uses of colon in math, as a relation (in sets \{ x : f(x) = 0 \} and in ratios A:B, etc) and as a punctuation ($f \colon A -> B, etc.[1]). Only one of them can be mapped to the literal :, the other must use a macro name. Knuth chose to map : to the relation and mapped \colon to a punctuation and every other macro package follows that convention.
Right. Perhaps he didn’t use functions much. :-)
It is easy to change the mapping, but if the mapping is reversed, is there is standard name for : as a relation?
It seems that “\:” might be used. I get an error when trying to use it in luatex. But note: In pure math, “:” is also used for projective coordinates, it does not seem to have operator spaces around them. This is what I think is the right look: https://en.wikipedia.org/wiki/Homogeneous_coordinates#Notation There is also Unicode ∶ RATIO U+2236. So a proposal might be to keep \colon, and make a new \ratio for those that want to use the operator : in ASCII. The : without spaces might perhaps be called \proj or something. Looking at https://en.wikipedia.org/wiki/Mathematical_Operators a UTF-8 mapping would be sending U+2236 to \ratio, the operator :. There is no special colon for the other uses, function and projective coordinates, it seems. So the \: might be mapped to \proj or \ratio according to taste.
On 20 Jul 2015, at 18:37, Aditya Mahajan
wrote:
It is easy to change the mapping, but if the mapping is reversed, is there is standard name for : as a relation?
Looking into a book on algebraic geometry, it seems fine to use operator : for projective coordinates. So skip the variation without spaces then. Then one might use two short commands : and \: that correspond, by an option, to \colon and \ratio. Unicode ∶ RATIO U+2236 should always be operator :, i.e. \ratio, then, though.
On 20 Jul 2015, at 18:37, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
It would be nice with such an option, as it helps the readability of the input files.
There are two uses of colon in math, as a relation (in sets \{ x : f(x) = 0 \} and in ratios A:B, etc) and as a punctuation ($f \colon A -> B, etc.[1]). Only one of them can be mapped to the literal :, the other must use a macro name.
It is easy to change the mapping, but if the mapping is reversed, is there is standard name for : as a relation?
It might be simplest to align towards Unicode and UTF-8, while retaining ASCII commands, avoiding a plethora of options: So one has the commands \colon for function “:" as is now, and the new \ratio for operator “:". Then Unicode ∶ RATIO U+2236 is mapped to the same as \ratio, which leaves : COLON U+003A the only possibility to be the same as \colon. Such an option might be called say colon=unicode, and be a part other similar options.
On 7/20/2015 6:06 PM, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
already for some years i'm thinking of something similar to openmath dictionaries i.e. in many cases when one writes math it is in some field that is consistent within a document, say logic or engineering it is rather trivial to support something \setupmathematics[domain=logic] or so, where we automatically relate the math class with the symbols used, something that becomes more important once we start coding in unicode instead of using names but ... in order to provide this, i need information about useful categories i had planned this for later this year but anyway uploaded a beta that has an experimental feature (this is something to discuss at the upcoming context meeting) \startluacode mathematics.registerdomain { name = "foo", parents = { "bar" }, characters = { [0x3A] = { char = 0x2236, class = "inner" } } } \stopluacode \startTEXpage $a: b$\par \setupmathematics[domain=foo]$a: b$\par \mathematics[domain=foo]{a: b}\par \definemathematics[foo][domain=foo]\mathematics[foo]{a: b}\par \stopTEXpage eventually we can consider a set of domains and a macro for defining a set of them etc but it all depends on use ... i'll upload a beta ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
[Note: I use the cc to know that I have received a reply.]
On 24 Jul 2015, at 10:30, Hans Hagen
wrote: On 7/20/2015 6:06 PM, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
already for some years i'm thinking of something similar to openmath dictionaries i.e. in many cases when one writes math it is in some field that is consistent within a document, say logic or engineering
it is rather trivial to support something
\setupmathematics[domain=logic]
or so, where we automatically relate the math class with the symbols used, something that becomes more important once we start coding in unicode instead of using names
but ... in order to provide this, i need information about useful categories
Unicode provides one such category. The reason is all math characters are added and in that process analyzed. I worked with Taco on that in the late 1990s. So one main option, which might be the simplest, to assume that the input is UTF-8. Oen can the added ASCII command names, based on the Unicode names. In addition some options for special needs and legacy.
On 7/24/2015 2:32 PM, Hans Aberg wrote:
[Note: I use the cc to know that I have received a reply.]
On 24 Jul 2015, at 10:30, Hans Hagen
wrote: On 7/20/2015 6:06 PM, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
already for some years i'm thinking of something similar to openmath dictionaries i.e. in many cases when one writes math it is in some field that is consistent within a document, say logic or engineering
it is rather trivial to support something
\setupmathematics[domain=logic]
or so, where we automatically relate the math class with the symbols used, something that becomes more important once we start coding in unicode instead of using names
but ... in order to provide this, i need information about useful categories
Unicode provides one such category. The reason is all math characters are added and in that process analyzed. I worked with Taco on that in the late 1990s.
So one main option, which might be the simplest, to assume that the input is UTF-8. Oen can the added ASCII command names, based on the Unicode names. In addition some options for special needs and legacy.
i don't understand what you mean as the issue is not unicode or ascii but categorizing symbols in classes when we have a symbol in the input (can be a : but also something else) in some cases it is a binary but in other cases a relation or whatever this influences the spacing and the 'domain' (or dictionaries) group symbols so that we can assign the right properties entering a utf sequence representing 0x2236 still doesn't always prescribe what mathclass it is, 0x22A5 0x22C5 0x25B3 are examples of such dual face characters (this is actually more important in for instance xml input) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 15:29, Hans Hagen
wrote: On 7/24/2015 2:32 PM, Hans Aberg wrote:
[Note: I use the cc to know that I have received a reply.]
On 24 Jul 2015, at 10:30, Hans Hagen
wrote: On 7/20/2015 6:06 PM, Hans Aberg wrote:
On 20 Jul 2015, at 16:40, Aditya Mahajan
wrote: On Mon, 20 Jul 2015, Hans Aberg wrote:
The LaTeX package unicode-math has an option colon=literal, which makes it behave as in math functions (as in example below). Has ConTeXt a similar option?
No. You have to use \colon.
It would be nice with such an option, as it helps the readability of the input files.
already for some years i'm thinking of something similar to openmath dictionaries i.e. in many cases when one writes math it is in some field that is consistent within a document, say logic or engineering
it is rather trivial to support something
\setupmathematics[domain=logic]
or so, where we automatically relate the math class with the symbols used, something that becomes more important once we start coding in unicode instead of using names
but ... in order to provide this, i need information about useful categories
Unicode provides one such category. The reason is all math characters are added and in that process analyzed. I worked with Taco on that in the late 1990s.
So one main option, which might be the simplest, to assume that the input is UTF-8. Oen can the added ASCII command names, based on the Unicode names. In addition some options for special needs and legacy.
i don't understand what you mean as the issue is not unicode or ascii but categorizing symbols in classes
Right, but that has in part already been done by Unicode. It is not really possible to classify math symbols from the the mathematical point of view, as every author in principle use their own notation.
when we have a symbol in the input (can be a : but also something else) in some cases it is a binary but in other cases a relation or whatever
Right. When TeX was written, there was only ASCII, so Knuth set “:” to the ratio binary operator, and the function “:” to \colon. Now, when Unicode is available, it sets the ratio binary operator to ≔ COLON EQUALS U+2254, leaving : COLON U+003A open for other uses. So set the latter to \colon, and add a command \ratio for the former.
this influences the spacing and the 'domain' (or dictionaries) group symbols so that we can assign the right properties
entering a utf sequence representing 0x2236 still doesn't always prescribe what mathclass it is, 0x22A5 0x22C5 0x25B3 are examples of such dual face characters
(this is actually more important in for instance xml input)
I was thinking of just having the two, \colon and \ratio. Looking into some books before electronic typesetting, the spacing of the latter can vary widely: some do not use spaces at all. So a set might look {x:x < a} instead of {x : x < a} But that would be a typographical issue, rather than semantic.
On 7/24/2015 4:08 PM, Hans Aberg wrote:
I was thinking of just having the two, \colon and \ratio. Looking into some books before electronic typesetting, the spacing of the latter can vary widely: some do not use spaces at all. So a set might look {x:x < a} instead of {x : x < a} But that would be a typographical issue, rather than semantic.
but we do need to deal with the typographic issue and unicode is not covering every symantic (otherwise we would have more) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 24 Jul 2015, at 16:26, Hans Hagen
wrote: On 7/24/2015 4:08 PM, Hans Aberg wrote:
I was thinking of just having the two, \colon and \ratio. Looking into some books before electronic typesetting, the spacing of the latter can vary widely: some do not use spaces at all. So a set might look {x:x < a} instead of {x : x < a} But that would be a typographical issue, rather than semantic.
but we do need to deal with the typographic issue
Yes, that is what I meant, typographic adjustments on top.
and unicode is not covering every symantic (otherwise we would have more)
It covers all standard symbols at the end of 1990s. Since then a number of symbols have come into use. There was a discussion about that on the Unicode list. Those using them might add them as well. But new characters are created, so there is a need for accessing them as well.
participants (4)
-
Aditya Mahajan
-
Hans Aberg
-
Hans Hagen
-
Manuel Blanco