doc-codec 1.1.2 → 2.1.0

package/dist/table/decoration.cjs

@@ -2,6 +2,7 @@ Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
 const require_errors = require("../errors.cjs");
 const require_bytes = require("../bytes.cjs");
 const require_color = require("../color.cjs");
+let document_schema_js = require("document-schema.js");
 //#region src/table/decoration.ts
 /** The four sides of a cell, in the order TC80 declares them ([MS-DOC] 2.9.313: brcTop, brcLeft, brcBottom, brcRight). Used as the iteration order for both directions, so a side can never be read from one offset and written to another. */
 const CELL_BORDER_SIDES = [
@@ -78,6 +79,10 @@ const EIGHTHS_PER_POINT = 8;
 const MIN_DPT_LINE_WIDTH = 2;
 /** dptLineWidth is a single byte, so 255 eighths (31.875pt) is the widest border the format can state at all. */
 const MAX_DPT_LINE_WIDTH = 255;
+/** For BrcType 0x03 (ECMA-376 ST_Border 'double') specifically, dptLineWidth states the width of one of the border's two lines, with the gap between them the same width again, rather than the border's own total rendered width -- neither [MS-DOC] nor [ECMA-376] says so in words, but LibreOffice's own WW8 border-width conversion (editeng/source/items/borderline.cxx: BorderWidthImpl for SvxBorderLineStyle::DOUBLE splits a total width into three equal 1/3 shares for line/gap/line on import, and ConvertBorderWidthToWord divides a total width by 3 on export) states it in code, and this package's own measurements agree with that split exactly: a dptLineWidth of 5 read from a genuine LibreOffice-authored file tripled to 15 eighths (1.875pt) is what LibreOffice's own re-export calls the identical border ~1.8pt double (the small remaining gap is LibreOffice's own twip-rounding on the way through its internal representation, not a further disagreement), and writing a 2pt double border under the pre-fix formula (dptLineWidth 16, i.e. widthPt taken as the field directly) came back from LibreOffice as 6pt double -- 16 read as a single line's width and tripled is exactly 6pt. Scoped to the literal 0x03 value rather than every brcType BRC_TYPE_STYLE collapses onto 'double': the same ConvertBorderWidthToWord gives most of the others their own explicit ratio too, not none -- fWidth/2.0 for THINTHICK_MEDIUMGAP/THICKTHIN_MEDIUMGAP/EMBOSSED/ENGRAVED (BrcTypes 0x0e/0x0f/0x18/0x19), a fixed line/gap width subtracted from the total for THINTHICK_SMALLGAP/THINTHICK_LARGEGAP/THICKTHIN_SMALLGAP/THICKTHIN_LARGEGAP (0x0b/0x11/0x0c/0x12), and that same subtraction halved afterwards for OUTSET/INSET (0x1a/0x1b) -- `std::max(1.0, (fWidth - OUTSET_line1) / 2.0)` and its INSET mirror, not a bare subtraction the way the SMALLGAP/LARGEGAP quartet's own formulas are -- known ratios this package deliberately does not apply, not unknown ones, because BRC_TYPE_STYLE has already collapsed every one of those, plus triple, the three-line thinThickThin gap variants, and doubleWave (none of which LibreOffice's own WW8 exporter writes at all, having no SvxBorderLineStyle member for them), onto ContentStrokeStyle's single 'double' member by the time a ContentBorder reaches dptLineWidthFor on write, so there is no way left to tell which family a given widthPt came from and therefore no way to choose the right one of even the formulas that are known; literal 0x03 is the one case free of that ambiguity, since it is the only BrcType every format in this family's own 'double' token (OOXML's w:val="double", ODF's fo:border-* double) and ContentStrokeStyle's own 'double' member actually mean. Reading one of the other 23 collapsed BrcTypes therefore still reports dptLineWidth's own untripled value as widthPt -- an approximation of unknown accuracy even before this correction existed -- and writing that value back re-emits it as a literal 0x03 with this multiplier applied regardless, a further, compounding approximation on an already-lossy round trip for that narrow, WW8-only decorative corner; decoration.test.ts pins this explicitly rather than leaving it a silent surprise. */
+const DOUBLE_BORDER_WIDTH_MULTIPLIER = 3;
+/** The lowest non-zero dptLineWidth this writer will ever store for a BRC_TYPE_DOUBLE border's own one-third-of-total field, once DOUBLE_BORDER_WIDTH_MULTIPLIER's own division has been applied -- not MIN_DPT_LINE_WIDTH's floor of 2, which belongs to a field that states a border's whole width directly. [MS-DOC]'s "values of less than 2 are considered to be equivalent to 2" is a read-side interpretation rule, not a constraint a producer's own writer has to respect when choosing what to store: LibreOffice's own WW8 export (sw/source/filter/ww8/ww8atr.cxx, TranslateBorderLine, calling editeng's ConvertBorderWidthToWord) applies two separate floors in two different units at two different stages, not one shared floor -- ConvertBorderWidthToWord's own std::max(1.0, fWidth / 3.0) floors double's one-third share to 1.0 twip while the value is still in twips; the result is then converted to eighths-of-a-point ("nWidth = ((nWidth * 8) + 10) / 20", an integer, rounding conversion), which truncates that 1-twip minimum straight down to 0; only then does the "if (0 == nWidth) nWidth = 1; // really thin line, don't omit" floor re-raise it, to 1 eighth-of-a-point (2.5 twips) -- a different, larger unit than the 1.0 twip the first floor stated. The two are analogous in pattern (each is its own never-quite-zero minimum-of-1 rule) but not identical in value, and it is the second, eighths-of-a-point floor MIN_DPT_LINE_WIDTH_DOUBLE mirrors, since that is the one that actually survives into the written BRC. Keeping the general single-line refusal at 2 (MIN_DPT_LINE_WIDTH, a genuinely different field-to-width relationship) while giving double its own floor of 1 keeps refusal for a width the format truly cannot state at all -- below roughly 0.1875pt total, where even a tripled dptLineWidth of 1 rounds down to 0 -- rather than at 0.5625pt, a threshold that only exists as an artefact of applying MIN_DPT_LINE_WIDTH's single-line floor after dividing by three and that no real producer observes: Word's own UI default border width (ooxml.js's own DEFAULT_BORDER_WIDTH_EIGHTH_POINTS, 0.5pt) would otherwise be unwritable as a double border at all. */
+const MIN_DPT_LINE_WIDTH_DOUBLE = 1;
 /** The colour a border with no colour of its own resolves to. [MS-DOC]'s automatic colour (Ico 0x00, or a COLORREF with fAuto set) "designates the default color for the application" and names no components, but ContentBorder.color is required, so a border stating one has to resolve to something. Black is what an automatic border renders as against a default background, and resolving to it keeps the border itself -- which genuinely exists and genuinely renders -- rather than dropping the border outright to avoid stating a colour for it. */
 const AUTOMATIC_BORDER_COLOR = {
 	r: 0,
@@ -87,9 +92,11 @@ const AUTOMATIC_BORDER_COLOR = {
 function borderFrom(dptLineWidth, brcType, color) {
 	const style = BRC_TYPE_STYLE[brcType];
 	if (style === void 0) return void 0;
+	const lineWidthEighths = Math.max(dptLineWidth, MIN_DPT_LINE_WIDTH);
+	const widthEighths = brcType === BRC_TYPE_DOUBLE ? lineWidthEighths * DOUBLE_BORDER_WIDTH_MULTIPLIER : lineWidthEighths;
 	const border = {
 		color: color ?? AUTOMATIC_BORDER_COLOR,
-		widthPt: Math.max(dptLineWidth, MIN_DPT_LINE_WIDTH) / EIGHTHS_PER_POINT
+		widthPt: widthEighths / EIGHTHS_PER_POINT
 	};
 	if (style !== "solid") border.style = style;
 	return border;
@@ -113,6 +120,24 @@ function readBrc(bytes, offset) {
 	if (brcType === BRC_TYPE_NONE) return void 0;
 	return borderFrom(require_bytes.readUint8(bytes, offset + 4), brcType, require_color.readColorRef(bytes, offset));
 }
+function readTableBordersFields(operand, fieldSize, readField) {
+	return {
+		top: readField(operand, 1),
+		left: readField(operand, 1 + fieldSize),
+		bottom: readField(operand, 1 + fieldSize * 2),
+		right: readField(operand, 1 + fieldSize * 3),
+		insideHorizontal: readField(operand, 1 + fieldSize * 4),
+		insideVertical: readField(operand, 1 + fieldSize * 5)
+	};
+}
+/** TableBordersOperand's own 49 bytes ([MS-DOC] 2.9.302): cb (1 byte, MUST be 0x30) then six real Brc fields (8 bytes each, 2.9.16) back to back -- brcTop, brcLeft, brcBottom, brcRight, brcHorizontalInside, brcVerticalInside -- each an exact COLORREF exactly like sprmTSetBrc's own per-cell layer. */
+function readTableBordersOperand(operand) {
+	return readTableBordersFields(operand, 8, readBrc);
+}
+/** TableBordersOperand80's own 25 bytes ([MS-DOC] 2.9.303): the Word 97-era spelling, cb (1 byte, MUST be 0x18) then the same six fields as Brc80MayBeNil (4 bytes each, 2.9.18), palette-indexed exactly like TC80's own Brc80 fields. */
+function readTableBordersOperand80(operand) {
+	return readTableBordersFields(operand, 4, readBrc80);
+}
 /** Brc80MayBeNil's own no-border value, [MS-DOC] 2.9.18: "When all bits are set (0xFFFFFFFF when interpreted as a 4-byte unsigned integer), this structure specifies that the region in question has no border." */
 const NIL_BRC80 = [
 	255,
@@ -120,28 +145,36 @@ const NIL_BRC80 = [
 	255,
 	255
 ];
-/** dptLineWidth for a border of `widthPt`, in the 1/8-point increments [MS-DOC] states it in. Refuses a width the single-byte field cannot hold rather than silently clamping it to a thinner border than the caller asked for, matching how every other out-of-range operand in this writer is handled. */
-function dptLineWidthFor(widthPt) {
-	const eighths = Math.round(widthPt * EIGHTHS_PER_POINT);
-	if (eighths < MIN_DPT_LINE_WIDTH || eighths > MAX_DPT_LINE_WIDTH) throw new require_errors.DocFormatError(`a table cell border is ${widthPt}pt, outside the ${MIN_DPT_LINE_WIDTH / EIGHTHS_PER_POINT}..${MAX_DPT_LINE_WIDTH / EIGHTHS_PER_POINT}pt range [MS-DOC]'s own single-byte dptLineWidth can state in 1/8-point increments`);
+/** dptLineWidth for a border of `widthPt` rendered as `brcType`, in the 1/8-point increments [MS-DOC] states it in. For BRC_TYPE_DOUBLE, `widthPt` is the border's own total rendered width and the field holds one third of it (see DOUBLE_BORDER_WIDTH_MULTIPLIER's own note); every other brcType states `widthPt` directly. Refuses a width the single-byte field cannot hold rather than silently clamping it to a thinner border than the caller asked for, matching how every other out-of-range operand in this writer is handled -- the minimum itself is brcType-dependent (see MIN_DPT_LINE_WIDTH_DOUBLE's own note for why double's own floor is lower than the general one). Accepting a width does not mean it always survives a round trip unchanged, though: for any `double` `widthPt` in the 0.1875pt (inclusive) to 0.5625pt (exclusive) range, the stored dptLineWidth is exactly 1 -- the one value MIN_DPT_LINE_WIDTH_DOUBLE permits that MIN_DPT_LINE_WIDTH would not -- and borderFrom's own read-side floor then raises that 1 to 2 before DOUBLE_BORDER_WIDTH_MULTIPLIER's tripling applies, so e.g. a border written at 0.5pt reads back as 0.75pt, 50% wider than requested. This is a real, [MS-DOC]-consistent narrowing this function deliberately accepts rather than refuses ("values less than 2 are considered to be equivalent to 2" is exactly what a real producer's own reader would apply to the identical bytes), not a silent bug -- decoration.test.ts pins the exact numbers. */
+function dptLineWidthFor(widthPt, brcType) {
+	const multiplier = brcType === BRC_TYPE_DOUBLE ? DOUBLE_BORDER_WIDTH_MULTIPLIER : 1;
+	const minEighths = brcType === BRC_TYPE_DOUBLE ? MIN_DPT_LINE_WIDTH_DOUBLE : MIN_DPT_LINE_WIDTH;
+	const eighths = Math.round(widthPt / multiplier * EIGHTHS_PER_POINT);
+	if (eighths < minEighths || eighths > MAX_DPT_LINE_WIDTH) {
+		const minPt = (minEighths - .5) * multiplier / EIGHTHS_PER_POINT;
+		const maxPt = 255.5 * multiplier / EIGHTHS_PER_POINT;
+		throw new require_errors.DocFormatError(`a table cell border is ${widthPt}pt, outside the ${minPt}..${maxPt}pt range [MS-DOC]'s own single-byte dptLineWidth can state in 1/8-point increments${brcType === BRC_TYPE_DOUBLE ? " of one line's own width, a double border's field being one third of its total rendered width" : ""}`);
+	}
 	return eighths;
 }
 /** One TC80 border field's own four bytes: the Brc80MayBeNil no-border sentinel for an absent border, otherwise a real Brc80 whose colour is the nearest Ico the fixed palette offers (see color.ts's nearestIco, and borderNeedsExactColor for how the exact colour still reaches the file). dptSpace, fShadow and fFrame are always zero -- ContentBorder models none of the three, so writing anything else would be inventing a fact the input never stated. */
 function writeBrc80(border) {
 	if (border === void 0) return [...NIL_BRC80];
+	const brcType = STYLE_BRC_TYPE[border.style ?? "solid"];
 	return [
-		dptLineWidthFor(border.widthPt),
-		STYLE_BRC_TYPE[border.style ?? "solid"],
+		dptLineWidthFor(border.widthPt, brcType),
+		brcType,
 		require_color.nearestIco(border.color),
 		0
 	];
 }
 /** One TableBrcOperand.brc field's own eight bytes: a real Brc carrying the border's colour exactly, as a COLORREF rather than a palette index. Only ever called for a border that exists, since a TableBrcOperand naming no sides is never emitted at all. */
 function writeBrc(border) {
+	const brcType = STYLE_BRC_TYPE[border.style ?? "solid"];
 	return [
 		...require_color.colorRefBytes(border.color),
-		dptLineWidthFor(border.widthPt),
-		STYLE_BRC_TYPE[border.style ?? "solid"],
+		dptLineWidthFor(border.widthPt, brcType),
+		brcType,
 		0,
 		0
 	];
@@ -154,41 +187,118 @@ function borderNeedsExactColor(border) {
 	const approximated = require_color.colorRefBytes(palette);
 	return wanted[0] !== approximated[0] || wanted[1] !== approximated[1] || wanted[2] !== approximated[2];
 }
-/** ipatAuto, [MS-DOC] 2.9.121: "Clear, ST_Shd: clear" -- the pattern under which a cell simply shows its own cvBack, which is how both Word and LibreOffice spell a flat background colour, and the only pattern this package writes. */
+/** ipatAuto, [MS-DOC] 2.9.121: "Clear, ST_Shd: clear" -- the pattern under which a cell simply shows its own cvBack, which is how both Word and LibreOffice spell a flat background colour. */
 const IPAT_AUTO = 0;
 /** ipatSolid, [MS-DOC] 2.9.121: "Solid ST_Shd: solid" -- the cell is filled entirely with cvFore. */
 const IPAT_SOLID = 1;
 /**
-* One Shd ([MS-DOC] 2.9.247) as a flat background colour, or undefined where it states none.
+* Every Ipat value [MS-DOC] 2.9.121 maps onto a real ECMA-376 ST_Shd token, to the ContentCellPatternType name document-schema.js's own ContentCellPatternTypeSchema gives that same ST_Shd token (see that schema's own top comment for the full citation and the two vocabularies' shared naming rationale). ipatAuto and ipatSolid are handled by their own callers rather than listed here, since each resolves to a 'solid' fill, not a 'pattern' one. The sixteen ipatPctNew* fine percentages [MS-DOC] itself says "SHOULD NOT be used" (2.9.121's own note) and that have no ST_Shd equivalent at all -- 2.5%, 7.5%, 17.5%, 22.5%, 27.5%, 32.5%, 42.5%, 47.5%, 52.5%, 57.5%, 67.5%, 72.5%, 77.5%, 82.5%, 92.5%, 97.5% -- are deliberately absent, exactly as ContentCellPatternTypeSchema deliberately has no member for them; a cell stating one of these reads as no background, the same fallback every other genuinely unrepresentable Ipat value already resolves to.
+*/
+const IPAT_TO_PATTERN_TYPE = {
+	2: "percent5",
+	3: "percent10",
+	4: "percent20",
+	5: "percent25",
+	6: "percent30",
+	7: "percent40",
+	8: "percent50",
+	9: "percent60",
+	10: "percent70",
+	11: "percent75",
+	12: "percent80",
+	13: "percent90",
+	14: "horizontalStripe",
+	15: "verticalStripe",
+	16: "reverseDiagonalStripe",
+	17: "diagonalStripe",
+	18: "horizontalCross",
+	19: "diagonalCross",
+	20: "thinHorizontalStripe",
+	21: "thinVerticalStripe",
+	22: "thinReverseDiagonalStripe",
+	23: "thinDiagonalStripe",
+	24: "thinHorizontalCross",
+	25: "thinDiagonalCross",
+	37: "percent12",
+	38: "percent15",
+	43: "percent35",
+	44: "percent37",
+	46: "percent45",
+	49: "percent55",
+	51: "percent62",
+	52: "percent65",
+	57: "percent85",
+	58: "percent87",
+	60: "percent95"
+};
+/** The inverse of IPAT_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 Word-family half of the shared vocabulary is exactly IPAT_TO_PATTERN_TYPE's own value set -- the SpreadsheetML-only members (mediumGray through gray0625) are absent, ST_Shd having no equivalent for them at all. */
+const PATTERN_TYPE_TO_IPAT = new Map(Object.entries(IPAT_TO_PATTERN_TYPE).map(([ipat, patternType]) => [patternType, Number(ipat)]));
+/**
+* One Shd ([MS-DOC] 2.9.247) as a ContentCellFill, or undefined where it states none.
 *
-* Only the two patterns that genuinely produce a flat fill resolve: ipatAuto, under which the cell shows cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background), and ipatSolid, under which it shows cvFore. Every other Ipat -- the fourteen percentage fills, the stripe and crosshatch families, and ipatNil -- is a genuine pattern that Color cannot express, and reads as no background rather than as one of its two colours: reporting a 50% grey crosshatch as its own foreground colour would misstate what the cell actually shows. This is the same deliberate judgment xls-codec makes for BIFF8's own FillPattern enumeration, for the same reason, and it costs nothing on a round trip because this package's own writer emits ipatAuto and nothing else.
+* ipatAuto resolves to a 'solid' fill of cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background) and ipatSolid to a 'solid' fill of cvFore. Every other named Ipat resolves to a real 'pattern' fill via IPAT_TO_PATTERN_TYPE, carrying whichever of cvFore/cvBack the cell actually states -- either may be cvAuto (the application's own default) and therefore absent, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention. ipatNil and the sixteen ipatPctNew* values with no ST_Shd equivalent (see IPAT_TO_PATTERN_TYPE's own note) resolve to no background at all, the same fallback this reader has always used for a pattern it cannot express.
 *
-* A cvAuto colour under either pattern is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
+* A cvAuto colour under ipatAuto/ipatSolid is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
 */
 function readShd(bytes, offset) {
-	const ipat = require_bytes.readUint16LE(bytes, offset + 8);
-	if (ipat === IPAT_AUTO) return require_color.readColorRef(bytes, offset + 4);
-	if (ipat === IPAT_SOLID) return require_color.readColorRef(bytes, offset);
+	return shdFill(require_color.readColorRef(bytes, offset), require_color.readColorRef(bytes, offset + 4), require_bytes.readUint16LE(bytes, offset + 8));
 }
-/** One Shd's own ten bytes: cvFore left automatic and the background stated as cvBack under ipatAuto, which is exactly how LibreOffice 26.2.5.2 writes a cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000). An absent background writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
-function writeShd(background) {
-	return [
+/** Resolves one cvFore/cvBack/ipat triple -- however the caller sourced the three, whether from Shd's own COLORREFs (readShd) or Shd80's Ico-palette pair (readShd80) -- into the ContentCellFill readShd's own doc comment describes. Shared so the two callers can never disagree about what a given ipat means. */
+function shdFill(cvFore, cvBack, ipat) {
+	if (ipat === IPAT_AUTO) return cvBack === void 0 ? void 0 : {
+		kind: "solid",
+		color: cvBack
+	};
+	if (ipat === IPAT_SOLID) return cvFore === void 0 ? void 0 : {
+		kind: "solid",
+		color: cvFore
+	};
+	const patternType = IPAT_TO_PATTERN_TYPE[ipat];
+	if (patternType === void 0) return void 0;
+	return {
+		kind: "pattern",
+		patternType,
+		...cvFore !== void 0 ? { foregroundColor: cvFore } : {},
+		...cvBack !== void 0 ? { backgroundColor: cvBack } : {}
+	};
+}
+/** One Shd's own ten bytes, the inverse of readShd: a 'solid' fill states cvFore automatic and the fill's own colour as cvBack under ipatAuto, exactly how LibreOffice 26.2.5.2 writes a plain cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000) -- writing ipatSolid instead would be an equally spec-conformant alternative Shd never needed, since the two patterns are read identically apart from which COLORREF they draw from. A 'pattern' fill states its own foreground/background colours (automatic where the fill left one unstated) under the Ipat value PATTERN_TYPE_TO_IPAT names for it, throwing DocUnsupportedError for a SpreadsheetML-only pattern type ([MS-DOC]'s Ipat vocabulary has no member for one -- see PATTERN_TYPE_TO_IPAT's own note) rather than silently writing the wrong pattern or dropping it. An absent fill writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
+function writeShd(fill) {
+	if (fill === void 0) return [
+		...require_color.autoColorRefBytes(),
 		...require_color.autoColorRefBytes(),
-		...background === void 0 ? require_color.autoColorRefBytes() : require_color.colorRefBytes(background),
 		0,
 		0
 	];
+	switch (fill.kind) {
+		case "solid": return [
+			...require_color.autoColorRefBytes(),
+			...require_color.colorRefBytes(fill.color),
+			0,
+			0
+		];
+		case "pattern": {
+			const ipat = PATTERN_TYPE_TO_IPAT.get(fill.patternType);
+			if (ipat === void 0) throw new require_errors.DocUnsupportedError(`doc-codec cannot write a '${fill.patternType}' cell fill: [MS-DOC]'s own Ipat enumeration has no member for it, that pattern name belonging only to SpreadsheetML's ST_PatternType half of ContentCellPatternType's shared vocabulary`);
+			return [
+				...fill.foregroundColor === void 0 ? require_color.autoColorRefBytes() : require_color.colorRefBytes(fill.foregroundColor),
+				...fill.backgroundColor === void 0 ? require_color.autoColorRefBytes() : require_color.colorRefBytes(fill.backgroundColor),
+				ipat & 255,
+				ipat >> 8 & 255
+			];
+		}
+		default: throw new require_errors.DocUnsupportedError(`doc-codec cannot write a cell fill with kind '${(0, document_schema_js.unrecognizedFillKind)(fill)}': ContentCellFillSchema's discriminated union only defines 'solid' and 'pattern'`);
+	}
 }
 /** Shd80Nil, [MS-DOC] 2.9.248: icoFore 0x1F, icoBack 0x1F, ipat 0x3F -- every bit set, "specifies that no shading is applied", and explicitly exempt from the Ico and Ipat bounds the fields otherwise carry. */
 const SHD80_NIL = 65535;
-/** One Shd80 ([MS-DOC] 2.9.248) as a flat background colour: the same ipatAuto/ipatSolid reading readShd applies, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no background instead of aborting the whole document read. */
+/** One Shd80 ([MS-DOC] 2.9.248) as a ContentCellFill: the same Ipat vocabulary readShd resolves, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no concrete colour (the same fallback cvAuto already gets) instead of aborting the whole document read. */
 function readShd80(value) {
 	if (value === SHD80_NIL) return void 0;
 	const icoFore = value & 31;
 	const icoBack = value >> 5 & 31;
 	const ipat = value >> 10 & 63;
-	if (ipat === IPAT_AUTO) return require_color.decorativeIcoColor(icoBack);
-	if (ipat === IPAT_SOLID) return require_color.decorativeIcoColor(icoFore);
+	return shdFill(require_color.decorativeIcoColor(icoFore), require_color.decorativeIcoColor(icoBack), ipat);
 }
 /** A cell's four sides as a ContentCellBorders, or undefined when it has none -- the shape ContentTableCell.borders carries, with an absent side meaning that side has no border rather than an explicitly-null one. */
 function cellBordersFrom(sides) {
@@ -215,6 +325,8 @@ exports.readBrc = readBrc;
 exports.readBrc80 = readBrc80;
 exports.readShd = readShd;
 exports.readShd80 = readShd80;
+exports.readTableBordersOperand = readTableBordersOperand;
+exports.readTableBordersOperand80 = readTableBordersOperand80;
 exports.writeBrc = writeBrc;
 exports.writeBrc80 = writeBrc80;
 exports.writeShd = writeShd;

package/dist/table/decoration.d.cts

@@ -1,4 +1,4 @@
-import { Color, ContentBorder, ContentCellBorders } from "document-schema.js";
+import { ContentBorder, ContentCellBorders, ContentCellFill } from "document-schema.js";
 //#region src/table/decoration.d.ts
 /** The four sides of a cell, in the order TC80 declares them ([MS-DOC] 2.9.313: brcTop, brcLeft, brcBottom, brcRight). Used as the iteration order for both directions, so a side can never be read from one offset and written to another. */
 declare const CELL_BORDER_SIDES: readonly ["top", "left", "bottom", "right"];
@@ -17,6 +17,19 @@ declare const SHD80_SIZE = 2;
 declare function readBrc80(bytes: Uint8Array, offset: number): ContentBorder | undefined;
 /** The eight bytes of one TableBrcOperand.brc field: a BrcMayBeNil ([MS-DOC] 2.9.20) -- "If the last four bytes are 0xFFFFFFFF, the BrcMayBeNil is a NilBrc that specifies that the table cells in question have no border", otherwise a Brc ([MS-DOC] 2.9.16) whose own cv states the colour exactly. */
 declare function readBrc(bytes: Uint8Array, offset: number): ContentBorder | undefined;
+/** A row's own six-side border cascade, from sprmTTableBorders ([MS-DOC] 2.9.302) or the Word 97-era sprmTTableBorders80 ([MS-DOC] 2.9.303) -- the layer table/tap.ts's own top-of-file note calls "a cascade above the per-cell layer rather than another spelling of it". Both structures always state all six fields (there is no bordersToApply-style subset the way TableBrcOperand has), in the same order: brcTop, brcLeft, brcBottom, brcRight, brcHorizontalInside (the border between this row and its table neighbours), brcVerticalInside (the border between this row's own cells). Left unresolved onto any particular cell here: which of the six reaches a given cell/side depends on that cell's position in the WHOLE table -- is this the table's first row; does this cell reach the table's real bottom edge (the table's own last physical row directly, or any non-continuation cell -- a plain cell or a vertically-merged anchor -- whose own merge chain's last row no later row covers at all in a ragged table, a plain cell being the length-one special case of that chain); is this row's first or last physical cell -- which only table/read.ts's own cross-row assembly knows -- see its applyRowLevelBorderCascade and cellReachesTableBottom. */
+interface TableBordersSet {
+  readonly top?: ContentBorder;
+  readonly left?: ContentBorder;
+  readonly bottom?: ContentBorder;
+  readonly right?: ContentBorder;
+  readonly insideHorizontal?: ContentBorder;
+  readonly insideVertical?: ContentBorder;
+}
+/** TableBordersOperand's own 49 bytes ([MS-DOC] 2.9.302): cb (1 byte, MUST be 0x30) then six real Brc fields (8 bytes each, 2.9.16) back to back -- brcTop, brcLeft, brcBottom, brcRight, brcHorizontalInside, brcVerticalInside -- each an exact COLORREF exactly like sprmTSetBrc's own per-cell layer. */
+declare function readTableBordersOperand(operand: Uint8Array): TableBordersSet;
+/** TableBordersOperand80's own 25 bytes ([MS-DOC] 2.9.303): the Word 97-era spelling, cb (1 byte, MUST be 0x18) then the same six fields as Brc80MayBeNil (4 bytes each, 2.9.18), palette-indexed exactly like TC80's own Brc80 fields. */
+declare function readTableBordersOperand80(operand: Uint8Array): TableBordersSet;
 /** One TC80 border field's own four bytes: the Brc80MayBeNil no-border sentinel for an absent border, otherwise a real Brc80 whose colour is the nearest Ico the fixed palette offers (see color.ts's nearestIco, and borderNeedsExactColor for how the exact colour still reaches the file). dptSpace, fShadow and fFrame are always zero -- ContentBorder models none of the three, so writing anything else would be inventing a fact the input never stated. */
 declare function writeBrc80(border: ContentBorder | undefined): number[];
 /** One TableBrcOperand.brc field's own eight bytes: a real Brc carrying the border's colour exactly, as a COLORREF rather than a palette index. Only ever called for a border that exists, since a TableBrcOperand naming no sides is never emitted at all. */
@@ -24,18 +37,18 @@ declare function writeBrc(border: ContentBorder): number[];
 /** Whether this border's colour survives the Ico palette Brc80 is limited to. When it does, TC80's own Brc80 already states the border exactly and the sprmTSetBrc precision layer would be pure duplication; when it does not, that layer is the only place the real colour can be stated. Compared on the written byte values rather than the floating-point components, so a colour that round-trips through colorRefBytes to the identical palette entry counts as exact. */
 declare function borderNeedsExactColor(border: ContentBorder): boolean;
 /**
- * One Shd ([MS-DOC] 2.9.247) as a flat background colour, or undefined where it states none.
+ * One Shd ([MS-DOC] 2.9.247) as a ContentCellFill, or undefined where it states none.
  *
- * Only the two patterns that genuinely produce a flat fill resolve: ipatAuto, under which the cell shows cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background), and ipatSolid, under which it shows cvFore. Every other Ipat -- the fourteen percentage fills, the stripe and crosshatch families, and ipatNil -- is a genuine pattern that Color cannot express, and reads as no background rather than as one of its two colours: reporting a 50% grey crosshatch as its own foreground colour would misstate what the cell actually shows. This is the same deliberate judgment xls-codec makes for BIFF8's own FillPattern enumeration, for the same reason, and it costs nothing on a round trip because this package's own writer emits ipatAuto and nothing else.
+ * ipatAuto resolves to a 'solid' fill of cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background) and ipatSolid to a 'solid' fill of cvFore. Every other named Ipat resolves to a real 'pattern' fill via IPAT_TO_PATTERN_TYPE, carrying whichever of cvFore/cvBack the cell actually states -- either may be cvAuto (the application's own default) and therefore absent, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention. ipatNil and the sixteen ipatPctNew* values with no ST_Shd equivalent (see IPAT_TO_PATTERN_TYPE's own note) resolve to no background at all, the same fallback this reader has always used for a pattern it cannot express.
  *
- * A cvAuto colour under either pattern is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
+ * A cvAuto colour under ipatAuto/ipatSolid is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
  */
-declare function readShd(bytes: Uint8Array, offset: number): Color | undefined;
-/** One Shd's own ten bytes: cvFore left automatic and the background stated as cvBack under ipatAuto, which is exactly how LibreOffice 26.2.5.2 writes a cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000). An absent background writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
-declare function writeShd(background: Color | undefined): number[];
-/** One Shd80 ([MS-DOC] 2.9.248) as a flat background colour: the same ipatAuto/ipatSolid reading readShd applies, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no background instead of aborting the whole document read. */
-declare function readShd80(value: number): Color | undefined;
+declare function readShd(bytes: Uint8Array, offset: number): ContentCellFill | undefined;
+/** One Shd's own ten bytes, the inverse of readShd: a 'solid' fill states cvFore automatic and the fill's own colour as cvBack under ipatAuto, exactly how LibreOffice 26.2.5.2 writes a plain cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000) -- writing ipatSolid instead would be an equally spec-conformant alternative Shd never needed, since the two patterns are read identically apart from which COLORREF they draw from. A 'pattern' fill states its own foreground/background colours (automatic where the fill left one unstated) under the Ipat value PATTERN_TYPE_TO_IPAT names for it, throwing DocUnsupportedError for a SpreadsheetML-only pattern type ([MS-DOC]'s Ipat vocabulary has no member for one -- see PATTERN_TYPE_TO_IPAT's own note) rather than silently writing the wrong pattern or dropping it. An absent fill writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
+declare function writeShd(fill: ContentCellFill | undefined): number[];
+/** One Shd80 ([MS-DOC] 2.9.248) as a ContentCellFill: the same Ipat vocabulary readShd resolves, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no concrete colour (the same fallback cvAuto already gets) instead of aborting the whole document read. */
+declare function readShd80(value: number): ContentCellFill | undefined;
 /** A cell's four sides as a ContentCellBorders, or undefined when it has none -- the shape ContentTableCell.borders carries, with an absent side meaning that side has no border rather than an explicitly-null one. */
 declare function cellBordersFrom(sides: Readonly<Record<CellBorderSide, ContentBorder | undefined>>): ContentCellBorders | undefined;
 //#endregion
-export { BORDERS_TO_APPLY, BRC80_SIZE, BRC_SIZE, CELL_BORDER_SIDES, CellBorderSide, SHD80_SIZE, SHD_SIZE, borderNeedsExactColor, cellBordersFrom, readBrc, readBrc80, readShd, readShd80, writeBrc, writeBrc80, writeShd };
+export { BORDERS_TO_APPLY, BRC80_SIZE, BRC_SIZE, CELL_BORDER_SIDES, CellBorderSide, SHD80_SIZE, SHD_SIZE, TableBordersSet, borderNeedsExactColor, cellBordersFrom, readBrc, readBrc80, readShd, readShd80, readTableBordersOperand, readTableBordersOperand80, writeBrc, writeBrc80, writeShd };

package/dist/table/decoration.d.ts

@@ -1,4 +1,4 @@
-import { Color, ContentBorder, ContentCellBorders } from "document-schema.js";
+import { ContentBorder, ContentCellBorders, ContentCellFill } from "document-schema.js";
 //#region src/table/decoration.d.ts
 /** The four sides of a cell, in the order TC80 declares them ([MS-DOC] 2.9.313: brcTop, brcLeft, brcBottom, brcRight). Used as the iteration order for both directions, so a side can never be read from one offset and written to another. */
 declare const CELL_BORDER_SIDES: readonly ["top", "left", "bottom", "right"];
@@ -17,6 +17,19 @@ declare const SHD80_SIZE = 2;
 declare function readBrc80(bytes: Uint8Array, offset: number): ContentBorder | undefined;
 /** The eight bytes of one TableBrcOperand.brc field: a BrcMayBeNil ([MS-DOC] 2.9.20) -- "If the last four bytes are 0xFFFFFFFF, the BrcMayBeNil is a NilBrc that specifies that the table cells in question have no border", otherwise a Brc ([MS-DOC] 2.9.16) whose own cv states the colour exactly. */
 declare function readBrc(bytes: Uint8Array, offset: number): ContentBorder | undefined;
+/** A row's own six-side border cascade, from sprmTTableBorders ([MS-DOC] 2.9.302) or the Word 97-era sprmTTableBorders80 ([MS-DOC] 2.9.303) -- the layer table/tap.ts's own top-of-file note calls "a cascade above the per-cell layer rather than another spelling of it". Both structures always state all six fields (there is no bordersToApply-style subset the way TableBrcOperand has), in the same order: brcTop, brcLeft, brcBottom, brcRight, brcHorizontalInside (the border between this row and its table neighbours), brcVerticalInside (the border between this row's own cells). Left unresolved onto any particular cell here: which of the six reaches a given cell/side depends on that cell's position in the WHOLE table -- is this the table's first row; does this cell reach the table's real bottom edge (the table's own last physical row directly, or any non-continuation cell -- a plain cell or a vertically-merged anchor -- whose own merge chain's last row no later row covers at all in a ragged table, a plain cell being the length-one special case of that chain); is this row's first or last physical cell -- which only table/read.ts's own cross-row assembly knows -- see its applyRowLevelBorderCascade and cellReachesTableBottom. */
+interface TableBordersSet {
+  readonly top?: ContentBorder;
+  readonly left?: ContentBorder;
+  readonly bottom?: ContentBorder;
+  readonly right?: ContentBorder;
+  readonly insideHorizontal?: ContentBorder;
+  readonly insideVertical?: ContentBorder;
+}
+/** TableBordersOperand's own 49 bytes ([MS-DOC] 2.9.302): cb (1 byte, MUST be 0x30) then six real Brc fields (8 bytes each, 2.9.16) back to back -- brcTop, brcLeft, brcBottom, brcRight, brcHorizontalInside, brcVerticalInside -- each an exact COLORREF exactly like sprmTSetBrc's own per-cell layer. */
+declare function readTableBordersOperand(operand: Uint8Array): TableBordersSet;
+/** TableBordersOperand80's own 25 bytes ([MS-DOC] 2.9.303): the Word 97-era spelling, cb (1 byte, MUST be 0x18) then the same six fields as Brc80MayBeNil (4 bytes each, 2.9.18), palette-indexed exactly like TC80's own Brc80 fields. */
+declare function readTableBordersOperand80(operand: Uint8Array): TableBordersSet;
 /** One TC80 border field's own four bytes: the Brc80MayBeNil no-border sentinel for an absent border, otherwise a real Brc80 whose colour is the nearest Ico the fixed palette offers (see color.ts's nearestIco, and borderNeedsExactColor for how the exact colour still reaches the file). dptSpace, fShadow and fFrame are always zero -- ContentBorder models none of the three, so writing anything else would be inventing a fact the input never stated. */
 declare function writeBrc80(border: ContentBorder | undefined): number[];
 /** One TableBrcOperand.brc field's own eight bytes: a real Brc carrying the border's colour exactly, as a COLORREF rather than a palette index. Only ever called for a border that exists, since a TableBrcOperand naming no sides is never emitted at all. */
@@ -24,18 +37,18 @@ declare function writeBrc(border: ContentBorder): number[];
 /** Whether this border's colour survives the Ico palette Brc80 is limited to. When it does, TC80's own Brc80 already states the border exactly and the sprmTSetBrc precision layer would be pure duplication; when it does not, that layer is the only place the real colour can be stated. Compared on the written byte values rather than the floating-point components, so a colour that round-trips through colorRefBytes to the identical palette entry counts as exact. */
 declare function borderNeedsExactColor(border: ContentBorder): boolean;
 /**
- * One Shd ([MS-DOC] 2.9.247) as a flat background colour, or undefined where it states none.
+ * One Shd ([MS-DOC] 2.9.247) as a ContentCellFill, or undefined where it states none.
  *
- * Only the two patterns that genuinely produce a flat fill resolve: ipatAuto, under which the cell shows cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background), and ipatSolid, under which it shows cvFore. Every other Ipat -- the fourteen percentage fills, the stripe and crosshatch families, and ipatNil -- is a genuine pattern that Color cannot express, and reads as no background rather than as one of its two colours: reporting a 50% grey crosshatch as its own foreground colour would misstate what the cell actually shows. This is the same deliberate judgment xls-codec makes for BIFF8's own FillPattern enumeration, for the same reason, and it costs nothing on a round trip because this package's own writer emits ipatAuto and nothing else.
+ * ipatAuto resolves to a 'solid' fill of cvBack (ECMA-376's own `clear` shading with a fill colour, which is what a real producer writes for a plain cell background) and ipatSolid to a 'solid' fill of cvFore. Every other named Ipat resolves to a real 'pattern' fill via IPAT_TO_PATTERN_TYPE, carrying whichever of cvFore/cvBack the cell actually states -- either may be cvAuto (the application's own default) and therefore absent, matching ContentCellFillSchema's own "a colour can defer instead of asserting" convention. ipatNil and the sixteen ipatPctNew* values with no ST_Shd equivalent (see IPAT_TO_PATTERN_TYPE's own note) resolve to no background at all, the same fallback this reader has always used for a pattern it cannot express.
  *
- * A cvAuto colour under either pattern is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
+ * A cvAuto colour under ipatAuto/ipatSolid is likewise no background: it designates the application's own default, which for a cell background is "not shaded" rather than a colour to state. ShdAuto and ShdNil -- the two special values [MS-DOC] 2.9.247 names for "no shading is applied" -- both fall out of exactly that, with no separate check: each is a pair of cvAuto colours under ipatAuto.
  */
-declare function readShd(bytes: Uint8Array, offset: number): Color | undefined;
-/** One Shd's own ten bytes: cvFore left automatic and the background stated as cvBack under ipatAuto, which is exactly how LibreOffice 26.2.5.2 writes a cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000). An absent background writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
-declare function writeShd(background: Color | undefined): number[];
-/** One Shd80 ([MS-DOC] 2.9.248) as a flat background colour: the same ipatAuto/ipatSolid reading readShd applies, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no background instead of aborting the whole document read. */
-declare function readShd80(value: number): Color | undefined;
+declare function readShd(bytes: Uint8Array, offset: number): ContentCellFill | undefined;
+/** One Shd's own ten bytes, the inverse of readShd: a 'solid' fill states cvFore automatic and the fill's own colour as cvBack under ipatAuto, exactly how LibreOffice 26.2.5.2 writes a plain cell fill (confirmed against its own `.doc` output: a #ffff00 cell came back as cvFore cvAuto, cvBack `ff ff 00 00`, ipat 0x0000) -- writing ipatSolid instead would be an equally spec-conformant alternative Shd never needed, since the two patterns are read identically apart from which COLORREF they draw from. A 'pattern' fill states its own foreground/background colours (automatic where the fill left one unstated) under the Ipat value PATTERN_TYPE_TO_IPAT names for it, throwing DocUnsupportedError for a SpreadsheetML-only pattern type ([MS-DOC]'s Ipat vocabulary has no member for one -- see PATTERN_TYPE_TO_IPAT's own note) rather than silently writing the wrong pattern or dropping it. An absent fill writes ShdAuto -- the all-automatic value [MS-DOC] 2.9.247 defines as "no shading is applied" -- so an undecorated cell inside a row that has decorated ones still states its own lack of shading rather than inheriting a neighbour's. */
+declare function writeShd(fill: ContentCellFill | undefined): number[];
+/** One Shd80 ([MS-DOC] 2.9.248) as a ContentCellFill: the same Ipat vocabulary readShd resolves, over the Ico palette rather than COLORREFs. This is the Word 97-era spelling of cell shading, superseded by Shd but still written -- alongside it -- by a real producer, so a file carrying only this one still reads. Never written by this package, which states shading through Shd alone. icoFore/icoBack are each a 5-bit field, so a value the 17-entry palette cannot hold is a real possibility rather than a format-level impossibility; decorativeIcoColor resolves that case to no concrete colour (the same fallback cvAuto already gets) instead of aborting the whole document read. */
+declare function readShd80(value: number): ContentCellFill | undefined;
 /** A cell's four sides as a ContentCellBorders, or undefined when it has none -- the shape ContentTableCell.borders carries, with an absent side meaning that side has no border rather than an explicitly-null one. */
 declare function cellBordersFrom(sides: Readonly<Record<CellBorderSide, ContentBorder | undefined>>): ContentCellBorders | undefined;
 //#endregion
-export { BORDERS_TO_APPLY, BRC80_SIZE, BRC_SIZE, CELL_BORDER_SIDES, CellBorderSide, SHD80_SIZE, SHD_SIZE, borderNeedsExactColor, cellBordersFrom, readBrc, readBrc80, readShd, readShd80, writeBrc, writeBrc80, writeShd };
+export { BORDERS_TO_APPLY, BRC80_SIZE, BRC_SIZE, CELL_BORDER_SIDES, CellBorderSide, SHD80_SIZE, SHD_SIZE, TableBordersSet, borderNeedsExactColor, cellBordersFrom, readBrc, readBrc80, readShd, readShd80, readTableBordersOperand, readTableBordersOperand80, writeBrc, writeBrc80, writeShd };