xls-codec 2.0.2 → 3.0.0

package/README.md

@@ -18,7 +18,7 @@ Under active development, with real, tested **read and write** support. Built an
 - **Formula text recovery** (`src/biff/ptg.ts`, `src/biff/ptg-functions.ts`) — a Formula record's compiled `rgce` token stream ([MS-XLS] 2.5.198's `Ptg` vocabulary) read and rebuilt into the infix text a spreadsheet application would show: literal operands (`PtgInt`/`PtgNum`/`PtgStr`/`PtgBool`/`PtgErr`/`PtgMissArg`), cell and range references including their 3D (cross-sheet) forms (`PtgRef`/`PtgArea`/`PtgRef3d`/`PtgArea3d`, `$`-qualified per their own relative/absolute flags, a 3D reference's sheet name resolved through `EXTERNSHEET` and a self-referencing `SupBook` — `src/workbook/globals.ts`'s own `sheetRanges`), every arithmetic/comparison/unary/percent operator and explicit parentheses, and function calls through both `PtgFunc` (fixed arity, resolved from a curated table of [MS-XLS]'s own Ftab grammar) and `PtgFuncVar` (variable arity, its own on-disk `cparams`) — see "Formula expressions" under Read-side gaps below for the exact boundary of what this does not resolve.
 - **Schema mapping** — `readXlsContent`/`readXls` (`src/content.ts`) as before, now also populating `ContentSheetCell.formula` wherever the Ptg reader above resolves it; `writeXlsContent`/`writeXls` (`src/write.ts`) the counterpart, taking a `ContentDocument`/`DocumentTree` of `kind: 'spreadsheet'` and producing genuine `.xls` bytes: a real BIFF8 `Workbook` stream (globals substream, one worksheet substream per sheet, `BoundSheet8.lbPlyPos` patched to each sheet's real byte offset once every substream's length is known) wrapped in a real [MS-CFB] compound file via `archive-codec`'s `writeCompoundFile`.
 - **Document metadata** — `title`/`subject`/`author`/`keywords`/`createdIso`/`modifiedIso` read from a `"\x05SummaryInformation"` stream when one is present, and written back to one whenever the input's metadata carries anything that stream can hold (see [Metadata](#metadata)).
-- **Cell decoration** — a cell's background fill (solid pattern only) and per-side borders, read from and written to `XF`'s trailing `CellXF` payload plus the workbook's own `Palette` record, in both directions and verified against real LibreOffice-produced BIFF8, not just this package's own round trip (see [Cell decoration](#cell-decoration)).
+- **Cell decoration** — a cell's background fill (every named `FillPattern` value, solid and pattern alike) and per-side borders, read from and written to `XF`'s trailing `CellXF` payload plus the workbook's own `Palette` record, in both directions and verified against real LibreOffice-produced BIFF8, not just this package's own round trip (see [Cell decoration](#cell-decoration)).
 - **Print settings** — every field of `ContentSheetPrintSettings`: page size and orientation, all four margins, gridline and row/column-header printing, page order, print scale or fit-to-page counts, manual page breaks, the print range, and the repeated header rows and columns — read from and written to the nine worksheet-substream records and the two built-in defined names that carry them, in both directions and verified against real LibreOffice-produced BIFF8 (see [Print settings](#print-settings)).
 - **Cell alignment** — a cell's own horizontal (`left`/`center`/`right`/`justify`) and vertical (`top`/`middle`) alignment, read from and written to `XF`'s trailing `CellXF`/`StyleXF` payload's own leading word, in both directions and verified against real LibreOffice-produced BIFF8 (see [Cell alignment](#cell-alignment)).
 
@@ -26,7 +26,7 @@ Verified primarily by round trip (`src/write.test.ts`, plus a dedicated `test/wo
 
 ### Writer scope
 
-What `writeXlsContent`/`writeXls` cover: every `ContentCellValue` kind a real `.xls` can hold (`number`, `percentage`, `currency`, `boolean`, `date`, `time`, `dateTime`, `string`, `error`; an `empty` cell is written as a `Blank` record when it carries formatting and as nothing at all when it does not — see below), merged ranges (`colSpan`/`rowSpan`), row heights and hidden rows, column widths and hidden columns, multiple sheets, explicit and default number formats, a shared string table deduplicated across the whole workbook, every field of a sheet's own [print settings](#print-settings), a cell's own [alignment](#cell-alignment), and — see [Cell decoration](#cell-decoration) — a cell's own solid background fill and per-side borders, deduplicated across the workbook the same way number formats are. What it deliberately does not:
+What `writeXlsContent`/`writeXls` cover: every `ContentCellValue` kind a real `.xls` can hold (`number`, `percentage`, `currency`, `boolean`, `date`, `time`, `dateTime`, `string`, `error`; an `empty` cell is written as a `Blank` record when it carries formatting and as nothing at all when it does not — see below), merged ranges (`colSpan`/`rowSpan`), row heights and hidden rows, column widths and hidden columns, multiple sheets, explicit and default number formats, a shared string table deduplicated across the whole workbook, every field of a sheet's own [print settings](#print-settings), a cell's own [alignment](#cell-alignment), and — see [Cell decoration](#cell-decoration) — a cell's own background fill (solid or a genuine two-colour pattern) and per-side borders, deduplicated across the workbook the same way number formats are. What it deliberately does not:
 
 | Not written                                                                                                        | Why                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -46,7 +46,7 @@ Column widths round-trip to the nearest pixel Excel's own integer-pixel-grid qua
 Each deliberate rather than overlooked:
 
 - **Formula expressions, mostly recovered.** A `Formula` record's compiled `Ptg` token stream (`src/biff/ptg.ts`) is walked and rebuilt into real formula text — literal operands, cell/range references (`$`-qualified, including 3D cross-sheet references resolved through `EXTERNSHEET` and a self-referencing `SupBook`), every arithmetic/comparison/unary/percent operator, explicit parentheses, and both fixed- and variable-arity function calls, resolved by name against [MS-XLS]'s own built-in function table (`src/biff/ptg-functions.ts`, covering the whole published table — [MS-XLS] 2.5.198.17 — cited to that table's own `iftab` index; PtgFunc's fixed argument count is a curated subset of it, since PtgFunc's own token carries no count and only a function [MS-XLS]'s grammar states a fixed, non-optional arity for is resolved through it, empirically confirmed against real LibreOffice-written BIFF8 rather than assumed from the grammar alone). Three constructs remain genuinely unresolved, each leaving `ContentSheetCell.formula` absent for that cell specifically rather than fabricating text: a **shared formula** (`PtgExp`, whose real expression lives in a separate `ShrFmla` record this reader does not yet join), an **array formula** (`PtgArray`, whose literal values live in a separate `PtgExtraArray` trailer this reader does not yet parse), and a **genuinely external workbook** reference (a `SupBook` naming another file, a DDE/OLE data source, or an add-in, rather than this same workbook) — each is real, meaningfully separate work, not an oversight. A defined name (`PtgName`/`PtgNameX`) and a natural-language "Elf" reference are likewise not resolved, for the same reason `Lbl` (defined names) is not read at all yet (see below).
-- **Cell decoration and alignment resolved for real; font still not.** `XF`'s trailing `CellXF` payload's fill pattern/colour and per-side border style/colour are read and resolved through the `Palette` record (or the default colour table when one is absent) — see [Cell decoration](#cell-decoration) for the full mapping, the fill-pattern-beyond-solid judgment call, and how this was verified against real LibreOffice-produced BIFF8. The same payload's leading word is resolved too — see [Cell alignment](#cell-alignment) for the full `alc`/`alcV` mapping. `Font` records are not read at all: `ContentSheetCell` has no cell-level font field, and `ooxml.js`'s xlsx reader makes the identical scope choice.
+- **Cell decoration and alignment resolved for real; font still not.** `XF`'s trailing `CellXF` payload's fill pattern/colours and per-side border style/colour are read and resolved through the `Palette` record (or the default colour table when one is absent) — see [Cell decoration](#cell-decoration) for the full mapping, including every named pattern beyond solid, and how this was verified against real LibreOffice-produced BIFF8. The same payload's leading word is resolved too — see [Cell alignment](#cell-alignment) for the full `alc`/`alcV` mapping. `Font` records are not read at all: `ContentSheetCell` has no cell-level font field, and `ooxml.js`'s xlsx reader makes the identical scope choice.
 - **Print settings, resolved for real.** Every field of `ContentSheetPrintSettings` is read from the records that carry it, with Excel's own "Normal" preset standing in per field for whatever the file leaves unstated — see [Print settings](#print-settings) for the record map, the two of BIFF8's own conditional rules that decide how to read `Setup`, and the three things that genuinely do not come through.
 - **Not read at all:** charts, drawings and images, cell comments (`Note`/`Txo`), data validation, and conditional formatting. Defined names (`Lbl`) are read only for the two built-in ones a sheet's print range and repeated header bands live in ([Print settings](#print-settings)); a user-defined name has nowhere to land in `document-schema.js`'s spreadsheet model, so it is skipped.
 - **Encrypted workbooks** are refused rather than mis-read: a `FilePass` record means every record after it is ciphertext.
@@ -55,11 +55,11 @@ This package is wired into `documents.js`'s conversion registry (`xlsToPdf`/`pdf
 
 ## Cell decoration
 
-A cell's own solid background fill and per-side borders are read from and written to `XF`'s trailing `CellXF`/`StyleXF` payload ([MS-XLS] 2.4.353) and the workbook's own `Palette` record ([MS-XLS] 2.4.188), verified both by round trip and against a real, independent BIFF8 implementation — [ExaDev/documents.js#815](https://github.com/ExaDev/documents.js/issues/815) as a scoped chunk of that issue's own broader tracking, not a claim of closing it outright. `src/biff/xf-colors.ts` is the one place the payload's border/fill bit layout is packed or unpacked, shared by `workbook/globals.ts`'s read side and `biff/xf-writer.ts`'s write side, so the two directions cannot silently disagree on what a given byte means.
+A cell's own background fill -- solid, or a genuine two-colour pattern -- and per-side borders are read from and written to `XF`'s trailing `CellXF`/`StyleXF` payload ([MS-XLS] 2.4.353) and the workbook's own `Palette` record ([MS-XLS] 2.4.188), verified both by round trip and against a real, independent BIFF8 implementation — [ExaDev/documents.js#815](https://github.com/ExaDev/documents.js/issues/815) as a scoped chunk of that issue's own broader tracking, not a claim of closing it outright. `src/biff/xf-colors.ts` is the one place the payload's border/fill bit layout is packed or unpacked, shared by `workbook/globals.ts`'s read side and `biff/xf-writer.ts`'s write side, so the two directions cannot silently disagree on what a given byte means.
 
 **Colour resolution.** A fill or border colour is a 7-bit `icv` index into BIFF8's own colour table ([MS-XLS] "Icv"): 0-7 name eight fixed built-in colours (this package's writer never emits one of these, per the spec's own "SHOULD NOT be ≤ 0x07"; the reader still resolves them, for a real third-party file that does), 8-63 index into either the workbook's own `Palette` record when one is present or a fixed 56-entry default table when it is not. The writer scans every distinct decoration colour a workbook's cells use before writing anything: when every one already matches the default table exactly, no `Palette` record is written at all, keeping an undecorated-adjacent file as minimal as it always was; the moment even one colour falls outside that table, a real 56-entry `Palette` record is minted, with every distinct colour the workbook actually uses (not only the non-default ones) assigned its own dedicated slot, so the whole table is self-consistent rather than a mix of "the file's own entries" and "the implicit default".
 
-**Fill patterns beyond solid — a deliberate judgment call, not an oversight.** [MS-XLS]'s own `FillPattern` enumeration names nineteen patterns: no fill, solid, four grey shades, and stripe/crosshatch families. `ContentSheetCell.background` models exactly one flat colour, so only `FLSSOLID` maps onto it — using the pattern's own foreground colour (`icvFore`), which [MS-XLS] itself documents as the only colour a solid fill actually renders ("If this value is 1, then only `icvFore` is rendered"). Every other pattern reads as no background at all. Approximating a 50% grey crosshatch or a diagonal stripe as its own foreground colour would misreport what the cell actually shows, so this reader leaves it unmapped rather than guessing; this package's own writer never emits anything but `FLSNULL`/`FLSSOLID` either, so a round trip never needs to invent a lossy pattern encoding on the way back out.
+**Fill patterns beyond solid, resolved for real (ExaDev/documents.js#951).** [MS-XLS]/[MS-XLSB]'s own `FillPattern` enumeration names nineteen values: no fill, solid, and seventeen genuine two-colour patterns -- five grey shades (`FLSMEDGRAY`/`FLSDKGRAY`/`FLSLTGRAY`/`FLSGRAY125`/`FLSGRAY0625`) and the stripe/crosshatch families. `ContentSheetCell.background` is `document-schema.js`'s own `ContentCellFill`: a discriminated `'solid'`/`'pattern'` shape, `'pattern'` naming a closed `ContentCellPatternType` vocabulary spanning both this format's own `FillPattern` and WordprocessingML's `ST_Shd` (see that schema's own top comment for the full citation). `FLSSOLID` resolves to a `'solid'` fill of the pattern's own foreground colour (`icvFore`), which [MS-XLS] itself documents as the only colour a solid fill actually renders ("If this value is 1, then only `icvFore` is rendered") -- `icvBack` carries no meaning for it and is never consulted. Every other named `FillPattern` value resolves to a real `'pattern'` fill via `xf-colors.ts`'s own `FILL_PATTERN_TO_PATTERN_TYPE`, an exact 1:1 mapping onto the identical ECMA-376 `ST_PatternType` token name (`FLSMEDGRAY` through `FLSGRAY0625`, values 0x02-0x12, onto `mediumGray` through `gray0625` in that order) -- carrying whichever of the pattern's own foreground (`icvFore`, drawn as the pattern's strokes) and background (`icvBack`, the colour its gaps show through) colours actually resolve to a fixed RGB value; either may be an "Automatic" icv this package cannot express and is left unstated, matching `ContentCellFillSchema`'s own "a colour can defer instead of asserting" convention. A reserved `FillPattern` value beyond 0x12 still reads as no background at all, there being no pattern name to give it. Writing a `'pattern'` fill states its own colours (automatic where the fill leaves one unstated) under the `FillPattern` value the same table's inverse names for it; a WordprocessingML-only pattern name (the `percentN` family, or a stripe/cross member `ST_Shd` names but `ST_PatternType` does not) throws `BiffWriteError` rather than writing the wrong pattern or silently dropping it.
 
 **Borders.** Each of a cell's four sides carries its own [MS-XLS] `BorderStyle` line-style token and colour, mapped onto `ContentBorder`'s `widthPt`/`style` pair the same way `ooxml.js`'s own `typed/xlsx/styles.ts` maps xlsx's border tokens: four named weights — hair/thin/medium/thick, at 0.5/0.75/1.5/2.25pt, derived from Excel's own documented 96-DPI rendering and held once in [`document-schema.js`](../document-schema.js/README.md)'s own `border-weight` module, which this package and `ooxml.js` both import rather than each keeping a copy of it — crossed with a pattern (solid/dashed/dotted/double); the dash-family tokens (`dashDot`, `dashDotDot`, and their medium/slant variants) collapse to `'dashed'`, the closest `ContentStrokeStyle` member, exactly as `ooxml.js`'s equivalent table does for xlsx's own dash tokens. Diagonal borders (`dgDiag`/`grbitDiag`) are out of scope — `ContentCellBordersSchema` has no diagonal member — and are always read as absent, always written as none.
 
@@ -67,7 +67,9 @@ A cell's own solid background fill and per-side borders are read from and writte
 
 The decorated-blank case was checked the same way, in both directions and against the same implementation: a `.fods` whose one styled cell has a fill and four borders but no value converts to a `.xls` in which LibreOffice writes a real `Blank` record, and this reader recovers that cell's fill colour and all four border colours exactly; a `.xls` this package writes for the equivalent `empty` cell converts back to a `.fods` in which LibreOffice recovers a valueless cell carrying the same `fo:background-color` and `fo:border` colours — at its own 0.74pt rendering of the `thin` weight, per the note above.
 
-**Decoration on a cell with no value.** A cell can be empty and still have something to show, and BIFF8 says so with a `Blank` record ([MS-XLS] 2.4.20) — a cell header naming an `XF` and nothing else, written precisely because that `XF` carries a fill or a border. Both directions honour it: a `Blank` or `MulBlank` whose `XF` resolves to real decoration is read as an `empty`-kind cell carrying that decoration rather than dropped, and an `empty` cell carrying a background or a border is written back as a `Blank` record pointing at an `XF` encoding it. An empty cell with no decoration is still written as nothing at all and still read as absent, which is what keeps `ContentSheet`'s cell array sparse; "decoration this reader can express" is the same test the value-cell path applies, so a fill pattern beyond solid or an unresolvable colour leaves a blank cell dropped exactly as before.
+A genuine two-colour pattern fill was not checked against LibreOffice in either direction: ODF's own `style:table-cell-properties` has no attribute for a two-colour pattern fill for a hand-authored `.fods` to state one through, so there was no third-party bytes to compare against. Reading and writing every named `FillPattern` value is instead pinned against bytes hand-built from [MS-XLS]/[MS-XLSB]'s own enumeration (`biff/xf-colors.test.ts`) and against a whole-document round trip through this package's own reader and writer (`write.test.ts`).
+
+**Decoration on a cell with no value.** A cell can be empty and still have something to show, and BIFF8 says so with a `Blank` record ([MS-XLS] 2.4.20) — a cell header naming an `XF` and nothing else, written precisely because that `XF` carries a fill or a border. Both directions honour it: a `Blank` or `MulBlank` whose `XF` resolves to real decoration is read as an `empty`-kind cell carrying that decoration rather than dropped, and an `empty` cell carrying a background or a border is written back as a `Blank` record pointing at an `XF` encoding it. An empty cell with no decoration is still written as nothing at all and still read as absent, which is what keeps `ContentSheet`'s cell array sparse; "decoration this reader can express" is the same test the value-cell path applies, so a reserved `FillPattern` value with no pattern name, or an unresolvable colour on every field a cell states, leaves a blank cell dropped exactly as before.
 
 A per-cell font remains out of scope in both directions — see [Read-side gaps](#read-side-gaps) and [Writer scope](#writer-scope) above. The payload's leading word, once similarly out of scope, is now [Cell alignment](#cell-alignment) below.
 

package/dist/biff/xf-colors.cjs

@@ -3,8 +3,32 @@ let document_schema_js = require("document-schema.js");
 //#region src/biff/xf-colors.ts
 /** FLSNULL: no fill pattern -- the cell's fill colour fields carry no meaning. */
 const FILL_PATTERN_NONE = 0;
-/** FLSSOLID: a solid fill, the only pattern this package maps onto ContentSheetCell.background -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). Every other pattern (50%/75%/25% gray, the stripe and crosshatch families, ...) is a real information-loss case this reader does not approximate: see resolveFillBackground below. */
+/** FLSSOLID: a solid fill -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). */
 const FILL_PATTERN_SOLID = 1;
+/**
+* Every other named FillPattern value ([MS-XLS]/[MS-XLSB] "FillPattern" enumeration, 0x02-0x12), mapped onto the ContentCellPatternType name document-schema.js's own ContentCellPatternTypeSchema gives that same ECMA-376 ST_PatternType token verbatim -- this is the identical vocabulary, values 0x02 (FLSMEDGRAY, "50% gray") through 0x12 (FLSGRAY0625, "6.25% gray") mapping onto ST_PatternType's mediumGray/darkGray/lightGray/darkHorizontal/darkVertical/darkDown/darkUp/darkGrid/darkTrellis/lightHorizontal/lightVertical/lightDown/lightUp/lightGrid/lightTrellis/gray125/gray0625 in that exact order (see ContentCellPatternTypeSchema's own top comment for the full citation). Unlike doc-codec's Ipat table, every value in this contiguous range names a real pattern -- there is no ipatNil/ipatPctNew*-style gap to skip.
+*/
+const FILL_PATTERN_TO_PATTERN_TYPE = {
+	2: "mediumGray",
+	3: "darkGray",
+	4: "lightGray",
+	5: "darkHorizontal",
+	6: "darkVertical",
+	7: "darkDown",
+	8: "darkUp",
+	9: "darkGrid",
+	10: "darkTrellis",
+	11: "lightHorizontal",
+	12: "lightVertical",
+	13: "lightDown",
+	14: "lightUp",
+	15: "lightGrid",
+	16: "lightTrellis",
+	17: "gray125",
+	18: "gray0625"
+};
+/** The inverse of FILL_PATTERN_TO_PATTERN_TYPE, built from it rather than restated by hand so the two can never drift apart. Every ContentCellPatternType this package's own writer is ever asked to state has an entry, since the SpreadsheetML half of the shared vocabulary is exactly FILL_PATTERN_TO_PATTERN_TYPE's own value set -- the WordprocessingML-only members (the percentN family and the stripe/cross families ST_Shd names) are absent, FillPattern having no equivalent for them at all. */
+const PATTERN_TYPE_TO_FILL_PATTERN = new Map(Object.entries(FILL_PATTERN_TO_PATTERN_TYPE).map(([fls, patternType]) => [patternType, Number(fls)]));
 const ALC_GENERAL = 0;
 const ALC_LEFT = 1;
 const ALC_CENTER = 2;
@@ -248,10 +272,30 @@ function borderStyleTokenFor(border) {
 		case void 0: return SOLID_BORDER_STYLE[(0, document_schema_js.borderWeightForWidthPt)(border.widthPt)];
 	}
 }
-/** A solid fill's own foreground colour resolved to a real background, or undefined for every other FillPattern value -- FLSNULL (no fill at all) and every pattern beyond solid (50%/75%/25% gray, the stripe and crosshatch family) alike. A non-solid pattern is a real information-loss case rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its foreground colour alone would misrepresent what the cell actually shows -- see xls-codec's README for this package's own stated judgment call. */
-function resolveFillBackground(fillPattern, foregroundIcv, palette) {
-	if (fillPattern !== 1) return;
-	return resolveIcvColor(foregroundIcv, palette);
+/**
+* Resolves a cell's own FillPattern/icvFore/icvBack triple to a real ContentCellFill (ExaDev/documents.js#951), or undefined for FLSNULL (no fill at all), for a reserved/unrecognised FillPattern value, or for FLSSOLID when its own icvFore does not resolve to a fixed RGB value (an "Automatic" or otherwise unmapped icv, which leaves nothing to state a solid fill's colour as).
+*
+* FLSSOLID resolves to a 'solid' fill of icvFore alone -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF), so icvBack carries no meaning for it and is never consulted. Every other named FillPattern resolves to a real 'pattern' fill via FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of icvFore/icvBack resolves to a real colour (either may be an "Automatic" icv this package cannot express as a fixed RGB value, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention).
+*/
+function resolveFillBackground(fillPattern, foregroundIcv, backgroundIcv, palette) {
+	if (fillPattern === 0) return;
+	if (fillPattern === 1) {
+		const color = resolveIcvColor(foregroundIcv, palette);
+		return color === void 0 ? void 0 : {
+			kind: "solid",
+			color
+		};
+	}
+	const patternType = FILL_PATTERN_TO_PATTERN_TYPE[fillPattern];
+	if (patternType === void 0) return;
+	const foregroundColor = resolveIcvColor(foregroundIcv, palette);
+	const backgroundColor = resolveIcvColor(backgroundIcv, palette);
+	return {
+		kind: "pattern",
+		patternType,
+		...foregroundColor !== void 0 ? { foregroundColor } : {},
+		...backgroundColor !== void 0 ? { backgroundColor } : {}
+	};
 }
 const UNDECORATED_EDGE = {
 	style: 0,
@@ -261,6 +305,7 @@ const UNDECORATED_EDGE = {
 const UNDECORATED_XF_FIELDS = {
 	fillPattern: 0,
 	fillForegroundIcv: 64,
+	fillBackgroundIcv: 65,
 	left: UNDECORATED_EDGE,
 	right: UNDECORATED_EDGE,
 	top: UNDECORATED_EDGE,
@@ -288,6 +333,7 @@ function unpackXfDecoration(word2, word3, word4) {
 	return {
 		fillPattern: word3 >>> 26 & 63,
 		fillForegroundIcv: word4 & 127,
+		fillBackgroundIcv: word4 >>> 7 & 127,
 		left: {
 			style: dgLeft,
 			icv: icvLeft
@@ -313,10 +359,14 @@ function unpackXfDecoration(word2, word3, word4) {
 */
 function packXfDecorationWords(decoration = UNDECORATED_XF_FIELDS) {
 	const { left, right, top, bottom } = decoration;
+	const word2 = left.style & 15 | (right.style & 15) << 4 | (top.style & 15) << 8 | (bottom.style & 15) << 12 | (left.icv & 127) << 16 | (right.icv & 127) << 23 | 0;
+	const word3 = top.icv & 127 | (bottom.icv & 127) << 7 | 0 | (decoration.fillPattern & 63) << 26;
+	const icvFore = decoration.fillPattern === 0 ? 64 : decoration.fillForegroundIcv;
+	const icvBack = decoration.fillPattern === 0 || decoration.fillPattern === 1 ? 65 : decoration.fillBackgroundIcv;
 	return {
-		word2: left.style & 15 | (right.style & 15) << 4 | (top.style & 15) << 8 | (bottom.style & 15) << 12 | (left.icv & 127) << 16 | (right.icv & 127) << 23 | 0,
-		word3: top.icv & 127 | (bottom.icv & 127) << 7 | 0 | (decoration.fillPattern & 63) << 26,
-		word4: (decoration.fillPattern === 1 ? decoration.fillForegroundIcv : 64) & 127 | 8320
+		word2,
+		word3,
+		word4: icvFore & 127 | (icvBack & 127) << 7
 	};
 }
 /** LongRGB: red, green, blue, then a reserved byte that MUST be 0 -- one entry of a Palette record's rgColor array, or of the fixed-length buffer this package's own writer emits. */
@@ -358,6 +408,7 @@ exports.ICV_AUTOMATIC_BACKGROUND = ICV_AUTOMATIC_BACKGROUND;
 exports.ICV_AUTOMATIC_FOREGROUND = ICV_AUTOMATIC_FOREGROUND;
 exports.PALETTE_BASE_ICV = PALETTE_BASE_ICV;
 exports.PALETTE_ENTRY_COUNT = PALETTE_ENTRY_COUNT;
+exports.PATTERN_TYPE_TO_FILL_PATTERN = PATTERN_TYPE_TO_FILL_PATTERN;
 exports.UNDECORATED_XF_FIELDS = UNDECORATED_XF_FIELDS;
 exports.borderStyleTokenFor = borderStyleTokenFor;
 exports.horizAlignTokenFor = horizAlignTokenFor;

package/dist/biff/xf-colors.d.cts

@@ -1,2 +1,2 @@
-import { A as readLongRgbColor, C as XfAlignmentFields, D as horizAlignTokenFor, E as borderStyleTokenFor, F as resolveVerticalAlignment, I as unpackXfAlignment, L as unpackXfDecoration, M as resolveFillBackground, N as resolveHorizontalAlignment, O as longRgbBytesOf, P as resolveIcvColor, R as vertAlignTokenFor, S as UNDECORATED_XF_FIELDS, T as XfDecorationFields, _ as FILL_PATTERN_SOLID, a as BORDER_STYLE_DOUBLE, b as PALETTE_BASE_ICV, c as BORDER_STYLE_MEDIUM_DASHDOT, d as BORDER_STYLE_NONE, f as BORDER_STYLE_SLANT_DASHDOT, g as FILL_PATTERN_NONE, h as DEFAULT_PALETTE_HEX_TO_ICV, i as BORDER_STYLE_DOTTED, j as resolveBorderEdge, k as packXfDecorationWords, l as BORDER_STYLE_MEDIUM_DASHDOTDOT, m as BORDER_STYLE_THIN, n as BORDER_STYLE_DASHDOTDOT, o as BORDER_STYLE_HAIR, p as BORDER_STYLE_THICK, r as BORDER_STYLE_DASHED, s as BORDER_STYLE_MEDIUM, t as BORDER_STYLE_DASHDOT, u as BORDER_STYLE_MEDIUM_DASHED, v as ICV_AUTOMATIC_BACKGROUND, w as XfBorderEdge, x as PALETTE_ENTRY_COUNT, y as ICV_AUTOMATIC_FOREGROUND } from "../xf-colors-CehHZtBy.cjs";
-export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, UNDECORATED_XF_FIELDS, XfAlignmentFields, XfBorderEdge, XfDecorationFields, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };
+import { A as packXfDecorationWords, C as UNDECORATED_XF_FIELDS, D as borderStyleTokenFor, E as XfDecorationFields, F as resolveIcvColor, I as resolveVerticalAlignment, L as unpackXfAlignment, M as resolveBorderEdge, N as resolveFillBackground, O as horizAlignTokenFor, P as resolveHorizontalAlignment, R as unpackXfDecoration, S as PATTERN_TYPE_TO_FILL_PATTERN, T as XfBorderEdge, _ as FILL_PATTERN_SOLID, a as BORDER_STYLE_DOUBLE, b as PALETTE_BASE_ICV, c as BORDER_STYLE_MEDIUM_DASHDOT, d as BORDER_STYLE_NONE, f as BORDER_STYLE_SLANT_DASHDOT, g as FILL_PATTERN_NONE, h as DEFAULT_PALETTE_HEX_TO_ICV, i as BORDER_STYLE_DOTTED, j as readLongRgbColor, k as longRgbBytesOf, l as BORDER_STYLE_MEDIUM_DASHDOTDOT, m as BORDER_STYLE_THIN, n as BORDER_STYLE_DASHDOTDOT, o as BORDER_STYLE_HAIR, p as BORDER_STYLE_THICK, r as BORDER_STYLE_DASHED, s as BORDER_STYLE_MEDIUM, t as BORDER_STYLE_DASHDOT, u as BORDER_STYLE_MEDIUM_DASHED, v as ICV_AUTOMATIC_BACKGROUND, w as XfAlignmentFields, x as PALETTE_ENTRY_COUNT, y as ICV_AUTOMATIC_FOREGROUND, z as vertAlignTokenFor } from "../xf-colors-BB5MKq6R.cjs";
+export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, PATTERN_TYPE_TO_FILL_PATTERN, UNDECORATED_XF_FIELDS, XfAlignmentFields, XfBorderEdge, XfDecorationFields, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };

package/dist/biff/xf-colors.d.ts

@@ -1,2 +1,2 @@
-import { A as readLongRgbColor, C as XfAlignmentFields, D as horizAlignTokenFor, E as borderStyleTokenFor, F as resolveVerticalAlignment, I as unpackXfAlignment, L as unpackXfDecoration, M as resolveFillBackground, N as resolveHorizontalAlignment, O as longRgbBytesOf, P as resolveIcvColor, R as vertAlignTokenFor, S as UNDECORATED_XF_FIELDS, T as XfDecorationFields, _ as FILL_PATTERN_SOLID, a as BORDER_STYLE_DOUBLE, b as PALETTE_BASE_ICV, c as BORDER_STYLE_MEDIUM_DASHDOT, d as BORDER_STYLE_NONE, f as BORDER_STYLE_SLANT_DASHDOT, g as FILL_PATTERN_NONE, h as DEFAULT_PALETTE_HEX_TO_ICV, i as BORDER_STYLE_DOTTED, j as resolveBorderEdge, k as packXfDecorationWords, l as BORDER_STYLE_MEDIUM_DASHDOTDOT, m as BORDER_STYLE_THIN, n as BORDER_STYLE_DASHDOTDOT, o as BORDER_STYLE_HAIR, p as BORDER_STYLE_THICK, r as BORDER_STYLE_DASHED, s as BORDER_STYLE_MEDIUM, t as BORDER_STYLE_DASHDOT, u as BORDER_STYLE_MEDIUM_DASHED, v as ICV_AUTOMATIC_BACKGROUND, w as XfBorderEdge, x as PALETTE_ENTRY_COUNT, y as ICV_AUTOMATIC_FOREGROUND } from "../xf-colors-CpykR3B9.js";
-export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, UNDECORATED_XF_FIELDS, XfAlignmentFields, XfBorderEdge, XfDecorationFields, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };
+import { A as packXfDecorationWords, C as UNDECORATED_XF_FIELDS, D as borderStyleTokenFor, E as XfDecorationFields, F as resolveIcvColor, I as resolveVerticalAlignment, L as unpackXfAlignment, M as resolveBorderEdge, N as resolveFillBackground, O as horizAlignTokenFor, P as resolveHorizontalAlignment, R as unpackXfDecoration, S as PATTERN_TYPE_TO_FILL_PATTERN, T as XfBorderEdge, _ as FILL_PATTERN_SOLID, a as BORDER_STYLE_DOUBLE, b as PALETTE_BASE_ICV, c as BORDER_STYLE_MEDIUM_DASHDOT, d as BORDER_STYLE_NONE, f as BORDER_STYLE_SLANT_DASHDOT, g as FILL_PATTERN_NONE, h as DEFAULT_PALETTE_HEX_TO_ICV, i as BORDER_STYLE_DOTTED, j as readLongRgbColor, k as longRgbBytesOf, l as BORDER_STYLE_MEDIUM_DASHDOTDOT, m as BORDER_STYLE_THIN, n as BORDER_STYLE_DASHDOTDOT, o as BORDER_STYLE_HAIR, p as BORDER_STYLE_THICK, r as BORDER_STYLE_DASHED, s as BORDER_STYLE_MEDIUM, t as BORDER_STYLE_DASHDOT, u as BORDER_STYLE_MEDIUM_DASHED, v as ICV_AUTOMATIC_BACKGROUND, w as XfAlignmentFields, x as PALETTE_ENTRY_COUNT, y as ICV_AUTOMATIC_FOREGROUND, z as vertAlignTokenFor } from "../xf-colors--5oxSeI1.js";
+export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, PATTERN_TYPE_TO_FILL_PATTERN, UNDECORATED_XF_FIELDS, XfAlignmentFields, XfBorderEdge, XfDecorationFields, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };

package/dist/biff/xf-colors.js

@@ -2,8 +2,32 @@ import { BORDER_WIDTH_PT, borderWeightForWidthPt, colorToRgbHex, dashedBorderWei
 //#region src/biff/xf-colors.ts
 /** FLSNULL: no fill pattern -- the cell's fill colour fields carry no meaning. */
 const FILL_PATTERN_NONE = 0;
-/** FLSSOLID: a solid fill, the only pattern this package maps onto ContentSheetCell.background -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). Every other pattern (50%/75%/25% gray, the stripe and crosshatch families, ...) is a real information-loss case this reader does not approximate: see resolveFillBackground below. */
+/** FLSSOLID: a solid fill -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). */
 const FILL_PATTERN_SOLID = 1;
+/**
+* Every other named FillPattern value ([MS-XLS]/[MS-XLSB] "FillPattern" enumeration, 0x02-0x12), mapped onto the ContentCellPatternType name document-schema.js's own ContentCellPatternTypeSchema gives that same ECMA-376 ST_PatternType token verbatim -- this is the identical vocabulary, values 0x02 (FLSMEDGRAY, "50% gray") through 0x12 (FLSGRAY0625, "6.25% gray") mapping onto ST_PatternType's mediumGray/darkGray/lightGray/darkHorizontal/darkVertical/darkDown/darkUp/darkGrid/darkTrellis/lightHorizontal/lightVertical/lightDown/lightUp/lightGrid/lightTrellis/gray125/gray0625 in that exact order (see ContentCellPatternTypeSchema's own top comment for the full citation). Unlike doc-codec's Ipat table, every value in this contiguous range names a real pattern -- there is no ipatNil/ipatPctNew*-style gap to skip.
+*/
+const FILL_PATTERN_TO_PATTERN_TYPE = {
+	2: "mediumGray",
+	3: "darkGray",
+	4: "lightGray",
+	5: "darkHorizontal",
+	6: "darkVertical",
+	7: "darkDown",
+	8: "darkUp",
+	9: "darkGrid",
+	10: "darkTrellis",
+	11: "lightHorizontal",
+	12: "lightVertical",
+	13: "lightDown",
+	14: "lightUp",
+	15: "lightGrid",
+	16: "lightTrellis",
+	17: "gray125",
+	18: "gray0625"
+};
+/** The inverse of FILL_PATTERN_TO_PATTERN_TYPE, built from it rather than restated by hand so the two can never drift apart. Every ContentCellPatternType this package's own writer is ever asked to state has an entry, since the SpreadsheetML half of the shared vocabulary is exactly FILL_PATTERN_TO_PATTERN_TYPE's own value set -- the WordprocessingML-only members (the percentN family and the stripe/cross families ST_Shd names) are absent, FillPattern having no equivalent for them at all. */
+const PATTERN_TYPE_TO_FILL_PATTERN = new Map(Object.entries(FILL_PATTERN_TO_PATTERN_TYPE).map(([fls, patternType]) => [patternType, Number(fls)]));
 const ALC_GENERAL = 0;
 const ALC_LEFT = 1;
 const ALC_CENTER = 2;
@@ -247,10 +271,30 @@ function borderStyleTokenFor(border) {
 		case void 0: return SOLID_BORDER_STYLE[borderWeightForWidthPt(border.widthPt)];
 	}
 }
-/** A solid fill's own foreground colour resolved to a real background, or undefined for every other FillPattern value -- FLSNULL (no fill at all) and every pattern beyond solid (50%/75%/25% gray, the stripe and crosshatch family) alike. A non-solid pattern is a real information-loss case rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its foreground colour alone would misrepresent what the cell actually shows -- see xls-codec's README for this package's own stated judgment call. */
-function resolveFillBackground(fillPattern, foregroundIcv, palette) {
-	if (fillPattern !== 1) return;
-	return resolveIcvColor(foregroundIcv, palette);
+/**
+* Resolves a cell's own FillPattern/icvFore/icvBack triple to a real ContentCellFill (ExaDev/documents.js#951), or undefined for FLSNULL (no fill at all), for a reserved/unrecognised FillPattern value, or for FLSSOLID when its own icvFore does not resolve to a fixed RGB value (an "Automatic" or otherwise unmapped icv, which leaves nothing to state a solid fill's colour as).
+*
+* FLSSOLID resolves to a 'solid' fill of icvFore alone -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF), so icvBack carries no meaning for it and is never consulted. Every other named FillPattern resolves to a real 'pattern' fill via FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of icvFore/icvBack resolves to a real colour (either may be an "Automatic" icv this package cannot express as a fixed RGB value, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention).
+*/
+function resolveFillBackground(fillPattern, foregroundIcv, backgroundIcv, palette) {
+	if (fillPattern === 0) return;
+	if (fillPattern === 1) {
+		const color = resolveIcvColor(foregroundIcv, palette);
+		return color === void 0 ? void 0 : {
+			kind: "solid",
+			color
+		};
+	}
+	const patternType = FILL_PATTERN_TO_PATTERN_TYPE[fillPattern];
+	if (patternType === void 0) return;
+	const foregroundColor = resolveIcvColor(foregroundIcv, palette);
+	const backgroundColor = resolveIcvColor(backgroundIcv, palette);
+	return {
+		kind: "pattern",
+		patternType,
+		...foregroundColor !== void 0 ? { foregroundColor } : {},
+		...backgroundColor !== void 0 ? { backgroundColor } : {}
+	};
 }
 const UNDECORATED_EDGE = {
 	style: 0,
@@ -260,6 +304,7 @@ const UNDECORATED_EDGE = {
 const UNDECORATED_XF_FIELDS = {
 	fillPattern: 0,
 	fillForegroundIcv: 64,
+	fillBackgroundIcv: 65,
 	left: UNDECORATED_EDGE,
 	right: UNDECORATED_EDGE,
 	top: UNDECORATED_EDGE,
@@ -287,6 +332,7 @@ function unpackXfDecoration(word2, word3, word4) {
 	return {
 		fillPattern: word3 >>> 26 & 63,
 		fillForegroundIcv: word4 & 127,
+		fillBackgroundIcv: word4 >>> 7 & 127,
 		left: {
 			style: dgLeft,
 			icv: icvLeft
@@ -312,10 +358,14 @@ function unpackXfDecoration(word2, word3, word4) {
 */
 function packXfDecorationWords(decoration = UNDECORATED_XF_FIELDS) {
 	const { left, right, top, bottom } = decoration;
+	const word2 = left.style & 15 | (right.style & 15) << 4 | (top.style & 15) << 8 | (bottom.style & 15) << 12 | (left.icv & 127) << 16 | (right.icv & 127) << 23 | 0;
+	const word3 = top.icv & 127 | (bottom.icv & 127) << 7 | 0 | (decoration.fillPattern & 63) << 26;
+	const icvFore = decoration.fillPattern === 0 ? 64 : decoration.fillForegroundIcv;
+	const icvBack = decoration.fillPattern === 0 || decoration.fillPattern === 1 ? 65 : decoration.fillBackgroundIcv;
 	return {
-		word2: left.style & 15 | (right.style & 15) << 4 | (top.style & 15) << 8 | (bottom.style & 15) << 12 | (left.icv & 127) << 16 | (right.icv & 127) << 23 | 0,
-		word3: top.icv & 127 | (bottom.icv & 127) << 7 | 0 | (decoration.fillPattern & 63) << 26,
-		word4: (decoration.fillPattern === 1 ? decoration.fillForegroundIcv : 64) & 127 | 8320
+		word2,
+		word3,
+		word4: icvFore & 127 | (icvBack & 127) << 7
 	};
 }
 /** LongRGB: red, green, blue, then a reserved byte that MUST be 0 -- one entry of a Palette record's rgColor array, or of the fixed-length buffer this package's own writer emits. */
@@ -336,4 +386,4 @@ function longRgbBytesOf(color) {
 	];
 }
 //#endregion
-export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, UNDECORATED_XF_FIELDS, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };
+export { BORDER_STYLE_DASHDOT, BORDER_STYLE_DASHDOTDOT, BORDER_STYLE_DASHED, BORDER_STYLE_DOTTED, BORDER_STYLE_DOUBLE, BORDER_STYLE_HAIR, BORDER_STYLE_MEDIUM, BORDER_STYLE_MEDIUM_DASHDOT, BORDER_STYLE_MEDIUM_DASHDOTDOT, BORDER_STYLE_MEDIUM_DASHED, BORDER_STYLE_NONE, BORDER_STYLE_SLANT_DASHDOT, BORDER_STYLE_THICK, BORDER_STYLE_THIN, DEFAULT_PALETTE_HEX_TO_ICV, FILL_PATTERN_NONE, FILL_PATTERN_SOLID, ICV_AUTOMATIC_BACKGROUND, ICV_AUTOMATIC_FOREGROUND, PALETTE_BASE_ICV, PALETTE_ENTRY_COUNT, PATTERN_TYPE_TO_FILL_PATTERN, UNDECORATED_XF_FIELDS, borderStyleTokenFor, horizAlignTokenFor, longRgbBytesOf, packXfDecorationWords, readLongRgbColor, resolveBorderEdge, resolveFillBackground, resolveHorizontalAlignment, resolveIcvColor, resolveVerticalAlignment, unpackXfAlignment, unpackXfDecoration, vertAlignTokenFor };

package/dist/biff/xf-writer.d.cts

@@ -1,4 +1,4 @@
-import { T as XfDecorationFields } from "../xf-colors-CehHZtBy.cjs";
+import { E as XfDecorationFields } from "../xf-colors-BB5MKq6R.cjs";
 import { Alignment, Color } from "document-schema.js";
 //#region src/biff/xf-writer.d.ts
 /** Writes one cell-format XF record (fStyle=0): ifnt/ifmt as given, ixfParent pointing at the Normal cell-style XF (index 0), a CellXF payload carrying `alignment`/`verticalAlignment`/`decoration`'s own fields -- general alignment, bottom vertical alignment, and no fill/border (the same bytes this always wrote before either existed) for whatever is omitted. Twenty bytes total ([MS-XLS] 2.4.353). */

package/dist/biff/xf-writer.d.ts

@@ -1,4 +1,4 @@
-import { T as XfDecorationFields } from "../xf-colors-CpykR3B9.js";
+import { E as XfDecorationFields } from "../xf-colors--5oxSeI1.js";
 import { Alignment, Color } from "document-schema.js";
 //#region src/biff/xf-writer.d.ts
 /** Writes one cell-format XF record (fStyle=0): ifnt/ifmt as given, ixfParent pointing at the Normal cell-style XF (index 0), a CellXF payload carrying `alignment`/`verticalAlignment`/`decoration`'s own fields -- general alignment, bottom vertical alignment, and no fill/border (the same bytes this always wrote before either existed) for whatever is omitted. Twenty bytes total ([MS-XLS] 2.4.353). */

package/dist/content.cjs

@@ -192,14 +192,14 @@ function mapCell(cell, globals) {
 	return mapped;
 }
 /**
-* A cell's own resolved fill colour, or undefined for a genuinely unfilled cell AND for every fill pattern beyond solid.
+* A cell's own resolved background fill (ExaDev/documents.js#951), or undefined for a genuinely unfilled cell and for a reserved/unrecognised FillPattern value.
 *
-* A non-solid pattern (the 50%/75%/25% gray shades, the stripe and crosshatch family [MS-XLS]'s FillPattern enumeration also names) is a deliberate, permanent gap rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its own foreground colour alone would misreport what the cell actually shows -- see xls-codec's README, "Cell decoration".
+* A solid fill resolves to a 'solid' ContentCellFill of its own foreground colour; every other named FillPattern -- the 50%/75%/25% gray shades, the stripe and crosshatch family -- resolves to a real 'pattern' fill via xf-colors.ts's own FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of the pattern's foreground/background colours actually resolve to a fixed RGB value. See xls-codec's README, "Cell decoration".
 */
 function backgroundOf(globals, xfIndex) {
 	const format = globals.cellFormats[xfIndex];
 	if (format === void 0) return;
-	return require_biff_xf_colors.resolveFillBackground(format.decoration.fillPattern, format.decoration.fillForegroundIcv, globals.palette);
+	return require_biff_xf_colors.resolveFillBackground(format.decoration.fillPattern, format.decoration.fillForegroundIcv, format.decoration.fillBackgroundIcv, globals.palette);
 }
 /** A cell's own resolved horizontal/vertical alignment -- already the exact Alignment/verticalAlignment members (or undefined) globals.ts's readCellFormat resolved through xf-colors.ts's unpackXfAlignment, so this is a lookup rather than a further resolution step, mirroring backgroundOf/bordersOf's own shape. Both fields undefined for a cell whose XF resolves to no CellFormat at all (an out-of-range xfIndex), matching every other resolveXOf helper's behaviour in that case. */
 function alignmentOf(globals, xfIndex) {

package/dist/content.js

@@ -191,14 +191,14 @@ function mapCell(cell, globals) {
 	return mapped;
 }
 /**
-* A cell's own resolved fill colour, or undefined for a genuinely unfilled cell AND for every fill pattern beyond solid.
+* A cell's own resolved background fill (ExaDev/documents.js#951), or undefined for a genuinely unfilled cell and for a reserved/unrecognised FillPattern value.
 *
-* A non-solid pattern (the 50%/75%/25% gray shades, the stripe and crosshatch family [MS-XLS]'s FillPattern enumeration also names) is a deliberate, permanent gap rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its own foreground colour alone would misreport what the cell actually shows -- see xls-codec's README, "Cell decoration".
+* A solid fill resolves to a 'solid' ContentCellFill of its own foreground colour; every other named FillPattern -- the 50%/75%/25% gray shades, the stripe and crosshatch family -- resolves to a real 'pattern' fill via xf-colors.ts's own FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of the pattern's foreground/background colours actually resolve to a fixed RGB value. See xls-codec's README, "Cell decoration".
 */
 function backgroundOf(globals, xfIndex) {
 	const format = globals.cellFormats[xfIndex];
 	if (format === void 0) return;
-	return resolveFillBackground(format.decoration.fillPattern, format.decoration.fillForegroundIcv, globals.palette);
+	return resolveFillBackground(format.decoration.fillPattern, format.decoration.fillForegroundIcv, format.decoration.fillBackgroundIcv, globals.palette);
 }
 /** A cell's own resolved horizontal/vertical alignment -- already the exact Alignment/verticalAlignment members (or undefined) globals.ts's readCellFormat resolved through xf-colors.ts's unpackXfAlignment, so this is a lookup rather than a further resolution step, mirroring backgroundOf/bordersOf's own shape. Both fields undefined for a cell whose XF resolves to no CellFormat at all (an out-of-range xfIndex), matching every other resolveXOf helper's behaviour in that case. */
 function alignmentOf(globals, xfIndex) {

package/dist/workbook/globals-writer.d.cts

@@ -1,4 +1,4 @@
-import { T as XfDecorationFields } from "../xf-colors-CehHZtBy.cjs";
+import { E as XfDecorationFields } from "../xf-colors-BB5MKq6R.cjs";
 import { t as PrintNamePlanEntry } from "../print-names-D-njuzVw.cjs";
 import { Alignment, Color } from "document-schema.js";
 //#region src/workbook/globals-writer.d.ts

package/dist/workbook/globals-writer.d.ts

@@ -1,4 +1,4 @@
-import { T as XfDecorationFields } from "../xf-colors-CpykR3B9.js";
+import { E as XfDecorationFields } from "../xf-colors--5oxSeI1.js";
 import { t as PrintNamePlanEntry } from "../print-names-DUlpVE00.js";
 import { Alignment, Color } from "document-schema.js";
 //#region src/workbook/globals-writer.d.ts

package/dist/workbook/globals.d.cts

@@ -1,6 +1,6 @@
 import { n as SheetRange } from "../ptg-B2K8t3js.cjs";
 import { t as RecordGroup } from "../substreams-Ddtvn_Vr.cjs";
-import { C as XfAlignmentFields, T as XfDecorationFields } from "../xf-colors-CehHZtBy.cjs";
+import { E as XfDecorationFields, w as XfAlignmentFields } from "../xf-colors-BB5MKq6R.cjs";
 import { n as SheetPrintNames } from "../print-names-D-njuzVw.cjs";
 import { Color } from "document-schema.js";
 //#region src/workbook/globals.d.ts

package/dist/workbook/globals.d.ts

@@ -1,6 +1,6 @@
 import { n as SheetRange } from "../ptg-B2K8t3js.js";
 import { t as RecordGroup } from "../substreams-D7dQiJbp.js";
-import { C as XfAlignmentFields, T as XfDecorationFields } from "../xf-colors-CpykR3B9.js";
+import { E as XfDecorationFields, w as XfAlignmentFields } from "../xf-colors--5oxSeI1.js";
 import { n as SheetPrintNames } from "../print-names-DUlpVE00.js";
 import { Color } from "document-schema.js";
 //#region src/workbook/globals.d.ts

package/dist/write.cjs

@@ -90,9 +90,18 @@ function buildPalettePlan(sheets) {
 		const hex = (0, document_schema_js.colorToRgbHex)(color);
 		if (!colorByHex.has(hex)) colorByHex.set(hex, color);
 	};
+	const recordFill = (fill) => {
+		if (fill === void 0) return;
+		if (fill.kind === "solid") {
+			record(fill.color);
+			return;
+		}
+		record(fill.foregroundColor);
+		record(fill.backgroundColor);
+	};
 	for (const sheet of sheets) for (const cell of sheet.cells) {
 		if (!require_written_cells.writesCellRecord(cell)) continue;
-		record(cell.background);
+		recordFill(cell.background);
 		record(cell.borders?.left?.color);
 		record(cell.borders?.right?.color);
 		record(cell.borders?.top?.color);
@@ -149,12 +158,36 @@ function resolveWriteEdge(border, icvOf) {
 		icv: icvOf(border.color)
 	};
 }
+/** A ContentCellFill's own fillPattern/fillForegroundIcv/fillBackgroundIcv triple, resolved for whichever of 'solid'/'pattern' the cell states -- undefined input resolves to FLSNULL with both colours Automatic, matching the pre-#951 undecorated case exactly. A 'pattern' fill leaving one of its own colours unstated writes that colour Automatic too, the inverse of xf-colors.ts's own resolveFillBackground treating an unresolvable icv the same way on read. */
+function resolveFillFields(fill, icvOf) {
+	if (fill === void 0) return {
+		fillPattern: 0,
+		fillForegroundIcv: 64,
+		fillBackgroundIcv: 65
+	};
+	switch (fill.kind) {
+		case "solid": return {
+			fillPattern: 1,
+			fillForegroundIcv: icvOf(fill.color),
+			fillBackgroundIcv: 65
+		};
+		case "pattern": {
+			const fillPattern = require_biff_xf_colors.PATTERN_TYPE_TO_FILL_PATTERN.get(fill.patternType);
+			if (fillPattern === void 0) throw new require_biff_write_errors.BiffWriteError(`xls-codec cannot write a '${fill.patternType}' cell fill: [MS-XLS]'s own FillPattern enumeration has no member for it, that pattern name belonging only to WordprocessingML's ST_Shd half of ContentCellPatternType's shared vocabulary`);
+			return {
+				fillPattern,
+				fillForegroundIcv: fill.foregroundColor === void 0 ? 64 : icvOf(fill.foregroundColor),
+				fillBackgroundIcv: fill.backgroundColor === void 0 ? 65 : icvOf(fill.backgroundColor)
+			};
+		}
+		default: throw new require_biff_write_errors.BiffWriteError(`xls-codec cannot write a cell fill with kind '${(0, document_schema_js.unrecognizedFillKind)(fill)}': ContentCellFillSchema's discriminated union only defines 'solid' and 'pattern'`);
+	}
+}
 /** A cell's own decoration, resolved into the raw XfDecorationFields the CellXF payload packs -- undefined for a cell with neither a background nor any border, so it shares the workbook's plain undecorated XF exactly as it did before decoration existed. The "has decoration at all" question is written-cells.ts's, since the writer's own record-emission predicate turns on the identical answer. */
 function resolveDecorationForCell(cell, icvOf) {
 	if (!require_written_cells.cellCarriesFormatting(cell)) return;
 	return {
-		fillPattern: cell.background === void 0 ? 0 : 1,
-		fillForegroundIcv: cell.background === void 0 ? 64 : icvOf(cell.background),
+		...resolveFillFields(cell.background, icvOf),
 		left: resolveWriteEdge(cell.borders?.left, icvOf),
 		right: resolveWriteEdge(cell.borders?.right, icvOf),
 		top: resolveWriteEdge(cell.borders?.top, icvOf),
@@ -165,7 +198,7 @@ function resolveDecorationForCell(cell, icvOf) {
 function signatureOfCellXf(formatId, alignment, verticalAlignment, decoration) {
 	let signature = `f${formatId}|a${alignment ?? ""}|v${verticalAlignment ?? ""}`;
 	if (decoration === void 0) return signature;
-	signature += `|p${decoration.fillPattern}:${decoration.fillForegroundIcv}|l${decoration.left.style}:${decoration.left.icv}|r${decoration.right.style}:${decoration.right.icv}|t${decoration.top.style}:${decoration.top.icv}|b${decoration.bottom.style}:${decoration.bottom.icv}`;
+	signature += `|p${decoration.fillPattern}:${decoration.fillForegroundIcv}:${decoration.fillBackgroundIcv}|l${decoration.left.style}:${decoration.left.icv}|r${decoration.right.style}:${decoration.right.icv}|t${decoration.top.style}:${decoration.top.icv}|b${decoration.bottom.style}:${decoration.bottom.icv}`;
 	return signature;
 }
 /**

package/dist/write.js

@@ -1,5 +1,5 @@
 import { SUMMARY_INFORMATION_STREAM } from "./container.js";
-import { DEFAULT_PALETTE_HEX_TO_ICV, borderStyleTokenFor } from "./biff/xf-colors.js";
+import { DEFAULT_PALETTE_HEX_TO_ICV, PATTERN_TYPE_TO_FILL_PATTERN, borderStyleTokenFor } from "./biff/xf-colors.js";
 import { BiffWriteError } from "./biff/write-errors.js";
 import { printNameEntriesFor } from "./workbook/print-names.js";
 import { layoutMetadataToSummaryInformation as layoutMetadataToSummaryInformation$1 } from "./metadata.js";
@@ -7,7 +7,7 @@ import { GENERAL_CELL_XF_INDEX, buildWorkbookGlobals } from "./workbook/globals-
 import { cellCarriesFormatting, writesCellRecord } from "./written-cells.js";
 import { buildWorksheetSubstream } from "./workbook/sheet-writer.js";
 import { hasSummaryInformationFields, writeCompoundFile, writeSummaryInformationStream } from "archive-codec";
-import { colorToRgbHex, flattenTree } from "document-schema.js";
+import { colorToRgbHex, flattenTree, unrecognizedFillKind } from "document-schema.js";
 import { BUILTIN_NUMBER_FORMATS } from "excel-number-format";
 //#region src/write.ts
 const WORKBOOK_STREAM_NAME = "Workbook";
@@ -89,9 +89,18 @@ function buildPalettePlan(sheets) {
 		const hex = colorToRgbHex(color);
 		if (!colorByHex.has(hex)) colorByHex.set(hex, color);
 	};
+	const recordFill = (fill) => {
+		if (fill === void 0) return;
+		if (fill.kind === "solid") {
+			record(fill.color);
+			return;
+		}
+		record(fill.foregroundColor);
+		record(fill.backgroundColor);
+	};
 	for (const sheet of sheets) for (const cell of sheet.cells) {
 		if (!writesCellRecord(cell)) continue;
-		record(cell.background);
+		recordFill(cell.background);
 		record(cell.borders?.left?.color);
 		record(cell.borders?.right?.color);
 		record(cell.borders?.top?.color);
@@ -148,12 +157,36 @@ function resolveWriteEdge(border, icvOf) {
 		icv: icvOf(border.color)
 	};
 }
+/** A ContentCellFill's own fillPattern/fillForegroundIcv/fillBackgroundIcv triple, resolved for whichever of 'solid'/'pattern' the cell states -- undefined input resolves to FLSNULL with both colours Automatic, matching the pre-#951 undecorated case exactly. A 'pattern' fill leaving one of its own colours unstated writes that colour Automatic too, the inverse of xf-colors.ts's own resolveFillBackground treating an unresolvable icv the same way on read. */
+function resolveFillFields(fill, icvOf) {
+	if (fill === void 0) return {
+		fillPattern: 0,
+		fillForegroundIcv: 64,
+		fillBackgroundIcv: 65
+	};
+	switch (fill.kind) {
+		case "solid": return {
+			fillPattern: 1,
+			fillForegroundIcv: icvOf(fill.color),
+			fillBackgroundIcv: 65
+		};
+		case "pattern": {
+			const fillPattern = PATTERN_TYPE_TO_FILL_PATTERN.get(fill.patternType);
+			if (fillPattern === void 0) throw new BiffWriteError(`xls-codec cannot write a '${fill.patternType}' cell fill: [MS-XLS]'s own FillPattern enumeration has no member for it, that pattern name belonging only to WordprocessingML's ST_Shd half of ContentCellPatternType's shared vocabulary`);
+			return {
+				fillPattern,
+				fillForegroundIcv: fill.foregroundColor === void 0 ? 64 : icvOf(fill.foregroundColor),
+				fillBackgroundIcv: fill.backgroundColor === void 0 ? 65 : icvOf(fill.backgroundColor)
+			};
+		}
+		default: throw new BiffWriteError(`xls-codec cannot write a cell fill with kind '${unrecognizedFillKind(fill)}': ContentCellFillSchema's discriminated union only defines 'solid' and 'pattern'`);
+	}
+}
 /** A cell's own decoration, resolved into the raw XfDecorationFields the CellXF payload packs -- undefined for a cell with neither a background nor any border, so it shares the workbook's plain undecorated XF exactly as it did before decoration existed. The "has decoration at all" question is written-cells.ts's, since the writer's own record-emission predicate turns on the identical answer. */
 function resolveDecorationForCell(cell, icvOf) {
 	if (!cellCarriesFormatting(cell)) return;
 	return {
-		fillPattern: cell.background === void 0 ? 0 : 1,
-		fillForegroundIcv: cell.background === void 0 ? 64 : icvOf(cell.background),
+		...resolveFillFields(cell.background, icvOf),
 		left: resolveWriteEdge(cell.borders?.left, icvOf),
 		right: resolveWriteEdge(cell.borders?.right, icvOf),
 		top: resolveWriteEdge(cell.borders?.top, icvOf),
@@ -164,7 +197,7 @@ function resolveDecorationForCell(cell, icvOf) {
 function signatureOfCellXf(formatId, alignment, verticalAlignment, decoration) {
 	let signature = `f${formatId}|a${alignment ?? ""}|v${verticalAlignment ?? ""}`;
 	if (decoration === void 0) return signature;
-	signature += `|p${decoration.fillPattern}:${decoration.fillForegroundIcv}|l${decoration.left.style}:${decoration.left.icv}|r${decoration.right.style}:${decoration.right.icv}|t${decoration.top.style}:${decoration.top.icv}|b${decoration.bottom.style}:${decoration.bottom.icv}`;
+	signature += `|p${decoration.fillPattern}:${decoration.fillForegroundIcv}:${decoration.fillBackgroundIcv}|l${decoration.left.style}:${decoration.left.icv}|r${decoration.right.style}:${decoration.right.icv}|t${decoration.top.style}:${decoration.top.icv}|b${decoration.bottom.style}:${decoration.bottom.icv}`;
 	return signature;
 }
 /**

package/dist/{xf-colors-CpykR3B9.d.ts → xf-colors--5oxSeI1.d.ts}

@@ -1,10 +1,12 @@
 import { t as BlockCursor } from "./cursor-VMtw9uVP.js";
-import { Alignment, Color, ContentBorder } from "document-schema.js";
+import { Alignment, Color, ContentBorder, ContentCellFill, ContentCellPatternType } from "document-schema.js";
 //#region src/biff/xf-colors.d.ts
 /** FLSNULL: no fill pattern -- the cell's fill colour fields carry no meaning. */
 declare const FILL_PATTERN_NONE = 0;
-/** FLSSOLID: a solid fill, the only pattern this package maps onto ContentSheetCell.background -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). Every other pattern (50%/75%/25% gray, the stripe and crosshatch families, ...) is a real information-loss case this reader does not approximate: see resolveFillBackground below. */
+/** FLSSOLID: a solid fill -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). */
 declare const FILL_PATTERN_SOLID = 1;
+/** The inverse of FILL_PATTERN_TO_PATTERN_TYPE, built from it rather than restated by hand so the two can never drift apart. Every ContentCellPatternType this package's own writer is ever asked to state has an entry, since the SpreadsheetML half of the shared vocabulary is exactly FILL_PATTERN_TO_PATTERN_TYPE's own value set -- the WordprocessingML-only members (the percentN family and the stripe/cross families ST_Shd names) are absent, FillPattern having no equivalent for them at all. */
+declare const PATTERN_TYPE_TO_FILL_PATTERN: ReadonlyMap<ContentCellPatternType, number>;
 /** alc (a CellXF/StyleXF payload's word1, bits 0-2) -> ContentSheetCell.alignment, or undefined for ALCGEN (the value-kind default this field being absent already requests) and for the three HorizAlign members (ALCFILL/ALCCONTCTR/ALCDIST) Alignment has no member for -- matching ooxml.js's readHorizontalAlignment policy of only the four direct members surviving. */
 declare function resolveHorizontalAlignment(alc: number): Alignment | undefined;
 /** ContentSheetCell.alignment -> the alc token to pack into word1 -- undefined maps to ALCGEN, the "use the value-kind default" token every genuinely unaligned cell already carried before this module modelled alignment at all. */
@@ -56,12 +58,17 @@ interface XfBorderEdge {
 declare function resolveBorderEdge(edge: XfBorderEdge, palette: readonly Color[] | undefined): ContentBorder | undefined;
 /** The inverse of resolveBorderEdge's style resolution: picks the BorderStyle token carrying a ContentBorder's own pattern at the closest named weight, bucketing a solid/dashed border's widthPt back to a weight through document-schema.js's own shared quantisation -- the same one resolveBorderEdge's widths came out of, and the same one ooxml.js's borderToXlsxStyle buckets xlsx's string tokens through. */
 declare function borderStyleTokenFor(border: ContentBorder): number;
-/** A solid fill's own foreground colour resolved to a real background, or undefined for every other FillPattern value -- FLSNULL (no fill at all) and every pattern beyond solid (50%/75%/25% gray, the stripe and crosshatch family) alike. A non-solid pattern is a real information-loss case rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its foreground colour alone would misrepresent what the cell actually shows -- see xls-codec's README for this package's own stated judgment call. */
-declare function resolveFillBackground(fillPattern: number, foregroundIcv: number, palette: readonly Color[] | undefined): Color | undefined;
-/** Every decoration field the trailing payload's word2/word3/word4 carry ([MS-XLS] 2.4.353's own CellXF/StyleXF "Data" field), read or write side alike: which fill pattern (if any) and its foreground colour, and each of the four sides' own border style plus colour. Diagonal borders (dgDiag/grbitDiag/icvDiag) are out of this package's scope -- ContentCellBordersSchema has no diagonal member -- and are always read as absent / always written as none. */
+/**
+ * Resolves a cell's own FillPattern/icvFore/icvBack triple to a real ContentCellFill (ExaDev/documents.js#951), or undefined for FLSNULL (no fill at all), for a reserved/unrecognised FillPattern value, or for FLSSOLID when its own icvFore does not resolve to a fixed RGB value (an "Automatic" or otherwise unmapped icv, which leaves nothing to state a solid fill's colour as).
+ *
+ * FLSSOLID resolves to a 'solid' fill of icvFore alone -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF), so icvBack carries no meaning for it and is never consulted. Every other named FillPattern resolves to a real 'pattern' fill via FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of icvFore/icvBack resolves to a real colour (either may be an "Automatic" icv this package cannot express as a fixed RGB value, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention).
+ */
+declare function resolveFillBackground(fillPattern: number, foregroundIcv: number, backgroundIcv: number, palette: readonly Color[] | undefined): ContentCellFill | undefined;
+/** Every decoration field the trailing payload's word2/word3/word4 carry ([MS-XLS] 2.4.353's own CellXF/StyleXF "Data" field), read or write side alike: which fill pattern (if any) and its foreground/background colours, and each of the four sides' own border style plus colour. fillBackgroundIcv carries no meaning for a solid fill (icvFore alone is rendered) but is real for every other named pattern, where it is the colour the pattern's gaps show through. Diagonal borders (dgDiag/grbitDiag/icvDiag) are out of this package's scope -- ContentCellBordersSchema has no diagonal member -- and are always read as absent / always written as none. */
 interface XfDecorationFields {
   readonly fillPattern: number;
   readonly fillForegroundIcv: number;
+  readonly fillBackgroundIcv: number;
   readonly left: XfBorderEdge;
   readonly right: XfBorderEdge;
   readonly top: XfBorderEdge;
@@ -88,4 +95,4 @@ declare function readLongRgbColor(cursor: BlockCursor): Color;
 /** The inverse of readLongRgbColor: a colour's own red/green/blue/reserved bytes, rounded to the nearest byte (the same rounding colorToRgbHex applies) -- exact for any colour this package itself constructed via rgbHexToColor, which is what write.ts's own palette-colour interning does. */
 declare function longRgbBytesOf(color: Color): readonly [number, number, number, number];
 //#endregion
-export { readLongRgbColor as A, XfAlignmentFields as C, horizAlignTokenFor as D, borderStyleTokenFor as E, resolveVerticalAlignment as F, unpackXfAlignment as I, unpackXfDecoration as L, resolveFillBackground as M, resolveHorizontalAlignment as N, longRgbBytesOf as O, resolveIcvColor as P, vertAlignTokenFor as R, UNDECORATED_XF_FIELDS as S, XfDecorationFields as T, FILL_PATTERN_SOLID as _, BORDER_STYLE_DOUBLE as a, PALETTE_BASE_ICV as b, BORDER_STYLE_MEDIUM_DASHDOT as c, BORDER_STYLE_NONE as d, BORDER_STYLE_SLANT_DASHDOT as f, FILL_PATTERN_NONE as g, DEFAULT_PALETTE_HEX_TO_ICV as h, BORDER_STYLE_DOTTED as i, resolveBorderEdge as j, packXfDecorationWords as k, BORDER_STYLE_MEDIUM_DASHDOTDOT as l, BORDER_STYLE_THIN as m, BORDER_STYLE_DASHDOTDOT as n, BORDER_STYLE_HAIR as o, BORDER_STYLE_THICK as p, BORDER_STYLE_DASHED as r, BORDER_STYLE_MEDIUM as s, BORDER_STYLE_DASHDOT as t, BORDER_STYLE_MEDIUM_DASHED as u, ICV_AUTOMATIC_BACKGROUND as v, XfBorderEdge as w, PALETTE_ENTRY_COUNT as x, ICV_AUTOMATIC_FOREGROUND as y };
+export { packXfDecorationWords as A, UNDECORATED_XF_FIELDS as C, borderStyleTokenFor as D, XfDecorationFields as E, resolveIcvColor as F, resolveVerticalAlignment as I, unpackXfAlignment as L, resolveBorderEdge as M, resolveFillBackground as N, horizAlignTokenFor as O, resolveHorizontalAlignment as P, unpackXfDecoration as R, PATTERN_TYPE_TO_FILL_PATTERN as S, XfBorderEdge as T, FILL_PATTERN_SOLID as _, BORDER_STYLE_DOUBLE as a, PALETTE_BASE_ICV as b, BORDER_STYLE_MEDIUM_DASHDOT as c, BORDER_STYLE_NONE as d, BORDER_STYLE_SLANT_DASHDOT as f, FILL_PATTERN_NONE as g, DEFAULT_PALETTE_HEX_TO_ICV as h, BORDER_STYLE_DOTTED as i, readLongRgbColor as j, longRgbBytesOf as k, BORDER_STYLE_MEDIUM_DASHDOTDOT as l, BORDER_STYLE_THIN as m, BORDER_STYLE_DASHDOTDOT as n, BORDER_STYLE_HAIR as o, BORDER_STYLE_THICK as p, BORDER_STYLE_DASHED as r, BORDER_STYLE_MEDIUM as s, BORDER_STYLE_DASHDOT as t, BORDER_STYLE_MEDIUM_DASHED as u, ICV_AUTOMATIC_BACKGROUND as v, XfAlignmentFields as w, PALETTE_ENTRY_COUNT as x, ICV_AUTOMATIC_FOREGROUND as y, vertAlignTokenFor as z };

package/dist/{xf-colors-CehHZtBy.d.cts → xf-colors-BB5MKq6R.d.cts}

@@ -1,10 +1,12 @@
 import { t as BlockCursor } from "./cursor-VMtw9uVP.cjs";
-import { Alignment, Color, ContentBorder } from "document-schema.js";
+import { Alignment, Color, ContentBorder, ContentCellFill, ContentCellPatternType } from "document-schema.js";
 //#region src/biff/xf-colors.d.ts
 /** FLSNULL: no fill pattern -- the cell's fill colour fields carry no meaning. */
 declare const FILL_PATTERN_NONE = 0;
-/** FLSSOLID: a solid fill, the only pattern this package maps onto ContentSheetCell.background -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). Every other pattern (50%/75%/25% gray, the stripe and crosshatch families, ...) is a real information-loss case this reader does not approximate: see resolveFillBackground below. */
+/** FLSSOLID: a solid fill -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF). */
 declare const FILL_PATTERN_SOLID = 1;
+/** The inverse of FILL_PATTERN_TO_PATTERN_TYPE, built from it rather than restated by hand so the two can never drift apart. Every ContentCellPatternType this package's own writer is ever asked to state has an entry, since the SpreadsheetML half of the shared vocabulary is exactly FILL_PATTERN_TO_PATTERN_TYPE's own value set -- the WordprocessingML-only members (the percentN family and the stripe/cross families ST_Shd names) are absent, FillPattern having no equivalent for them at all. */
+declare const PATTERN_TYPE_TO_FILL_PATTERN: ReadonlyMap<ContentCellPatternType, number>;
 /** alc (a CellXF/StyleXF payload's word1, bits 0-2) -> ContentSheetCell.alignment, or undefined for ALCGEN (the value-kind default this field being absent already requests) and for the three HorizAlign members (ALCFILL/ALCCONTCTR/ALCDIST) Alignment has no member for -- matching ooxml.js's readHorizontalAlignment policy of only the four direct members surviving. */
 declare function resolveHorizontalAlignment(alc: number): Alignment | undefined;
 /** ContentSheetCell.alignment -> the alc token to pack into word1 -- undefined maps to ALCGEN, the "use the value-kind default" token every genuinely unaligned cell already carried before this module modelled alignment at all. */
@@ -56,12 +58,17 @@ interface XfBorderEdge {
 declare function resolveBorderEdge(edge: XfBorderEdge, palette: readonly Color[] | undefined): ContentBorder | undefined;
 /** The inverse of resolveBorderEdge's style resolution: picks the BorderStyle token carrying a ContentBorder's own pattern at the closest named weight, bucketing a solid/dashed border's widthPt back to a weight through document-schema.js's own shared quantisation -- the same one resolveBorderEdge's widths came out of, and the same one ooxml.js's borderToXlsxStyle buckets xlsx's string tokens through. */
 declare function borderStyleTokenFor(border: ContentBorder): number;
-/** A solid fill's own foreground colour resolved to a real background, or undefined for every other FillPattern value -- FLSNULL (no fill at all) and every pattern beyond solid (50%/75%/25% gray, the stripe and crosshatch family) alike. A non-solid pattern is a real information-loss case rather than an oversight: ContentSheetCell.background models one flat colour, and approximating a striped or crosshatched fill as its foreground colour alone would misrepresent what the cell actually shows -- see xls-codec's README for this package's own stated judgment call. */
-declare function resolveFillBackground(fillPattern: number, foregroundIcv: number, palette: readonly Color[] | undefined): Color | undefined;
-/** Every decoration field the trailing payload's word2/word3/word4 carry ([MS-XLS] 2.4.353's own CellXF/StyleXF "Data" field), read or write side alike: which fill pattern (if any) and its foreground colour, and each of the four sides' own border style plus colour. Diagonal borders (dgDiag/grbitDiag/icvDiag) are out of this package's scope -- ContentCellBordersSchema has no diagonal member -- and are always read as absent / always written as none. */
+/**
+ * Resolves a cell's own FillPattern/icvFore/icvBack triple to a real ContentCellFill (ExaDev/documents.js#951), or undefined for FLSNULL (no fill at all), for a reserved/unrecognised FillPattern value, or for FLSSOLID when its own icvFore does not resolve to a fixed RGB value (an "Automatic" or otherwise unmapped icv, which leaves nothing to state a solid fill's colour as).
+ *
+ * FLSSOLID resolves to a 'solid' fill of icvFore alone -- "If this value is 1 ... then only icvFore is rendered" ([MS-XLS] CellXF), so icvBack carries no meaning for it and is never consulted. Every other named FillPattern resolves to a real 'pattern' fill via FILL_PATTERN_TO_PATTERN_TYPE, carrying whichever of icvFore/icvBack resolves to a real colour (either may be an "Automatic" icv this package cannot express as a fixed RGB value, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention).
+ */
+declare function resolveFillBackground(fillPattern: number, foregroundIcv: number, backgroundIcv: number, palette: readonly Color[] | undefined): ContentCellFill | undefined;
+/** Every decoration field the trailing payload's word2/word3/word4 carry ([MS-XLS] 2.4.353's own CellXF/StyleXF "Data" field), read or write side alike: which fill pattern (if any) and its foreground/background colours, and each of the four sides' own border style plus colour. fillBackgroundIcv carries no meaning for a solid fill (icvFore alone is rendered) but is real for every other named pattern, where it is the colour the pattern's gaps show through. Diagonal borders (dgDiag/grbitDiag/icvDiag) are out of this package's scope -- ContentCellBordersSchema has no diagonal member -- and are always read as absent / always written as none. */
 interface XfDecorationFields {
   readonly fillPattern: number;
   readonly fillForegroundIcv: number;
+  readonly fillBackgroundIcv: number;
   readonly left: XfBorderEdge;
   readonly right: XfBorderEdge;
   readonly top: XfBorderEdge;
@@ -88,4 +95,4 @@ declare function readLongRgbColor(cursor: BlockCursor): Color;
 /** The inverse of readLongRgbColor: a colour's own red/green/blue/reserved bytes, rounded to the nearest byte (the same rounding colorToRgbHex applies) -- exact for any colour this package itself constructed via rgbHexToColor, which is what write.ts's own palette-colour interning does. */
 declare function longRgbBytesOf(color: Color): readonly [number, number, number, number];
 //#endregion
-export { readLongRgbColor as A, XfAlignmentFields as C, horizAlignTokenFor as D, borderStyleTokenFor as E, resolveVerticalAlignment as F, unpackXfAlignment as I, unpackXfDecoration as L, resolveFillBackground as M, resolveHorizontalAlignment as N, longRgbBytesOf as O, resolveIcvColor as P, vertAlignTokenFor as R, UNDECORATED_XF_FIELDS as S, XfDecorationFields as T, FILL_PATTERN_SOLID as _, BORDER_STYLE_DOUBLE as a, PALETTE_BASE_ICV as b, BORDER_STYLE_MEDIUM_DASHDOT as c, BORDER_STYLE_NONE as d, BORDER_STYLE_SLANT_DASHDOT as f, FILL_PATTERN_NONE as g, DEFAULT_PALETTE_HEX_TO_ICV as h, BORDER_STYLE_DOTTED as i, resolveBorderEdge as j, packXfDecorationWords as k, BORDER_STYLE_MEDIUM_DASHDOTDOT as l, BORDER_STYLE_THIN as m, BORDER_STYLE_DASHDOTDOT as n, BORDER_STYLE_HAIR as o, BORDER_STYLE_THICK as p, BORDER_STYLE_DASHED as r, BORDER_STYLE_MEDIUM as s, BORDER_STYLE_DASHDOT as t, BORDER_STYLE_MEDIUM_DASHED as u, ICV_AUTOMATIC_BACKGROUND as v, XfBorderEdge as w, PALETTE_ENTRY_COUNT as x, ICV_AUTOMATIC_FOREGROUND as y };
+export { packXfDecorationWords as A, UNDECORATED_XF_FIELDS as C, borderStyleTokenFor as D, XfDecorationFields as E, resolveIcvColor as F, resolveVerticalAlignment as I, unpackXfAlignment as L, resolveBorderEdge as M, resolveFillBackground as N, horizAlignTokenFor as O, resolveHorizontalAlignment as P, unpackXfDecoration as R, PATTERN_TYPE_TO_FILL_PATTERN as S, XfBorderEdge as T, FILL_PATTERN_SOLID as _, BORDER_STYLE_DOUBLE as a, PALETTE_BASE_ICV as b, BORDER_STYLE_MEDIUM_DASHDOT as c, BORDER_STYLE_NONE as d, BORDER_STYLE_SLANT_DASHDOT as f, FILL_PATTERN_NONE as g, DEFAULT_PALETTE_HEX_TO_ICV as h, BORDER_STYLE_DOTTED as i, readLongRgbColor as j, longRgbBytesOf as k, BORDER_STYLE_MEDIUM_DASHDOTDOT as l, BORDER_STYLE_THIN as m, BORDER_STYLE_DASHDOTDOT as n, BORDER_STYLE_HAIR as o, BORDER_STYLE_THICK as p, BORDER_STYLE_DASHED as r, BORDER_STYLE_MEDIUM as s, BORDER_STYLE_DASHDOT as t, BORDER_STYLE_MEDIUM_DASHED as u, ICV_AUTOMATIC_BACKGROUND as v, XfAlignmentFields as w, PALETTE_ENTRY_COUNT as x, ICV_AUTOMATIC_FOREGROUND as y, vertAlignTokenFor as z };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xls-codec",
-  "version": "2.0.2",
+  "version": "3.0.0",
   "description": "Hand-written reader for the legacy Excel Binary File Format (.xls, BIFF8) as specified by [MS-XLS], mapping a workbook's record stream onto the shared document-schema.js spreadsheet model - the .xls codec for the documents.js family.",
   "type": "module",
   "repository": {
@@ -68,9 +68,9 @@
   },
   "packageManager": "pnpm@11.6.0",
   "dependencies": {
-    "archive-codec": "^1.4.2",
-    "document-schema.js": "^5.6.0",
-    "excel-number-format": "^1.0.1"
+    "archive-codec": "^1.4.3",
+    "document-schema.js": "^6.0.0",
+    "excel-number-format": "^1.0.2"
   },
   "devDependencies": {
     "@arethetypeswrong/cli": "^0.18.5",