Rather than pushing on with Art I was busy reconnecting the DISQUS comments engines and links, and working on a greatest hits post for imgur – check it out here.
Just updated the link to GOLEM – looks like the old player no longer works. If you’re interested in a strictly pulp monster tale where the Art starts off looking really awful but improves as you go – check it out https://www.theblackgates.com/comic/golem-small-town-massacre/
Have put down the first lines on part 6.
All very well pumping up the res of images, and adding SVG text but there are issues with loading out of order, showing future content while loading the current page. to be addressed.
Super-low file sizes crisp and scalable.
- Text to outline from within exporter (not before)
- Save (Single Page) as SVGZ
- SVG 1.0 template.
I’m using a really old (no longer made) application MACROMEDIA FREEHAND MX for laying out with text because I’m a fanboy and haven’t found anything that I prefer. Only the second part of wildflower makes use of SVG text as I realised the first part (done back in the day a pc rebuild/install or two since then) was done in clipstudio/mangastudio. Which is why the font has a different look.
Had issues with (valid) licence trying to re-install so I have looked to re-export.
Issues with the archive meant I’ve lost any since 2014. Not a huge drama.
YUS. Not my best work but given the tortured birth of the thing, its out and done.
Read it here http://www.theblackgates.com/comic/binary/?part=100
COMICROCKET Version not yet up to date will jump on to this soon.
for static, not for animate.
Now that the current story is no longer displaying at a fixed width and scales to fit the browser it might be worth updating the text on the art to a vector format to be readable at large resolutions. Rendered out a 1200px currently it looks a bit shit when stretched.
Note the change in font hasn’t helped, but.
Above: Text stretched beyond 100% – not good. Below @ 100%
Artwork size in general ranges from ~150kb to 350kb depending on detail gradients etc. I’m generally happy with modern browsers pixel interpolation when resizing images and personally feel not much is to be achieved by ramping the average image size up to achieve crisper text. This could also impact load times for viewers, not a fan of the idea.
Not to say that you cannot have hi-res images, but that it should be served only when the device or browser window requires them, either by img srcset 2x,3x or by browser width detection.
Text as SVG, SVGZ
So I’ll probably look to implement SVG text in the revised comic engine. Running as a separate layer on top of the image. While you could embed the image into the SVG, this causes a few problems, most notably the CMS does not recognise importing SVGs as images.
Testing wise exporting text at a larger size ~3300px gave a file size of 100kb. The comparable SVG file gave a filesize of 77kb when SVGZ, 250kb when SVG, so using the gzipped variant will be the go.
SVGZ Crisp as a motherfucker.
There are many additional processes that could be run for optimising I’m sure – but I don’t have the time or enthusiasm to continually run through a who series of steps each time I want to output. At best I want the CMS to take one hi-resolution page of art, export to reduced sizes that will be chosen depending on requirement, then load the comparable FILENAME.SVGZ to overlay the relevant FILENAME.JPG.
Looks promising though will look at in further when able.
EXCEPT IT IS NO GOOD FOR WHAT I WANT Didnt think about animation. SVG is not pixel based it does not play nice with animate(); Kills things dead. I ran some tests with a static svgz overlay, with text fading out / replace / fade up upon the slide transition occurring but it just looked NAFF. Animating over the top of a static SVG also proved a performance hit. So no go. NEW APPROACH I will look to use the fallback of a higher-rez text file overlay with filters e.g. filter: contrast(1.2); see how that goes…
WRONG ASSUMPTION, RIGHT APPROACH
Ok, turns out the SVG works if handled the right way. The performance hit was not from the SVG, but from the nested div with background image. Trying to animate the outer div with image + inner div with text was the issue. I found this when I swapped out the svg for the png image and had exactly the same issue.
How to fix? Use CSS3 multiple background image functionality instead, using the svgz as second url() proved to have no deal-breaking performance hit – cool.
As promised new pages. Partial upload. I dreaded the thought of coming back to this dated old website and CMS, so have started migrating across to a new platform (wordpress). So looking into that has chewed up some time.
Looked at changing the comic engine to a standard gallery slider, but have found I prefer the existing slide-over to reveal approach than any kind of scroller. The behaviour/reveal of the next page just feels right.
Anyway, I havent found how to update the link for the LATEST COMIC (seriously hate this POS) so read the new 3 pages here: