xymostech / XymosTeX / 70
82%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 40
Run time 9s
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
70

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

Jobs
ID Job ID Ran Files Coverage
3 70.3 0
90.73
 Travis Job 70.3
Source Files on build 70
Detailed source file information is not available for this build.