Exporting the shipped right-to-left examples to Word shows documents that read correctly and look nothing like the source. Some of that is inherent — the DOCX backend is semantic, so Word reflows rather than honouring absolute placement. But three of the biggest differences are missing mapping, not missing capability: Word can express all three.
Measured on hebrew-invoice.docx (the invoice's line items are rows):
|
source |
what Word gets |
| row borders |
none |
9 tables, every one with <w:tblBorders> all single — a full grid |
row fillColor (header band, zebra) |
2 fills |
0 <w:shd> — dropped |
addDivider |
3 |
dropped entirely — no DividerNode/LineNode handling in the backend |
1. Row-tables ship POI's default gridlines
writeRow represents a row as a one-row table so the cells sit side by side, and never touches borders — so POI's createTable default lands: single on top/left/bottom/right/insideH/insideV. The source row has no border at all. This is the single biggest contributor to the look, and the fix is to write w:tblBorders = none for a row-table (a real TableNode should keep its own resolved stroke instead).
2. Cell fills are dropped
RowBuilder.fillColor(...) and a table's resolved cell fill have a direct Word counterpart, <w:shd w:fill="RRGGBB"/>, and nothing writes it. The invoice's header band and zebra rows come out white.
3. Dividers are dropped
addDivider(...) produces a node the backend does not handle, so it is warned and skipped. Word's counterpart is a paragraph bottom border (w:pBdr/w:bottom), which is exactly a horizontal rule and is how Word itself draws one.
What stays inherent
Absolute placement, corner radii, exact gaps and padding, and anything positioned rather than flowed. A semantic export is a Word document, not a picture of a page — that part is by design and belongs in the capability matrix rather than in a fix.
Exporting the shipped right-to-left examples to Word shows documents that read correctly and look nothing like the source. Some of that is inherent — the DOCX backend is semantic, so Word reflows rather than honouring absolute placement. But three of the biggest differences are missing mapping, not missing capability: Word can express all three.
Measured on
hebrew-invoice.docx(the invoice's line items are rows):<w:tblBorders>allsingle— a full gridfillColor(header band, zebra)<w:shd>— droppedaddDividerDividerNode/LineNodehandling in the backend1. Row-tables ship POI's default gridlines
writeRowrepresents a row as a one-row table so the cells sit side by side, and never touches borders — so POI'screateTabledefault lands:singleon top/left/bottom/right/insideH/insideV. The source row has no border at all. This is the single biggest contributor to the look, and the fix is to writew:tblBorders=nonefor a row-table (a realTableNodeshould keep its own resolved stroke instead).2. Cell fills are dropped
RowBuilder.fillColor(...)and a table's resolved cell fill have a direct Word counterpart,<w:shd w:fill="RRGGBB"/>, and nothing writes it. The invoice's header band and zebra rows come out white.3. Dividers are dropped
addDivider(...)produces a node the backend does not handle, so it is warned and skipped. Word's counterpart is a paragraph bottom border (w:pBdr/w:bottom), which is exactly a horizontal rule and is how Word itself draws one.What stays inherent
Absolute placement, corner radii, exact gaps and padding, and anything positioned rather than flowed. A semantic export is a Word document, not a picture of a page — that part is by design and belongs in the capability matrix rather than in a fix.