LTEM: LLM-Friendly Table-Enhanced Markdown for Table Understanding and Generation

# LTEM: LLM-Friendly Table-Enhanced Markdown for Table Understanding and Generation
Source: [https://arxiv.org/html/2610.29188](https://arxiv.org/html/2610.29188)
Eunbin Kim, Hyeonseok Kang, Sangkeun Jung††thanks:Corresponding author\.Email:[\{eunbinkim777,dnfldjaak11,hugmanskj\}@gmail\.com](mailto:)Affiliation:Department of Computer Science and EngineeringChungnam National University, Republic of KoreaAffiliation:EurekaAI

###### Abstract

Tables in real\-world documents, including scientific papers, financial reports, and statistical summaries, frequently use merged cells, multi\-level headers, and sectioned layouts\. Yet the lightweight formats LLMs handle best \(Markdown, CSV\) cannot express these structures, while expressive formats \(HTML, LaTeX\) impose excessive token cost and parsing complexity\. To enable systematic analysis of this trade\-off, we introduce ataxonomydecomposing table structure into six atomic features \(F1–F6\) and corresponding complexity levels \(L1–L6\), and constructSTB\(Synthetic Table Benchmark\), a controlled benchmark with 1,089 tables systematically distributed across complexity levels\. Using this framework, we proposeLTEM\(LLM\-friendly Table\-Enhanced Markdown\), a formally specified, minimal extension of Markdown that explicitly encodes spans and hierarchical headers\. Experiments across five state\-of\-the\-art LLMs show that LTEM achieves accuracy comparable to HTML, offers a favorable accuracy–token trade\-off relative to HTML and LaTeX, and produces substantially fewer invalid responses than LaTeX; for table generation, LTEM is comparable to MultiMarkdown though HTML is best\. We release our taxonomy, benchmark, and format specification to support future research on LLM\-table interaction\.

## 1Introduction

LLMs excel at natural language tasks, yet many practical applications, including document editing, report writing, and data summarization, require tables\. Because tables are two\-dimensional while LLM inputs are linear, models must reconstruct header roles, spans, and hierarchies from serialized text, making performance sensitive to therepresentation format\.

Recent work confirms that format choice matters: identical tables yield different performance depending on serialization, delimiters, and ordering\([Sui et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib24);[Li et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib20);[Wu et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib9)\)\. However, existing studies provide limited tools for comparingwhat structural informationeach format preserves\.

Real\-world tables often include merged cells, multi\-level headers, and sectioned layouts\. Lightweight formats \(Markdown, CSV\) are easy for LLMs but cannot faithfully express these structures, while expressive formats \(HTML, LaTeX\) are verbose and increase token cost and parsing burden\. For example, GitHub\-Flavored Markdown \(GFM\) defines pipe\-delimited tables\([GitHub, 2019](https://arxiv.org/html/2610.29188#bib.bib13)\)but does not supportcolspan/rowspan\([MDN Web Docs, 2026](https://arxiv.org/html/2610.29188#bib.bib12)\)\. MultiMarkdown adds column\-spanning syntax through repeated pipes\([Penney, 2023](https://arxiv.org/html/2610.29188#bib.bib14)\)\. In contrast, HTML and LaTeX can represent complex tables but require substantial markup interpretation\.

To systematize this trade\-off, we define sixStructural Features \(F1–F6\)andComplexity Levels \(L1–L6\)as cumulative feature requirements\. This taxonomy makes table complexity explicit and enables direct comparison of formats by expressiveness\.

We then proposeLTEM\(LLM\-friendly Table\-Enhanced Markdown\), a minimal extension of Markdown that explicitly encodes spans and multi\-level headers while remaining linear to read and parsable in a single pass\. LTEM targets L3–L5 structures with less verbosity than HTML/LaTeX, aiming to improve token efficiency and response stability without sacrificing expressiveness\.

We evaluate LTEM onTable Understanding\(Table QA\) andTable Generationacross formats \(Markdown, CSV, HTML, LaTeX, MultiMarkdown, LTEM\) and five state\-of\-the\-art LLMs, and analyzeToken Efficiencyusing token\-normalized metrics\.

Our contributions are as follows:

- •Structural complexity taxonomy: We formalize table difficulty and format expressiveness via F1–F6 and L1–L6, providing a systematic framework for comparing serialization capabilities\.
- •STB benchmark: We construct a controlled benchmark with 1,089 tables systematically distributed across complexity levels, enabling controlled analysis of structural effects on LLM performance\.
- •LTEM: We propose a minimal, formally specified Markdown extension that instantiates the taxonomy\-derived requirements, explicitly encoding cell spans and hierarchical headers while preserving LLM\-friendly linear readability\.
- •Empirical trade\-off analysis: We evaluate understanding, generation, and token efficiency across formats and diverse LLM backbones\.

## 2Related Work

### 2\.1Table QA and Table Reasoning

Early Table QA focused on semantic parsing, mapping questions to executable programs\. WTQ\([Pasupat and Liang, 2015](https://arxiv.org/html/2610.29188#bib.bib19)\)and WikiSQL\([Zhong et al\., 2017](https://arxiv.org/html/2610.29188#bib.bib27)\)established QA over Wikipedia tables, and later work introduced pretrained table encoders such as TAPAS and TaBERT\([Herzig et al\., 2020](https://arxiv.org/html/2610.29188#bib.bib22);[Yin et al\., 2020](https://arxiv.org/html/2610.29188#bib.bib23)\)\. However, these datasets largely emphasize flat tables, underrepresenting document\-style structures such as merged cells and hierarchical headers\. Benchmarks including HiTab and TAT\-QA better reflect hierarchical and numerically grounded reasoning\([Cheng et al\., 2022](https://arxiv.org/html/2610.29188#bib.bib28);[Zhu et al\., 2021](https://arxiv.org/html/2610.29188#bib.bib29)\)\. In contrast to work centered on tasks or model variants, we treatserialization formatas a primary variable and study its impact on stability and token efficiency across structural complexity\.

### 2\.2LLMs on Tables and Format Choice

Recent studies show that LLM performance on tabular tasks is sensitive to serialization, delimiters, and ordering\([Sui et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib24);[Fang et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib34);[Lu et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib35)\)\. LongTableBench emphasizes format and context length in long\-context table reasoning\([Li et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib20)\), and RealHiTBench compares representations for complex hierarchical tables across LaTeX, HTML, and images\([Wu et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib9)\)\. While these works establish that format matters, they offer limited tools to compare*what structural information*each representation preserves\. Our taxonomy addresses this gap by decomposing table structure into atomic operations\.

### 2\.3Markup Expressiveness and Text\-to\-Table Evaluation

Markdown tables are common: GFM defines pipe\-delimited tables\([GitHub, 2019](https://arxiv.org/html/2610.29188#bib.bib13)\)but lacks structural attributes such ascolspan/rowspan\([MDN Web Docs, 2026](https://arxiv.org/html/2610.29188#bib.bib12)\), while MultiMarkdown adds column\-spanning syntax through repeated pipes\([Penney, 2023](https://arxiv.org/html/2610.29188#bib.bib14)\)\. HTML and LaTeX provide explicit span constructs for complex tables\([WHATWG, 2026](https://arxiv.org/html/2610.29188#bib.bib36);[LaTeX2e Unofficial Reference Manual Project, 2026](https://arxiv.org/html/2610.29188#bib.bib37);[van Oostrum et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib38)\)\. Their more verbose syntax motivates our evaluation of format\-dependent accuracy and structural consistency\. For text\-to\-table generation, evaluation is difficult because multiple surface forms can represent the same structure\. Prior work proposes multi\-granularity table metrics\([Pal et al\., 2023](https://arxiv.org/html/2610.29188#bib.bib17)\), statement\-based checks\([Ramu et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib21)\), and discusses structure\-aware metrics under constrained decoding\([Oestreich and Müller, 2025](https://arxiv.org/html/2610.29188#bib.bib26)\)\. We analyze format\-dependent structural consistency via normalized representations, following exact\-match perspectives common in structured output evaluation\([Yu et al\., 2018](https://arxiv.org/html/2610.29188#bib.bib18)\)\.

## 3Taxonomy of Table Structural Complexity

An objective comparison of table representation format capabilities requires clear criteria\. This section presents ataxonomythat serves as an evaluation methodology for systematically characterizing table structural complexity and the structural information a serialization must preserve for LLMs\. This classification scheme comprises two axes:Structural Features \(F1–F6\), the atomic operations for expressing table structure, andComplexity Levels \(L1–L6\), the cumulative feature requirements for expressing specific tables\.

### 3\.1Structural Features

We define six atomic operations for expressing table structure\. Each Feature is independent of the others, enabling binary assessment of whether a specific structural capability is present or absent\.

#### F1 \(Grid Formation\)\.

F1 \(Grid Formation\) represents the most basic requirement: that cells “exist” at row\-column intersections\.

#### F2 \(Header Designation\)\.

F2 \(Header Designation\) indicates that cells have assigned “roles\.” In HTML, header cells use<th\>while data cells use<td\>; in Markdown, rows above the separator line \(\|\-\-\-\|\) are treated as headers\.

#### F3 \(Cell Merging\)\.

F3 \(Cell Merging\) is the critical branching point in this taxonomy\. A substantial portion of tables in scientific papers require cell merging for group headers or category representation\.

#### F4 \(Header Nesting\)\.

F4 \(Header Nesting\) applies when headers themselves have parent–child hierarchies, exemplified by grouping quarterly revenue as “Q1”, “Q2”, “Q3” under a “Revenue” superheader\.

#### F5 \(Section Stacking\)\.

F5 \(Section Stacking\) and F6 \(Table Composition\) address compound table structures\. F5 applies when multiple sections sharing identical column structure \(schema\) coexist within a single table, such as displaying “Model A Results” and “Model B Results” in one table in regression analysis\.

#### F6 \(Table Composition\)\.

F6 applies when tables with different schemas constitute a single logical unit, such as placing “\(a\) Correlation Matrix” and “\(b\) Sample Sizes” in one figure\.

Table 1:Structural feature support by format\. ✓ = native support;△\\triangle= partial or non\-standard; ✗ = not supported\. Dashed vertical rule separates existing formats from LTEM\.

### 3\.2Complexity Levels

Complexity Level is defined as thecumulative features requiredto express a specific table\. Each Level includes all Features from previous Levels and adds new required Features\. Complexity Level definitions are summarized in Table[5](https://arxiv.org/html/2610.29188#A1.T5)in the Appendix\.

The key implication of this cumulative structure is: a format that cannot support a specific Level cannot structurally express any higher Levels\. For example, a format not supporting F3 \(Cell Merging\) cannot structurally express not only L3 but also L4, L5, and L6 tables\.

### 3\.3Expressiveness of Existing Formats

We apply the above taxonomy to analyze the expressiveness of major table representation formats\. The analysis covers five formats spanning minimal data exchange formats \(CSV\), lightweight markup with high frequency in LLM training data \(Markdown, MultiMarkdown\), and document standards with complete structural expressiveness \(HTML, LaTeX\)\. Two important patterns emerge from this analysis \(Table[1](https://arxiv.org/html/2610.29188#S3.T1)\)\.

First, F3 \(Cell Merging\) is the decisive branching point\. Markdown does not support F3 at all, fundamentally precluding expression of L3\+ tables\. MultiMarkdown supportscolspanin some renderers but lacks standardization, with even more limitedrowspansupport\. This is not merely a feature absence but a structural limitation: the syntax for encoding this information simply does not exist\.

Second, only LaTeX has complete expressiveness\. HTML can approximate F5 and F6 using multiple<tbody\>elements or separate<table\>elements, but cannot structurally specify logical relationships between sections\. LaTeX is the only format that can express structures at all levels through a nesting\-based approach using nestedtabularenvironments andsubtable\.

This analysis presents an important implication overlooked in prior research: the format LLMs process most efficiently \(Markdown\) cannot express L3\+ tables commonly found in scientific papers, while formats capable of such expression \(LaTeX, HTML\) are inefficient for LLM processing\.

LaTeX’s\\multicolumn\{2\}\{c\}\{\.\.\.\}and HTML’s<td colspan="2"\>encode cell merging information, but LLMs must undergo additional steps to interpret this syntax and infer actual cell positions and ranges\. The same burden exists when providing tables as images, requiring inference of cell boundaries and merging relationships from visual structure\.

This taxonomy\-based analysis yields concrete serialization requirements for LLM table processing: a format targeting L3–L5 structures should explicitly encode span information and header hierarchies while maintaining linear readability\. This motivates the design of a new table markup language optimized for LLM comprehension\.

## 4LTEM: Language Design

To demonstrate how the taxonomy\-derived requirements \(Section 3\) translate into concrete format design, we present LTEM \(LLM\-friendlyTable\-EnhancedMarkdown\) as an instantiation that explicitly encodes F3–F5 features while preserving Markdown’s linear readability\. This section describes design principles, syntax specification, and LTEM’s position within the landscape presented in Section 3\.

### 4\.1Design Principles

LTEM’s design is grounded infiveprinciples derived from the taxonomy\-based analysis in Section 3, each addressing specific structural requirements identified by our framework\.

#### Markdown Compatibility\.

LLM training corpora include substantial proportions of sources using Markdown format, such as GitHub and StackExchange \(e\.g\., GitHub 4\.5%, StackExchange 2% in LLaMA;\([Touvron et al\., 2023](https://arxiv.org/html/2610.29188#bib.bib25)\)\)\. This composition leads LLMs to exhibit high familiarity with Markdown syntax; in fact, major commercial LLMs such as ChatGPT and Claude use Markdown as their default output format for table generation\. LTEM is designed as a superset of Markdown to leverage this existing knowledge\. Even when new syntax elements render as plain text in existing Markdown parsers, basic table structure is preserved\. This design enables LLMs to understand LTEM as an extension of familiar Markdown rather than learning an entirely new format\.

#### Linear Readability\.

Table structure should besemantically comprehensiblewhen reading source text sequentially from top to bottom\. This principle aligns with LLMs’ autoregressive processing and simultaneously facilitates human review and debugging\.

#### Explicit Structure\.

Structural information should be expressed through explicit markers rather than implicit rules\. For example, a cell with colspan=2 is clearly indicated with a\{c:2\}attribute or<<marker, eliminating the burden of contextual inference by LLMs\. This blocks a major source of structural hallucination\.

#### Minimal Grammar Extension\.

We minimize the number of new syntax elements\. LTEM adds only seven syntax elements to standard Markdown: four for span expression \(<<,^^,\{c:N\},\{r:N\}\), one for in\-cell line breaks \(\\\\\), one for table identification \(\| \# id \|\), and one for references \(@\)\. Appendix[H\.2](https://arxiv.org/html/2610.29188#A8.SS2)reports a design\-choice ablation comparing alternative forms for five LTEM elements\.

#### Unidirectional Parsing\.

While Linear Readability concerns semantic understanding, this principle concernssyntax parsing implementation\. LTEM is parsable in a single pass without forward references, guaranteeing efficient parser implementation with linear time complexity\.

### 4\.2Core Syntax

LTEM’s core syntax addresses cell spanning and multi\-level headers\. Appendix[C](https://arxiv.org/html/2610.29188#A3)shows the tables these constructs render to\.

#### Colspan\.

Column spanning is expressed via marker syntax \(<<\) or attribute syntax \(\{c:N\}\)\. The two forms are structurally equivalent, as illustrated in Figure[1](https://arxiv.org/html/2610.29188#S4.F1)\.

\(a\)Motivation: span\-aware vs\. span\-unaware\.\(b\)Equivalent encodings:<<vs\.\{c:N\}\.
Figure 1:Colspan in LTEM\. \(a\) illustrates why explicit span markers matter; \(b\) shows marker\- and attribute\-based forms are structurally equivalent\.Marker syntax maintains visual alignment, while attribute syntax is efficient for large span values, allowing concise expression like\{c:5\}without repeated marker entry\.

#### Rowspan\.

Row spanning is expressed via the^^marker or\{r:N\}attribute\. Compound spanning combines as\{c:N,r:M\}\.

Figure 2:Multi\-level headers in LTEM: multiple header rows above the separator line naturally encode hierarchical header nesting \(F4\)\.
#### Multi\-header Rows\.

All rows above the separator line \(\|\-\-\-\|\) are treated as headers\. This design naturally supports F4 \(Header Nesting\) without additional syntax \(Figure[2](https://arxiv.org/html/2610.29188#S4.F2)\)\.

#### Multiline Cell\.

The\\\\escape sequence represents line breaks within cells\.

### 4\.3Rich Cell Content

LTEM supports structured content within cells based on\\\\\. Bullet lists, numbered lists, checkboxes, and formulas can be combined within a single cell, as illustrated in Figure[3](https://arxiv.org/html/2610.29188#S4.F3)\.

Figure 3:Rich cell content in LTEM: inline line breaks \(\\\\\) enable structured content \(lists, checkboxes\) and math within a single cell\.
### 4\.4Relational Tables

LaTeX and HTML permit nested structures inserting tables within cells, but this requires recursive parsing, disrupts linear reading, and expresses inter\-table relationships only implicitly\. To address this, LTEM adopts an alternative approach:table decomposition with explicit references, as illustrated in Figure[4](https://arxiv.org/html/2610.29188#S4.F4)\. This is analogous to normalization principles in relational databases\.

Figure 4:Relational tables in LTEM: tables are decomposed and linked via explicit table IDs \(\| \# id \|\) and references \(@ref\) instead of nesting\.A table is identified by a unique label placed in the first row as\| \# identifier \|\. Other tables are referenced with the@prefix\.

### 4\.5Formal Specification

LTEM syntax is defined as a Context\-Free Grammar \(CFG\)\. The complete EBNF \(Extended Backus\-Naur Form\) specification is provided in Appendix[D](https://arxiv.org/html/2610.29188#A4), together with syntax validation rules \(V1–V12\) and AST and TableStructure JSON schemas\.

## 5Experimental Setup

### 5\.1Experimental Design

The experiments are designed to answer the following research questions:

- •RQ1: Can LTEM sufficiently express diverse tables? - –RQ1\-1: Does LTEM improve LLM table comprehension? - –RQ1\-2: Does LTEM achieve high fidelity in table generation?
- •RQ2: Is LTEM more token\-efficient than existing formats?

To address these questions, we utilize two complementary datasets\. First, the Synthetic Table Benchmark \(STB\) provides synthetic tables with systematically controlled structural complexity, enabling controlled analysis of format effects at each Complexity Level\. Second, existing public benchmarks such as HiTab[Cheng et al\. \(2022\)](https://arxiv.org/html/2610.29188#bib.bib28)ensure comparability with prior research\.

### 5\.2Synthetic Table Benchmark \(STB\)

Existing table benchmarks were collected for specific tasks like Table QA or Table\-to\-Text, without systematic control of table structural complexity\. Most tables in WikiTableQuestions have simple header–data structures \(L2\), with only a minority containing cell merging or multi\-level headers\. This distributional bias implies that conclusions like “format A outperforms format B” may only hold within specific complexity ranges\.

To overcome this limitation, we constructed the Synthetic Table Benchmark \(STB\), a synthetic dataset systematically distributed according to the Complexity Levels \(L1–L6\) defined in Section 3\. STB comprises 1,089 tables and 4,356 question–answer pairs, with each table containing an average of 4 QA pairs\.

STB’s complexity distribution was deliberately designed for research purposes \(Table[6](https://arxiv.org/html/2610.29188#A2.T6)\)\. Notably, approximately 30% is allocated to L3, the first level requiring Cell Merging and the boundary where Markdown and CSV become structurally incapable of representation\. We anticipated LTEM’s differential value would be most evident at this point\. To ensure content realism, we defined five domains:Scientific, Financial, Product, Survey, andSchedule\(Table[7](https://arxiv.org/html/2610.29188#A2.T7)\), with complexity levels and domains sampled independently to prevent specific domains from being biased toward specific complexity levels\.

Table generation follows a 3\-stage pipeline: \(i\) rule\-based determination of table structure \(row/column counts and merging patterns\), \(ii\) Claude Sonnet 4\.5 and Opus 4\.5\([Anthropic, 2025b](https://arxiv.org/html/2610.29188#bib.bib15);[Anthropic, 2025a](https://arxiv.org/html/2610.29188#bib.bib16)\)populate domain\-appropriate headers and cell values, then \(iii\) GPT\-5\-mini generates question–answer pairs\([OpenAI, 2025](https://arxiv.org/html/2610.29188#bib.bib2)\)\. Question types comprise LOOKUP, COUNTING, COMPARISON, and AGGREGATION, referencing operation types repeatedly used in prior Table QA research[Pasupat and Liang \(2015\)](https://arxiv.org/html/2610.29188#bib.bib19);[Cheng et al\. \(2022\)](https://arxiv.org/html/2610.29188#bib.bib28)\. Additional implementation details and prompt templates are provided in Appendices[F](https://arxiv.org/html/2610.29188#A6)and[E](https://arxiv.org/html/2610.29188#A5)\.

Since automatically generated QA may contain errors, we adopted an indirect verification approach usingmodel agreementrather than explicitly computing or verifying answer labels with rules\. Specifically, we input identical tables and questions to two models from different families \(Qwen3\-VL\-8B\-Instruct and Phi\-4\-mini\-instruct\([Qwen Team, 2025b](https://arxiv.org/html/2610.29188#bib.bib8);[Microsoft, 2025](https://arxiv.org/html/2610.29188#bib.bib7)\)\), retaining QA samples only when both models’ outputs match the GPT\-5\-mini\-generated answer under the same normalization criteria\. This agreement serves as a reliability filter, although errors shared across models may remain\.

### 5\.3Table QA Benchmarks

To verify whether trends observed in the synthetic dataset \(STB\) generalize to real\-world tables, we used HiTab[Cheng et al\. \(2022\)](https://arxiv.org/html/2610.29188#bib.bib28), a public benchmark for hierarchical table question answering\. HiTab contains tables extracted from Wikipedia and statistical reports, featuring multi\-level headers, cell merging, and hierarchical structure properties underrepresented in existing Table QA benchmarks\.

We used HiTab’stest splitto evaluate two distinct tasks\.

First, for the Table Understanding Task, we use one original HiTab question–answer pair per table to evaluate how effectively different table representation formats convey complex table structures to LLMs\. Each table is converted to six table representation formats \(Markdown, CSV, HTML, LaTeX, MultiMarkdown, LTEM\) while preserving original structure and content, with evaluation conducted using question–answer pairs for each format\.

Second, as an additional task, we evaluate table generation performance from natural language inputs based on the same HiTab tables\. Natural language generation requests are generated using GPT\-5 based on each table’s structure and values, with format\-specific generation results analyzed through comparison with pre\-generated reference tables for six table representation formats\.

### 5\.4Models and Evaluation Metrics

#### Evaluation Models\.

To assess the consistency of format effects across model families, we conduct Table Understanding experiments with five LLMs and Table Generation experiments with three\. Closed\-weight models include GPT\-5 and Gemini 2\.5 Pro\([OpenAI, 2025](https://arxiv.org/html/2610.29188#bib.bib2);[Google DeepMind, 2025](https://arxiv.org/html/2610.29188#bib.bib3)\)\. Open\-weight models include the multimodal general\-purpose Llama\-4\-Maverick\-17B\-128E\-Instruct\([Meta AI, 2025](https://arxiv.org/html/2610.29188#bib.bib4)\), the large\-parameter Qwen3\-235B\-A22B\-Instruct\-2507\([Qwen Team, 2025a](https://arxiv.org/html/2610.29188#bib.bib5)\), and the reasoning\-specialized DeepSeek\-R1[DeepSeek\-AI \(2025\)](https://arxiv.org/html/2610.29188#bib.bib6)\.

Task\-specific prompt templates are held constant across models and formats, with format\-dependent variation restricted to the table serialization or target output format and, where applicable, the corresponding syntax guidance\. Temperature is set to each model’s default value\.

#### Table Understanding Evaluation\.

Table QA performance is primarily evaluated with normalized Exact Match \(nEM\), and we additionally report token\-level F1 \(tokenF1\) to capture partial\-match behavior\([Pasupat and Liang, 2015](https://arxiv.org/html/2610.29188#bib.bib19);[Cheng et al\., 2022](https://arxiv.org/html/2610.29188#bib.bib28);[Rajpurkar et al\., 2016](https://arxiv.org/html/2610.29188#bib.bib10)\)\. Following numeric\-answer evaluation practice in table QA\([Zhu et al\., 2021](https://arxiv.org/html/2610.29188#bib.bib29)\), we compute numeric Exact Match \(numEM\) by extracting numbers and checking equality within a tolerance to reduce notation\-induced discrepancies\. To assess format stability, we decompose errors into Refusal \(explicit answer avoidance\) and Invalid \(unnormalizable output or parsing failure\); both are counted as incorrect, and their sum is reported as Total Error\.

#### Table Generation Evaluation\.

For Table Generation, we prompt models to reconstruct HiTab tables*from natural\-language descriptions only*in a specified output format \(Markdown/CSV/HTML/LaTeX/MultiMarkdown/LTEM\)\. Unlike Table Understanding,*exact format\-level reproduction*is highly challenging, so we adoptANLS\(Average Normalized Levenshtein Similarity\) as the primary metric to capture graded similarity between generated outputs and reference tables\([Biten et al\., 2019](https://arxiv.org/html/2610.29188#bib.bib1)\)\. We additionally reportGood\+\(ANLS≥0\.7\\geq 0\.7\) andExcellent\(ANLS≥0\.9\\geq 0\.9\) rates as practical success criteria; the full Excellent\-rate breakdown is provided in Appendix[G](https://arxiv.org/html/2610.29188#A7)\.

#### Token Efficiency Evaluation\.

Since input length varies by serialization format, we also report token\-normalized metrics normalizing performance by input token count\. For modelmm, formatff, and benchmark/settingss, let input prompt token count beT​o​kprompt​\(m,f,s\)Tok\_\{\\text\{prompt\}\}\(m,f,s\)\. When format\-specific fixed\-length grammar guides are included \(e\.g\., LTEM\), we separate this as a constant term:

T​o​kpromptadj​\(m,f,s\)=T​o​kprompt​\(m,f,s\)−gfTok\_\{\\text\{prompt\}\}^\{\\text\{adj\}\}\(m,f,s\)=Tok\_\{\\text\{prompt\}\}\(m,f,s\)\-g\_\{f\}Token\-normalized performance for Table Understanding is then:

TNPadj​\(m,f,s\)=1000×nEM⁡\(m,f,s\)T​o​kpromptadj​\(m,f,s\)\\mathrm\{TNP\}\_\{\\mathrm\{adj\}\}\(m,f,s\)=1000\\times\\frac\{\\mathrm\{nEM\}\(m,f,s\)\}\{Tok\_\{\\text\{prompt\}\}^\{\\text\{adj\}\}\(m,f,s\)\}This token/cost budget perspective for efficiency comparison is related to prior efficiency analyses\([Han et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib30);[Zhang et al\., 2025](https://arxiv.org/html/2610.29188#bib.bib31);[Zhang et al\., 2024](https://arxiv.org/html/2610.29188#bib.bib32);[Jung and Kim, 2024](https://arxiv.org/html/2610.29188#bib.bib33)\)\.

#### Statistical Validation\.

For Table Understanding \(QA\), we performed three repeated runs per setting \(model×\\timesformat\) on identical instances\. We applied McNemar’s test\([McNemar, 1947](https://arxiv.org/html/2610.29188#bib.bib11)\)on paired predictions \(Fisher\-combined across runs\) and report mean performance over runs, interpreting only consistent differences as significant\.

## 6Results

### 6\.1Table Understanding

![Refer to caption](https://arxiv.org/html/2610.29188v1/fig2_stb_model_format_heatmap.png)Figure 5:Model×\\timesserialization\-format performance \(nEM\) on STB\. Format sensitivity varies by model; notably, Qwen3\-235B exhibits a large degradation under LaTeX serialization\.In this section, we analyze how table serialization formats affect Table QA accuracy and response stability\. We first examine format effects on STB under controlled structural conditions, with each table–question instance serialized in all six formats\. We then assess whether the observed trends extend to HiTab, a real\-world hierarchical\-table benchmark with a substantially different distribution of table sizes and structural properties\.

On STB, LTEM achieves nEM comparable to HTML \(0\.813 vs\. 0\.812\), while LaTeX is lower at 0\.777 \(Table[2](https://arxiv.org/html/2610.29188#S6.T2)\)\. The gap is clearer in the error breakdown: LTEM keeps Refusal at 0\.15% and Invalid at 0\.14%, yielding the lowest Total Error, whereas LaTeX shows a sharp increase in Invalid to 2\.67% \(Table[3](https://arxiv.org/html/2610.29188#S6.T3)\)\. Figure[5](https://arxiv.org/html/2610.29188#S6.F5)further shows that some models are particularly sensitive to LaTeX serialization, whereas LTEM remains stable under the same evaluation setting\. Relative to HTML and LaTeX, LTEM provides a favorable accuracy–token trade\-off \(Table[2](https://arxiv.org/html/2610.29188#S6.T2)\)\. McNemar tests show that LTEM significantly outperforms LaTeX for four of five models \(Fisher\-combinedp<0\.01p<0\.01\); Gemini\-2\.5\-Pro shows no significant difference \(Appendix[I](https://arxiv.org/html/2610.29188#A9)\)\. Failure\-mode and question\-type breakdowns are in Appendix[H\.4](https://arxiv.org/html/2610.29188#A8.SS4)\.

When broken down by Complexity Level, performance declines from L2 to L3 and further at L4 \(Figure[6](https://arxiv.org/html/2610.29188#S6.F6)\)\. These transitions reflect the point where models must reliably track span ranges and header roles as cell merging and multi\-level headers appear\. LTEM is designed to reduce ambiguity at this boundary by explicitly encoding spans and header nesting\. Structure\-conditioned results are reported in Appendix[H\.3](https://arxiv.org/html/2610.29188#A8.SS3)\. Additional level\- and feature\-wise breakdowns are in Appendix[H\.1](https://arxiv.org/html/2610.29188#A8.SS1)\.

On HiTab, absolute accuracy decreases across formats and rankings become more dependent on dataset characteristics \(Figure[7](https://arxiv.org/html/2610.29188#S6.F7)\)\. Average nEM is 0\.295 for HTML, 0\.292 for LaTeX, and 0\.289 for LTEM, with a small 0\.6 percentage\-point gap \(full results in Appendix[G](https://arxiv.org/html/2610.29188#A7)\)\. Overall, on STB, LTEM achieves accuracy comparable to HTML and has a substantially lower Invalid rate than LaTeX \(Tables[2](https://arxiv.org/html/2610.29188#S6.T2)and[3](https://arxiv.org/html/2610.29188#S6.T3)\)\.

Table 2:Overall STB performance by format \(average over 5 models, 3 runs\)\. PromptTok excludes LTEM guide tokens; TNPadj\{\}\_\{\\text\{adj\}\}= nEM/PromptTok×\\times1000\. LTEM and HTML achieve comparable nEM\. Shorter formats obtain higher token\-normalized scores, while LTEM provides a favorable accuracy–token trade\-off relative to HTML and LaTeX\.Table 3:Error rate analysis on STB\. LTEM shows the lowest refusal rate\. LaTeX exhibits a markedly higher invalid response rate than the other formats, primarily due to formatting and parsing failures\.Figure 6:Average performance \(nEM\) by structural complexity level \(L1–L6\) on STB\. Arrow labels report absolute nEM changes in percentage points \(pp\)\. The highlighted L2–L3 and L3–L4 transitions correspond to the introduction of cell merging and multi\-level headers\.Figure 7:Format\-wise performance comparison \(nEM\) between STB and HiTab\. The relative ordering of formats changes across datasets\.
### 6\.2Table Generation

For theTable Generationtask, we use HiTab tables as targets and evaluate whether a model can reconstruct the same tablesfrom natural\-language descriptions onlyin a specified output format\. Generation quality is evaluated usingANLS\(normalized string similarity\) and theGood\+rate \(ANLS≥0\.7\\geq 0\.7\), whilePromptTokdenotes the token count of the user prompt\.

As shown in Table[4](https://arxiv.org/html/2610.29188#S6.T4), HTML achieves the best generation quality \(ANLS 0\.913\) and the highest Good\+ rate \(96\.2%\)\. LaTeX, MultiMarkdown, and LTEM form a similar middle\-performing group, while Markdown and CSV perform worse as they cannot directly express complex structures \(e\.g\., merged cells and hierarchical headers\)\.

LTEM is designed to encode complex structures \(F3–F4\) rather than maximize generation scores; limited pretraining exposure constrains short\-term performance, yet it remains close to MultiMarkdown \(ANLS 0\.720 vs\. 0\.734\), suggesting it is a viable alternative in structure\-heavy pipelines\.

Table 4:Table Generation performance \(HiTab average; ANLS: normalized string similarity\)\. PromptTok includes format\-specific generation instructions, with an additional syntax guide for LTEM\.

## 7Conclusion

This paper introduced astructural complexity taxonomy\(F1–F6, L1–L6\) andSTB, a controlled benchmark for analyzing how serialization formats affect LLM performance across complexity levels\. We then proposedLTEM, a minimal Markdown extension that explicitly encodes cell spans and hierarchical headers, instantiating taxonomy\-derived requirements as concrete syntax choices\. Experiments on STB and HiTab show that LTEM achieves competitive table understanding accuracy while improving response stability at structural transitions where lightweight formats fail and verbose formats introduce noise\. Beyond LTEM itself, we hope the taxonomy and benchmark provide reusable infrastructure for future research on robust and efficient LLM–table interaction\.

## Limitations

- •Dependence on data distribution\.Because the ranking of formats differs between STB \(synthetic\) and HiTab \(real\-world\), it is difficult to generalize the superiority of a particular serialization format from a single benchmark\. In practice, formats should be re\-evaluated on a validation set whose distribution matches the target domain\.
- •Training Distribution Bias\.LLM pretraining corpora contain substantially more HTML and Markdown tables than LTEM\-formatted content, as LTEM is introduced in this work\. This exposure imbalance may favor established formats, particularly in generation tasks that depend on learned serialization patterns\. HTML’s strong generation performance \(ANLS: 0\.913, 76% Excellent\) may partly reflect this imbalance\. In a separate table\-QA setting, Appendix[H\.5](https://arxiv.org/html/2610.29188#A8.SS5)reports a small LoRA pilot showing that 4B\-scale models can adapt to LTEM with limited supervision\.
- •Model–format interactions\.Format effects vary substantially across models, and some model–format pairs exhibit atypical behaviors such as elevated invalid\-response rates\. Therefore, format selection cannot be made independently of the model, and prior validation on the deployment backbone is necessary\.
- •Sensitivity to experimental settings \(prompting/decoding\)\.Our experiments are based on a specific prompt template and decoding configuration\. In particular, output length constraints, instruction wording, and post\-processing rules can affect invalid/refusal rates for verbose formats such as LaTeX, and relative rankings may change under different settings\.
- •Limited coverage of formats and domains\.While we compare six representative formats, the space of possible serialization designs is broader\. Moreover, HiTab focuses primarily on Wikipedia tables, so our conclusions may not directly transfer to other industrial domains \(e\.g\., OCR\-extracted tables or noisy financial/log tables\) without additional verification\.

## Acknowledgments

This work was supported by the National Research Foundation of Korea \(NRF\) grant funded by the Korean government \(MSIT\) \(No\. RS\-2025\-0055621731482092640101\); the Institute of Information & Communications Technology Planning & Evaluation \(IITP\) grant funded by the Korean government \(MSIT\) \(RS\-2019\-II190004,Development of Semi\-supervised Learning Language Intelligence Technology and Korean Tutoring Service for Foreigners\); a grant \(26212MFDS008\) from the Ministry of Food and Drug Safety in 2026; the Institute of Information & Communications Technology Planning & Evaluation \(IITP\) grant funded by the Korean government \(MSIT\) \(RS\-2026\-25569031,Development of an AIBOM\-Based Platform for Strengthening the Reliability and Security of the AI Supply Chain\); and the BK21 FOUR Program by Chungnam National University Research Grant, 2026\.

## References

- AnthropicSystem card: claude opus 4\.5\.Note:[https://www\-cdn\.anthropic\.com/bf10f64990cfda0ba858290be7b8cc6317685f47/Claude%20Opus%204\.5%20System%20Card\.pdf](https://www-cdn.anthropic.com/bf10f64990cfda0ba858290be7b8cc6317685f47/Claude%20Opus%204.5%20System%20Card.pdf)Cited by:[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p4.1)\.
- Anthropic \(2025b\)AnthropicSystem card: claude sonnet 4\.5\.Note:[https://www\-cdn\.anthropic\.com/963373e433e489a87a10c823c52a0a013e9172dd/Claude%20Sonnet%204\.5%20System%20Card\.pdf](https://www-cdn.anthropic.com/963373e433e489a87a10c823c52a0a013e9172dd/Claude%20Sonnet%204.5%20System%20Card.pdf)Cited by:[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p4.1)\.
- Bitenet al\.\(2019\)A\. F\. Biten, R\. Tito, A\. Mafla, L\. Gomez, M\. Rusiñol, E\. Valveny, C\. V\. Jawahar, and D\. KaratzasScene text visual question answering\.InProceedings of the IEEE/CVF International Conference on Computer Vision \(ICCV\),pp\. 4291–4301\.External Links:[Link](https://openaccess.thecvf.com/content_ICCV_2019/html/Biten_Scene_Text_Visual_Question_Answering_ICCV_2019_paper.html)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px3.p1.1)\.
- Chenget al\.\(2022\)Z\. Cheng, H\. Dong, Z\. Wang, R\. Jia, J\. Guo, Y\. Gao, S\. Han, J\. Lou, and D\. ZhangHiTab: a hierarchical table dataset for question answering and natural language generation\.InProceedings of the 60th Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),Dublin, Ireland,pp\. 1094–1110\.External Links:[Link](https://aclanthology.org/2022.acl-long.78/),[Document](https://dx.doi.org/10.18653/v1/2022.acl-long.78)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1),[§5\.1](https://arxiv.org/html/2610.29188#S5.SS1.p3.1),[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p4.1),[§5\.3](https://arxiv.org/html/2610.29188#S5.SS3.p1.1),[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px2.p1.1)\.
- DeepSeek\-AI \(2025\)DeepSeek\-AIDeepSeek\-R1 incentivizes reasoning in LLMs through reinforcement learning\.Nature645\(8081\),pp\. 633–638\.External Links:ISSN 1476\-4687,[Document](https://dx.doi.org/10.1038/s41586-025-09422-z),[Link](https://doi.org/10.1038/s41586-025-09422-z)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px1.p1.1)\.
- Fanget al\.\(2024\)X\. Fang, W\. Xu, F\. A\. Tan, Z\. Hu, J\. Zhang, Y\. Qi, S\. H\. Sengamedu, and C\. FaloutsosLarge language models \(LLMs\) on tabular data: prediction, generation, and understanding \- a survey\.Transactions on Machine Learning Research\.External Links:ISSN 2835\-8856,[Link](https://openreview.net/forum?id=IZnrCGF9WI)Cited by:[§2\.2](https://arxiv.org/html/2610.29188#S2.SS2.p1.1)\.
- GitHub \(2019\)GitHubGitHub Flavored Markdown spec\.Note:[https://github\.github\.com/gfm/](https://github.github.com/gfm/)Version 0\.29\-gfmCited by:[§1](https://arxiv.org/html/2610.29188#S1.p3.1),[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Google DeepMind \(2025\)Google DeepMindGemini 2\.5: pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities\.External Links:2507\.06261,[Link](https://arxiv.org/abs/2507.06261)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px1.p1.1)\.
- Hanet al\.\(2025\)T\. Han, Z\. Wang, C\. Fang, S\. Zhao, S\. Ma, and Z\. ChenToken\-budget\-aware llm reasoning\.InFindings of the Association for Computational Linguistics: ACL 2025,Vienna, Austria,pp\. 24842–24855\.External Links:[Document](https://dx.doi.org/10.18653/v1/2025.findings-acl.1274),[Link](https://aclanthology.org/2025.findings-acl.1274/)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px4.p1.3)\.
- Herziget al\.\(2020\)J\. Herzig, P\. K\. Nowak, T\. Müller, F\. Piccinno, and J\. EisenschlosTaPas: weakly supervised table parsing via pre\-training\.InProceedings of the 58th Annual Meeting of the Association for Computational Linguistics,D\. Jurafsky, J\. Chai, N\. Schluter, and J\. Tetreault \(Eds\.\),Online,pp\. 4320–4333\.External Links:[Link](https://aclanthology.org/2020.acl-main.398/),[Document](https://dx.doi.org/10.18653/v1/2020.acl-main.398)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1)\.
- Jung and Kim \(2024\)H\. Jung and K\. KimDiscrete prompt compression with reinforcement learning\.IEEE Access12,pp\. 72578–72587\.External Links:[Document](https://dx.doi.org/10.1109/ACCESS.2024.3403426)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px4.p1.3)\.
- LaTeX2e Unofficial Reference Manual Project \(2026\)LaTeX2e Unofficial Reference Manual ProjectLaTeX2e: an unofficial reference manual —\\multicolumn\.Note:[https://latexref\.xyz/\_005cmulticolumn\.html](https://latexref.xyz/_005cmulticolumn.html)Section 8\.23\.1; version of June 2026Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Liet al\.\(2025\)L\. Li, J\. Tian, H\. Chen, W\. Ye, C\. Ye, H\. Wang, N\. Wang, X\. Fu, G\. Chen, and J\. ZhaoLongTableBench: benchmarking long\-context table reasoning across real\-world formats and domains\.InFindings of the Association for Computational Linguistics: EMNLP 2025,C\. Christodoulopoulos, T\. Chakraborty, C\. Rose, and V\. Peng \(Eds\.\),Suzhou, China,pp\. 11927–11965\.External Links:[Link](https://aclanthology.org/2025.findings-emnlp.638/),[Document](https://dx.doi.org/10.18653/v1/2025.findings-emnlp.638)Cited by:[§1](https://arxiv.org/html/2610.29188#S1.p2.1),[§2\.2](https://arxiv.org/html/2610.29188#S2.SS2.p1.1)\.
- Luet al\.\(2025\)W\. Lu, J\. Zhang, J\. Fan, Z\. Fu, Y\. Chen, and X\. DuLarge language model for table processing: a survey\.Frontiers of Computer Science19\(2\),pp\. 192350\.External Links:ISSN 2095\-2236,[Document](https://dx.doi.org/10.1007/s11704-024-40763-6),[Link](https://doi.org/10.1007/s11704-024-40763-6)Cited by:[§2\.2](https://arxiv.org/html/2610.29188#S2.SS2.p1.1)\.
- McNemar \(1947\)Q\. McNemarNote on the sampling error of the difference between correlated proportions or percentages\.Psychometrika12\(2\),pp\. 153–157\.External Links:ISSN 1860\-0980,[Document](https://dx.doi.org/10.1007/BF02295996),[Link](https://doi.org/10.1007/BF02295996)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px5.p1.1)\.
- MDN Web Docs \(2026\)MDN Web DocsHow to write in Markdown\.Note:[https://developer\.mozilla\.org/en\-US/docs/MDN/Writing\_guidelines/Howto/Markdown\_in\_MDN](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Howto/Markdown_in_MDN)Last modified 2026\-01\-04Cited by:[§1](https://arxiv.org/html/2610.29188#S1.p3.1),[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Meta AI \(2025\)Meta AIThe llama 4 herd: the beginning of a new era of natively multimodal ai innovation\.Note:[https://ai\.meta\.com/blog/llama\-4\-multimodal\-intelligence/](https://ai.meta.com/blog/llama-4-multimodal-intelligence/)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px1.p1.1)\.
- Microsoft \(2025\)MicrosoftPhi\-4\-mini technical report: compact yet powerful multimodal language models via mixture\-of\-LoRAs\.External Links:2503\.01743,[Link](https://arxiv.org/abs/2503.01743)Cited by:[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p5.1)\.
- Oestreich and Müller \(2025\)J\. Oestreich and L\. MüllerEvaluating structured decoding for text\-to\-table generation: evidence from three datasets\.InProceedings of the First Workshop on Comparative Performance Evaluation: From Rules to Language Models,A\. Picazo\-Izquierdo, E\. L\. Estevanell\-Valladares, R\. Mitkov, R\. Munoz Guillena, and R\. Garcia Cerda \(Eds\.\),Varna, Bulgaria,pp\. 113–122\.External Links:[Link](https://aclanthology.org/2025.r2lm-1.12/)Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- OpenAI \(2025\)OpenAIGPT\-5 system card\.Note:[https://cdn\.openai\.com/gpt\-5\-system\-card\.pdf](https://cdn.openai.com/gpt-5-system-card.pdf)Cited by:[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p4.1),[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px1.p1.1)\.
- Palet al\.\(2023\)V\. Pal, A\. Yates, E\. Kanoulas, and M\. de RijkeMultiTabQA: generating tabular answers for multi\-table question answering\.InProceedings of the 61st Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),A\. Rogers, J\. Boyd\-Graber, and N\. Okazaki \(Eds\.\),Toronto, Canada,pp\. 6322–6334\.External Links:[Link](https://aclanthology.org/2023.acl-long.348/),[Document](https://dx.doi.org/10.18653/v1/2023.acl-long.348)Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Pasupat and Liang \(2015\)P\. Pasupat and P\. LiangCompositional semantic parsing on semi\-structured tables\.InProceedings of the 53rd Annual Meeting of the Association for Computational Linguistics and the 7th International Joint Conference on Natural Language Processing \(Volume 1: Long Papers\),C\. Zong and M\. Strube \(Eds\.\),Beijing, China,pp\. 1470–1480\.External Links:[Link](https://aclanthology.org/P15-1142/),[Document](https://dx.doi.org/10.3115/v1/P15-1142)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1),[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p4.1),[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px2.p1.1)\.
- Penney \(2023\)F\. T\. PenneyMultiMarkdown user’s guide\.Note:[https://fletcher\.github\.io/MultiMarkdown\-6/MMD\_Users\_Guide\.html](https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html)Version 6\.6\.0; revised 2023\-05\-25Cited by:[§1](https://arxiv.org/html/2610.29188#S1.p3.1),[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Qwen Team \(2025a\)Qwen TeamQwen3 technical report\.External Links:2505\.09388,[Link](https://arxiv.org/abs/2505.09388)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px1.p1.1)\.
- Qwen Team \(2025b\)Qwen TeamQwen3\-vl technical report\.External Links:2511\.21631,[Link](https://arxiv.org/abs/2511.21631)Cited by:[§5\.2](https://arxiv.org/html/2610.29188#S5.SS2.p5.1)\.
- Rajpurkaret al\.\(2016\)P\. Rajpurkar, J\. Zhang, K\. Lopyrev, and P\. LiangSQuAD: 100,000\+ questions for machine comprehension of text\.InProceedings of the 2016 Conference on Empirical Methods in Natural Language Processing,J\. Su, K\. Duh, and X\. Carreras \(Eds\.\),Austin, Texas,pp\. 2383–2392\.External Links:[Link](https://aclanthology.org/D16-1264/),[Document](https://dx.doi.org/10.18653/v1/D16-1264)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px2.p1.1)\.
- Ramuet al\.\(2024\)P\. Ramu, A\. Garimella, and S\. BandyopadhyayIs this a bad table? a closer look at the evaluation of table generation from text\.InProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing,Y\. Al\-Onaizan, M\. Bansal, and Y\. Chen \(Eds\.\),Miami, Florida, USA,pp\. 22206–22216\.External Links:[Link](https://aclanthology.org/2024.emnlp-main.1239/),[Document](https://dx.doi.org/10.18653/v1/2024.emnlp-main.1239)Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Suiet al\.\(2024\)Y\. Sui, M\. Zhou, M\. Zhou, S\. Han, and D\. ZhangTable meets LLM: can large language models understand structured table data? a benchmark and empirical study\.InProceedings of the 17th ACM International Conference on Web Search and Data Mining,WSDM ’24,New York, NY, USA,pp\. 645–654\.External Links:ISBN 9798400703713,[Link](https://doi.org/10.1145/3616855.3635752),[Document](https://dx.doi.org/10.1145/3616855.3635752)Cited by:[§1](https://arxiv.org/html/2610.29188#S1.p2.1),[§2\.2](https://arxiv.org/html/2610.29188#S2.SS2.p1.1)\.
- Touvronet al\.\(2023\)H\. Touvron, T\. Lavril, G\. Izacard, X\. Martinet, M\. Lachaux, T\. Lacroix, B\. Rozière, N\. Goyal, E\. Hambro, F\. Azhar, A\. Rodriguez, A\. Joulin, E\. Grave, and G\. LampleLLaMA: open and efficient foundation language models\.External Links:2302\.13971,[Link](https://arxiv.org/abs/2302.13971)Cited by:[§4\.1](https://arxiv.org/html/2610.29188#S4.SS1.SSS0.Px1.p1.1)\.
- van Oostrumet al\.\(2024\)P\. van Oostrum, Ø\. Bache, and J\. LeichterThemultirow,bigstrutandbigdelimpackages\.Note:[https://mirrors\.ctan\.org/macros/latex/contrib/multirow/multirow\.pdf](https://mirrors.ctan.org/macros/latex/contrib/multirow/multirow.pdf)Version 2\.9, released 2024\-11\-12Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- WHATWG \(2026\)WHATWGHTML living standard: tables\.Note:[https://html\.spec\.whatwg\.org/multipage/tables\.html](https://html.spec.whatwg.org/multipage/tables.html)Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Wuet al\.\(2025\)P\. Wu, Y\. Yang, G\. Zhu, C\. Ye, H\. Gu, X\. Lu, R\. Xiao, B\. Bao, Y\. He, L\. Zha, W\. Ye, J\. Zhao, and H\. WangRealHiTBench: a comprehensive realistic hierarchical table benchmark for evaluating LLM\-based table analysis\.InFindings of the Association for Computational Linguistics: ACL 2025,W\. Che, J\. Nabende, E\. Shutova, and M\. T\. Pilehvar \(Eds\.\),Vienna, Austria,pp\. 7105–7137\.External Links:[Link](https://aclanthology.org/2025.findings-acl.371/),[Document](https://dx.doi.org/10.18653/v1/2025.findings-acl.371),ISBN 979\-8\-89176\-256\-5Cited by:[§1](https://arxiv.org/html/2610.29188#S1.p2.1),[§2\.2](https://arxiv.org/html/2610.29188#S2.SS2.p1.1)\.
- Yinet al\.\(2020\)P\. Yin, G\. Neubig, W\. Yih, and S\. RiedelTaBERT: pretraining for joint understanding of textual and tabular data\.InProceedings of the 58th Annual Meeting of the Association for Computational Linguistics,D\. Jurafsky, J\. Chai, N\. Schluter, and J\. Tetreault \(Eds\.\),Online,pp\. 8413–8426\.External Links:[Link](https://aclanthology.org/2020.acl-main.745/),[Document](https://dx.doi.org/10.18653/v1/2020.acl-main.745)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1)\.
- Yuet al\.\(2018\)T\. Yu, R\. Zhang, K\. Yang, M\. Yasunaga, D\. Wang, Z\. Li, J\. Ma, I\. Li, Q\. Yao, S\. Roman, Z\. Zhang, and D\. RadevSpider: a large\-scale human\-labeled dataset for complex and cross\-domain semantic parsing and text\-to\-SQL task\.InProceedings of the 2018 Conference on Empirical Methods in Natural Language Processing,E\. Riloff, D\. Chiang, J\. Hockenmaier, and J\. Tsujii \(Eds\.\),Brussels, Belgium,pp\. 3911–3921\.External Links:[Link](https://aclanthology.org/D18-1425/),[Document](https://dx.doi.org/10.18653/v1/D18-1425)Cited by:[§2\.3](https://arxiv.org/html/2610.29188#S2.SS3.p1.1)\.
- Zhanget al\.\(2025\)J\. Zhang, Y\. Zhu, M\. Sun, Y\. Luo, S\. Qiao, L\. Du, D\. Zheng, H\. Chen, and N\. ZhangLightThinker: thinking step\-by\-step compression\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,Suzhou, China,pp\. 13307–13328\.External Links:[Document](https://dx.doi.org/10.18653/v1/2025.emnlp-main.673),[Link](https://aclanthology.org/2025.emnlp-main.673/)Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px4.p1.3)\.
- Zhanget al\.\(2024\)X\. Zhang, Z\. Huang, E\. O\. Taga, C\. Joe\-Wong, S\. Oymak, and J\. ChenEfficient contextual LLM cascades through budget\-constrained policy learning\.InProceedings of the 38th International Conference on Neural Information Processing Systems,NIPS ’24,Red Hook, NY, USA\.External Links:ISBN 9798331314385Cited by:[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px4.p1.3)\.
- Zhonget al\.\(2017\)V\. Zhong, C\. Xiong, and R\. SocherSeq2SQL: generating structured queries from natural language using reinforcement learning\.External Links:1709\.00103,[Link](https://arxiv.org/abs/1709.00103),[Document](https://dx.doi.org/10.48550/arXiv.1709.00103)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1)\.
- Zhuet al\.\(2021\)F\. Zhu, W\. Lei, Y\. Huang, C\. Wang, S\. Zhang, J\. Lv, F\. Feng, and T\. ChuaTAT\-QA: a question answering benchmark on a hybrid of tabular and textual content in finance\.InProceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing \(Volume 1: Long Papers\),Online,pp\. 3277–3287\.External Links:[Link](https://aclanthology.org/2021.acl-long.254/),[Document](https://dx.doi.org/10.18653/v1/2021.acl-long.254)Cited by:[§2\.1](https://arxiv.org/html/2610.29188#S2.SS1.p1.1),[§5\.4](https://arxiv.org/html/2610.29188#S5.SS4.SSS0.Px2.p1.1)\.

## Appendix AComplexity Level Definitions

Table 5:Complexity Level Definitions\.
## Appendix BAdditional Statistics of STB

### B\.1Complexity and Domain Distributions of STB

Tables[6](https://arxiv.org/html/2610.29188#A2.T6)and[7](https://arxiv.org/html/2610.29188#A2.T7)summarize the complexity\-level and domain distributions of STB, respectively\.

Table 6:Complexity\-level distribution and average table size of STB \(tables containing all four intents: LOOKUP/COUNTING/COMPARISON/AGGREGATION\)\. Average rows/cols aggregate all sub\-tables for multi\-table cases\.Table 7:Domain distribution of STB \(tables containing all four intents\)\.

## Appendix CLTEM Rendering Examples

The syntax figures in Section[4\.2](https://arxiv.org/html/2610.29188#S4.SS2)show LTEM source only\. Figure[8](https://arxiv.org/html/2610.29188#A3.F8)pairs each span construct with the table it renders to, and Figure[9](https://arxiv.org/html/2610.29188#A3.F9)shows a report table that combines them\. Span markers are highlighted in the source, and merged cells are shaded in the rendered tables\.

\(a\) Column span \(F3\)\.<<merges a cell into the cell on its left\.

\|Time\|RoomA\|RoomB\|

\|\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\|

\|09:00\|Keynote\|<<\|

\|10:00\|Workshop\|Panel\|

⇒\\Rightarrow

\(b\) Row span \(F3\)\.^^merges a cell into the cell above\.

\|Region\|City\|Sales\|

\|\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\|

\|Asia\|Seoul\|120\|

\|^^\|Tokyo\|95\|

\|Europe\|Paris\|80\|

\|^^\|Berlin\|70\|

⇒\\Rightarrow

\(c\) Span attribute \(F3\)\.\{c:5\}spans five columns, the same as writing<<four times\.

\|Time\|Mon\|Tue\|Wed\|Thu\|Fri\|

\|\-\-\-\-\-\-\-\|\-\-\-\-\-\-\|\-\-\-\-\-\-\|\-\-\-\-\-\-\|\-\-\-\-\-\-\|\-\-\-\-\-\-\|

\|07:00\|Yoga\|Spin\|Yoga\|Spin\|Yoga\|

\|12:00\|Closed\{c:5\}\|

\|18:00\|HIIT\|Yoga\|HIIT\|Yoga\|HIIT\|

⇒\\RightarrowTimeMonTueWedThuFri07:00YogaSpinYogaSpinYoga12:00Closed18:00HIITYogaHIITYogaHIIT

\(d\) Block span \(F3\)\.\{c:2,r:2\}spans two columns and two rows; the covered cells are left empty\.

\|Time\|RoomA\|RoomB\|RoomC\|

\|\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\|

\|09:00\|Workshop\{c:2,r:2\}\|\|Talk\|

\|10:00\|\|\|Demo\|

\|11:00\|Standup\|Lunch\|Review\|

⇒\\Rightarrow

\(e\) Multi\-level header \(F4\)\.Every row above the separator is a header row;<<and^^group the headers\.

\|Region\|Revenue\|<<\|

\|^^\|Q1\|Q2\|

\|\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\|

\|Asia\|100\|120\|

\|Europe\|90\|110\|

⇒\\Rightarrow

\(f\) Section rows \(F5\)\.A row merged across all columns starts a new section that shares the same columns\.

\|Card\|Annualfee\|Rewards\|

\|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\-\|

\|Travelcards\|<<\|<<\|

\|Globe\|$95\|2xmiles\|

\|Atlas\|$250\|3xmiles\|

\|Cash\-backcards\|<<\|<<\|

\|Daily\|$0\|1\.5%\|

⇒\\RightarrowCardAnnual feeRewardsTravel cardsGlobe$952x milesAtlas$2503x milesCash\-back cardsDaily$01\.5%

Figure 8:LTEM source \(left\) and the rendered table \(right\) for each span construct\.\|Area\|Program\|FY2025\|<<\|FY2026\|<<\|Change\|

\|^^\|^^\|Budget\|Spent\|Budget\|Spent\|^^\|

\|\-\-\-\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\|\-\-\-\-\-\-\-:\|\-\-\-\-\-\-:\|\-\-\-\-\-\-\-:\|\-\-\-\-\-\-:\|\-\-\-\-\-\-\-:\|

\|Digital\|E\-documentstandards\|1,240\|1,180\|1,380\|612\|\+11\.3%\|

\|^^\|Openpublicdata\|860\|845\|910\|402\|\+5\.8%\|

\|^^\|Datastructuring\|\-\|\-\|420\|95\|\-\|

\|Regional\|Regionalhubs\|2,100\|2,064\|2,050\|1,010\|\-2\.4%\|

\|^^\|Youthsettlement\|730\|701\|790\|355\|\+8\.2%\|

\|Grandtotal\|<<\|4,930\|4,790\|5,550\|2,474\|\+12\.6%\|

⇓\\Downarrow

FY2025FY2026AreaProgramBudgetSpentBudgetSpentChangeE\-document standards1,2401,1801,380612\+11\.3%Open public data860845910402\+5\.8%DigitalData structuring\-\-42095\-Regional hubs2,1002,0642,0501,010\-2\.4%RegionalYouth settlement730701790355\+8\.2%Grand total4,9304,7905,5502,474\+12\.6%

Figure 9:A report table that combines row spans, column spans, and a two\-row header \(F3–F4\), as LTEM source \(top\) and the rendered table \(bottom\)\. Numeric columns use the Markdown right\-alignment marker \(\-\-\-:\)\.
## Appendix DFormal Grammar \(EBNF\)

This appendix defines thesyntaxof LTEM using Extended Backus–Naur Form \(EBNF\)\. The grammar is a context\-free grammar \(CFG\) and follows the notation of ISO/IEC 14977:1996\.

### D\.1Notation Conventions

Table 8:Notation conventions used in the EBNF specification\.
### D\.2Document Structure

document=\{table\};

table=\[table\_id\_row\],header\_section,separator\_row,\[data\_section\];

table\_id\_row="\|","\#",whitespace,table\_id,whitespace,"\|",newline;

table\_id=letter\_or\_underscore,\{letter\_or\_digit\_or\_underscore\};

header\_section=row,\{row\};

data\_section=row,\{row\};

separator\_row="\|",separator\_cell,\{"\|",separator\_cell\},"\|",newline;

separator\_cell=\{"\-"\},\[":"\],\{"\-"\};

row="\|",cell,\{"\|",cell\},"\|",\[newline\];

### D\.3Cell Structure

cell=cell\_content,\[span\_attribute\]

\|colspan\_marker

\|rowspan\_marker

\|empty\_cell;

empty\_cell=\{whitespace\};

cell\_content=\{content\_element\};

content\_element=plain\_text

\|table\_reference

\|inline\_math

\|display\_math

\|inline\_list

\|line\_break

\|checkbox;

plain\_text=?anycharacterexcept\|,\{,\},\\,$,@,newline?;

### D\.4Span Syntax

colspan\_marker=\{whitespace\},"<<",\{whitespace\};

rowspan\_marker=\{whitespace\},"^^",\{whitespace\};

span\_attribute="\{",span\_spec,\{",",span\_spec\},"\}";

span\_spec=colspan\_spec\|rowspan\_spec;

colspan\_spec="c",":",positive\_integer;

rowspan\_spec="r",":",positive\_integer;

positive\_integer=nonzero\_digit,\{digit\};

### D\.5Reference Syntax \(Phase 4\)

table\_reference=simple\_reference

\|filtered\_reference

\|column\_reference

\|cell\_reference;

simple\_reference="@",table\_id;

filtered\_reference="@",table\_id,"\[",filter\_condition,"\]";

column\_reference="@",table\_id,"\.",column\_name;

cell\_reference="@",table\_id,"\[",row\_index,"\]","\.",column\_name;

filter\_condition=column\_name,comparison\_op,value;

comparison\_op="<"\|"\>"\|"<="\|"\>="\|"="\|"\!=";

column\_name=letter\_or\_underscore,\{letter\_or\_digit\_or\_underscore\};

row\_index=digit,\{digit\};

value=number\|string\_literal;

number=\["\-"\],digit,\{digit\},\["\.",digit,\{digit\}\];

string\_literal="’",\{?anycharacterexcept’?\},"’";"

### D\.6Inline Content Syntax

line\_break="\\\\","\\\\";

inline\_math="$",math\_content,"$";

display\_math="$$",math\_content,"$$";

math\_content=\{?anycharacterexcept$?\};

inline\_list=list\_item,\{line\_break,list\_item\};

list\_item=bullet\_item\|numbered\_item\|checkbox\_item;

bullet\_item="\-",whitespace,item\_text;

numbered\_item=digit,\{digit\},"\.",whitespace,item\_text;

checkbox\_item=checkbox,whitespace,item\_text;

checkbox="\[",\("x"\|""\),"\]";

item\_text=\{?anycharacterexcept\\\\,\|,newline?\};

### D\.7Terminal Definitions

letter="A"\|"B"\|\.\.\.\|"Z"\|"a"\|"b"\|\.\.\.\|"z";

digit="0"\|"1"\|"2"\|"3"\|"4"\|"5"\|"6"\|"7"\|"8"\|"9";

nonzero\_digit="1"\|"2"\|"3"\|"4"\|"5"\|"6"\|"7"\|"8"\|"9";

letter\_or\_underscore=letter\|"\_";

letter\_or\_digit\_or\_underscore=letter\|digit\|"\_";

whitespace=""\|"\\t";

newline="\\n"\|"\\r\\n";

### D\.8Grammar Properties

Table 9:Summary of grammar properties\.
### D\.9Lark Implementation

The following is a Lark parser grammar derived from the EBNF above:

//LTEMGrammarforLarkParser

//Version1\.0

start:document

document:table\+

table:table\_id\_row?header\_sectionseparator\_rowdata\_section?

table\_id\_row:"\|""\#"TABLE\_ID"\|"NEWLINE

header\_section:row\+

data\_section:row\+

separator\_row:"\|"SEP\_CELL\("\|"SEP\_CELL\)\*"\|"NEWLINE

SEP\_CELL:/:?\-\+:?/

row:"\|"cell\("\|"cell\)\*"\|"NEWLINE?

cell:cell\_contentspan\_attr?

\|COLSPAN\_MARKER

\|ROWSPAN\_MARKER

\|EMPTY\_CELL

cell\_content:content\_element\+

content\_element:TEXT

\|table\_ref

\|INLINE\_MATH

\|DISPLAY\_MATH

\|LINE\_BREAK

\|CHECKBOX

span\_attr:"\{"span\_spec\(","span\_spec\)\*"\}"

span\_spec:COLSPAN\_ATTR\|ROWSPAN\_ATTR

COLSPAN\_ATTR:"c:"POSITIVE\_INT

ROWSPAN\_ATTR:"r:"POSITIVE\_INT

POSITIVE\_INT:/\[1\-9\]\[0\-9\]\*/

COLSPAN\_MARKER:/\\s\*<<\\s\*/

ROWSPAN\_MARKER:/\\s\*\\^\\^\\s\*/

EMPTY\_CELL:/\\s\*/

table\_ref:REF\_CELL\|REF\_COLUMN\|REF\_FILTERED\|REF\_SIMPLE

REF\_SIMPLE:/@\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*/

REF\_FILTERED:/@\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*\\\[\[^\\\]\]\+\\\]/

REF\_COLUMN:/@\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*\\\.\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*/

REF\_CELL:/@\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*\\\[\[0\-9\]\+\\\]\\\.\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*/

INLINE\_MATH:/\\$\[^$\]\+\\$/

DISPLAY\_MATH:/\\$\\$\[^$\]\+\\$\\$/

LINE\_BREAK:/\\s\*\\\\\\\\\\s\*/

CHECKBOX:/\\\[\[x\]\\\]/

TABLE\_ID:/\[a\-zA\-Z\_\]\[a\-zA\-Z0\-9\_\]\*/

TEXT:/\[^\|\{\}\\n\\\\$@\]\+/

NEWLINE:/\\r?\\n/

%importcommon\.WS\_INLINE

%ignoreWS\_INLINE

## Appendix EPrompt Templates

This appendix reports the prompt templates used for STB QA generation, QA verification, and table\-understanding evaluation\. Curly\-brace fields denote runtime variables filled by the pipeline\.

STB QA Generation Prompt[⬇](data:text/plain;base64,Q3JlYXRlIDEgdGFibGUgUUEgYXMgSlNPTi4KSU5URU5UPXtpbnRlbnR9ClJldHVybiBPTkxZOiBxdWVzdGlvbiwgYW5zd2VyLCB0YXJnZXRzLiB7dGFyZ2V0c19ydWxlfQpSdWxlczogYW5zd2VyYWJsZSBPTkxZIGZyb20gQ2VsbHM7IHF1ZXN0aW9uIG11c3QgTk9UIG1lbnRpb24gW2hlYWRlcixyb3dzcGFuLGNvbHNwYW4sbWVyZ2UsbGF5b3V0LHN0cnVjdHVyZSxsZXZlbCxpbmRleCxyb3csY29sdW1uXTsgYW5zd2VyIG11c3QgYmUgc2hvcnQgKG51bWJlci9zaG9ydCBwaHJhc2UpLCBubyBleHBsYW5hdGlvbjsgVGFyZ2V0cyBzaG91bGQgbGlzdCBvbmx5IGRhdGEgY2VsbHMgdGhhdCBkaXJlY3RseSBjb250cmlidXRlIHRvIHRoZSBmaW5hbCBhbnN3ZXIuIENvbXB1dGUgdGhlIGFuc3dlciBjb25zaWRlcmluZyB0aGUgdW5pdHMgYW5kIHN5bWJvbHMgc2hvd24gaW4gdGhlIHRhYmxlLgpGb3JtYXQ6IHRhYmxlX2tleShvcHRpb25hbCl8cm93LGNvbCxyb3dzcGFuLGNvbHNwYW4sSHxEfHRleHQgKEg9aGVhZGVyLCBEPWRhdGEpLiB7dGFyZ2V0X2hpbnR9CntpbnRlbnRfZ3VpZGFuY2V9CntsZXZlbF9oaW50fQp7bXVsdGlfaGludH0KQ2VsbHM6Cnt0YWJsZV9saW5lc30KT3V0cHV0IGV4YWN0bHk6IHtvdXRwdXRfc2NoZW1hfQ==)Create1tableQAasJSON\.INTENT=\{intent\}ReturnONLY:question,answer,targets\.\{targets\_rule\}Rules:answerableONLYfromCells;questionmustNOTmention\[header,rowspan,colspan,merge,layout,structure,level,index,row,column\];answermustbeshort\(number/shortphrase\),noexplanation;Targetsshouldlistonlydatacellsthatdirectlycontributetothefinalanswer\.Computetheanswerconsideringtheunitsandsymbolsshowninthetable\.Format:table\_key\(optional\)\|row,col,rowspan,colspan,H\|D\|text\(H=header,D=data\)\.\{target\_hint\}\{intent\_guidance\}\{level\_hint\}\{multi\_hint\}Cells:\{table\_lines\}Outputexactly:\{output\_schema\}

The intent guidance field is instantiated as follows: LOOKUP reads one value for a specific item and attribute; AGGREGATION computes a numeric summary over multiple numeric cells; COUNTING returns an integer count of items meeting a condition; and COMPARISON compares multiple numeric values and selects the higher, lower, best, or worst item\.

QA Verification Prompt[⬇](data:text/plain;base64,WW91IGFyZSBhIHN0cmljdCB2YWxpZGF0b3IuCkFuc3dlciB0aGUgcXVlc3Rpb24gdXNpbmcgT05MWSB0aGUgdGFibGUgY2VsbHMuClJldHVybiBKU09OIE9OTFk6IHsiYW5zd2VyIjoiLi4uIn0uCk5vIGV4cGxhbmF0aW9uLiBObyBleHRyYSBrZXlzLiBBbnN3ZXIgbXVzdCBiZSBzaG9ydC4KCntmbXRfbGluZX0KClF1ZXN0aW9uOiB7cXVlc3Rpb259CkNlbGxzOgp7dGFibGVfbGluZXN9)Youareastrictvalidator\.AnswerthequestionusingONLYthetablecells\.ReturnJSONONLY:\{"answer":"\.\.\."\}\.Noexplanation\.Noextrakeys\.Answermustbeshort\.\{fmt\_line\}Question:\{question\}Cells:\{table\_lines\}

Table Understanding Evaluation Prompt[⬇](data:text/plain;base64,WW91IGFyZSBhbiBleHBlcnQgZGF0YSBhbmFseXN0IGFuc3dlcmluZyBxdWVzdGlvbnMgZnJvbSB0YWJsZXMuIFVzZSBvbmx5IHRoZSB0YWJsZTsgaWYgYW5zd2VyIG1pc3NpbmcsIG91dHB1dCBOL0EuIFJlc3BvbmQgd2l0aCBPTkxZIHRoZSBmaW5hbCBhbnN3ZXIgdmFsdWUgKG5vIGV4cGxhbmF0aW9uLCBubyBwcmVmaXgpLiBJZiBhIG51bWJlciBoYXMgY29tbWFzLCBvbWl0IGNvbW1hcy4gSW5jbHVkZSB1bml0cyBvbmx5IGlmIHNob3duIGluIHRoZSB0YWJsZS4KVGFibGUgZm9ybWF0OiB7Zm10fS57Zm10X2hpbnR9CgpUQUJMRToKe3RhYmxlX3RleHR9CgpRVUVTVElPTjoge3F1ZXN0aW9ufQpBTlNXRVIgOg==)Youareanexpertdataanalystansweringquestionsfromtables\.Useonlythetable;ifanswermissing,outputN/A\.RespondwithONLYthefinalanswervalue\(noexplanation,noprefix\)\.Ifanumberhascommas,omitcommas\.Includeunitsonlyifshowninthetable\.Tableformat:\{fmt\}\.\{fmt\_hint\}TABLE:\{table\_text\}QUESTION:\{question\}ANSWER:

For LTEM inputs, the evaluation prompt additionally includes the following guide:

LTEM Guide Added to Evaluation Prompt[⬇](data:text/plain;base64,TFRFTSBndWlkZTogJzw8JyA9IGNvcHkgbmVhcmVzdCBub24tPDwgY2VsbCB0byB0aGUgbGVmdDsgJ15eJyA9IGNvcHkgbmVhcmVzdCBub24tXl4gY2VsbCBhYm92ZTsge2M6Tn0ve3I6Tn0gPSBleHBsaWNpdCBjb2wvcm93IHNwYW5zOyAnfC0tLXwnIHNlcGFyYXRlcyBoZWFkZXJzOyAnXFwnIGlzIGEgbmV3bGluZS4gUmVzb2x2ZSBtZXJnZXMvc3BhbnMgZmlyc3QgYW5kIGFuc3dlciBmcm9tIHRoZSByZXNvbHZlZCB0YWJsZS4=)LTEMguide:’<<’=copynearestnon\-<<celltotheleft;’^^’=copynearestnon\-^^cellabove;\{c:N\}/\{r:N\}=explicitcol/rowspans;’\|\-\-\-\|’separatesheaders;’\\\\’isanewline\.Resolvemerges/spansfirstandanswerfromtheresolvedtable\.

All token counts reported in the paper are computed from the stored prompts using theo200k\_basetokenizer\.

## Appendix FSTB Generation Pipeline

STB generation follows a controlled three\-stage pipeline\. In the first stage, a rule\-based structural generator samples the complexity level, domain, row/column count, and the structural operations \(F1–F6\) required for each table\. In the second stage, large language models populate each table with domain\-appropriate headers and cell values while preserving the sampled structure\. In the third stage, question–answer pairs are generated for four intent types \(LOOKUP, COUNTING, COMPARISON, AGGREGATION\) and filtered by agreement between two independent model families\. Prompt templates used in each stage are provided in Appendix[E](https://arxiv.org/html/2610.29188#A5)\.

## Appendix GHiTab Overall Results

Per\-format performance on the HiTab test split is shown below\. The STB overall results appear as Table[2](https://arxiv.org/html/2610.29188#S6.T2)in the main body\.

Table 10:Overall performance on the HiTab test split \(515 hierarchical tables\)\. HTML achieves the highest nEM, followed by LaTeX\. The ranking of LaTeX reverses compared to STB \(rank 6→\\rightarrow2\), suggesting format effectiveness is dataset\-dependent\.#### Table Generation success rates\.

Table[11](https://arxiv.org/html/2610.29188#A7.T11)reports the Excellent\-rate breakdown corresponding to the Table Generation results in Table[4](https://arxiv.org/html/2610.29188#S6.T4)\.

Table 11:Excellent\-rate breakdown for Table Generation on HiTab\. Excellent denotes ANLS≥0\.9\\geq 0\.9; the values use the same evaluation setting as Table[4](https://arxiv.org/html/2610.29188#S6.T4)\.

## Appendix HSupplementary Analyses

This appendix consolidates additional fine\-grained analyses that characterize format behavior beyond the aggregate results in the main paper\. Unless otherwise stated, the reported STB understanding numbers are normalized exact match \(nEM\) over the same evaluation protocol as the main paper\. These results are intended to clarify where format differences arise rather than to replace the primary aggregate comparisons in the main Results section\.

### H\.1Fine\-grained STB Understanding Analyses

#### Level\- and feature\-wise Markdown–LTEM comparison\.

Table[12](https://arxiv.org/html/2610.29188#A8.T12)compares Markdown and LTEM across the STB complexity levels\. The nEM differences are small, with LTEM slightly higher at each level\. Invalid rates are low for both formats and do not show a uniform level\-wise advantage\. This supports a conservative interpretation: LTEM’s main distinction is explicit structural representation rather than a uniform large QA gain\.

Table 12:Level\-wise comparison of Markdown and LTEM on STB\. Invalid rates are percentages\.The same pattern appears when conditioning on structural features \(Table[13](https://arxiv.org/html/2610.29188#A8.T13)\)\. The main distinction starts at F3, cell merging: Markdown can only approximate such tables through visual alignment or repeated text, whereas LTEM explicitly marks span extent\.

Table 13:Feature\-conditioned Markdown–LTEM comparison on STB\. F2–F6 denote operational slices in which the corresponding structural feature is observed; the slices may overlap and are not cumulative level subsets\. Invalid rates are percentages\.

### H\.2LTEM Design\-Choice Ablation

To examine the sensitivity of Table QA performance to LTEM’s surface syntax, we compare the proposed forms of five elements with structure\-preserving alternatives on matched STB instances\. For each comparison, table content, questions, reference answers, and the evaluation protocol are held fixed, and only the notation of the target element is varied\. Experiments use GPT\-5, and paired differences are assessed using exact McNemar tests\.

Table 14:Element\-wise LTEM design\-choice ablation on STB using GPT\-5\. Each row compares the LTEM form with a structure\-preserving alternative on the same QA pairs \(NN\)\. nEM is reported as LTEM/alternative;p\-values are from exact McNemar tests\.None of the five paired comparisons reaches statistical significance \(allp≥\.302p\\geq\.302\); the ablation therefore does not identify a preferred surface form on the basis of QA accuracy\. LTEM adopts the proposed forms in accordance with the Markdown Compatibility and Linear Readability principles\.

### H\.3Structure\-conditioned Accuracy

We stratify L1–L5 single\-table examples by span\-continuation and repeated\-value ratios, using None/Low/Medium/High cutoffs of 0/\.15/\.35 and 0/\.30/\.60, respectively\. Table[15](https://arxiv.org/html/2610.29188#A8.T15)reports descriptive nEM results\. Across the larger slices, LTEM remains comparable to HTML and Markdown, while LaTeX is generally lower; the small High buckets are reported without broad generalization\.

Table 15:Structure\-conditioned nEM on STB L1–L5 by merged\-cell density and duplicate\-value ambiguity\. Table counts are shown in parentheses\.
### H\.4Failure Modes and Question Types

Refusal and Invalid rates are low for most formats\. LaTeX nevertheless shows substantially higher Invalid and logged\-error rates than the other text formats \(Table[16](https://arxiv.org/html/2610.29188#A8.T16)\)\.

Table 16:Failure diagnostics on STB\. Refusal and Invalid are calculated among nEM\-incorrect outputs; Logged error is recorded independently and may overlap\. Values other than nEM are percentages\.Table[17](https://arxiv.org/html/2610.29188#A8.T17)reports descriptive nEM by question type\. Aggregation is the most difficult type across formats; we do not infer a format\-specific question\-type advantage from this breakdown\.

Table 17:Question\-type nEM breakdown on STB\.
### H\.5Fine\-tuning Pilot

To assess whether small instruction\-tuned models can adapt to LTEM with limited supervision, we conducted a LoRA pilot using LTEM\-formatted STB QA examples\. Tables were partitioned across the training, validation, and test sets, yielding 3,472, 424, and 460 examples, respectively\. We used LoRA rank 16, alpha 32, dropout 0\.05, two epochs, a learning rate of2×10−42\\times 10^\{\-4\}, and a maximum sequence length of 4096\.

Table[18](https://arxiv.org/html/2610.29188#A8.T18)shows substantial gains for all three backbones on held\-out STB tables\. These results indicate that LTEM\-formatted table QA is amenable to adaptation with limited in\-domain supervision\. Because format exposure and task supervision are introduced jointly, however, the pilot does not isolate their individual contributions\. The evaluation is limited to 4B\-scale backbones, the STB distribution, and a single set of LoRA hyperparameters\.

Table 18:LTEM LoRA pilot results on held\-out STB tables using normalized Exact Match \(nEM\) as defined in the main evaluation\.For Qwen3\-4B\-Instruct, the largest gains occur on comparison and aggregation questions \(Table[19](https://arxiv.org/html/2610.29188#A8.T19)\), while lookup and counting improve more modestly\.

Table 19:Qwen3\-4B LTEM LoRA breakdown by question type and complexity level\.

## Appendix IMcNemar’s Test for LTEM vs\. LaTeX on STB

To assess paired differences between LTEM and LaTeX on STB, we applied McNemar’s test to matched predictions within each of three runs and combined the resulting p\-values using Fisher’s method\.

Table 20:McNemar test comparing LTEM vs\. LaTeX on STB\. n01denotes LTEM\-wrong & LaTeX\-correct, and n10denotes LTEM\-correct & LaTeX\-wrong\. The discordant counts are summed across three runs, and the p\-values are Fisher\-combined\. Significance: \*\*\*p<<0\.001, \*\*p<<0\.01, \*p<<0\.05\.
## Appendix JTranslation Disclosure

We used AI tools as auxiliary aids for some translation\. All translations were reviewed and revised by the authors, and the final manuscript reflects our verification of factual accuracy and phrasing\.