@zombie-mermaid/ascii-renderer 2.2.1

package/src/__tests__/ascii-er-cardinality.test.ts

@@ -0,0 +1,40 @@
+// ============================================================================
+// ASCII ER diagram crow's-foot cardinality marker tests
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER crow-foot cardinality markers', () => {
+  it('mirrors the zero-one marker orientation on the left side (regression)', () => {
+    // Left-side markers sit at the left entity's right edge, pointing away
+    // from it (line nearest the entity, circle furthest): "|o". Before the
+    // fix, getCrowsFootChars() always returned "o|" regardless of side,
+    // which is only correct on the right side.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        WIDGET |o--|| GADGET : rel`,
+      { useAscii: true },
+    )
+    expect(ascii).toContain('|o')
+
+    const unicode = renderMermaidASCII(`erDiagram
+      WIDGET |o--|| GADGET : rel`)
+    expect(unicode).toContain('│○')
+  })
+
+  it('keeps the zero-one marker orientation on the right side', () => {
+    // Right-side markers sit at the right entity's left edge, pointing away
+    // from it: circle nearest the entity, line furthest: "o|".
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        WIDGET ||--o| GADGET : rel`,
+      { useAscii: true },
+    )
+    expect(ascii).toContain('o|')
+
+    const unicode = renderMermaidASCII(`erDiagram
+      WIDGET ||--o| GADGET : rel`)
+    expect(unicode).toContain('○│')
+  })
+})

package/src/__tests__/ascii-er-corner-glyphs.test.ts

@@ -0,0 +1,249 @@
+// ============================================================================
+// ASCII ER diagram: routed relationship lines get a corner glyph at each
+// jog/detour turn (issue #414)
+//
+// renderErAscii drew every relationship line, jog, and detour purely out of
+// plain '─'/'│' segments meeting at unmarked right angles, even at a point
+// where the routed path actually changes direction. In a dense diagram this
+// reads ambiguously: a viewer can't tell "this line turns here" from "this
+// line ends here and an unrelated line begins right next to it".
+//
+// The fix draws a box-drawing corner glyph ('┌'/'┐'/'└'/'┘', or '+' in ASCII
+// mode) at each of the three routing paths that can change direction:
+//   - the same-row detour beneath an obstructing entity
+//     (`obstructionBottom`/`detourY`)
+//   - a vertical relationship's horizontal jog (`needsJog`/`pickBandY`/`midY`)
+//   - a vertical relationship's multi-row-obstruction bypass
+//     (`multiRowObstruction`/`routingX`)
+// through the same setCGuarded occupancy guard as every other relationship
+// write, so a corner can never overwrite an entity box border or another
+// relationship's label (the same corruption shape #391 fixed).
+//
+// Each assertion below pins an exact substring of the rendered output that
+// was verified (via a before/after diff against the pre-fix renderer) to
+// contain the new corner glyph at the exact cell the path turns, and to be
+// completely absent from the pre-fix render. Reverting the fix in
+// src/ascii/er-diagram.ts makes every one of these assertions fail — the
+// dashes/lines render as before, without the corner character.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER relationship routing draws a corner glyph at each turn (issue #414)', () => {
+  it('draws corner glyphs at a same-row detour around an obstructing entity', () => {
+    // FIRST_ENTITY and THIRD_ENTITY are same-row, non-adjacent (MIDDLE_ENTITY
+    // sits between them), so "relates_to" must detour beneath
+    // MIDDLE_ENTITY's box. FOURTH_ENTITY/FIFTH_ENTITY exist only to keep this
+    // component's row width at 3 (sqrt-based row limit), same trick REPRO_*
+    // in ascii-er-relationship-label-corruption-350.test.ts uses.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        FIRST_ENTITY ||--|{ MIDDLE_ENTITY : contains
+        MIDDLE_ENTITY ||--o{ THIRD_ENTITY : includes
+        FIRST_ENTITY ||--o| THIRD_ENTITY : relates_to
+        FIRST_ENTITY ||--o{ FOURTH_ENTITY : owns
+        MIDDLE_ENTITY ||--o{ FIFTH_ENTITY : tracks`,
+      { colorMode: 'none' },
+    )
+    // The detour's horizontal run opens with '└' (turning up out of the
+    // left vertical drop) and closes with '┘' (turning up into the right
+    // vertical drop) instead of plain '─' at both ends.
+    //
+    // MIDDLE_ENTITY's own vertical "one" marker for its "tracks"
+    // relationship no longer crosses this detour row directly — #390's
+    // flush-marker change (merged after this test was first written) puts
+    // the marker flush against MIDDLE_ENTITY's own border, one row above
+    // the detour line, rather than inset into the detour's own row the
+    // way the old inset positioning did. Checked separately below instead
+    // of assuming they share a row.
+    expect(ascii).toContain('└─────────────── tracks ────────────┘')
+    const lines = ascii.split('\n')
+    const detourLineIndex = lines.findIndex((l) =>
+      l.includes('└─────────────── tracks ────────────┘'),
+    )
+    expect(detourLineIndex).toBeGreaterThan(0)
+    // MIDDLE_ENTITY's "tracks" marker ('┼', flush against its own border)
+    // sits on the row immediately above the detour line.
+    expect(lines[detourLineIndex - 1]).toMatch(/┼/)
+    expect(ascii).toContain('relates_to')
+    expect(ascii).toContain('tracks')
+    expect(ascii).not.toMatch(/[a-z]+[─│┊╌][a-z]+/)
+  })
+
+  it("draws corner glyphs at a vertical relationship's horizontal jog", () => {
+    // USER and SESSION don't share a center column, so "opens" needs a
+    // horizontal jog partway down — the exact repro from
+    // ascii-er-jog-stray-line.test.ts's stray-duplicate-line fix.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        USER ||--o{ LOG_ENTRY : generates
+        USER ||..o{ SESSION : opens`,
+      { colorMode: 'none' },
+    )
+    // The jog's dashed line ('╌', a non-identifying relationship) opens
+    // with a solid '┐' corner glyph at the turn instead of another dash.
+    // USER's own vertical "one" marker for this relationship ('┼', a
+    // crossing tick rather than '│', which would blend into the plain
+    // line, or a bare '─', which would sever it — see getCrowsFootChars'
+    // `vertical` param) sits flush against USER's own border, one row
+    // above the jog — not fused onto the same row as the jog's corner
+    // (#390's flush-marker change, merged after this test was first
+    // written, shifted the marker there).
+    const lines = ascii.split('\n')
+    const jogLineIndex = lines.findIndex((l) => l.includes('└┐ opens'))
+    expect(jogLineIndex).toBeGreaterThan(0)
+    expect(lines[jogLineIndex - 1]).toMatch(/┼/)
+  })
+
+  it('draws the ASCII-mode corner glyph ("+") at the same jog, in useAscii mode', () => {
+    // Same repro and turn as the Unicode jog test above — getCornerChar's
+    // useAscii branch (a plain '+', matching getCrowsFootChars' own
+    // Unicode/ASCII split) has no Unicode-mode equivalent path, so it needs
+    // its own coverage rather than assuming the Unicode assertion implies it.
+    // Both adjacent corners use the same '+' glyph regardless of direction
+    // in ASCII mode, so the two-corner pair reads as '++' rather than
+    // Unicode's direction-distinct '└┐' — see the Unicode test above for
+    // why there are two adjacent corners here at all.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        USER ||--o{ LOG_ENTRY : generates
+        USER ||..o{ SESSION : opens`,
+      { colorMode: 'none', useAscii: true },
+    )
+    // Both '+' characters are the jog's own two adjacent corner glyphs
+    // (ASCII mode uses a plain '+' for every corner direction — see the
+    // Unicode test above, which shows the same shape as '└┐'). USER's own
+    // vertical "one" marker sits on its own row above this line, flush
+    // against USER's border (#390's flush-marker change) — not fused onto
+    // this line the way an earlier version of this comment assumed.
+    expect(ascii).toContain('++ opens')
+  })
+
+  it("draws corner glyphs at a vertical relationship's multi-row-obstruction bypass", () => {
+    // Same 7-entity, 3-row shape as the multi-row-obstruction regression in
+    // ascii-er-relationship-label-corruption-350.test.ts: A-G shares D's
+    // column two rows down, so "ag" must bypass through a free column with
+    // two short jogs (one leaving A's row, one entering G's row).
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        B ||--o{ C : bc
+        C ||--o{ D : cd
+        D ||--o{ E : de
+        E ||--o{ F : ef
+        F ||--o{ G : fg
+        A ||--o{ G : ag
+        A {
+          string id
+          string name
+        }
+        D {
+          string id
+          string title
+        }
+        G {
+          string id
+          string label
+        }`,
+      { colorMode: 'none' },
+    )
+    // Corner glyphs at both jogs of the bypass route. G is also the shared
+    // target of "fg" (from F, same row as G) and "ag" (this bypass) — since
+    // issue #453, each gets its own staggered attachment column instead of
+    // both landing on G's exact center, which shifts these exact strings
+    // from a single shared-center bypass to two side-by-side ones; the
+    // corner glyphs at the bypass's own turns are still there, just at the
+    // updated column.
+    expect(ascii).toContain('┌─│──────────────────┘')
+    expect(ascii).toContain('○╟─────────────────┘')
+    expect(ascii).toContain('ag')
+  })
+
+  it('handles a bypass whose free column search finds a match to the left, not just to the right', () => {
+    // Same shape as the bypass test above, but D's box is widened enough
+    // that the free-column search (which tries lineX+offset before
+    // lineX-offset at every step — see columnClearOfBoxes' caller) exhausts
+    // rightward space and finds its match on the left side instead. This
+    // exercises the *other* branch of the horizDirAtLine/horizDirAtLower
+    // ternaries in the bypass block — every other test in this file only
+    // ever exercises the rightward case, since a plain sqrt-based row
+    // layout with same-sized entities always searches rightward-first
+    // successfully.
+    //
+    // In this specific diagram, the matched free column (routingX) lands
+    // off-canvas (negative — nothing to A's own left in this narrow
+    // layout), and the two corners at valid coordinates (A's own column,
+    // and G's own column) both land exactly on cells the crow's-foot
+    // markers already occupy — the marker legitimately wins there (same
+    // precedence as the rightward case: markers are drawn after corners,
+    // see drawCorner's own doc comment), so there's no *visible* new
+    // glyph to assert on here. What this test actually pins down is that
+    // reaching that branch doesn't corrupt anything or throw — content
+    // integrity, not a specific rendered character.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        B ||--o{ C : bc
+        C ||--o{ D : cd
+        D ||--o{ E : de
+        E ||--o{ F : ef
+        F ||--o{ G : fg
+        A ||--o{ G : ag
+        D {
+          string this_is_a_very_long_attribute_name_to_widen_the_box
+        }
+        G {
+          string id
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('ag')
+    expect(ascii).toContain('string id')
+    expect(ascii).toContain(
+      'string this_is_a_very_long_attribute_name_to_widen_the_box',
+    )
+    expect(ascii).not.toMatch(/[a-z]+[─│┊╌][a-z]+/)
+  })
+
+  it('does not corrupt content when the bypass free-column search matches lineX itself (content-integrity coverage only)', () => {
+    // The obstruction that triggers multiRowObstruction is detected within
+    // the narrow row-gap band (bandTop..bandBottom — see the comment above
+    // that check), but the free-column search below scans the *full*
+    // startY..endY span. When the obstruction is confined to the band and
+    // lineX's own column is otherwise clear across the fuller span, offset
+    // 0 of that search succeeds immediately at lineX itself — so
+    // `routingX === lineX`, skipping the "if (lineX !== routingX)" corner
+    // block entirely (every other bypass test in this file has
+    // routingX !== lineX, since a same-sized-entity layout's obstruction
+    // isn't usually confined that way). Found the same way as the
+    // leftward-bypass case above: varying A's own attribute width while
+    // instrumenting routingX locally, not by construction alone.
+    //
+    // When that block is skipped, nothing observably distinguishes this
+    // render from an equivalent diagram that never triggered
+    // multiRowObstruction at all — skipping the block draws no corner, so
+    // there is no glyph unique to this path to assert on (raised in review
+    // on this PR: the assertions below prove the branch doesn't corrupt
+    // content or throw when reached, not that it visibly changed anything —
+    // hence this test's name and scope are deliberately about integrity,
+    // not a specific rendered character).
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        B ||--o{ C : bc
+        C ||--o{ D : cd
+        D ||--o{ E : de
+        E ||--o{ F : ef
+        F ||--o{ G : fg
+        A ||--o{ G : ag
+        A {
+          string x
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('ag')
+    expect(ascii).toContain('string x')
+    expect(ascii).not.toMatch(/[a-z]+[─│┊╌][a-z]+/)
+  })
+})

package/src/__tests__/ascii-er-jog-stray-line.test.ts

@@ -0,0 +1,111 @@
+// ============================================================================
+// ASCII ER diagram: a vertical relationship's jog must not leave a stray
+// duplicate line at its original column
+//
+// renderErAscii's vertical-connection branch always drew the initial
+// straight vertical line for the *entire* startY..endY span at the upper
+// entity's own center column (lineX), even when a horizontal jog then
+// redirects the path to the lower entity's center column (lowerCX). Below
+// the jog row, that left two parallel vertical segments where only one
+// path exists: the "real" one at lowerCX (leading into the lower entity),
+// and a leftover one still running the rest of the way down at the
+// *original* lineX — connected to nothing, since the path already turned.
+// Spotted as an unexplained doubled "││" / "┊┊" glyph pair in a real
+// catalog sample's rendered output.
+//
+// A bare "││"/"┊┊" substring is not on its own proof of this bug: a
+// same-row (horizontal) connection's flush-against-the-border crow's-foot
+// marker for "one" cardinality is also a lone "│", so a "one"-cardinality
+// relationship starting right at an entity's own right border legitimately
+// prints "│<border>│<marker>" on the *same row* as the rest of that
+// entity's box — see issue #351's marker-inset removal. The actual bug
+// this test guards against instead leaves a *connector-only* row: a row
+// whose sole non-blank content is the doubled glyph pair, with no entity
+// box or text sharing that row, since the leftover stem runs down through
+// empty space between two entity rows.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+/**
+ * True when some row's only non-whitespace content is a doubled line/dash
+ * glyph ("││" or "┊┊") — the signature of a leftover parallel vertical
+ * stem left behind by an unstopped jog. A legitimate box-border-flush-
+ * against-a-marker "││" always shares its row with other box/text
+ * content (the entity's own border and label), so it's excluded by
+ * requiring the rest of the row to be blank.
+ */
+function hasStrayDuplicateColumn(ascii: string): boolean {
+  return ascii.split('\n').some((line) => {
+    for (const pattern of ['││', '┊┊']) {
+      const col = line.indexOf(pattern)
+      if (col === -1) continue
+      const rest = line.slice(0, col) + line.slice(col + pattern.length)
+      if (rest.trim() === '') return true
+    }
+    return false
+  })
+}
+
+describe('ASCII ER vertical relationship jog does not leave a stray duplicate line', () => {
+  it('does not draw a leftover line at the original column once a relationship has jogged over', () => {
+    // Real catalog sample ("ER: Non-Identifying (Dashed) Relationship"):
+    // USER-SESSION needs a horizontal jog (their centers don't align), so
+    // its path runs straight down from USER, jogs sideways, then straight
+    // down into SESSION. Before this fix, the row directly below the jog
+    // showed two dotted-line glyphs side by side ("┊┊") instead of one —
+    // the real jogged path, plus a stray remnant of the pre-jog column
+    // that was never told to stop.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        USER ||--o{ LOG_ENTRY : generates
+        USER ||..o{ SESSION : opens`,
+      { colorMode: 'none' },
+    )
+
+    expect(hasStrayDuplicateColumn(ascii)).toBe(false)
+  })
+
+  it('does not draw a leftover line for either of two independently-jogging relationships', () => {
+    // Real catalog sample ("ER: School Management Schema"): both
+    // STUDENT-COURSE ("enrolled") and TEACHER-ENROLLMENT ("teaches") jog
+    // over to reach their lower entity. Before this fix, the row right
+    // below each jog showed a doubled "│╟"/"││" pair on both sides at
+    // once — confirming the leftover-column bug wasn't specific to one
+    // relationship's geometry.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        STUDENT {
+          int id PK
+          string name
+          date dob
+          string grade
+        }
+        TEACHER {
+          int id PK
+          string name
+          string department
+        }
+        COURSE {
+          int id PK
+          string title
+          int teacher_id FK
+          int credits
+        }
+        ENROLLMENT {
+          int id PK
+          int student_id FK
+          int course_id FK
+          string semester
+          float grade
+        }
+        STUDENT ||--o{ COURSE : enrolled
+        TEACHER ||--o{ ENROLLMENT : teaches
+        COURSE ||--o{ ENROLLMENT : has`,
+      { colorMode: 'none' },
+    )
+
+    expect(hasStrayDuplicateColumn(ascii)).toBe(false)
+  })
+})

package/src/__tests__/ascii-er-label-padding.test.ts

@@ -0,0 +1,118 @@
+// ============================================================================
+// ASCII ER diagram relationship label truncation/padding regression tests
+// (GitHub issue #67)
+//
+// Relationship labels were clamped to a fixed 6-char inter-entity gap,
+// silently truncating anything longer (e.g. "ordered in" → "ordere") and,
+// even when a label did fit, leaving it flush against both entity boxes
+// with zero padding. The cardinality glyph cluster (e.g. "││───○╟") was
+// also crammed directly against the entity box border.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+const REPRO = `erDiagram
+  CUSTOMER ||--o{ ORDER : places
+  PRODUCT ||--o{ LINE_ITEM : "ordered in"`
+
+describe('ASCII ER relationship label truncation and padding (issue #67)', () => {
+  it('renders a long quoted label in full instead of truncating it', () => {
+    const ascii = renderMermaidASCII(REPRO, { colorMode: 'none' })
+
+    expect(ascii).toContain('ordered in')
+    // The old bug truncated to "ordere" — make sure that's gone.
+    expect(ascii).not.toMatch(/ordere(?!d)/)
+  })
+
+  it('renders a long label in full in Unicode mode too', () => {
+    const ascii = renderMermaidASCII(REPRO, {
+      colorMode: 'none',
+      useAscii: false,
+    })
+    expect(ascii).toContain('ordered in')
+  })
+
+  it('renders a long label in full in pure-ASCII mode too', () => {
+    const ascii = renderMermaidASCII(REPRO, {
+      colorMode: 'none',
+      useAscii: true,
+    })
+    expect(ascii).toContain('ordered in')
+  })
+
+  it('keeps at least 1 char of padding between the label and each entity box', () => {
+    const ascii = renderMermaidASCII(REPRO, { colorMode: 'none' })
+    const lines = ascii.split('\n')
+
+    // "places" sits on the row directly below the CUSTOMER/ORDER connector line,
+    // between the two boxes' bottom borders. Find that row and confirm the
+    // label isn't flush against either "└" border character.
+    const placesLine = lines.find((l) => l.includes('places'))
+    expect(placesLine).toBeDefined()
+    const idx = placesLine!.indexOf('places')
+    // Character immediately before/after the label must not be a box border.
+    expect(placesLine![idx - 1]).not.toBe('┘')
+    expect(placesLine![idx - 1]).not.toBe('└')
+    expect(placesLine![idx + 'places'.length]).not.toBe('┌')
+    expect(placesLine![idx + 'places'.length]).not.toBe('└')
+
+    const orderedInLine = lines.find((l) => l.includes('ordered in'))
+    expect(orderedInLine).toBeDefined()
+    const idx2 = orderedInLine!.indexOf('ordered in')
+    expect(orderedInLine![idx2 - 1]).not.toBe('┘')
+    expect(orderedInLine![idx2 - 1]).not.toBe('└')
+    expect(orderedInLine![idx2 + 'ordered in'.length]).not.toBe('┌')
+    expect(orderedInLine![idx2 + 'ordered in'.length]).not.toBe('└')
+  })
+
+  it('keeps at least 1 char of padding between the cardinality glyph cluster and each entity box', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        CUSTOMER ||--o{ ORDER : places`,
+      { colorMode: 'none' },
+    )
+    const lines = ascii.split('\n')
+    // The connector line row contains the crow's foot markers, e.g.
+    // "│ CUSTOMER │─│───○╟─│ ORDER │" — the marker must not sit directly
+    // against the "│" that closes the CUSTOMER box or opens the ORDER box.
+    const connectorLine = lines.find(
+      (l) => l.includes('CUSTOMER') && (l.includes('│') || l.includes('|')),
+    )
+    expect(connectorLine).toBeDefined()
+
+    // Locate the right border of the CUSTOMER box and left border of the ORDER box.
+    const customerEnd = connectorLine!.indexOf('CUSTOMER') + 'CUSTOMER'.length
+    const closingBorderIdx = connectorLine!.indexOf('│', customerEnd)
+    expect(closingBorderIdx).toBeGreaterThan(-1)
+    // The very next character must not itself be a cardinality marker glyph
+    // touching the border — there must be at least 1 separating cell.
+    const afterBorder = connectorLine![closingBorderIdx + 1]
+    expect(afterBorder).not.toBe('○')
+    expect(afterBorder).not.toBe('╟')
+  })
+
+  it('does not widen the gap for short labels that already fit (stays compact)', () => {
+    const compact = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : x`,
+      { colorMode: 'none' },
+    )
+    // Sanity: still renders correctly and compactly (no huge gap for a 1-char label).
+    const lines = compact.split('\n')
+    const line = lines.find((l) => l.includes('A') && l.includes('│'))
+    expect(line).toBeDefined()
+    expect(line!.length).toBeLessThan(30)
+    expect(compact).toContain('x')
+  })
+
+  it('full example diagram from the issue renders every entity and full labels', () => {
+    const ascii = renderMermaidASCII(REPRO, { colorMode: 'none' })
+    expect(ascii).toContain('CUSTOMER')
+    expect(ascii).toContain('ORDER')
+    expect(ascii).toContain('PRODUCT')
+    expect(ascii).toContain('LINE_ITEM')
+    expect(ascii).toContain('places')
+    expect(ascii).toContain('ordered in')
+  })
+})

package/src/__tests__/ascii-er-padding.test.ts

@@ -0,0 +1,114 @@
+// ============================================================================
+// ASCII ER diagram padding tests (issue #343)
+//
+// `-x`/`-y`/`-p` (AsciiRenderOptions.paddingX/paddingY/boxBorderPadding)
+// previously only affected the flowchart/state grid layout — ER diagrams
+// ignored them entirely (hGap/vGap/componentGap were fixed constants, and
+// drawMultiBox was always called with its implicit default padding). This
+// file verifies the fix, and that a render with no explicit padding option
+// still renders byte-for-byte identical to before the fix (see the
+// DEFAULT_PADDING_* comment in src/ascii/types.ts for why that matters).
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+// A single relationship with a short label — exercises the horizontal gap
+// between entities without the label itself becoming the binding constraint
+// (a long label widens the gap independently of hGap — see the
+// `pairLabelWidth` widening in er-diagram.ts — which would make the
+// hGap-driven shift non-linear across padding values).
+const RELATED = `erDiagram
+  CUSTOMER ||--o{ ORDER : x`
+
+// Two disconnected entities — exercises componentGap (vertical stacking).
+const DISCONNECTED = `erDiagram
+  CUSTOMER {
+    string name
+  }
+  ORDER {
+    string id
+  }`
+
+function colOf(ascii: string, lineIndex: number, needle: string): number {
+  const line = ascii.split('\n')[lineIndex]
+  if (line === undefined) throw new Error(`no line ${lineIndex}`)
+  const idx = line.indexOf(needle)
+  if (idx === -1) throw new Error(`"${needle}" not found on line ${lineIndex}`)
+  return idx
+}
+
+function lineCount(ascii: string): number {
+  return ascii.split('\n').filter((l) => l.length > 0).length
+}
+
+function borderWidth(ascii: string, lineIndex: number): number {
+  const line = ascii.split('\n')[lineIndex]
+  const match = line ? /\+-+\+/.exec(line) : null
+  if (!match) throw new Error(`no border run on line ${lineIndex}: ${line}`)
+  return match[0].length
+}
+
+describe('ASCII ER diagrams — padding (issue #343)', () => {
+  it('renders identically with no padding options and with explicit defaults', () => {
+    const withoutOptions = renderMermaidASCII(RELATED, { useAscii: true })
+    const withDefaults = renderMermaidASCII(RELATED, {
+      useAscii: true,
+      paddingX: 5,
+      paddingY: 5,
+      boxBorderPadding: 1,
+    })
+    expect(withDefaults).toBe(withoutOptions)
+  })
+
+  it('paddingX widens the gap between related entities', () => {
+    const base = renderMermaidASCII(RELATED, { useAscii: true })
+    const wide = renderMermaidASCII(RELATED, { useAscii: true, paddingX: 25 })
+    const baseCol = colOf(base, 1, '| ORDER |')
+    const wideCol = colOf(wide, 1, '| ORDER |')
+    expect(wideCol).toBeGreaterThan(baseCol)
+    const mid = renderMermaidASCII(RELATED, { useAscii: true, paddingX: 15 })
+    const midCol = colOf(mid, 1, '| ORDER |')
+    expect(midCol - baseCol).toBe(wideCol - midCol)
+  })
+
+  it('a very small paddingX does not shrink the gap below the safe minimum', () => {
+    // Unlike sequence/class diagrams, ER's horizontal gap has a floor equal
+    // to its own default (6) rather than a smaller generic minimum — a
+    // smaller gap lets the crow's-foot markers on each end overlap (see the
+    // hGap comment in er-diagram.ts and ascii-padding-edge-cases.test.ts for
+    // the regression test), so a very negative paddingX clamps to the same
+    // gap as the default rather than tightening further.
+    const base = renderMermaidASCII(RELATED, { useAscii: true })
+    const tight = renderMermaidASCII(RELATED, {
+      useAscii: true,
+      paddingX: -10,
+    })
+    expect(tight).toBe(base)
+  })
+
+  it('paddingY widens the gap between disconnected components', () => {
+    const base = renderMermaidASCII(DISCONNECTED, { useAscii: true })
+    const tall = renderMermaidASCII(DISCONNECTED, {
+      useAscii: true,
+      paddingY: 25,
+    })
+    expect(lineCount(tall)).toBeGreaterThan(lineCount(base))
+    const mid = renderMermaidASCII(DISCONNECTED, {
+      useAscii: true,
+      paddingY: 15,
+    })
+    expect(lineCount(mid) - lineCount(base)).toBe(
+      lineCount(tall) - lineCount(mid),
+    )
+  })
+
+  it('boxBorderPadding widens entity boxes by exactly 2 columns per unit', () => {
+    const base = renderMermaidASCII(RELATED, { useAscii: true })
+    const padded = renderMermaidASCII(RELATED, {
+      useAscii: true,
+      boxBorderPadding: 4,
+    })
+    expect(borderWidth(padded, 0) - borderWidth(base, 0)).toBe(6)
+  })
+})