A BMP, a TIFF or a WebP cut short loses the share of its picture asked for

CHANGELOG.md

@@ -16,6 +16,12 @@ because it turns other people's test suites red.
 
 ### Breaking
 
+- **A TIFF of an odd size is not byte for byte what 0.5.0 wrote.** Its
+  directory, which says where the pixels are, came last and so started on an
+  odd byte, where the TIFF specification has it start on an even one. Every
+  reader tried took it, but a strict one may not. It now stands right after
+  the eight byte header, and the pixels are the same. A TIFF of an even size is
+  unchanged.
 - **Some AVIF pictures and WebM and MP4 films are not byte for byte what
   0.5.0 wrote.** The AV1 encoder underneath, gav1d, is now 0.2.6. Where the
   right or bottom edge of a picture cuts through a block, the encoder now
@@ -87,8 +93,8 @@ because it turns other people's test suites red.
   outcome is `unspecified`, offers both answers in the new `policy_options`
   field and says why. `tfg damage <id>` lists those formats.
 - **A file cut short says where the cut fell and how much of its content is
-  left.** In some formats a large file is mostly padding beside its content,
-  so a cut can take all of the content or none of it. The `truncate` entry in
+  left.** A file of a few kilobytes cut by 1% or 2% can lose less of its
+  content than that, or none of it. The `truncate` entry in
   the manifest's `damage` now carries `cut`: `in` (`content`, `padding`,
   `structure` or `end`) and `content_kept_bytes`, and `content_bytes` where
   the length of the content is known. A cut in the padding also gets the
@@ -138,6 +144,13 @@ because it turns other people's test suites red.
   cut. Chrome and Firefox stop a cut MP4 with an error and end a cut WebM
   without one. The manifest of a cut WebM now says how long its pictures are,
   where it said nothing. Films nothing cuts are unchanged.
+- **`truncate` cuts the picture of a BMP, a TIFF or a WebP by the percentage
+  you set, also when you set its width and height.** With a small picture in a
+  large file, a cut used to take only padding and leave a WebP whole, or take
+  the whole picture of a BMP or a TIFF. Now `--damage truncate:missing=50`
+  removes half of the pixels. Pillow shows the rows left of a cut BMP or TIFF,
+  and Preview on a Mac opens a cut TIFF without a warning. Files nothing cuts
+  are unchanged.
 
 - **tfg is on npm, for tests in Node.**
   `npm install --save-dev testing-files-generator` gives Playwright, Vitest

README.md

@@ -522,11 +522,12 @@ how many more there are, and the manifest lists every one. The label is still
 written before the damage, so the damage can overwrite it, and the manifest does
 not promise it is there.
 
-In most formats `truncate` removes the same percentage of the content as of the
-file: `missing=50` leaves about the top half of a PNG's picture, half of a WAV's sound
-or half of a text's lines, the way an interrupted upload does. In some formats a
-large file is mostly padding beside its content, so a cut there can take all of the
-content or none of it. The manifest says where each cut fell: the `truncate` entry
+`truncate` removes the same percentage of the content as of the file:
+`missing=50` leaves about the top half of a PNG's picture, half of a WAV's sound
+or half of a text's lines, the way an interrupted upload does. A file of a few
+kilobytes cut by 1% or 2% can lose less of its content than that, or none of it
+when the cut falls in what the format puts after the content, such as a ZIP's
+list of its files. The manifest says where each cut fell: the `truncate` entry
 carries `cut`, with `in` (`content`, `padding`, `structure` or `end`) and
 `content_kept_bytes`, and with `content_bytes`, how long the content of the whole
 file is, where that is known. A cut in the padding also gets the note

internal/damage/truncate.go

@@ -49,17 +49,23 @@ func init() {
 				Min: fewestMissing, Max: mostMissing,
 				Default: strconv.Itoa(defaultMissing),
 				// The last two sentences are what a person cannot see from the
-				// outside. In most formats the cut removes the same percentage
-				// of the picture, sound or text, png among them since it lays
-				// its padding out for the cut. In the rest the padding stands
-				// only on one side of the content, so a large file cut at any
-				// share keeps all of it or none (docs/TRUNCATE-2026-11-11.md
-				// section 7.1, and notYetCutAtTheShare in internal/guard for
-				// which). The manifest says per file where the cut fell.
+				// outside. Every format lays its padding out for the cut, so the
+				// cut removes the same percentage of the content
+				// (docs/TRUNCATE-2026-11-11.md sections 7 to 15, and
+				// TestACutTakesTheShareOfTheContentItIsAskedFor). In a file of
+				// a few kilobytes it can take less: a WebP with less than 26 B
+				// of padding cannot put any in front of its picture and keeps up
+				// to that much more of it, and where what a format puts after
+				// its content - the central directory of a ZIP or an Office
+				// document, that WebP's padding - is longer than a cut of 1% or
+				// 2%, the cut falls in it and leaves the content whole
+				// (docs/TRUNCATE-2026-11-11.md section 15.4, measured in
+				// docs/REVIEW-244-2026-11-14.md). The manifest says per file
+				// where the cut fell.
 				Detail: "How much of the whole file is gone, as a percentage. " +
 					"At least this much is cut - a few bytes more where the format cannot end exactly there. " +
-					"In most formats the cut removes the same percentage of the content. " +
-					"In some, a large file is mostly padding beside its content, so the cut can take all of the content or none - " +
+					"The cut removes the same percentage of the content - of the picture, the sound, the pages or the text. " +
+					"A file of a few kilobytes cut by 1% or 2% can lose less of its content than that, or none of it when the cut falls in what the format puts after the content, such as a ZIP's list of its files - " +
 					"the manifest says what each cut left.",
 			},
 		},

internal/format/bmp/bmp.go

@@ -105,6 +105,9 @@ type memo struct {
 	label         string
 	// gap is how many bytes sit between the header and the pixel data.
 	gap int64
+	// back is how many bytes of padding follow the pixels, only in a file
+	// laid out for a cut (splitForACut).
+	back int64
 }
 
 // stride is the length of one row on disk. Every row is rounded up to a
@@ -150,6 +153,9 @@ func (generator) Plan(r format.Request) (format.Plan, error) {
 	}
 
 	m := memo{width: w, height: h, seed: r.Seed, label: label, gap: r.Bytes - bare}
+	if r.CutAt > 0 {
+		splitForACut(&m, r.Bytes, r.CutAt)
+	}
 
 	p := format.Plan{
 		Bytes:       r.Bytes,
@@ -290,18 +296,24 @@ func (generator) Write(ctx context.Context, w io.Writer, p format.Plan) error {
 	}
 
 	// The map, all of it known from the plan: the two headers, the gap that
-	// makes up the size, and the pixels. The gap stands BEFORE the pixels.
+	// makes up the size, and the pixels. The gap stands BEFORE the pixels,
+	// and in a file laid out for a cut the rest of the padding behind them.
+	pixels := pixelBytes(m.width, m.height)
 	format.Mark(w, format.RoleStructure, 0, headers)
 	format.Mark(w, format.RolePadding, headers, m.gap)
-	format.Mark(w, format.RoleContent, headers+m.gap, pixelBytes(m.width, m.height))
+	format.Mark(w, format.RoleContent, headers+m.gap, pixels)
+	format.Mark(w, format.RolePadding, headers+m.gap+pixels, m.back)
 
 	if err := writeHeaders(w, m, p.Bytes); err != nil {
 		return err
 	}
 	if err := writeGap(ctx, w, m.seed, m.gap); err != nil {
 		return err
 	}
-	return writePixels(ctx, w, m)
+	if err := writePixels(ctx, w, m); err != nil {
+		return err
+	}
+	return writeGap(ctx, w, m.seed+1, m.back)
 }
 
 func writeHeaders(w io.Writer, m memo, total int64) error {

internal/format/bmp/cut.go

@@ -0,0 +1,20 @@
+package bmp
+
+import "github.com/donislawdev/TestingFilesGenerator/internal/format"
+
+// splitForACut splits the padding of a BMP around its pixels for a cut after
+// its first cutAt bytes (format.Request.CutAt), so that the cut keeps the
+// share of the pixels it keeps of the whole file: in front of them, in the gap
+// bfOffBits points past, as much as the share wants, and the rest behind them,
+// where no field points. It is raw bytes on either side, so every length
+// lands. Ten decoders give the pixels of a BMP nothing cuts from the gap split
+// and from all of it behind, Go's x/image/bmp only with no gap in front - it
+// refuses every BMP with one (docs/TRUNCATE-2026-11-11.md section 15.3).
+//
+// A BMP nothing cuts keeps all of its padding in front, byte for byte what it
+// was (D11).
+func splitForACut(m *memo, total, cutAt int64) {
+	pad := m.gap
+	m.gap = format.SplitFront(pad, headers, pixelBytes(m.width, m.height), cutAt, total, 1)
+	m.back = pad - m.gap
+}

internal/format/tiff/cut.go

@@ -0,0 +1,73 @@
+package tiff
+
+import (
+	"context"
+	"io"
+
+	"github.com/donislawdev/TestingFilesGenerator/internal/format"
+)
+
+// layOut says where a TIFF's directory and padding go. A TIFF a damage will cut
+// is laid out for the cut (splitForACut). One of an odd size puts its directory
+// right behind the header, with all of its padding still in front of the
+// pixels: TIFF 6.0 starts a directory on a word boundary, and last, where the
+// 172 B of the directory and its values end the file, it would start on an odd
+// byte (O342). Nine decoders give the same pixels from that layout
+// (docs/TRUNCATE-2026-11-11.md section 15.3). The rest keep the directory last.
+func layOut(m *memo, total, cutAt int64) {
+	switch {
+	case cutAt > 0:
+		splitForACut(m, total, cutAt)
+	case total%2 == 1:
+		m.directoryFirst = true
+	}
+}
+
+// splitForACut lays a TIFF out for a cut after its first cutAt bytes
+// (format.Request.CutAt), so that the cut keeps the share of the pixels it
+// keeps of the whole file.
+//
+// The directory and the values it points at move up to right behind the
+// header. TIFF 6.0 lets the directory stand anywhere after the header on a
+// word boundary, and byte 8 is one. Left last, it is the end of the file: 172
+// B that a cut of 1% of a file of a few kilobytes falls in. The padding then
+// goes around the pixels - in front of them as much as the share wants, the
+// rest behind them, where no field points. It is raw bytes on either side, so
+// every length lands. Nine decoders give the pixels of a TIFF nothing cuts
+// from the directory first with the padding in front, split and behind, and
+// exiftool reads it (docs/TRUNCATE-2026-11-11.md section 15.3).
+//
+// A TIFF nothing cuts keeps its directory last and its padding in front, byte
+// for byte what it was (D11).
+func splitForACut(m *memo, total, cutAt int64) {
+	pad := m.gap
+	m.directoryFirst = true
+	m.gap = format.SplitFront(pad, header+directory+heap, pixelBytes(m.width, m.height), cutAt, total, 1)
+	m.back = pad - m.gap
+}
+
+// writeDirectoryFirst writes a TIFF whose directory follows its header - one
+// laid out for a cut, or one of an odd size: the header, the directory and its
+// values, the padding in front, the pixels and the padding behind.
+func writeDirectoryFirst(ctx context.Context, w io.Writer, m memo) error {
+	head := int64(header + directory + heap)
+	pixels := pixelBytes(m.width, m.height)
+	format.Mark(w, format.RoleStructure, 0, head)
+	format.Mark(w, format.RolePadding, head, m.gap)
+	format.Mark(w, format.RoleContent, head+m.gap, pixels)
+	format.Mark(w, format.RolePadding, head+m.gap+pixels, m.back)
+
+	if err := writeHeader(w, m); err != nil {
+		return err
+	}
+	if err := writeDirectory(w, m); err != nil {
+		return err
+	}
+	if err := writeGap(ctx, w, m.seed, m.gap); err != nil {
+		return err
+	}
+	if err := writePixels(ctx, w, m); err != nil {
+		return err
+	}
+	return writeGap(ctx, w, m.seed+1, m.back)
+}

internal/format/tiff/pixels.go

@@ -0,0 +1,93 @@
+package tiff
+
+import (
+	"context"
+	"image"
+	"image/color"
+	"io"
+
+	"github.com/donislawdev/TestingFilesGenerator/internal/format/imagelabel"
+)
+
+// writePixels streams the picture a row at a time.
+//
+// Only the label band is ever built as an image, and it is at most 24 rows
+// tall whatever the picture is. Everything else comes from the formula
+// straight into one reused row buffer, so a 64 MiB picture costs a row rather
+// than 64 MiB.
+//
+// A TIFF stores its rows top down, so the label band is written first - the
+// one place this is simpler than BMP, which stores them the other way up.
+func writePixels(ctx context.Context, w io.Writer, m memo) error {
+	row := make([]byte, m.width*samplesPerPixel)
+	off := int(m.seed % 256)
+
+	band := labelBand(m, off)
+	bandH := 0
+	if band != nil {
+		bandH = band.Bounds().Dy()
+	}
+
+	for y := 0; y < m.height; y++ {
+		if y%64 == 0 {
+			select {
+			case <-ctx.Done():
+				return ctx.Err()
+			default:
+			}
+		}
+		if y < bandH {
+			copyBandRow(row, band, y, m.width)
+		} else {
+			fillRow(row, y, m.width, off)
+		}
+		if _, err := w.Write(row); err != nil {
+			return err
+		}
+	}
+	return nil
+}
+
+// fillRow writes one row of the gradient in the order a TIFF wants it: red,
+// green, blue.
+func fillRow(row []byte, y, width, off int) {
+	for x := 0; x < width; x++ {
+		row[x*3] = uint8((x + off) % 256)
+		row[x*3+1] = uint8((y + off) % 256)
+		row[x*3+2] = uint8((x + y + off) % 256)
+	}
+}
+
+func copyBandRow(row []byte, band *image.RGBA, y, width int) {
+	for x := 0; x < width; x++ {
+		i := band.PixOffset(x, y)
+		row[x*3] = band.Pix[i]
+		row[x*3+1] = band.Pix[i+1]
+		row[x*3+2] = band.Pix[i+2]
+	}
+}
+
+// labelBand rasterises the top strip of the picture, label included, or
+// returns nil when there is no label to draw.
+func labelBand(m memo, off int) *image.RGBA {
+	if m.label == "" || !imagelabel.Fits(m.width, len(m.label)) {
+		return nil
+	}
+	h := maxBandHeight
+	if m.height < h {
+		h = m.height
+	}
+	img := image.NewRGBA(image.Rect(0, 0, m.width, h))
+	for y := 0; y < h; y++ {
+		for x := 0; x < m.width; x++ {
+			img.SetRGBA(x, y, color.RGBA{
+				R: uint8((x + off) % 256),
+				G: uint8((y + off) % 256),
+				B: uint8((x + y + off) % 256),
+				A: 255,
+			})
+		}
+	}
+	imagelabel.Draw(img, m.label)
+	return img
+}