[
  {
    "path": ".gitignore",
    "content": "output\nsubsuper-proposal.aux\nsubsuper-proposal.log\nsubsuper-proposal.out\nsubsuper-proposal.pdf\n"
  },
  {
    "path": ".travis.yml",
    "content": "email: false\nos: linux\nsudo: false\n\naddons:\n  apt:\n    packages:\n    - texlive-full\n\nscript: make travis\n\n"
  },
  {
    "path": "Makefile",
    "content": "MAIN=subsuper-proposal\n\npdf:\n\tlatexmk -pdf $(MAIN) -auxdir=output -outdir=output\n\ntravis:\n\t#Old latexmk doesn't understand auxdir and outdir options\n\tlatexmk -pdf -pdflatex='pdflatex %S %O -interaction=nonstopmode -halt-on-error' $(MAIN)\n\narxiv: pdf\n\tmkdir -p arxiv\n\tcp -ivR figures/*/* output/*.bbl *.tex arxiv\n\techo Fix paths to images before continuing\n\t#Test build\n\tcd arxiv && latexmk -pdf $(MAIN) -auxdir=crap -outdir=crap && rm -rf crap\n\tcd arxiv && zip arxiv.zip *\n\nclean:\n\trm -rvf *.bbl *.blg *.aux *.fls *.fdb_latexmk *.log *.out *.toc $(MAIN).pdf aux output arxiv\n\n"
  },
  {
    "path": "README.md",
    "content": "# Unicode Proposal to Encode Subscripts/Superscripts for Mathematical Programming\n\nThis is a draft proposal to encode additional subscript and\nsuperscript characters in future versions of Unicode, motivated mainly\nby computer programming for technical applications.\n\nMany programming languages (C#, Go, Java, Julia, Python, Rust, Swift, etc.) now\nallow identifiers to use a wide array of Unicode characters, which enables\nprograms in mathematical fields to use notations that closely hew\nto the original mathematical notations.  e.g. one can now have variable names\nlike `x̂` or `αₓ`.   Unfortunately, this opportunity is hampered by\na lack of subscript and superscript characters in Unicode 9.  (Most\nfamously, there are superscript characters for every lowercase Latin\nletter *except q*.)\n\nWe believe that, given the recent explosion of Unicode support in\nprogramming languages (and editors), the time is ripe to propose\nbetter support for mathematical subscripts/superscripts in Unicode.\n\nOur proposal is to add [combining characters](https://en.wikipedia.org/wiki/Combining_character), *mathematical subscript* and *mathematical superscript*, that indicate that the previous glyph (a character + combining characters) should be rendered in sub/superscript form.   Fonts can then implement these characters as \"ligatures\" for selected characters, so that e.g. an \"A\" followed by \"mathematical subscript\" would render as a subscript \"A\".\n\n## How you can help\n\nFirst, we welcome comments on this proposal (in the form of issues or\npull requests): corrections, references to notable\nsources/applications, and technical comments.\n\nSecond, we suspect that it will be easier to get the Unicode\nConsortium to take us seriously if prominent authors, organizations,\nfree/open-source projects, and companies can sign on to this proposal\n(as co-authors or endorsers).\n\nThird, it will greatly strengthen the proposal if we can commit to\nproviding draft fonts or (for new combining characters) the necessary\nimprovements to text-rendering software, so experts in those areas are\nwelcome.\n"
  },
  {
    "path": "subsuper-proposal.tex",
    "content": "\\documentclass[10pt,english]{article}\n\\usepackage[T1]{fontenc}\n\\usepackage[utf8]{inputenc}\n\\usepackage{geometry}\n\\geometry{verbose,lmargin=1in,rmargin=1in}\n\\usepackage{babel}\n\\usepackage{mathrsfs}\n\\usepackage{amsbsy}\n\\usepackage{amssymb}\n\\usepackage[unicode=true]{hyperref}\n\n\\usepackage{fouriernc}\n\\usepackage[T1]{fontenc}\n\n\\usepackage{todonotes} %XXX REMOVE ME WHEN DONE\n\\newcommand{\\TODO}[1]{\\todo[inline]{#1}}\n\n\\makeatletter\n\n\\usepackage{upgreek}\n\\usepackage{cite}\n\n\\newcommand{\\Secref}[1]{Section~\\ref{sec:#1}}\n\\newcommand{\\secref}[1]{Sec.~\\ref{sec:#1}}\n\n\\makeatother\n\n\\begin{document}\n\n\\title{Proposal to Encode Subscripts/Superscripts\\\\\nfor Use in Programming-Language Source Code}\n\n\n\\author{\nDr.\\ Jiahao Chen, AI Research Director, JPMorgan AI Research and Research Scientist, MIT CSAIL\n\\and\nProf.\\ Alan Edelman, MIT Department of Mathematics\n\\and\nProf.\\ Steven G.\\ Johnson, MIT Department of Mathematics\n\\and\nStefan Karpinski, Chief Open Source Officer, Julia Computing Inc.\n}\n\n\\maketitle\n\n\n\\TODO{%\n.... add other endorsers here --- we don't want to turn this into\nan Internet petition, but endorsements from well-known developers,\norganizations, open-source projects, and companies, could be helpful\n}\n\n\\abstract{Widespread Unicode support in programming-language parsers now allows software developers in technical fields to use notations like Greek letters and sub/superscripts \\emph{in their source code} that closely follow standard mathematical notations. This development has been hampered by the fact that only a subset of Latin and Greek characters have sub/superscript codepoints in Unicode 13, and so we propose to expand the set of sub/superscript characters to encompass common mathematical usage, ideally by simply adding two new combining characters.}\n\n\n\\section{Summary}\n\\label{sec:summary}\n\nMany recent programming languages (including C\\#~\\cite{Csharp}, Fortress~\\cite{Fortress},\nGo~\\cite{Go}, Java~\\cite{Java}, Julia~\\cite{Julia}, Python~3~\\cite{Python}, Scala\\cite{Scala}, and Swift\\cite{Swift}) allow\na broad range of Unicode characters to be employed \\textbf{in source code} by the programmer\nfor identifiers (names of functions and variables), and indeed such\nbehavior is recommended by the \\emph{Unicode Standard Annex~\\#31}~\\cite{UAX31}.\nFor programmers working in mathematical fields, including statistics,\nscience, and engineering, where a wide array of mathematical notations\nand symbols are commonplace, this often enables computer programs\nto be written in a notation that closely mimics standard mathematical\ndescriptions. For example, in a mathematical context one might easily\nhave a quantity with a name like $\\hat{x}$ or $\\alpha_{x}$, and\nthe same names can now be used in computer programs for this quantity\n($\\mathrm{\\hat{{x}}}$ = U+0078 U+0302, $\\mathrm{{\\upalpha_{x}}}$\n= U+03B1 U+2093) rather than ASCII approximations such as \\texttt{xhat}\nand \\texttt{alpha\\_x} that are used in older programming languages.\nFurthermore, Unicode-capable \\emph{code-editing software} has made it easy\nfor programmers to type such symbols by ``tab completion''\n(e.g. typing ``$\\mathrm{{\\upalpha_{x}}}$''\nas \\texttt{\\textbackslash{}alpha}\\texttt{\\emph{{[}tab{]}}}\\texttt{\\textbackslash{}\\_x}\\texttt{\\emph{{[}tab{]}}})\nor related techniques in several popular editors~\\cite{vsCode,Atom,Emacs,Sublime,Vim}\nand interactive-programming environments~\\cite{Julia,IPython}. This\nis an important and positive trend. To quote a 2001 draft of \\emph{Unicode\nTechnical Report~\\#25}~\\cite[section 5.3]{UTR25}, \\emph{Using real\nmathematical expressions in computer programs would be far superior\nin terms of readability, reduced coding times, program maintenance,\nand streamlined documentation.}\n\nOne notation that is extremely common throughout all of mathematics\nis the use of subscripts and superscripts. Unfortunately, Unicode\n13.0 provides only a very limited selection of subscript and superscript\ncharacters (digits 0--9, parentheses, $+$/$-$/$=$, a subset of\nthe Latin and Greek alphabets, and a few phonetic symbols). Therefore,\\textbf{\nwe propose that Unicode be extended to encode all the subscript/superscript\ncharacters most commonly used in mathematical notation}: all lower-\nand upper-case Latin and Greek letters (and variants thereof) and\na selection of other mathematical symbols described below. Because\nthese are all derived from existing Unicode codepoints, the assignment\nof their properties and the development of their fonts will be straightforward.\nAs one possible implementation strategy, we suggest that the Consortium\n\\textbf{add two new ``mathematical subscript'' and ``mathematical\nsuperscript'' combining characters} that convert the preceding character\n(or character + combining characters) into a sub/superscript. (This is\nclosely related to the superscript and ``scientific\ninferiors'' features already present in OpenType~\\cite{OpenType}.)\nAlthough the combining-character approach is potentially very general, it could\ninitially be suggested that the new combining characters may be ignored\nexcept following a limited subset of characters commonly used in\nmathematical notation (similar to how the emoji skin-tone modifiers only affect\nrendering of a small set of emoji characters with skin-tone variants).\n\nWe should mention that there were past proposals to extend the range\nof subscript and superscript characters in Unicode~\\cite{L2-10-230,L2-11-208}\n(neither of which mentioned mathematical or programming applications)\nthat were rejected. We have been unable to find an official record\nof the grounds for rejection of these proposals, but there seem to\nbe two common objections in discussions of this topic on Unicode forums~\\cite{Miller10,UCDF}.\nFirst, that this is \\emph{mere ``text presentation''}\ndevoid of semantic content, which is better accomplished via markup\nlanguages like MathML or other typesetting technologies such as the OpenType MATH table. Second, that\nthe set of characters that deserve sub/superscript variants is unclear\nand might be subjected to never-ending extension. We believe that\nboth of those objections must be re-evaluated in light of mathematical\nprogramming. First, subscripts and superscripts of any kind in mathematics\nalways have semantic content ($\\mathrm{{\\upalpha_{x}}}$ is very different\nin meaning from $\\mathrm{\\upalpha\\mathrm{{x}}}$). More importantly, \\textbf{programming\nlanguage source code is almost invariably restricted to ``plain text''}---in\nordinary usage, computer code (and especially identifiers) cannot\nbe intermingled with MathML markup or other formatting metadata---with\na few exceptions such as Mathematica~\\cite{Mathematica} that are\nedited and/or rendered mainly within specialized software. Finally,\nthe restriction to\n\\emph{common mathematical notations} greatly limits the scope\nof the additions, excluding the vast majority of Unicode characters\nfrom consideration.\n\nIt is not practical to encode the full range of mathematical\nnotations in Unicode; MathML and similar will always be useful,\nand generally should not be combined with Unicode-based formatting.\nHowever, in programming contexts, where non-Unicode math formatting\nis unavailable, increasing the set of available subscripts\nand superscripts is a ``low-hanging fruit'' that would be tremendously\nbeneficial in technical fields. We respectfully urge you to expand the\nset of mathematical subscripts and superscripts, and especially to\neliminate frustrating omissions from the Latin and Greek alphabets.\n\n\n\\section{Suggested Subscript/Superscript Characters}\n\\label{sec:required}\n\nThe following existing Unicode codepoints are widely used in subscripts and superscripts of mathematical notation, and should therefore have new sub/superscript variants (ideally via combining characters as described below, which will allow the set of available characters to be expanded incrementally by font providers as described in \\secref{fonts}):\n\n\\begin{itemize}\n\n\\item Latin upper- and lower-case characters `a'--`z' (U+0061--007A) and `A'--`Z' (U+0041--005A). (See \\secref{existingchars} regarding the subset of these already present in Unicode as sub/superscripts.)\n\n\\item Greek upper- and lower-case characters `$\\upalpha$'--`$\\upomega$' (U+03B1--03C9) and `A'--`$\\Upomega$' (U+0391--03A9) as well as lunate epsilon `$\\upepsilon$' (U+03F5).   (See \\secref{existingchars} regarding the small subset of these already present in Unicode as sub/superscripts.)\n\n\\item Decimal digits `0'--`9'  (U+0030--0039): these already have acceptable sub/superscript characters (U+2080--2089 and U+2070--2079), which should be canonically equivalent to the corresponding digit followed by a sub/superscript combining character as described below.\n\n\\item Common mathematical operators: `$+$` (U+002B), `$-$` (U+002D and U+2212), `$\\pm$' (U+00B1), `$*$' (U+002A), `$\\times$' (U+00D7), `/' (U+002F), `$=$' (U+003D), `$<$` (U+003C), `$>$' (U+003E).   Of these, `$+$', and `$-$', `$=$' already have acceptable sub/superscript characters (U+207A--207C and U+0208A--208C), which should be canonically equivalent to the corresponding character followed by a sub/superscript combining character as described below.\n\n\\item Other important mathematical symbols widely used in sub/superscript form: `$\\Vert$'  (U+2016), `$\\perp$' (U+27C2), `$\\infty$' (U+221E), `$\\dagger$' (U+2020), `$\\angle$' (U+2220).\n\n\\item Brackets: `(' and `)' (U+0028--0029),  `[ and `]' (U+005B and U+005D), `\\{' and `\\}' (U+007B and U+007D).   Of these, parentheses `()' already have acceptable sub/superscript characters (U+208D--208E and U+207D--207E), which should be canonically equivalent to the corresponding character followed by a sub/superscript combining character as described below.\n\n\\item Comma `,' (U+002C), colon `:' (U+003A), and semicolon `;' (U+003B).\n\n\\end{itemize}\n\n\\subsection{Relationship to existing sub/superscript letters}\n\\label{sec:existingchars}\n\nA subset of Latin and Greek letters already have sub/superscript variants in Unicode.  For example, `$^\\mathrm{a}$' is U+1D43 and `$_\\mathrm{a}$' is U+2090, while `$^\\mathrm{A}$' is U+1D2C but there is no subscript `A' character.   However, these codepoints seem to have been added piecemeal into the Unicode standard for a variety of semantic meanings unrelated to their usage in mathematical notation (e.g. `$^\\mathrm{a}$' is in the Latin-1 Supplement block, whereas `$^\\mathrm{k}$' is in the Phonetic Extensions block).  Therefore we suggest that these existing characters \\textbf{should not be canonically equivalent} to the proposed new mathematical sub/superscript characters (whether implemented by new codepoints or by combining characters).   However, the existing Latin and Greek sub/superscripts \\textbf{should at least be compatible} with the new characters because in a number of contexts (e.g. programming code where the existing superscripts are already in use) they should be interchangeable in practice.\n\nSeveral other proposed canonical equivalences are noted in \\secref{required}, above.\n\n\\section{Proposed new combining characters}\n\nWe believe that the simplest and most flexible way to support mathematical subscripts and superscripts would be to \\textbf{add two new combining characters}, ``MATHEMATICAL SUBSCRIPT'' and ``MATHEMATICAL SUPERSCRIPT,'' which would indicate that the \\textbf{preceding grapheme} should form a sub/superscript, respectively.   As mentioned in \\secref{summary}, text-rendering software might optionally display only a limited set of characters in sub/superscript form, following a recommended list such as the one in \\secref{required}, implemented as variant characters or ligatures (e.g. similar to emoji skin-tone variants) as described in \\secref{fonts}.\n\nBoth of these characters could be put into the general category Mn (nonspacing marks). Placing them in the nonspacing marks category would automatically allow the sub/superscript combining characters to be used following any valid identifier character in programming languages implementing \\emph{Unicode Standard Annex~\\#31}~\\cite{UAX31} or similar rules, since category Mn is included in the \\texttt{ID\\_Continue} lexical class of \\emph{Annex~\\#31}.  (That is, the languages would support the new combining characters automatically once their parsers are updated to use the new Unicode data tables, which typically happens within a reasonable interval after each Unicode revision.)   Alternatively, they could be added to category Sk (symbol modifiers), similar to the emoji skin-tone variants, with an amendment to \\emph{Annex~\\#31} adding them to \\texttt{ID\\_Continue}.\n\nThe new combining characters should have bidirectional class ``Other Neutrals (ON)'' and mirror class ``N'' similar to the emoji modifiers, with no upper/lowercase mapping, should be treated like other combining characters for line-breaking and collation, and should be allowed in identifiers as lexical class \\texttt{ID\\_Continue} as mentioned above.   Several  canonical equivalencies to existing sub/superscript characters are suggested in \\secref{required}.\n\nSome programming languages may further opt to allow additional sub/superscript mathematical symbols in identifiers on a case-by-case basis. For example, Julia~\\cite{Julia} already allows sub/superscript parentheses in identifiers (e.g. $\\upchi^{(3)}$ is a valid Julia identifier for a ``Kerr susceptibility'' in optics) so it might be natural in Julia to allow sub/superscript commas and asterisks (e.g. $\\mathrm{p}^*$ or $\\mathrm{p}_*$ may denote the ``primal optimum'' in convex-optimization problems).\n\n\\subsection{Alternative: Many new sub/superscript characters}\n\nThe alternative to adding new combining characters is to simply add new characters for the individual sub/superscripts proposed in \\secref{required}, which would then be treated similarly to existing sub/superscript characters.  They would be placed in general category Lm (modifier letter) for Latin and Greek letters, Ps/Pe (open/close punctuation) for brackets, Po (other punctuation) for comma and semicolon, and Sm (math symbol) for mathematical symbols.   The disadvantages of this approach are obvious: many new codepoints must be chosen and documented, and supporting additional mathematical sub/superscripts in the future will require additional revisions to the standard (as opposed to improvements in fonts or rendering software).\n\n\\section{Lack of Possible Equivalents}\n\nAs explained in \\secref{required}, Unicode currently contains only a subset of the most common mathematical subscripts and superscripts, and omits many Latin and Greek letters (e.g. there is no superscript `q' or subscript `A').  Furthermore, formatting/presentation markup like MathML, OpenDocument format (ODF), and similar typesetting/text-formatting technologies are \\textbf{not usable for source code} in programming languages, nearly all of which require ``plain text'' input with no XML or other formatting metadata.\n\n\\section{Provision of Fonts}\n\\label{sec:fonts}\n\nBecause the required glyphs are merely sub/superscript variants of existing characters, relatively little effort will be required to support the new combining characters for common mathematical usage. Common font editing software provides automated ways to take a set of glyphs and generate transformed variants by scaling them and shifting the baseline.  Having generated a sub/superscript glyph, e.g. a subscript `A', the font can then define a glyph substitution sequence indicating that `A' followed by the new subscript combining character will be rendered as a subscript-`A' \\emph{ligature}, e.g. using an OpenType glyph-substitution table~\\cite{opentypeGSUB}.  (Even if every glyph suggested in \\secref{required} is implemented in this way, it still represents only about 250 glyphs.)\n\nDraft versions of the proposed glyphs in \\secref{required} have already been implemented in the JuliaMono TrueType font~\\cite{juliamono}, and in collaboration with Stefan~Karpinski (co-author of this proposal) we plan to support the new combining character via these glyphs in JuliaMono if this proposal is accepted.\n\nIn the longer run, text-rendering software such as Microsoft DirectWrite, Apple Core Text, or the free/open-source HarfBuzz engine may choose to automate this process even for fonts\nlacking such substitution sequences.   While this would add flexibility and improve adoption, however, it is not required---\\emph{existing text rendering software would be sufficient} given a font\nproviding sub/superscript ligatures.\n\n\\section{Contact Information}\n\n\\TODO{``names and addresses of appropriate contacts\nwithin national body or user organizations''}\n\\begin{itemize}\n\\item Steven G. Johnson, MIT Room 2-345, 77 Massachusetts Ave. Cambridge,\nMA 02139.\n\n\\end{itemize}\n\\begin{thebibliography}{10}\n\n\\bibitem{Csharp}Microsoft Corporation, \\textit{C\\# Language Specification},\nversion 5.0, section 2.4.2 (2012).\n\n\\bibitem{Fortress}Sun Microsystems, Inc., \\textit{The Fortress Language\nSpecification}, version 1.0, \\url{http://www.ccs.neu.edu/home/samth/fortress-spec.pdf}\n(2008-03-31).\n\n\\bibitem{Go}The Go Authors, \\textit{The Go Programming Language Specification},\n\\url{https://golang.org/ref/spec} (2020-01-14).\n\n\\bibitem{Java}James Gosling, Bill Joy, Guy Steele, Gilad Bracha,\nand Alex Buckley, \\textit{The Java Language Specification: Java SE 8\nEdition}, section 3.8, \\url{http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html\\#jls-3.8}\n(2015-02-13).\n\n\\bibitem{Julia}The Julia Authors, \\textit{The Julia Programming Language\nManual}, \\url{http://docs.julialang.org/en/latest/manual/variables/}\n(retrieved 2016-08-25).\n\n\\bibitem{Python}Martin von L{\\\"o}wis, ``Python PEP 3131:\nSupporting Non-ASCII Identifiers,'' \\url{https://www.python.org/dev/peps/pep-3131/}\n(2007-05-01).\n\n\\bibitem{Scala}M.~Odersky \\textit{et al.}, \\textit{Scala Language Specification},\nversion 2.13, \\url{https://scala-lang.org/files/archive/spec/2.13/01-lexical-syntax.html}\n(2020-08-25).\n\n\\bibitem{Swift}Apple Inc, \\textit{The Swift Programming Language},\nversion 5.3, \\url{https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html}\n(2020-06-22).\n\n\\bibitem{UAX31}Mark Davis, \\textit{Unicode Standard Annex \\#31: Unicode\nIdentifier and Pattern Syntax}, version 13.0.0, \\url{https://www.unicode.org/reports/tr31/tr31-33.html}\n(2020-02-13).\n\n\\bibitem{vsCode}Unicode LaTeX plugin for the vsCode editor,\n\\url{https://marketplace.visualstudio.com/items?itemName=oijaz.unicode-latex}\n(retrieved 2020-08-24).\n\n\\bibitem{Atom}atom-latex-completions plugin for the Atom editor,\n\\url{https://github.com/JunoLab/atom-latex-completions}\n(retrieved 2020-08-24).\n\n\\bibitem{Emacs}\\TeX{} Input Method for the Emacs editor, \\url{https://www.emacswiki.org/emacs/TeXInputMethod}\n(retrieved 2020-08-24).\n\n\\bibitem{Sublime}UnicodeMath plugin for the Sublime editor, \\url{https://github.com/mvoidex/UnicodeMath}\n(retrieved 2020-08-24).\n\n\\bibitem{Vim}julia-vim plugin for the vim editor, \\url{https://github.com/JuliaLang/julia-vim}\n(retrieved 2020-08-24).\n\n\\bibitem{IPython}Brian E. Granger, ``Adds Julia-style\nlatex->unicode tab completion,'' \\textit{IPython pull\nrequest \\#6380}, \\url{https://github.com/ipython/ipython/pull/6380}\n(2014-08-28).\n\n\\bibitem{UTR25}Barbara Beeton, Asmus Freytag, and Murray Sargent\nIII, ``Proposed Draft Unicode Technical Report \\#25:\nUnicode Support for Mathematics'' \\url{http://www.unicode.org/unicode/reports/tr25/tr25-1.html} (2001-10-10).\n\n\\bibitem{L2-10-230}Karl Pentzlin, ``Proposal to encode\na modifier letter used in French abbreviations in the UCS,''\n\\url{http://www.unicode.org/L2/L2010/10230-modifier-q.pdf}\n(2010-07-13).\n\n\\bibitem{L2-11-208}ISO/IEC JTC1/SC35/WG1, ``Proposal\nto encode missing Latin small capital and modifier letters in the\nUCS,'' \\url{http://www.unicode.org/L2/L2011/11208-n4068.pdf}\n(2011-03-12).\n\n\\bibitem{Miller10}Eric Miller, ``Comment on L2-10-230,\nProposal to encode a modifier letter used in French abbreviations\nin the UCS,'' \\url{http://www.unicode.org/L2/L2010/10315-comment.pdf}\n(2010-08-09).\n\n\\bibitem{UCDF}``Superscript latin small letter q,''\ndiscussion on \\emph{The Unicode Consortium Discussion Forum}, \\url{http://www.unicode.org/forum/viewtopic.php?f=24&t=142}\n(2011) (retrieved at at \\url{https://web.archive.org/web/20151019072726/http://www.unicode.org/forum/viewtopic.php?f=24&t=142}  2020-08-24).\n\n\\bibitem{Mathematica}Stephen Wolfram, ``Mathematical\nNotation: Past and Future,'' \\url{http://www.stephenwolfram.com/publications/mathematical-notation-past-future/}\n(2000).\n\n\\bibitem{OpenType}Microsoft Corporation, ``Registered\nFeatures,'' \\emph{OpenType Specification}, version\n1.7 \\url{https://www.microsoft.com/typography/otspec/features_pt.htm\\#sinf}\n(2008-11-19). \n\n\\bibitem{opentypeGSUB}Microsoft Corporation, ``GSUB---Glyph Substitution Table,'' \\textit{OpenType Specification} \\url{https://docs.microsoft.com/en-us/typography/opentype/spec/gsub} (2018-08-15).\n\n\\bibitem{juliamono}``JuliaMono---A monospaced font for scientific and technical computing,'' \\url{https://cormullion.github.io/pages/2020-07-26-JuliaMono/} (2020-07-26).\n\n\\end{thebibliography}\n\n\\end{document}\n"
  }
]