nberlette / migo Goto Github PK

I've been meaning to tackle this for a while. Truth be told, it really should have been a primary feature from day one.

I'll be frank with you, I really dislike how long the image URL's become after just a few customizations. It's also a pain in the ass to try to remember exactly which dimensions / colors / font combinations I used, when trying to produce more images in the same style.

As a solution for this, I propose a "presets" or "themes" system: at a minimum it would be a hard-coded collection of some sensible default color-schemes and design presets (lazy option. yuck), but ideally I envision it as something integrated with a user-authentication system. The latter option would allow users to create/save style presets in their own personal accounts, then easily reference them with a unique URL identifier.

I picture it as a really basic feature at its core - instead of manually applying a bunch of params like ?titleFontSize=64&titleColor=000&subtitleFontSize=32&..., you could simply use ?p=f7f34fc5b71a4ffe4fbe&title=Title+Text&subtitle=Subtitle+Text. This would also enable things like user analytics, such as measuring traffic across different image presets to see which designs are most effective.

I'm starting to ramble now, but this seems like something that could possibly result in the need for monetization. If the service grows in size and userbase and we're providing traffic analytics and other extensive features, it's going to be burning a hole in my pocket if it isn't generating some form of revenue on its own. I really like the idea of keeping it 100% free though.

Please feel free to chime in with your thoughts, I'd really like to hear a voice other than my own in the echo chamber here 😅

Describe the Bug

The custom iconUrl parameter appears to be broken. In actuality, it functions fine when rendering an .svg, but displays nothing when requesting the same image as a .png. This is a major problem is PNG is by far the most popular file type.

There's a high likelihood of this being a problem with resvg_wasm rendering foreign objects / external image URLs. Maybe we can bypass this by encoding the image as a base64 datauri?

PR's welcome.

Expected Behavior

Instead of using the standard icon parameter, which is limited to the Iconify syntax of {collection-name}:{icon-identifier}, users are supposed to be able to provide a fully-resolved URL with the iconUrl parameter, overriding the former to display their custom icon instead.

Reproduction

These are the same exact image URL's, except for the extensions - .svg and .png. Notice the .svg renders fine, with the Apple Emoji T-Rex icon displaying as intended.

SVG: https://migo.deno.dev/image.svg?title=deno911%E2%81%84+kit&subtitle=deno+module+starter+template&titleFontFamily=serif&titleFontSize=72&titleFontWeight=900&titleTextAnchor=left&titleX=160&titleY=110&subtitleFontSize=36&subtitleFontWeight=900&subtitleFontFamily=monospace&subtitleTextAnchor=left&subtitleX=40&subtitleY=250&pxRatio=1.5&width=1000&height=300&bgColor=111827&titleColor=fff&subtitleColor=ddd&iconW=100&iconH=100&iconX=40&iconY=30&borderRadius=10&iconUrl=https://emoji.aranja.com/static/emoji-data/img-apple-160/1f996.png

The png, however.... no dice.

PNG: https://migo.deno.dev/image.png?title=deno911%E2%81%84+kit&subtitle=deno+module+starter+template&titleFontFamily=serif&titleFontSize=72&titleFontWeight=900&titleTextAnchor=left&titleX=160&titleY=110&subtitleFontSize=36&subtitleFontWeight=900&subtitleFontFamily=monospace&subtitleTextAnchor=left&subtitleX=40&subtitleY=250&pxRatio=1.5&width=1000&height=300&bgColor=111827&titleColor=fff&subtitleColor=ddd&iconW=100&iconH=100&iconX=40&iconY=30&borderRadius=10&iconUrl=https://emoji.aranja.com/static/emoji-data/img-apple-160/1f996.png

Screenshots

SVG

PNG

Currently there is no word-wrap functionality baked into the SVG rendering step, which is just shameful ☹️. This issue is mostly a place for me to store some thoughts, notes, and log my results throughout the process of implementing a "smart" wrapper function for migo.

Can we get away with using SVGTextElement.getComputedTextLength()? Does it produce accurate and dependable results...? On that note, what about SVGTextElement.getBoundingClientRect? Or SVGTextElement.getBBox? It sure would save me a lot of time to just be able to use a built-in interface for 90% of the logic in this scenario.

If not, heres a basic outline of the steps involved:

1. calculate glyph width from font size + weight

• (like @nicktaras/getFontCharWidth, or digging into the SVG font interfaces)

2. estimate required width for a given string in the desired font/size/weight

• (e.g. textLength * (glyphWidthFromStep1 + letterSpacing))

3. subtract a small percentage of the window width to determine a "safe-zone"; ensuring
   any breakable-words will be wrapped before it reaches the edge of the canvas or screen.

• e.g. width - (width * 0.05) ~> 950px / 1000px total (25px margin)

4. diff the required text width with the image safe-zone width.

let d = Math.ceil(requiredWidthFromStep2 - safeWidthFromStep3);
if (d > 0) {
  wrapLine();
  // if a line is reeeeeally long and requires 2+ screen breaks to fit
  // this re-wrap the text until all lines fit within the canvas.
  repeatStartingFromStep2ForEveryLine();
}

5. if all lines don't fit within the canvas size, attempt to scale the font size
   down until they do. Truncating the text should only be used as THE last resort.