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
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
.stypackages 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
Architecture
Prefer a layered structure conceptually similar to:
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:
Keep packages cohesive; avoid one giant style file and avoid fragmentation into trivial one-line packages.
Reusable Primitives
Evaluate reusable support for:
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:
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:
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:
Use the repository's current artifact validation and golden/conformance approaches where available.
Tests should detect obvious regressions such as:
Documentation
Document:
.styfiles versus a publication profileInclude a small example showing how a profile composes the shared style system without duplicating its implementation.
Non-Goals
.styfiles.Acceptance Criteria