Skip to content

Vision

Jump to bottom
Noah Baldwin edited this page Nov 28, 2025 · 2 revisions

OXVG aims to be the primary toolchain for SVGs. That is, for OXVG provide all the tools necessary for developers to build SVGs or design tools.

Vision

We want to graduate from the tagline "Rust alternative to SVGO and InkScape", which introduces the tool as an analogue to these titans, to a unique and standalone offering "The SVG toolchain".

SVG tooling as it is today is either available as proprietary software for designers or as disparate, often ageing, packages for developers. We'd like to provide a unified, high-quality toolchain for developers (where-ever they be) to build competitive software for designers.

Features

The features OXVG provides should extends the common use-cases of SVG tooling, all under one roof.

  • Optimisation: To be used to deliver smaller and more performance SVG files
  • Linting: To be used to gain confidence in the SVG files being used
  • Actions: To be used to manipulate SVG files

There are some features that OXVG will not provide, by merit of them being too complicated or irreplaceable.

  • Rendering. Consider using the industry standard Skia instead.
  • Non-SVG. SVG is an open standard, while other formats such as .ai are not.

Goals

  • Express the spec: Should abstract, but not hide, the underlying SVG spec.
  • Competitive: Should work with SVGs effectively at lower cost.
    • Fast, Correct, Effective, and Cheap: See the benchmarks
  • Everywhere: Should work where you need it, regardless of operating-system, interface, programming-language, or web/native

Open

  • MIT Licensed: Can be freely used, distributed, and modified as outlined by the MIT license
  • Community: Users of OXVG should feel encouraged to get in touch with and even work with maintainers
  • Monorepo: Whether you're looking for the source of a binary, library, etc, it should be discoverable under one codebase
  • Maintainable: Code and documentation should be structured as best as possible, without getting in the way of delivery

Dogfooding

As well as providing the primary features expressed in the vision, we also hope to dogfood the project to understand which areas the project needs to focus. I'd like to deliver a low-level modal design editor created using OXVG.

  • Modal: In the same vein as modal text-editors, to allow editing SVG files without being tied to a mouse
    • Editing, Visual, Command, Macro, etc modes
  • Discoverable: Should contextually display available elements and attributes based on the SVG spec.
  • Analog: Should be an analog rather than an abstraction over OXVG
    • History is represented as a set of actions upon the original SVG
    • UI interactions commit an action to history
    • Commands and macros can be created as actions
    • Node tree should be displayed that matches the SVG representation
    • Editor info such as history and state should be saveable directly into the SVG
  • Visual: A preview of the SVG should be displayed

TUI

Alongside the oxvg binary may be a modal editor for SVGs. This will display a UI simplified version of the PWA. This editor will be aimed more towards developers and will be MIT licensed.

PWA

I'd like to produce a source-available SVG editor that can be visited via a web browser and installable as a PWA. This editor will be aimed more towards designers and will be licensed but source available.

  • Local-first: Should be static and backend-less
  • Unenforced License: The PWA will likely have some sort of license to help support the overall project, but can easily be bypassed for those that cannot afford to.
  • Hackable: Should deliver the PWA unminified, so user's who've installed it can read and modify it as needed.

Clone this wiki locally