How to find the width of a symbol?
I’m writing this (long!) answer because I kind of promised CarLaTeX that I would do. I apologize for the long delay, but I simply couldn’t find the time to complete it until now.
There are several methods that permit to find out the width, height, and depth of a given character, the simplest of which is to use the commands \settowidth
, \settoheight
, and \settodepth
, respectively, which are defined by the LaTeX2e kernel and are described in a variety of sources, ranging from Lamport’s LaTeX – A Document Preparation System (see p. 216) to the answers to the question Retrieve length of a character, already cited in a comment to the present question (but see also Get width of a given text as length; other duplicates exist). Another viable approach, provided that you know the font from which the character in question is drawn, is to look up the required information in the TFM (TeX Font Metric) file of that font, after converting it to its textual representation, a PL (Property List) file.
This question, however, is not an exact duplicate of the abovementioned ones, in that it involves math and asks to express the required length (the width, in this case) in math units. I think that a brief digression is needed, here, in order to give some background information. After that, we’ll be able not only to get a better understanding of the methods hinted at above, but also to ask ourselves the fundamental question: “Is this ability of measuring character widths in math units of any practical utility?”—and to tell, alas, that in all probability the answer is “No”.
Background
Most of TeX’s units of measure are absolute, in the sense that they correspond to a fixed physical dimension (e.g., 1 point = 1/72.27 inches = roughly 0.351460 millimeters); but some of them, on the other hand, are relative, in that they are specified in terms of another dimension linked to some font. Perhaps better-known examples of units of the latter type are em
and ex
, but math units (mu
) are of this kind too. More precisely (cf. The TeXbook, p. 168), 1mu
= 1/18 of 1em
, where the measure of 1em
is taken from the font used for the symbols
math group (in NFSS parlance; it is equivalent to TeX’s “family 2
”), which, in the configuration set up by the LaTeX2e kernel, corresponds to cmsy10
in \displaystyle
and \textstyle
, to cmsy7
in \scriptstyle
, and to cmsy5
in \scriptscriptstyle
; note that the value assigned to the base measure of 1em
varies with the current math style, and this is precisely why, and how, math units scale with the current style as well.
The following points, though, should be kept in mind:
Since the effective width of a math unit depends on a parameter linked to the
symbols
font, and since the actual external font that is used for this purpose can (and usually does) vary if you choose different math fonts, it could well happen that the width of a symbol, when expressed in math units, changes even if the symbols in itself stays the same also in the new math setup for fonts. For instance, we’ll present below a situation in which, after loading thenewtxmath
package, we ensure, with a stratagem, that the symbol used for\vartriangleright
doesn’t change at all (not only it’s always taken from the same slot in themsam
font family, as it would ordinarily be the case even without any special expedient, it also retains exactly the same size as when thenewtxmath
package is not loaded), but its width measured in math units varies notwithstanding, in the script and scriptscript styles, exactly because of the different length of the math unit.Even if you don’t change the kernel’s setup for the math fonts, and although, as we have just said, math units do scale according to the current math style, there is no guarantee that the width of a symbol remains the same, when measured in math units, in passing, say, from
\textstyle
to\scripstyle
; indeed, we’ll see below that it typically changes, even for symbols taken from the same font family as the one from which the math unit itself is derived—thecmsy
family, for instance.
These two remarks entail that, given a problem as the one this question arose from, every solution that relies on kerning amounts that are specified in the code as literal, precomputed values is virtually doomed to break down sooner or later, although the problem described in 2 could be sidestepped with the help of \mathchoice
.
Use of \settowidth
(and of \widthof
) with math
We won’t dwell on the general usage of the \settowidth
, \settoheight
, and \settodepth
commands, nor on that of the companion commands \widthof
, \heightof
, \depthof
, \totalheightof
, and \settototalheight
, that are made available by the calc
package: as already said, there are plenty of sources of information about their usage. It is perhaps worth remarking, though, that when you want to measure the width of a math symbol, you shouldn’t forget to reset, locally, the \mathsurround
parameter. Recall that TeX can be instructed to insert a certain amount of kerning before and after each math formula: this happens precisely when the value of \mathsurround
is not zero at the end of a formula, in which case it gives the amount of kerning that should be applied to that particular formula. In LaTeX, \mathsurround
is typically equal to zero, but this could not always be the case (indeed, this parameter exists precisely because the house styles of certain publishers require that math formulas be typeset with this extra kerning). So, instead of writing just
\settowidth{\mylength}{$\vartriangleright$}
it’s much better, and safer, to write
\settowidth{\mylength}{$\mathsurround=0pt \vartriangleright$}
instead, lest you include the extra kerning in your measurement. The change to \mathsurround
is local to the group implied by $...$
(and \settowidth
actually supplies another group around it), so it won’t spoil the value that has been set for this style parameter in the rest of the document.
Both plain TeX and LaTeX define the abbreviation \m@th
for \mathsurround=0pt
, so you can actually write
\settowidth{\mylength}{$\m@th\vartriangleright$}
provided, of course, that you execute the statement in a context where the @
character is interpreted as a letter (e.g., between \makeatletter
and \makeatother
).
As the answers to the abovementioned question Get width of a given text as length explain, the trick of typesetting something into a temporary box, and then asking for the width of that box by means of the \wd
primitive, as in @CarLaTeX’s answer, is precisely what the \settowidth
command does internally; so, the above remark about \mathsurround
applies to this technique as well: you should say
\sbox0{$\mathsurround=0pt \vartriangleright$}\showthe\wd0
(or
\sbox0{$\m@th\vartriangleright$}\showthe\wd0
if applicable) to guard against an unusual (i.e., non-null) setting of this parameter.
Asking TeX to measure your symbol
With the precautions just outlined about \mathsurround
, it is possible to write a small program that measures, and then reports, the width of a given symbol in math units; we’ll use a program of this kind to prove the claims we’ve set forth above. The following points should be noted about the code we are going to present:
The command named
\WidthInMathUnitsOf
can be used only in contexts in which TeX is typesetting text, but not in the so-called “purely expandable contexts”; this means, among other things, that it cannot be used inside the argument of certain commands, and in particular inside the argument of\typeout
(not even if you\protect
it).Therefore, you can use a command like
\WidthInMathUnitsOf
to have the measured width reported directly in print amid the typeset text, but not on the terminal.If, on the other hand, your intent is not just to have the width reported, but you want to use the measured value directly in your code for some purpose (for example, you want to pass it as an argument to the
\mspace
command), probably the best strategy is to use a declaration like our\SetToWidthInMathUnits
, that stores the result in a control sequence, in the form of a string of decimal digits, from where it can subsequently be retrieved by means of pure expansion (you must add the unit of measure, that is,mu
).Both
\WidthInMathUnitsOf
and\SetToWidthInMathUnits
compute their result using e-TeX’s\dimexpr
extension: this is not the same as using the original TeX’s primitives\multiply
and\divide
, because e-TeX stores the intermediate result as a 64-bit value, whereas, with the original TeX, you’d almost surely get an “arithmetic overflow” error (unless you play some trick that, however, would severely affect the precision of the result).
Here’s the code (it must be compiled with pdflatex
):
% My standard header for TeX.SX answers:
\documentclass[a4paper]{article} % To avoid confusion, let us explicitly
% declare the paper format.
\usepackage[T1]{fontenc} % Not always necessary, but recommended.
% End of standard header. What follows pertains to the problem at hand.
% \usepackage{newtxtext,newtxmath}
\usepackage{amsmath}
\usepackage{amssymb}
% % Uncomment the following line of code to undo (but only for "\normalsize",
% % which in this document means 10 points) the change made to the math sizes by
% % the "newtxmath" package:
% \DeclareMathSizes{10}{10}{7}{5}
\makeatletter
\def\do#1{\@ifdefinable#1{\newdimen#1}}
\do\@TempWidthOne
\do\@TempWidthTwo
\newcommand*\WidthInMathUnitsOf[2]{%
\settowidth\@TempWidthOne{$\m@th #1#2$}%
\settowidth\@TempWidthTwo{$\m@th #1\mspace{1mu}$}%
\strip@pt \dimexpr \@TempWidthOne*\p@/\@TempWidthTwo \relax
}
\newcommand*\SetToWidthInMathUnits[3]{%
\settowidth\@TempWidthOne{$\m@th #2#3$}%
\settowidth\@TempWidthTwo{$\m@th #2\mspace{1mu}$}%
\edef #1{%
\strip@pt \dimexpr \@TempWidthOne*\p@/\@TempWidthTwo \relax
}%
}
\newcommand*\ExtractHexDigitOfFamilyOfSymbol[1]{%
\expandafter\@ExtractHexDigitOfFamily \meaning #1% must be a cs token
}
\@ifdefinable\@ExtractHexDigitOfFamily{
\def\@ExtractHexDigitOfFamily#1"#2#3#4#5{#3}
}
\makeatother
\newcommand*{\ReportWidthsOf}[1]{%
\par
\begingroup
\setlength{\abovedisplayskip}{\smallskipamount}%
\indent
Width of $#1$
(\texttt{\string #1}, \emph{i.e.}, \texttt{\meaning #1})
in:%
\begin{align*}%
% \ReportWidthFor\displaystyle {#1}\\%
\ReportWidthFor\textstyle {#1}\\%
\ReportWidthFor\scriptstyle {#1}\\%
\ReportWidthFor\scriptscriptstyle{#1}%
\end{align*}%
\endgroup
}
\newcommand*{\ReportWidthFor}[2]{%
\texttt{\string #1}&=
\texttt{\WidthInMathUnitsOf #1{#2}mu}%
}
\newcommand*{\ReportValueOfOneEm}[1]{%
&\text{in #1 size,}%
&\quad\texttt{1em}%
&=\texttt{\the \fontdimen 6 \csname #1font\endcsname 2}%
&&\qquad\text{(from \texttt{\fontname \csname #1font\endcsname 2})}%
}
\newcommand*{\ReportSizeOfFontOfSymbol}[2]{%
&\texttt{\pdffontsize\csname #2font\endcsname
"\ExtractHexDigitOfFamilyOfSymbol{#1}}%
&&\quad\text{in #2 size}%
&\qquad(\texttt{\string\fontname}%
&=\texttt{\fontname\csname #2font\endcsname
"\ExtractHexDigitOfFamilyOfSymbol{#1}})%
}
\newcommand*{\ReportSizeOfMSAMFont}{%
\ReportSizeOfFontOfSymbol{\vartriangleright}%
}
\newcommand*{\mytemp}{} % just declare the name
\begin{document}
% \show\defaultscriptratio
\ReportWidthsOf{\oplus}
\ReportWidthsOf{\wedge}
\ReportWidthsOf{\vartriangleright}
Note that \verb|\vartriangleright| now means \texttt{\meaning\vartriangleright},
but that the external font which corresponds to
family~\texttt{"\ExtractHexDigitOfFamilyOfSymbol{\vartriangleright}} remains
\texttt{\fontname\textfont"\ExtractHexDigitOfFamilyOfSymbol{\vartriangleright}}
(in text size). On the other hand, the external font linked to the
\texttt{symbols} font family is currently \texttt{\fontname\textfont2} (again in
text size), in which \( \texttt{1em} = \texttt{\the \fontdimen6 \textfont2} \).
More generally, for this \texttt{symbols} font family it turns out that:
%
\begin{alignat*}{3}
\ReportValueOfOneEm{text};\\
\ReportValueOfOneEm{script};\\
\ReportValueOfOneEm{scriptscript}.
\end{alignat*}
%
But---surprise!\@---the packages that configure the math fonts sometimes
redeclare the math sizes for the script and scriptscript styles (for example,
the \texttt{newtxmath} package does so), and this affects also the sizes at
which the fonts of the \texttt{msam} family are loaded. Indeed, in the present
run those fonts are loaded at the following sizes:
%
\begin{alignat*}{3}
\ReportSizeOfMSAMFont{text};\\
\ReportSizeOfMSAMFont{script};\\
\ReportSizeOfMSAMFont{scriptscript}.
\end{alignat*}
%
% Use the computed width in the argument of another command:
\SetToWidthInMathUnits{\mytemp}{\textstyle}{\vartriangleright}
% \show\mytemp
Now \verb|\mytemp| is \texttt{\mytemp}, and can be used in the argument of
another command:\\
X[$\vartriangleright$]X\\
X[$\mspace{\mytemp mu}$]X
\end{document}
If you compile this code as it stands, Computer Modern fonts will be used, and you’ll get the following output:
On the other hand, if you uncomment the line that says
% \usepackage{newtxtext,newtxmath}
the “newtx” fonts will be used instead, and the output will be
We see that, although the symbol for \vartriangleright
is always taken from the same source (namely, slot ”42
of the msam
font family), in the script sizes its width, expressed in math units, is significantly different than it was before. This, however, is in part a false clue, because the newtxmath
package slightly alters the ratios between the math size used for the main symbols and those used for scripts and double scripts, and this affects also the sizes at which the msam7
and msam5
fonts are loaded, as the output shows. For this reason, you have a third option: if you—after enabling the “newtx” fonts as we just did—uncomment the following line of code
% \DeclareMathSizes{10}{10}{7}{5}
the changes that the newtxmath
package applied to the math sizes are undone (but only for formulas that get typeset in \normalsize
). In this case, the output looks like this:
Note that, even in this case, the ntxsy7
font is loaded at 7.0pt
, that is, not at its nominal design size (which, as we’ll see below, is 10pt), and a similar remark applies to ntxsy5
as well. On the other hand, the msam7
and msam5
fonts are loaded at their design size (7pt and 5pt, respectively), exactly as they were in our first experiment; this proves beyond any doubt that the difference in the widths of \vartriangleright
(Computer Modern experiment: 13.72888mu
in \scriptstyle
, 13.24544mu
in \scriptscriptstyle
; this experiment: 16.07161mu
in \scriptstyle
, 19.50072mu
in \scriptscriptstyle
) is purely due, at least in this case, to the shrinkage of the math unit.
Looking up the measure in TFM files
Instead of asking TeX to find it out, you could also look up the required measure directly in the TFM (TeX Font Metric) file of the font that contains the character in question; of course, we are assuming here that this font is a “classic” TeX font, as it will be always the case if you are using a “classic” engine (TeX or pdfTeX). Keep in mind, however, that in TFM files all character-related dimensions are expressed in relative units, with one relative unit equaling the size at
which the font is loaded by TeX; and that, by default, TeX loads each font at its design size, which is also specified in the TFM file for the font. In order to show how to handle the conversion from these relative units to absolute ones both in the case of a font loaded at its design size, and in the case of a font loaded at a custom size (specified with an at
clause), we choose to exemplify the process of measuring the width, in math units, of the \vartriangleright
character when used in \scriptstyle
with the “newtx” fonts, but with our “math-size-reverting” stratagem in force (cf. the third of our experiments, above): this will involve a font loaded at its design size (msam7
) and a font, namely ntxsy7
, loaded at 7.0pt
, the latter being the font that supplies the width of one math unit.
The first thing you need to do is to convert the relevant TFM files to their human-readable counterpart, a PL (Property List) file; this is much like disassembling an object code file into a human-readable text file. So, move to a clean directory of your choice and type the following at the shell prompt:
tftopl msam7.tfm msam7.pl
tftopl ntxsy7.tfm ntxsy7.pl
The tftopl
utility should automatically pick up the .tfm
files from your TEXMF tree, and save the corresponding .pl
files in the local directory.
Next, open the msam7.pl
file in any text editor; its first lines should read
(FAMILY MSAM V2.2)
(FACE O 360)
(CODINGSCHEME TEX MATH SYMBOLS)
(DESIGNSIZE R 7.0)
(COMMENT DESIGNSIZE IS IN POINTS)
(COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
(CHECKSUM O 27035367067)
The lines that says
(DESIGNSIZE R 7.0)
tells (as you can expect!) that the design size of this font is 7.0pt; in the case of the code we posted above, this is also the size at which this font is loaded. Therefore, all subsequent sizes shown in the msam7.pl
file must be multiplied by 7.0pt in order to find their actual, absolute value. Now, scroll down in the msam7.pl
file until you find the lines
(CHARACTER O 102
(CHARWD R 0.892861)
(CHARHT R 0.565615)
(CHARDP R 0.075675)
)
This is the description of the character whose number is 102
when expressed in octal (O
) notation, which is the same as 42
in hexadecimal; so, it is precisely the character that corresponds to \vartriangleright
, as we saw above. Its width is given by the real (R
) number that follows the CHARWD
keyword; multiplying this number (0.892861
) by 7.0pt we obtain the absolute width, 6.250027pt.
Now we have to find out the width of one math unit in \scriptstyle
: this is 1/18 of the width of 1em in the ntxsy7
font. So, we open ntxsy7.pl
, and find that it begins like this:
(FAMILY UNSPECIFIED)
(FACE F MRR)
(CODINGSCHEME TEX MATH SYMBOLS)
(DESIGNSIZE R 10.0)
(COMMENT DESIGNSIZE IS IN POINTS)
(COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
(CHECKSUM O 31601054554)
(SEVENBITSAFEFLAG TRUE)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.0)
(STRETCH R 0.0)
(SHRINK R 0.0)
(XHEIGHT R 0.441)
(QUAD R 1.0)
(EXTRASPACE R 0.0)
(NUM1 R 0.677)
(NUM2 R 0.394)
(NUM3 R 0.444)
(DENOM1 R 0.686)
(DENOM2 R 0.345)
(SUP1 R 0.413)
(SUP2 R 0.363)
(SUP3 R 0.289)
(SUB1 R 0.15)
(SUB2 R 0.247)
(SUPDROP R 0.386)
(SUBDROP R 0.05)
(DELIM1 R 2.39)
(DELIM2 R 1.01)
(AXISHEIGHT R 0.257)
)
We learned from our experiment, above, that this font is loaded at 7.0pt
, not at its design size (which, according to the DESIGNSIZE
line, is 10.0pt even if this is meant to be—or, better, to be used as—a “7-point” font). So, it turns out that the amount by which the relative dimensions given in the rest of the file should be multiplied is again 7.0pt, albeit for a different reason than before. To get the measure of 1em we have to look at the QUAD
item inside the FONTDIMEN
list: we read
(QUAD R 1.0)
so we obtain that 1em = 1.0 × 7.0pt = 7.0pt (as the output of our experiment said); then, 1mu = 7.0pt/18 = 0.388889pt.
Finally, dividing 6.250027pt by 0.388889pt we find that the width of \vartriangleright
in math units is 16.07149. In our experiment, a width of 16.07161mu
was reported: the difference, 0.00012mu, is equivalent to roughly 0.00005pt, or about 3sp, and is therefore fully accounted for by rounding errors.
Furthermore, it should be remarked that in a case like this, in which both fonts are loaded at the same size, the step of converting the sizes to absolute units (in our example, multiplying them by 7.0pt) is obviously superfluous.
If you are interested in learning the whole story on how to read, and write, PL files, type
texdoc pltotf
at a command-line prompt and read sections 7–14 of the document that is put up (5 pages).
Conclusions
I hope that the foregoing discussion has exhaustively shown that the method of overprinting two symbols, in order to build a composite one, by means of a suitable backspace specified in the code as a literal, precomputed amount given in terms of math units is far from being robust enough to be deployed in any general-purpose application, and can, at most, be considered adequate for an ad-hoc solution. Probably, the idea underlying the use of math units was the belief that an amount specified in terms of these units would automatically scale down in the script and scriptscript styles, but we’ve seen that this is not at all the case. In principle, it would be possible to replace the literal precomputed amount with an amount calculated at run-time, also taking the current math font configuration into account; but this solution couldn’t withstand comparison with the \ooalign
method, in that:
it would entail replicating at the level of the TeX interpreter more or less the same computations that the
\halign
primitive, which\ooalign
invokes, would perform at the machine-code level of the host computer;it would not avoid the recourse to
\mathchoice
(that the\ooalign
approach requires in order to behave properly).
In conclusion, \ooalign
is the way to go in solving this kind of problem.
Since egreg doesn't want to get 15 points for free (@yo'), I'll try to answer by myself.
The width of the symbol, of course, depends on the font you're using.
To find the actual width (in points) you can use \sbox0{$<your_symbol>$}
(adding \showthe\wd0
to print it in the log file), and divide it by the width (in points) of 1 math unit, \sbox0{$\mspace{1mu}$}
.
In this way you'll find the width of your symbol in math units and you can easily calculate the correct kerning to apply.
\sbox
is like \savebox
with no optional arguments, see, for example, here for its use with \wd
.
In the example, with \sbox0{$\vartriangleright$}\showthe\wd0
in the log file you'll read 7.7778pt.
With \sbox0{$\mspace{1mu}$}\showthe\wd0
in the log you'll read 0.55554pt.
With \sbox0{$\circ$}\showthe\wd0
in the log you'll read 5.00002pt.
Hence the width of $\vartriangleright$
in math units is 7.7778/0.55554=14, and, since you have a -18.5 math units to compensate (and $\circ$
is shorter, 9 math units), the correct kerning is 18.5-14=4.5.
In this way it's possible to find a solution equivalent to the ones with \stackengine
or \ooalign
.
For more info about \stackengine
macro see the documentation of the gorgeous Steven's package, subsection 2.3.1.
Some detailed explanation about \ooalign
can be found in this - as always great - egreg's answer.
In the following code, I've added some \vline
s to show to alignment more clearly.
Edit:
As Gustavo pointed out, the solution with \mspace
does not remain the same in passing from \textstyle
to \scriptstyle
or to \scriptscriptstyle
. First of all, {..}
is needed around \vartriangleright
, otherwise, the new symbol is messed up in that passage. However, the \circ
becomes misaligned:
\documentclass{article}
\usepackage{amsmath, amssymb, stackengine}
\newcommand{\stsym}{\mathbin{\ensurestackMath{%
\stackengine{0pt}{\vartriangleright}{\circ\mkern3.5mu}{O}{c}{F}{T}{L}}}}
\newcommand{\oosym}{\mathbin{\ooalign{$\vartriangleright$\cr$\mkern.5mu\circ$\cr}}}
\newcommand{\mssym}{\mathbin{{\vartriangleright}\mspace{-13.5mu}\circ\mspace{4.5mu}}}
\begin{document}
\begin{tabular}{ll}
Only \textbackslash\texttt{vartriangleright} for bechmark:
&
$a\vline\mathbin{\vartriangleright}\vline b$
\\
Steven's solution (with \textbackslash\texttt{stackengine}):
&
$a\vline\stsym\vline b$
\\
Solution with \textbackslash\texttt{ooalign}:
&
$a\vline\oosym\vline b$
\\
Solution with \textbackslash\texttt{mspace} and the correct kerning:
&
$a\vline\mssym\vline b$
\\
Original example of the question:
&
$a\vline\mathbin{\vartriangleright\mspace{-18.5mu}\circ\mspace{3.5mu}}\vline b$
\\
\end{tabular}
\vspace{10pt}
\begin{tabular}{ll}
Example in \textbackslash\texttt{scriptstyle}:& \\
Only \textbackslash\texttt{vartriangleright} for bechmark:
&
$x_{a\vline\mathbin{\vartriangleright}\vline b}$
\\
Steven's solution (with \textbackslash\texttt{stackengine}):
&
$x_{a\vline\stsym\vline b}$
\\
Solution with \textbackslash\texttt{ooalign}:
&
$x_{a\vline\oosym\vline b}$
\\
Solution with \textbackslash\texttt{mspace} and the correct kerning:
&
$x_{a\vline\mssym\vline b}$
\\
Original example of the question:
&
$x_{a\vline\mathbin{\vartriangleright\mspace{-18.5mu}\circ\mspace{3.5mu}}\vline b}$
\\
\end{tabular}
\sbox0{$\vartriangleright$}\showthe\wd0
\sbox0{$\mspace{1mu}$}\showthe\wd0
\sbox0{$\circ$}\showthe\wd0
\end{document}
Output:
Log messages:
> 7.7778pt.
l.30 \sbox0{$\vartriangleright$}\showthe\wd0
> 0.55554pt.
l.31 \sbox0{$\mspace{1mu}$}\showthe\wd0
> 5.00002pt.
l.32 \sbox0{$\circ$}\showthe\wd0
This stackengine
approach does not remove the need to manually calculate a shift (since a glyph's sidebearings are unknowable without examination).
However, this approach does simplify things in that the stacked item (in this case the shifted \circ
) will not affect the underlying math spacing of the \mathbin{\vartriangleleft}
. This effect is brought about because the \useanchorwidth
parameter 7 of the \stackengine
call is set T
rue.
\documentclass{article}
\usepackage{amsmath, amssymb,stackengine}
\newcommand\mysym{\mathbin{\ensurestackMath{%
\stackengine{0pt}{\vartriangleright}{\circ\mkern3.5mu}{O}{c}{F}{T}{L}}}}
\begin{document}
\[
a \mysym b
\]
\end{document}