Skip to content

SVG export references local resource_images paths instead of embedding/copying icons #207

Description

@marcusx

Summary

When generating an SVG with terravision draw --format svg, the generated SVG contains <image xlink:href="..."> references to local files inside the TerraVision installation
directory.

Those icon paths are not portable and break when the SVG is opened on another machine, served from a static documentation site, or generated inside Docker.

The HTML output works correctly: the generated HTML contains embedded data:image/png;base64,... image references and the AWS icons render as expected.

Environment

  • TerraVision: 0.43.1
  • OS: macOS / Darwin amd64
  • Install method: local Python/pipx install
  • Also reproduced with Docker image: patrickchugh/terravision:latest
  • Terraform: v1.15.5
  • AWS provider: registry.terraform.io/hashicorp/aws v6.54.0
  • Graphviz:
    • dot - graphviz version 15.1.0 (20260618.0150)
    • gvpr version 15.1.0 (20260618.0150)

Command

Run from a Terraform root module:

  terravision draw --format svg --outfile arch-svg --use-resource-names

  The command completes successfully:

  Preflight check..
    dot command detected: /usr/local/bin/dot
    gvpr command detected: /usr/local/bin/gvpr
    git command detected: /usr/local/bin/git
    terraform command detected: /usr/local/bin/terraform
    terraform version detected: Terraform v1.15.5

  Detected cloud provider: AWS (10 resources)

  Rendering Architecture Image...
    Output file: .../production/services/komodo-domains/arch-svg-aws.dot.svg
    Completed!

Actual behavior

The generated SVG references icon files using absolute local paths:

  <image xlink:href="/Users/marcus/Library/Application Support/pipx/venvs/terravision/lib/python3.14/site-packages/resource_images/aws/general/aws.png" .../>
  <image xlink:href="/Users/marcus/Library/Application Support/pipx/venvs/terravision/lib/python3.14/site-packages/resource_images/aws/security/certificate-manager.png" .../>
  <image xlink:href="/Users/marcus/Library/Application Support/pipx/venvs/terravision/lib/python3.14/site-packages/resource_images/aws/network/route-53.png" .../>

When generated inside Docker, the SVG contains container-internal paths instead:

<image xlink:href="/usr/lib/python3.12/site-packages/resource_images/aws/management/cloudwatch.png" .../>

When this SVG is opened outside the container or embedded into a static docs site, the browser tries to load icons from paths such as:

file:///usr/lib/python3.12/site-packages/resource_images/aws/management/cloudwatch.png

The result is a diagram where the layout renders, but the AWS icons are broken or missing.

Expected behavior

terravision draw --format svg should generate a portable SVG.

Possible approaches:

  1. Embed icon images as data:image/png;base64,..., like the HTML output already appears to do.
  2. Copy the icon assets next to the SVG and reference them with relative paths.
  3. Add an explicit option such as --embed-assets or --asset-mode embed|copy|absolute.

Comparison with HTML output

The HTML output renders icons correctly. In the generated HTML, the inline SVG uses embedded image data:

<image xlink:href="data:image/png;base64,..." .../>

So the issue seems specific to the standalone SVG export path.

Why this matters

We want to publish TerraVision diagrams in an Antora static documentation site.

SVG would be the preferred format because it scales well and is easier to inspect in documentation. At the moment we have to use PNG as a workaround because the SVG output is not
portable.

Reproduction check

After generating the SVG:

grep -n "resource_images" arch-svg-aws.dot.svg

Actual result: the SVG contains absolute resource_images paths.

Expected result: the SVG should either contain embedded image data or portable relative asset references.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions