Summary:
The ability to use pre-determined character widths will benefit alternative
layout engines such as gagern's canvas layout engine. I would also like to
experiment would using CSS transforms to absolutely position each glyph. This
diff adds a new make rule, make extended_metrics, which generates metrics that
also containing glyph widths.
Test Plan:
- run `make extended_metrics`
- verify that fontMetricsData.js contains entries with 5 numbers instead of 4
Reviewers: emily alpert
There are two main motivations for this commit. One is unicode input, which
requires unicode characters to get past the lexer. See discussion in #261.
The second is in preparation for #266, where we'd deal with one token of
look-ahead but might be lexing that token in an unknown mode in some cases.
The unit test shipped with this commit addresses the latter concern, since
it checks that a math-mode-only token may immediately follow some text mode
content group.
In this new implementation, all the various things that could get matched
have been collected into a single regular expression. The hope is that
this will be beneficial for performance and keep the code simpler.
The code was written with Unicode input in mind, including non-BMP codepoints.
The role of the lexer as a gate keeper, keeping out invalid TeX syntax, has
been abandoned. That role is still fulfilled by the symbols and functions
tables, though, since any input which is neither a symbol nor a command is
still considered invalid input, even though it lexes successfully.
Fixes issue #255.
Mixing the variable number of arguments a function receives from TeX code
with the fixed arguments which the parser provides can cause some confusion.
After this change, a handler will receive exactly two arguments: one is a
context object from which things provided by the parser can be accessed by
name, which allows for simple extensions in the future. The other is the
list of TeX arguments, passed as an array.
If we ever switch to EcmaScript 2015, we might want to use its destructuring
features to name the elements of the args array in the function head. Until
then, destructuring that array manually immediately at the beginning of the
function seems like a useful convention to easily find the meaning of these
arguments.
Having long object literals containing the code is problematic.
It makes it difficult to add auxiliary functions or data close to the
function inside the map where it is needed.
Building the map in several steps, repeating the map name at each step,
avoids that problem since it makes the definitions independent from one
another, so anything can go between them.
This commit deliberately avoided reindenting existing code to match the new
surroundings. That way it is easier to see where actual changes happen,
even when not performing a whitespace-ignoring diff.
Having one long array literal to contain the code of all environment
implementations is problematic. It makes it difficult to add auxiliary
functions or data close to the function inside the list where it is needed.
Now the functions are no longer defined using such a literal, but instead
using calls to a "defineEnvironment" function which receives all the
relevant data. Since each function call is independent from the others,
anything can go in between.
This commit deliberately avoided reindenting existing code to match the new
surroundings. That way it is easier to see where actual changes happen,
even when not performing a whitespace-ignoring diff.
Using function calls instead of one big object literal for the symbols makes
the notation far more concise and readable. Having the actual symbol name
in the last position helps aligning the preceding columns, making the list
easier to read.
Another benefit is that all symbol definitions now pass through a single
function, where additional processing (e.g. for Unicode input) might take
place in a future commit.
Since the previous commit deliberately avoided reindenting, this one here
does just that: reindenting the existing code. There are no other changes.
Notice how the new indentation leaves more room to function handlers.
Having one long array literal to contain the code of all function
implementations is problematic. It makes it difficult to add auxiliary
functions or data close to the function inside the list where it is needed.
Now the functions are no longer defined using such a literal, but instead
using calls to a "declareFunction" function which receives all the relevant
data. Since each function call is independent from the others, anything can
go in between.
This commit deliberately avoided reindenting existing code to match the new
surroundings. That way it is easier to see where actual changes happen,
even when not performing a whitespace-ignoring diff.
Also, the MathBb-chrome test changed, to what I believe is the correct
result? Not sure why it looked wrong before.
Test plan:
- `make test`
- take screenshots, see nothing changed.
This adds the ability to add `|` to a column description and have
vertical separators be added. I added types to the column descriptions
and added some logic to handle the separators when building the vertical
lists of the array.
Test plan:
- See the Arrays screenshot looks good.
- `make test`
The dependencies of fonttools are much lighter than fontforge, and since all
we need are some metrics, fonttools is very much up to that task.
This addresses issue #288.
We had some duplicate mappings in mappings to start with. Now we have some
code to complain loudly about these, and all currently existing duplicates
have been dealt with.
We also had a problem where in some Python dict, existing stuff was using
strings as keys while new data would use numeric indices, thus not
overwriting the previous value. Now we always use strings as keys.
Along the road, the italic dotless i and j symbols were changed
so that they now are taken from cmmi10 instead of cmti10.
This will make reviewing modifications easier, since the affected glyphs
will be more readily visible in the diff.
The formatting tool was applied to the existing data, instead of
regenerating the data, so the semantic content should be unmodified.
This separates auto-generated code from manually created code.
We need a more recent version of browserify to directly require JSON.
Note that the data was copied, not recreated, so it has not been changed.
This addresses issue #301.
This adds \lgroup, \rgroup, \lmoustache and \rmoustache,
provides \lVert and \rVert with the correct type for each,
and makes \lvert, \rvert, \lVert and \rVert available
through \left...\right.
A fraction is surrounded by a box of width \nulldelimiterspace on either side.
That size is 1.2pt and does not scale with the style or font size.
Furthermore, a \frac creates a brace-enclosed group which results in a
\mathord, not a \mathinner.
