Have put down the first lines on part 6.
Preloading is a bit shit.
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.
New Site

Coming back to this I *(&n hated the old site. What a dog to use. Ported across the comic engine, added new drag-drop, resize approach and SVG support. Should be sweet please let me know if any issues.
Stripped back content, haven’t put back many stories other than an colourised version of SOUR.
Webcomic Engine now running SVGZ Text
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.
These posts look old but
Issues with the archive meant I’ve lost any since 2014. Not a huge drama.
WILDFLOWER PT2 RELEASED
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.
Webcomic text – upgrade to vector / SVGX?

TLDR. Ok 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.