captn3m0
commented
4 years ago Bit more explanation on the idea and why I think it can be helpful.
I had multiple approaches to this in mind, depending on what usecases you consider. The "big advantage" of allowing SVGs is that SVGs are vectorized, and support text directly. This means, a lot of banner images that are repetitive/textual can be generated much more easily if they were in SVG. Pseudo PHP code for eg:
include "svg.php";
// Generate a Yellow tiled triangles SVG banner
generate_svg_banner("yellow", "tiled_triangles", $_GET['title']";With such a script, you can use /svg.php?title=Hello+World and it generates a SVG image. Makes it easy and accessible, but nobody does this because <meta og-image src="svg.php?title=Hello+World> doesn't work.
This becomes more powerful with static site generators, where generating a SVG file is fairly similar to generating a XML text file (which SSGs are great at). At https://endoflife.date/, I want to create a banner image for every tool that has enough information to become a great meta image:
Generating this in SVG for all tools would be so much easier.
Another similar note for wordpress-plugins.
tl;dr: Generating an SVG is easier, faster, better for modern content-generation pipelines.
Now on to your questions:
Q1
Since OG:parsers run before any JS, you want something that runs server side and is super easy to implement. I had a URL lookup based implementation in mind. Something like:
<meta property="og:image" content="https://captnemo.in/img/title-banner.svg />
Gets changed to (yes, domain is available)
<meta property="og:image" content="https://image.sv/g/https://captnemo.in/img/title-banner.svg />
The endpoint fetches the SVG, generates PNG/JPG/WEBP and serves whatever formats the client supports.
Q2
Should this happen for any link with SVG automatically with a worker setup? Where would these converted pictures be stored?
Yes, I think such a usecase makes sense for "edge-compute". Most edge-worker-implementations will offer some storage API, but you'll likely end up using something like an S3 backend to do this at scale. A monetization strategy of charging once a domain crosses X requests, or Y images makes sense
Q3
Is this specific to a particular social media site like Twitter requiring dev access?
I don't think so. While the primary cool usecase is easy-to-generate-templated-open-graph-images, I can think of other cool usecases as well. (Generated book-covers, Generated album covers, Memes generated as SVG, but rendered as webP)
I can't think of a reason why twitter-dev-access might be required for this.
Q4
Where is the flow from? if from a particular_user_tweet with og:image = SVG -> Worker -> PNG replacement -> twitter parser?
No, this is more of a publishing workflow. See 1 above.
Hope this helps.
elbotho
Hi Nemo / Anyone,
First off, this is a great repository of ideas. I decided to pick up -> this one.
1) Just to be clear that I understood this correctly, since opengraph protocol doesn't support SVG, I am supposed to fetch the og:image (if not Twitter:card / Facebook equivalent) value and replace it with the converted PNG link before inputting to social media opengraph parser?
2) Should this happen for any link with SVG automatically with a worker setup? Where would these converted pictures be stored?
3) Is this specific to a particular social media site like Twitter requiring dev access?
4) Where is the flow from? if from a particular_user_tweet with og:image = SVG -> Worker -> PNG replacement -> twitter parser? how do I connect this preparsing...is there a separate api for it?
{ not an issue. Creating this for discussion on an idea as per documentation below }