SVG Images from Postgres | Hacker News Reader

SVG Images from Postgres

crunchydata.com

105 pointszdw28 comments

SVG is such an under-appreciated graphics format. I will expand his great quote about graphics:

> a two-dimensional representation to utilize the integrative capabilities of the human visual cortex

into:

SVG is a re-usable two-dimensional representation of data to utilize the integrative capabilities of the human visual cortex.

In a sense canvas, png/jpg etc are to SVG what PDF is to HTML. An information black hole.

As an example of the information-retaining quality of SVG representations you could fairly easily imagine the reverse operation: SVG Images TO Postgres.

> SVG is such an under-appreciated graphics format.

SVG is an over-romanticised format.

Support for logic makes it a major XSS vector, XML makes it inefficient, and the path langage makes it unreadable.

And yet compared to the alternatives its advantages outweigh these flaws.

> the path langage makes it unreadable.

at least this part seems over-the top criticism :-)

Anything that can capture free-form graphical information will be unreadable. You could represent paths with points but that would make it more inefficient.

The thing to keep in mind too is that because it fell out of favor the standard has not really evolved.

> at least this part seems over-the top criticism :-)

Individually the XML and the path format are “fine”, the problem is that they’re both in the same file format.

> Anything that can capture free-form graphical information will be unreadable.

It’s not the question of being freeform, it’s the weird-ass single-letter command names in an attribute string.

In an XML document which is otherwise self-descripting.

> It’s not the question of being freeform, it’s the weird-ass single-letter command names in an attribute string.

> In an XML document which is otherwise self-descripting.

This is an odd plaint. M/m is for move, L/l is for line-to, C/c is for curve-to, V/v and H/h are for vertical and horizontal lines respectively, and svgo might throw some 's' curves in there. It's the best of both worlds, giving excellent compression while remaining human readable enough for a novice to manipulate geometry by just messing about.

So what do you want? If it's readable, you call it inefficient, and if it's efficient, you call it unreadable. Make up your mind.

I don’t need to “make up my mind”, because the entire point is that SVG has all disadvantages thus having none of the advantages.

It could be readable or efficient, and either would be fine, but it’s neither.

I love svg solely because it's an open vector format, not because it allows javascript, is xml, etc. Any plaintext vector format would be equally nice.

Any language where you don’t know the syntax looks weird at first. There are 6 types of commands with 20 commands in total. Half of those use document based coordinate system and the other half are relative to the previous command.

The path language is somewhat a standard (lol) but is very similar to HPGL, glyph definitions in fonts, GCode, or even Logo and reading it is not a requirement.

I wholehearedly agree with your point on information blackholes but I think the reason some people hate SVG is that they've had had to advanced things with or had to work with the spec and implement something around it. I haven't done so myself but I can tell pain when I read it.

Here is a mostly compatible alternative: https://tinyvg.tech/

I should add though that with this alternative you lose the readability of SVG because it's binary encoded

> In a sense canvas, png/jpg etc are to SVG what PDF is to HTML. An information black hole.

Tiny disagreement: PDF isn't necessarily an information black hole compared to HTML. PDF is a structured format, not quite plaintext, yet not quite binary either. It can preserve original text and formatting metadata. It's the publishing tools that often (these days less so than in the past) pre-rasterize data, storing bitmaps instead of original text inside the PDF.

The nice thing PDF has going over HTML is fixing the layout. This is not desirable for most content of actual value (i.e. not glorified marketing brochures that half of the web is these days), but sometimes it is useful.

These days, SVG could probably be used as plaintext PDF replacement (maybe with some extensions for pagination, and other print-related metadata), though I bet some people would still opt to "render" SVGs using embedded data-url/base64 images instead of text + metadata...

> not quite plaintext, yet not quite binary either

this applies to SVG at low level as well (path data break with the semantically annotated pattern of higher level constructs). It is in some sense unavoidable / desirable to be able to include such numerical data intensive blobs.

Where PDF (and its broader ecosystem) blundered is that it feels it would be rather low cost to maintain logic and metadata that would make re-usability of document information much easier.

Of-course we talk with hindsight etc.

For things of sufficient complexity (e.g. maths), fixing the layout beforehand gives benefits to readers and writers of such documents. Also, receiving PDFs (over HTML) is much better for any processes which involve printing/sharing outside the confines of the web.

Can SVGs embed fonts? PDFs that don't embed fonts tend to have issues with rendering.

I deeply love SVG, I just wish they implemented some ability to do line wrapping with text. Today you have to use <foreignObject> and wrap a HTML element which doesn't play nice with a lot of SVG renderers. :(

> PDF is to HTML

PDF is also an under-appreciated graphics format. It can be a mere container for more primitive data, but a PDF can do a lot more, way more than HTML (I mean, Postscript is Turing complete on its own)

> As an example of the information-retaining quality of SVG representations you could fairly easily imagine the reverse operation: SVG Images TO Postgres.

I actually did this several years ago!

I ended up collecting the floorplan/layout for most of Australia's largest shopping centres by scraping the SVGs from the interactive maps on their websites. I parsed the coordinates they contained — the location/size of individual shops, ingress/egress points, ATMs, etc — as Well-Known Text and stored them as native geometry data types in PostgreSQL.

The shopping centres were even kind enough to leave labels and metadata embedded as attributes in the SVG. Bless.

Trying not to be negative with any cool project, this feels like the wrong layer in which to build SVG functionality.

I mean, if the path can already be generated, an intermediary executable can easily pipe that in and turn into an SVG file. That can be implemented in python, node, rust, whatever and can be given any number of styling options.

Some people might regard having one fewer moving part to be a benefit of just doing it in the database.

Sure, sure.

But the real question is, can this be utilized for unexpected use cases?

This really could use example visuals.

The path data is the most complex part of generating shapes in SVG, which is handled by postgis so I don't see a real benefit to installing an extension here.

I wonder how practical it would be to serve slippy map tiles as SVGs, dynamically generated out of a PostGIS database kind of like this

Possible yes, but probably not practical compared to serving unstyled MVT tiles out of PostGIS (ST_AsMVT) and styling them client-side with MapLibre GL JS.

SVG with normal CSS is not enough for styling a map in general. For comparison, here's MapLibre style properties for MVT layers: https://maplibre.org/maplibre-style-spec/layers/

Perhaps it's also solvable without the MVT tooling, but something to watch out for is what happens at tile edges: a polygon is split into two so you need to render tiles that are a bit larger than what's visible (to hide the extra seam at tile boundary); further, a map label may extend over tile boundary so you need a way to allow for that while avoiding collisions between labels from neighbouring tiles.

EDIT: and these are on top of performance issues. Maps are full of detailed geometry where GL leaves SVG far behind.

Geometries in MVT are just points, lines and polygons. These may be associated with zero or more key-values. The default 'viewport' (in SVG terms) is 4096x4096px, with geometries extending beyond this to allow for overlapping text labels, etc.

SVG could represent anything MVT can -- but files would be much larger, as MVT is optimized to store the data efficiently.

PostGIS is really really cool. I got a small look at it setting it up as a QGis backend and doing more with it is on my list. It feels a bit under-appreciated.

Postgres extensions also seem like a bit of a secret weapon.

Reply on news.ycombinator.com