Files
vectorcraft/crates
bflatasticandClaude Opus 5.5 a303add775 Fix #498: EPS colour images whose inks are read in turn aren't banded
Illustrator CS and later write a colour image (in their own and in every
CS-to-CC compatibility format) with one data source per ink: four
procedures that each read one row of their ink from the same file, as
`image` calls them in turn (C, M, Y, K, C, M, Y, K …). The reader drained
each source on its own, so the cyan plane took the first rows of all four
inks and the image came in as sheared horizontal bands (the map in #498).

- Image data sources are read in turn: a procedure once a round, a file or
  string a row a round, until each plane is full or its source ends.
  Single sources, filters over procedures and masked images share the same
  reader (`read_sources`); a string source starts each round where it left
  off without walking it from its start.
- Tests: CMYK procedures reading one file (dictionary form) and RGB ones
  (`colorimage` operand form), separate string sources, rows padded to a
  byte at 1, 2, 4, 12 and 16 bits with an odd width (one and several
  sources), PNG predictors of every row filter at an odd width. The first
  fails without the fix; the others pin down the stride rules the report
  suggested. The import fuzz vocabulary has several sources reading one
  file and sources of uneven lengths.
- Checked against EPS saved here by Illustrator 2026 with an embedded
  1001 × 667 RGB raster (and grey and RGBA ones, in RGB and CMYK
  documents, compatibility formats 3, 8, 10, CS6 and 2026): the 10, CS6 and
  2026 ones came in banded and now match the source image; those files
  aren't committed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 21:15:18 +07:00
..