xymostech / XymosTeX / 70 / 3
82%
master: 82%

DEFAULT BRANCH: master
Ran
Files 40
Run time 8s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 90.726% (+0.04%) from 90.685%
70.3

push

travis-ci-com

xymostech 
Keep track of scaled fonts

I realized that my support for fonts was not complete; instead of just
keeping track of the string name of a font, I also need to keep track
of whether a font is scaled. In order to make upcoming tests easier to
write, I'm planning on adding `\font` definitions, and I realized that
I will want to support scaled fonts when I do that, so this is the
initial step.

When I did this, I couldn't decide how to store the scale. One option
was to store it as just an integer scale factor which I computed when
the font was defined (i.e. natural would be 1000, `scaled` would be
stored as is, and `at` dimensions would be converted based on the
font's design size). Or, I could store the scale as the dimension that
the font should be rendered at (as a `Dimen`). Or alternatively, I
could store the different formats as exactly what is input and convert
them when they are used (e.g. an enum for natural size, scaled, or at
a certain dimension).

I would have liked to store the different formats separately in an
enum to aid in debugging and then just convert them to whatever form
was needed at usage time, but I ended up deciding to store the scale
as a `Dimen`, for a couple of reasons:

1. One of the main places that the font scale is used is when setting
   scale in a DVI font definition, which wants the size of the font in
   scaled points.

2. Also, when writing a DVI file we keep track of which fonts are used
   already so we can reuse a font definition. If I render a TeX file that has
```
\font\x=cmr10 scaled 1500
\x a
\font\x=cmr10 at 15pt
\x a
```
   we find that the same font definition is used for both 'a's, so TeX
   seems to not differentiate between the two formats when checking if
   it's seen a font already. Based on how I'm doing my hashing, it
   makes more sense to use a single type instead of an enum so that
   different, equivalent fonts are hashed the same and reuse the font
   definition.

3. I noticed that when doing e.g.... (continued)

5498 of 6060 relevant lines covered (90.73%)

2.18 hits per line

Source Files on job 70.3