Complex Tables in PIM and Publishing: Why They Become a Real Challenge
Simple at First Glance, Tricky in Practice
Tables exist to present multidimensional product information compactly and in a way that invites comparison: dimensions, materials, versions, or technical specifications can be set side by side at a glance instead of being described in long paragraphs of running text. That is exactly where their pitfall lies. Hardly any content type causes as much friction in PIM and publishing projects as the complex table.
Technical data sheets, size charts, comparison matrices, or feature overviews look simple at first glance, but in day-to-day management they often turn out to be one of the more demanding content elements. In consulting projects, the same pattern shows up around these tables again and again: they are barely maintainable in the system, and the layout breaks apart during publishing.
What actually makes a table complex?
A table becomes complex as soon as it goes beyond a simple row-column matrix. This includes cells merged across multiple rows or columns, nested tables within individual cells, a varying number of columns per row, and footnotes or references bound to individual cells. On top of that come variant-dependent cell values and localized units of measurement at the cell level.
A manufacturer of industrial valves, for example, maintains a table of pressure ratings, materials, and connection dimensions: depending on the variant selected, entire rows change, and the English version must additionally show inch instead of millimeter values.
Another form is calculated cell values that are derived from other cells instead of being maintained manually. A manufacturer of packaging solutions, for instance, shows package price and package size in a table, while the price per individual unit is calculated from these. If the package price changes, the derived value must adjust automatically, otherwise the two figures drift apart.
As soon as one of these characteristics is added, a simple attribute-value structure in the data model is no longer sufficient.
Why do PIM systems and web systems reach their limits with complex tables?
Most PIM data models are designed to assign individual attributes with a single value to each product, known in technical terms as the EAV principle, short for Entity-Attribute-Value. A table with a variable structure, row and column references, cell-specific formatting, and variant logic barely fits into this pattern.
Even established data standards for technical data sheets such as ETIM or BMEcat cover individual feature lists well, but are not designed for freely structured, multidimensional tables.
The practical consequence: editors maintain tables as embedded HTML fragments or as image files, because the native data model does not allow a structured representation. This, however, sacrifices versioning, cell-level multilingualism, and the reusability of individual table sections.
Why does PDF publishing become the second hurdle?
Even when a table is cleanly structured in the PIM, the next challenge begins at publishing. Layout engines for catalog or data sheet printing, such as priint:comet, need addressable cell structures in order to correctly implement column widths, page breaks within a table, and cell-specific formatting.
A table that wraps responsively on the web must instead fit exactly onto one page in a print layout, or continue in a controlled way across several pages, including a repeated header row.
The concrete technical implementation of this mapping lies within the responsibility of the respective publishing partner. From a PIM perspective, what matters is that the data source can deliver this structure cleanly in the first place.
What should a PIM or CMS offer for managing complex tables?
For tables to become genuinely manageable in day-to-day work, a PIM or CMS should bring a few prerequisites:
- A dedicated table type instead of an HTML fragment
Rows, columns, and individual cells can then be addressed and edited directly. An editor can, for example, change the value of a single cell in row 4, column 3, instead of opening the table's entire HTML code and searching for the right spot in it. - Merged cells and a variable number of columns per row
This keeps even unusual table shapes technically clean, such as a header row where "pressure rating" spans two columns while the actual values below it sit in separate columns. - Variants directly inside the table
When values differ depending on the product version, the system should be able to represent that without duplicating the table. In the valve example above, this means variant A automatically shows the values for variant A, and variant B the matching values, without maintaining two entirely separate tables. - Languages and units of measurement at the cell level
A single cell can, for example, be maintained in English with an inch value, independent of the rest of the table. Concretely: the "connection size" column shows "50 mm" in the German version and automatically "2 in" in the English version, without anyone rebuilding the table by hand for each language. - Versioning and reuse
A table maintained once, or even just part of one, can then be used across multiple products or publications. For example, a materials table that applies to an entire valve series: it is maintained once and then appears automatically in every single product data sheet of that series. If a value changes, it only has to be corrected in one place. - Separation of content and presentation
This allows the same table to be displayed responsively on the web while still fitting exactly in a print layout. In the online shop, the table collapses into individually expandable rows on a smartphone, while the same table appears in the printed catalog as a classic grid across the full page width, with both versions drawing on the same data source. - Accessible presentation on the web
This keeps tables understandable for users relying on screen readers. A screen reader can then automatically announce the corresponding column heading when reading out a cell, such as "connection size: 50 mm", instead of just reading out the bare number.
Conclusion
Complex tables are not a side topic; they are a litmus test for the data model quality of a PIM system. Anyone who thinks of table structures from the start as their own structured object type with cell references, variant logic, and multilingualism reduces the manual rework that otherwise arises at the latest during PDF publishing.
Are you facing exactly these challenges in managing or publishing complex tables? We are happy to advise you on how your table structures can be represented cleanly. NovaDB, as a headless CMS and PIM system, is a suitable tool for this: it represents even highly complex tables in a structured way and supports their management across variants, languages, and publication channels.
Yes, provided the PIM offers a dedicated table type with addressable cells. A nested table is then stored as its own reference within the parent cell instead of being embedded as an HTML fragment.
Through language-dependent cell values: the same cell shows, for example, "50 mm" in the German version and automatically "2 in" in the English version, without rebuilding the table for each language.
A calculated cell value, such as the price per individual unit, is derived from other cells like package price and package size. If the package price changes, the derived value adjusts automatically instead of being maintained manually.
An HTML fragment can be displayed, but it cannot be edited in a structured way, versioned, or adapted per language and cell. This loses exactly the properties that make complex tables manageable in day-to-day work.
