What this is about. I run a small t-shirt design lab on my own sites. You pick a drawing, pick an ink colour, and it prints. Two of my own designs refused to take any colour at all. This is the hunt: two genuine problems in the artwork that turned out not to be the cause, and the real one hiding in a function call that one of my two upload routes forgot to make.

Why. Vector files are not one thing. The same SVG means different things to Illustrator, to a browser, and to whatever pipeline you built, and all three can be confidently different at once. If you ever process user-uploaded artwork, the ending of this story is the bit to steal.

The complaint

I had drawn two designs and put them in the lab. Neither would recolour. What I typed was not a bug report, it was a shrug:

"the svg I want to use has somehow ended up with garbled colors or paths overlapping. Can you clean that up or do I do it manually? In that case, what to look for?"

Reasonable assumption. I had hand-edited both files. Obviously I had broken them.

Red herring one: the file with no colour at all

The first drawing had 89 paths and not a single fill anywhere. Just geometry, and an empty <style></style> where the colours used to live.

In my editor this looks like a disaster. Unfilled paths get drawn with whatever swatch is loaded, or as bare outlines. That was the "garbled, overlapping" look that sent me hunting in the first place.

In a browser it looks perfect, because the SVG spec says a shape with no fill is black. Same file, two programs, two completely different pictures, neither of them very wrong.

My pipeline agreed with the browser and handled it correctly. A real difference between programs, a real reason I thought it was broken, and not the bug.

Red herring two: two creams

The second drawing was broken, and this one I would never have caught by looking.

.a{fill:#ede4cf}   ← 7 paths: headline, kayak, water
.b{fill:#f2eecb}   ← 1 path:  the small line of text at the bottom

Two colours, ten units apart out of 255. On screen they are the same cream. No human eye separates those. At least not after 12h straight at the computer.

But recolouring in my lab is a literal text substitution: find the one colour the drawing uses and swap in whatever ink you pick. A file naming two is treated as deliberately multicoloured and stored exactly as drawn.

So one stray near-duplicate cream, on one line of text, silently demoted the whole design from "takes any ink" to "prints as-is". And as-is was cream on a white shirt, which is nothing at all.

I folded .b onto .a. Fixed. One real defect found and repaired, and I was fairly pleased with myself.

It still didn't work

"today's two vectors, this one and 'the qajaq came first' cannot change colors in the tee-lab. There must be something else in play."

There was. And the detail that cracked it was in the rest of that message:

"...the editor does not allow it, thinking it is fixed in color. Which a multi colored graphic should be"

The editor wasn't failing. It was reaching a conclusion. So the question stopped being "what is wrong with the drawing" and became "what is the editor actually looking at".

It looks at the stored bytes for the literal string that marks a recolourable file. No flag, no guess. If the string isn't there, the drawing is fixed, and greying out the swatches is correct. Which meant the drawing had reached storage without ever being normalised.

The actual bug

There are two ways a drawing gets into my lab, and I had written them months apart:

One line missing, in the worse of the two places: the admin route exists specifically to stock the shared library, and the whole point of a library drawing is that everyone recolours it.

It survived because nothing fails. Upload returns success, the file stores, the thumbnail renders, the asset appears in the list. The only symptom is a greyed-out swatch that looks like a property of the artwork rather than a bug in the software.

We had verified the conversion function worked on both my files. It did work. What we never checked, for two rounds, was whether the route I was using ever called it.

What happened, and how else it could have gone

The fix normalises at upload, which is the cheapest option and matches what the other route already did. It has one real cost: it isn't retroactive. Every drawing I had already added stayed broken until I deleted and re-uploaded it.

Three other ways I could have gone:

• Normalise at render time. Old files heal themselves and the stored file stays exactly as drawn. Costs work on every render rather than once per upload, and I render far more often than I upload.

• Store both versions. Most flexible, and useful if you ever want to show "as drawn". Twice the storage, two things to keep in step.

• Refuse multicoloured uploads at the door. Would have turned red herring two into a clear error message. Also rejects legitimately multicoloured art, which I may want later.

If I were starting again I would still normalise at upload, but I would have the editor say why a drawing is fixed. "This drawing names 2 colours" would have saved the entire evening.

The rule of thumb I'm keeping: when something doesn't work, confirm which code path you're actually on before you start examining the data. I checked that the function was correct. I never checked that it was being called.

The lab is at rebelkayaks.eu/tee-lab, and yes, both designs take any ink now.