ivanceras/svgbob

This system is a Rust-based toolset for converting ASCII art diagrams into SVG graphics. It provides a core rendering library that parses text into geometric shapes, alongside a command-line interface for batch processing and a REST API server for programmatic access. The project is structured as a Cargo workspace to manage these distinct components and automate their publication.

A new shell script has been added to automate the publishing process for the project's Rust crates. When executed, the script sequentially publishes the \svgbob\ and \svgbob\_cli\ crates to the registry, streamlining the release workflow for maintainers.

.scripts · high confidence

This change introduces the core \svgbob\ crate, providing a library that converts ASCII art diagrams into SVG graphics. It includes the complete rendering pipeline: a cell-based grid system for parsing text, a fragment buffer for geometric shapes (lines, arcs, circles, rects), and an endorsement logic that groups adjacent fragments into higher-level shapes like rounded rectangles. The release also ships with multiple example programs (e.g., \circles\, \demo\, \simple\) and comprehensive specification documentation detailing the supported ASCII characters and their rendering behavior.

crates/svgbob · high confidence

This change introduces the \svgbob\_cli\ and \svgbob\_server\ crates, providing the first executable entry points for the project. The CLI tool allows users to convert ASCII art to SVG via command-line arguments or stdin/stdout, supporting options for styling and batch processing. The server crate exposes a REST API on port 3000 (configurable via the PORT environment variable) that accepts POST requests with ASCII text and returns the corresponding SVG output.

_crates/svgbob\_cli, crates/svgbob\server · high confidence

The \src/lib.rs\ file, which contained the original implementation for generating SVG graphics (including settings, element definitions, and rendering logic), has been deleted. This indicates a significant architectural shift where the core SVG generation functionality has been removed or replaced by a different implementation in the codebase.

src · high confidence

The main binary entry point at src/bin/main.rs has been removed. This file previously contained a hardcoded, extensive ASCII-art diagram used for testing the SVG output of the svgbob library, along with basic argument parsing logic. Its removal indicates that the project is moving away from this specific hardcoded test/demo binary, likely consolidating binary logic or replacing it with other entry points or test suites.

src/bin · high confidence

The svgbob library has been upgraded to use the Sauron 0.61.0 web framework, replacing the previous local or older versions. This update is accompanied by bumps to key dependencies including nalgebra (to 0.32.1), parry2d (to 0.13.5), and itertools (to 0.11.0), while also replacing the lazy\_static crate with once\_cell for better performance. The project structure has been reorganized into a Cargo workspace containing the core library, CLI, and server components, all now targeting version 0.7.6.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 61 → 60 (-0.8)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 95 → 95 (+0.6)
• Architecture 100 → 97 (-3.3)
• Maturity 34 → 34 (+0.0)
• Readiness 74 → 70 (-4.6)
• Security 87 → 91 (+3.2)
• Performance 100 (new)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• TooManyMethods: CellGrid (crates/svgbob/src/buffer/cell_buffer/cell/cell_grid.rs)

• Ambiguous distinction between opt_ord and ord. Without documentation, it is unclear why two functions exist for comparing floats. opt_ord likely returns Option<Ordering> to handle NaN, while ord might panic or return a default, but the signatures provided both return Ordering (or the opt prefix is misleading if it doesn't return Option). If opt_ord returns Option<Ordering>, the naming is inconsistent with standard Rust conventions where opt usually implies an Option return type, but here it's not clear if the return type in the prompt is accurate or if the naming is just redundant.
• Confusing naming and type signature. The method add_fragments_to_cell takes a single Fragment (singular) in its signature but has a plural name. The other method add_fragment_to_cell also takes a single Fragment. This suggests either a typo in the signature (should be Vec<Fragment> or similar) or a typo in the name (should be singular).
• Documentation: contradicts the code (Architecture.md)
• Inconsistent return types and parameter grouping for size handling. get_node returns a tuple including dimensions, while get_node_override_size returns only the Node and takes dimensions as explicit arguments. This forces callers to handle size extraction differently depending on which method they use.
• Low cohesion: FragmentBuffer (LCOM4 4) (crates/svgbob/src/buffer/fragment_buffer.rs)
• Off the main sequence: svgbob
• Outdated: indexmap
• Outdated: log
• Outdated: once_cell
• Outdated: tokio
• Redundant naming and unclear distinction between 'to_svg' and 'to_svg_string_*'. The base method 'to_svg' likely returns a default string, while the suffixed variants imply specific formatting (pretty/compressed). However, 'to_svg' is ambiguous compared to the explicit 'to_svg_string' variants. Additionally, 'to_svg' and 'to_svg_with_settings' are inconsistent in naming convention (verb vs verb_with_...).

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ivanceras/svgbob was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.