Skip to content

🧩 Build a reusable LaTeX style and component library for publication profiles #381

Description

@szmyty

Description

Create a reusable, modular LaTeX style/component layer for Renderflow's document and publication profiles.

An early Renderflow design goal was to avoid repeating large monolithic LaTeX templates by extracting stable presentation primitives into reusable .sty packages and small components. The current implementation should adapt that idea to Renderflow's modern profile/artifact architecture rather than introducing a parallel legacy template system.

The result should let research papers, editorial articles, reports, magazines, and future publication profiles share typography, layout, callout, figure, table, and code-presentation primitives while retaining profile-specific composition.

Goals

  • reduce duplication across LaTeX/PDF publication profiles
  • provide composable presentation primitives rather than monolithic templates
  • centralize design tokens and typography rules where practical
  • support local-first font assets and deterministic rendering
  • keep content semantics separate from presentation implementation
  • make future Copilot-generated profiles easier to build correctly

Architecture

Prefer a layered structure conceptually similar to:

publication profile
  ↓
Pandoc-compatible LaTeX template
  ↓
Renderflow LaTeX component/style library
  ↓
Tectonic / LaTeX toolchain

Inspect the current repository first and choose paths/modules that fit its established architecture.

Do not force this exact directory structure when the repository has a better current convention, but evaluate components corresponding to areas such as:

latex/
  renderflow-core.sty
  typography.sty
  layout.sty
  color.sty
  figures.sty
  tables.sty
  code.sty
  callouts.sty
  metadata.sty

Keep packages cohesive; avoid one giant style file and avoid fragmentation into trivial one-line packages.

Reusable Primitives

Evaluate reusable support for:

  • page geometry and margins
  • semantic typography roles
  • heading hierarchy
  • paragraph rhythm and spacing
  • color/design tokens
  • figures and captions
  • tables
  • code blocks/listings
  • quotations
  • callouts/asides
  • footnotes/endnotes
  • links
  • title/author/metadata blocks
  • headers/footers/page numbers
  • table of contents
  • bibliography/citation presentation where supported by the profile
  • accessible/print-safe fallbacks where practical

Profile-specific content structure must remain in the profile/template rather than leaking into the shared style library.

Design Tokens

Where practical, expose reusable configuration values instead of scattering literal values throughout templates.

Examples include:

  • typography roles
  • spacing scale
  • page geometry
  • color roles
  • rule weights
  • border/callout styles

Use the repository's existing design/profile configuration model when one already exists rather than creating an unrelated token system.

Font Integration

Integrate with Renderflow's local-first font asset management work.

The style layer should:

  • refer to semantic font roles where practical
  • avoid assuming a developer machine has a particular font installed
  • support deterministic fallback behavior
  • preserve font embedding/provenance expectations for generated PDFs

Do not add unlicensed font binaries.

Pandoc Compatibility

Ensure the component library can be consumed cleanly by Pandoc-driven LaTeX generation.

Avoid assumptions that bypass Renderflow's current strategy/adapter/profile boundaries.

Support profile-specific overrides without requiring users to fork the entire shared style layer.

Testing / Fixtures

Add redistribution-safe synthetic fixtures that exercise the shared components.

At minimum validate representative rendering of:

  • title/metadata
  • headings and prose
  • quotation/callout
  • table
  • figure/caption
  • code block
  • footnote/link

Use the repository's current artifact validation and golden/conformance approaches where available.

Tests should detect obvious regressions such as:

  • LaTeX compilation failure
  • missing package/component
  • unresolved font dependency
  • broken page geometry
  • invalid template/component integration

Documentation

Document:

  • component/style architecture
  • which concerns belong in shared .sty files versus a publication profile
  • how a new profile consumes the library
  • supported override/customization points
  • font and asset expectations
  • how to add a new reusable component
  • compatibility constraints with Pandoc/Tectonic

Include a small example showing how a profile composes the shared style system without duplicating its implementation.

Non-Goals

  • Do not create a new document-content DSL.
  • Do not move article/research structure into .sty files.
  • Do not copy third-party commercial templates.
  • Do not make LaTeX the canonical representation for all Renderflow artifacts.
  • Do not require every output format to emulate LaTeX-specific presentation exactly.

Acceptance Criteria

  • Current LaTeX/PDF profile architecture is inspected before implementation
  • Shared LaTeX presentation concerns are extracted into cohesive reusable components/packages
  • Profile-specific semantics remain outside the shared style layer
  • Design/configuration values are centralized where practical
  • The library integrates with local-first font assets and deterministic fallbacks
  • Pandoc/Tectonic workflows can consume the library without bespoke manual setup
  • Research and/or editorial profile fixtures demonstrate reuse
  • Synthetic fixtures cover representative typography, figures, tables, code, callouts, and metadata
  • Documentation explains composition and extension boundaries
  • Formatting, tests, artifact validation, and CI pass

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions