We use arrow functions in most places; this enforces it.
Passing arrow functions to Mocha is discouraged: https://mochajs.org/#arrow-functions
This was a mix of autofixes and hand adjustments.
* add support for rgb, rgb, css named colors
* add support for hsl, hsla & add color-validate
* update makeBadge test, better coverage
* re-add comment
* add comment for supported colors
* dynamic badge gen, remove 'hex'
* add support for 1.0 opacity & fix 101-109
* fix colorscheme tests
* remove extra tests
* add test for negative values
* add test for uppercase & mixed case colors
* fix mixed case/uppercase test
* allow whitespace around color
* update test error messages
* add comments
* add more uppercase test
* update error message
* default to grey/red if invalid color chosen
default colorscheme:
colorA: grey
colorB: red
* Revert "default to grey/red if invalid color chosen"
This reverts commit 10db0c6d74.
Reverted as this affects the CLI version/when no color specified.
* validColor -> isCSSColor
* assignColor function
* update tests to use sazerac
- Avoid mutating the inputs
- Declare all the input and output keys
- Avoid recomputing escapeXml on the same values
- Capitalize social badge labels before measuring
Ref: #1379
This takes a naive approach to font-width computation, the most compute-intensive part of rendering badges.
1. Add the widths of the individual characters.
- These widths are measured on startup using PDFKit.
2. For each character pair, add a kerning adjustment
- The difference between the width of each character pair, and the sum of the characters' separate widths.
- These are computed for each character pair on startup using PDFKit.
3. For a string with characters outside the printable ASCII character set, fall back to PDFKit.
This branch averaged 0.041 ms in `makeBadge`, compared to 0.144 ms on master, a speedup of 73%. That was on a test of 10,000 consecutive requests (using the `benchmark-performance.sh` script, now checked in).
The speedup applies to badges containing exclusively printable ASCII characters. It wouldn't be as dramatic on non-ASCII text. Though, we could add some frequently used non-ASCII characters to the cached set.
