Comment by phoe-krk | Hacker News Reader

Comment by phoe-krk | Hacker News Reader

Here it is, in its full glory!

    <?xml version="1.0" encoding="utf-8"?>
    <svg viewBox="0 0 100 100" width="100" height="100" xmlns="http://www.w3.org/2000/svg">
      <rect x="0" y="0" width="100" height="100" fill="rgb(255, 102, 0)"></rect>
      <path d="M 50 77 L 50 50 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt">
      </path>
      <path d="M 94.93056731583404 35.622745513916016 L 71.2454833984375 71.2454833984375 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt" transform="matrix(1 0 0 1 -21.2455 -21.2455)">
      </path>
      <path d="M -78.93056731583404 36.17028045654297 L -55.67118835449219 71.79300689697266 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt" transform="matrix(1 0 0 1 105.396 -21.7213)">
      </path>
      <rect transform="" width="100" height="23.742591024555463" stroke-width="1" stroke="none" fill="#FF6600" stroke-opacity="1" fill-opacity="1" stroke-linecap="butt" stroke-linejoin="miter" >
      </rect>
    </svg>

Interesting, I never realized the Y wasn't symmetrical. The left branch is slightly lower and to the left of the right branch in the Y. This also creates a gap in the center of it at high resolutions: https://i.imgur.com/vwPnz2j.png

If this wasn't intentional, here's a symmetrical version:

    <svg width="100" height="100" viewBox="0 0 100 100" fill="none" xmlns="http://www.w3.org/2000/svg">
        <rect width="100" height="100" fill="#FF6600"/>
        <path fill-rule="evenodd" clip-rule="evenodd" d="M62.1762 23.7426H72.6857L54.3948 51.6515V76.9391H45.6048V51.6554L27.3143 23.7426H37.8233L49.9988 42.3233L62.1762 23.7426Z" fill="white"/>
    </svg>

Perhaps the asymmetry is there to subtly evoke a dip and recovery of a company's stock price. The subtext could be "we build resilient companies".

Imperfections in vector images make me twitch

Fun fact: "Y" in your comment is not symmetrical either. Letter shapes are usually not symmetrical, Y/X/etc. even in gothic sans typefaces add asymmetries that make text easier to read.

that's a lot of svg! svgo suggests the following without any manual tinkering:

  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><path fill="#F60" d="M0 0h100v100H0z"/><path fill="none" stroke="#FFF" stroke-width="8.79" d="M50 77V50m23.69-35.62L50 50M26.47 14.45l23.25 35.62"/><path fill="#F60" d="M0 0h100v23.74H0z"/></svg>

Transport compression should get it most of the way there, no? I think having human readable vector graphics is nice.

This the most HN string of replies I've seen. Cheers haha

Apart from being one-lined, the optimised version is more readable and roughly about as compressible. There’s really no reason to have transformation matrices for 2 squares and a simple polygon

transport compression isn't going to help with the unnecessary high precision coordinates.

There are also a bunch of things that are just the result of it being automatically generated by some vector package, such as the transforms, separate paths, masking of a bunch of strokes rather than just flattening the shape etc.

I see your 258 byte svgo version and raise it my 171 byte hand optimized version:

    <svg viewBox="-32 -32 64 64" xmlns="http://www.w3.org/2000/svg"><path fill="#f60" d="M-32-32h64v64h-64z"/><path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

Better still, an inline SVG fragment is only 151 bytes - and will save 318 bytes of http header:

    <svg viewBox="-32 -32 64 64" width=18 height=18><path fill=#f60 d="M-32-32h64v64h-64z"/><path fill=#fff d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

118, can we beat it anyone?

<svg viewBox="-32 -32 64 64" style="background: #f60"><path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

It doesn't need to be valid XML if you embed it in the HTML, which was their point.

Edit: I stand corrected, it does parse correctly when embedded in HTML!

By the tiniest of margins, 115. Deleted two spaces and an `l`. Largely inspired by `svgo`. Using `rsvg-convert` to render them both to PNG shows identical output between this and the 118 version. https://rjp.is/hn-svg.html seems to render them identically in Safari and Chrome.

    <svg viewBox="-32-32 64 64" style="background:#f60"><path fill="#fff" d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

But not in Firefox :(

That appears to be trigged by "-32-32" (broken) vs "-32 -32" (working). Looks like this has been a long-standing weirdness in Firefox[1] where it is allowed somewhere but not other places.

On the other hand, the spec[2] does specify whitespace or commas between the viewbox numbers.

I rescind my 115 claim and reset it back to 116.

[1] https://github.com/svg/svgo/issues/12

[2] "a list of four numbers <min-x>, <min-y>, <width> and <height>, separated by whitespace and/or a comma"

We can move the fill to the style attribute and get it back down to 114:

  <svg viewBox="-32 -32 64 64" style="background:#f60;fill:#fff"><path d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

Oh, if you then switch to the comma-style for viewBox, drop the / from the path tag, and drop the quotes from the style attributes, that takes it down to 109.

Safari, Chrome, and Firefox are all perfectly happy with it but then rsvg-convert chokes on all of those changes. 114 is probably the best that can be done and still be "conforming" (for want of a better word.)

viewBox can be comma-separated, so you can loose the quotes but only for inline SVG

Well, that seems to work in everything (Firefox, Safari, Chrome, rsvg-convert) and drops it down to 114. Ta!

Why use such un-round numbers though?

so many butts!

Reply on news.ycombinator.com