Image updates

[Pete-Robelou]

• Implement imagemin gifsicle
• Update blog post image paths
• Added file extension jpeg to widen the image capture net 🙂
• Added notes to README

I set the number of colours to 96 for gifsicle, this offers a reasonable level of compression without degrading the image too much. Our mileage will vary a bit though depending on the image, ideally we need to encourage the use of jpg for photography and png for everything else.

Closes #243

[adamduncan]

@Pete-Robelou I wonder whether here (and inblog-post) we just concat ${url}${image}, which is perhaps a more intuitive outcome for those filling out image: i.e. using the path to wherever their image is relative to the blog post itself?

I.e. We're proposing the convention is always to put blog images in an images directory (which thankfully the WP export has followed suit), but does it give us more predictability/flexibility, should someone not follow our advice in the README? I.e. And just puts a single image alongside the index.md? Should that be fair game?

[Pete-Robelou]

Yeah, that's fair. I'll remove our enforced /images.

[adamduncan]

Do we need to remove this test data?

[Pete-Robelou]

Good spot 🙂

[adamduncan]

I'm wondering whether we might want to roll this this same convention into Case studies (at the moment they're referencing assets from the global assets directory, which is perhaps a bit counter-intuitive). Saying that, some assets (e.g. company logos) it kinda does make sense to take these from a centralised collection of (i.e. SoftIron logo is the same on all SoftIron case studies, sponsored events, etc.)

What do you think, @Pete-Robelou?

[Pete-Robelou]

I'm wondering whether we might want to roll this this same convention into Case studies (at the moment they're referencing assets from the global assets directory, which is perhaps a bit counter-intuitive). Saying that, some assets (e.g. company logos) it kinda does make sense to take these from a centralised collection of (i.e. SoftIron logo is the same on all SoftIron case studies, sponsored events, etc.)

What do you think, @Pete-Robelou?

Yeah, that's an interesting one. Company logos definitely work better from a centralised location, this also prevents any duplication if they were all co-located. It does unfortunately introduce a mix in the front matter though if we co-locate regular assets and centralise logos.

If we document it in the README maybe that's good enough?

title: Virtualizing HPC at University of Kentucky
image: "photo-coral-09.jpg"
sponsor:
  name: SoftIron
  logo: "/assets/bitmaps/logo-softiron.png"
  website: "https://www.softiron.com"
tags:
  - information
  - technology

[adamduncan]

If we document it in the README maybe that's good enough?

Yep, I think so. If we specify that image is relative, and logos are root-relative where we spec the frontmatter scema, I think that's fair.

By extension, I can envisage a future solution that might check if the path startsWith / or http (hopefully contributors wouldn't be referencing external images for content assets on the site, but y'know), in which case we'd treat root-relative (i.e. use path as is, not preprending the page.url), or otherwise we treat as relative (and prepend the page.url accordingly)?

[Pete-Robelou]

By extension, I can envisage a future solution that might check if the path startsWith /, in which case we'd treat root-relative (i.e. use path as is, not preprending the page.url), or otherwise we treat as relative (and prepend the page.url accordingly)?

Maybe. That definitely feels like a magic solution. I guess as long as it's well documented it should be fine.

[adamduncan]

Yeah, suggesting that as a fairly established convention (e.g. hyperlinks would follow that convention), so hopefully feels intuitive even for those who skip the README

[Pete-Robelou]

Yeah, suggesting that as a fairly established convention (e.g. hyperlinks would follow that convention), so hopefully feels intuitive even for those who skip the README

That's fair.

Do you want to propose it as an update or shall we wait until it becomes more of a requirement?

[adamduncan]

Do you want to propose it as an update or shall we wait until it becomes more of a requirement?

Let's action separate to this update. Sorry, mentioned here as it triggered the thought, but actually a bigger fish to fry, I'd say.

[adamduncan]

Thanks @Pete-Robelou