Commit 79dd0f4
format: an SVG drawing can be any size you ask for (#87)
* format: byte counts are grouped in threes
A total printed as 2516582400 B. Eleven digits with nothing to hold on
to, and this tool prints byte counts everywhere - it is the whole point
of it, so the one number a person came for was the hardest to read.
It now prints 2 516 582 400 B, in every message that names bytes: the
minimum in tfg formats, the summary a run prints, what a preset says
its budget is, and what tfg validate reports.
A space rather than a comma. A comma is a thousands mark in some
countries and a decimal point in others, and this tool is read in both.
Machine output is untouched. Nothing in a manifest or under --json goes
through here, because a number there is a number rather than a
sentence, so no script anybody has written sees any of this.
One guard read the old shape and had to be taught the new one, and what
it said while it was wrong is worth keeping: it split the line on the
first space, read "1 220 B" as one byte, and reported that the tool
refuses the minimum it advertises. It was right about what it saw and
wrong about what it meant, which is what a parser splitting on the
wrong thing always is. Two tools outside this repository read the same
line and needed the same lesson.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix: teach three guards the grouped spelling they now read
CI went red on eight tests, all of them guards reading a byte count out
of the command line's own output. I had written in this branch's own
message that a change to a human sentence has a blast radius equal to
the number of things parsing it, and then shipped without running the
suite, so the branch proved its own point.
Three places, three different shapes:
- sizeText built the expected text with strconv.FormatInt, so it looked
for "36415" in a report saying "36 415 B" and found nothing. It asks
core.ExactBytes now, WITH the unit - which is stronger than what it
replaced rather than merely equal, because bare digits could match
inside a longer number and "36415" does match in "136415".
- The boundary announcement is pinned as literal text, so it moves to
the grouped spelling.
- The sizes a person writes are pinned as literal text as well, and
deliberately not asked of core.ExactBytes: that guard is over what a
PERSON reads, so the spelling is half of what it holds, and a guard
built from the same function the program prints with cannot tell the
two apart.
Every expected string was checked against what the program actually
prints rather than worked out by hand: 1 610 612 736 B, 10 485 760 B,
1 048 576 B, 716 800 B, 0 B, 15 728 640 B.
One subtest cannot run on this machine and it is not this change: 1.5gib
is refused with exit 6, the free space code, because the disk has 1.1 GB
left. The tool is behaving correctly and the runner has room.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* format: an SVG drawing can be any size you ask for
Two new settings on svg: width and height, a whole number of pixels from
1 to 20000 each. They default to the 800 by 600 these drawings have always
been, so a recipe that says nothing gets the same bytes it got before.
tfg generate --format svg --size 20kb --set width=1920 --set height=1080
There is no joint limit on the two, unlike the picture formats, because
nothing is drawn into pixels here - the file only says how big it is. That
makes a small file that claims to be enormous, which is the point: a 3 kB
drawing declaring 20000 by 20000 asks whether whatever opens it has a limit
on picture size and not only on file size.
The ceiling is not the renderer's. Measured headless: Inkscape draws 4295
megapixels in 165 s without complaint. The line worth crossing belongs to a
reader instead - Pillow refuses an image over 89478485 px as a decompression
bomb - and 20000 per axis reaches 400 megapixels, so a set can hold files on
both sides of it.
A drawing shorter than 57 pixels has no room for the label along its bottom
edge. It is still produced and still named, and the run says which files
those were.
Two defects the settings would otherwise have introduced, both invisible
while the dimensions were constants:
- the shape code assumed a margin of up to eighty units, and rand.IntN
panics on a non-positive argument, so a narrow canvas would have been a
panic on a value that looks entirely legal;
- a shape whose lower edge ran past the drawing would paint over the
label, which is the defect the strip along the bottom was added for in
the first place.
Both clamps are inert at 800 by 600 - the widest shape lands two units short
- so the stored byte hashes are unchanged and the guards press the sizes
where the clamps are not.
Four new guards, five new mutations, and four existing SVG mutations
repointed after the constants they aimed at became functions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* guard: compare the decoder's end of input with errors.Is
golangci-lint's errorlint rule refuses == against a sentinel error, because
it fails on a wrapped one. Reproduced locally with the pinned v2.13.2 rather
than read off the runner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>1 parent 39332d3 commit 79dd0f4
7 files changed
Lines changed: 555 additions & 62 deletions
File tree
- internal
- format/svgfile
- guard
- web/public
- formats
- pl/formaty
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
58 | 58 | | |
59 | 59 | | |
60 | 60 | | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
61 | 81 | | |
62 | 82 | | |
63 | 83 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
478 | 478 | | |
479 | 479 | | |
480 | 480 | | |
481 | | - | |
| 481 | + | |
| 482 | + | |
482 | 483 | | |
483 | 484 | | |
484 | 485 | | |
| |||
0 commit comments