Whilst in no way as complex as Linux kernel development, I felt I was going down multiple debugging rabbit holes whilst I was try it lying to figure out why Lib

Whilst in no way as complex as Linux kernel development, I felt I was going down multiple debugging rabbit holes whilst I was try it lying to figure out why LibreOffice wasn’t displaying a texture fill. My first stage of diagnosis found that we weren’t reading in texture brushes correctly. So I figured out how to do this. Then I found this didn’t work, so after a lot of checking if the EMF+ spec I realised we only read in compressed image data (PNG, JOEG, etc) but not uncompressed DIBs. I think the original coder didn’t realise what the bit so data type values represented and used a previous implementation to guess at what it did (this is no criticism of them, incidentally). So then I realise the existing VCL code could read a DIB, but relied on a valid DIB header, which the EMF image object doesn’t provide. So my next step was to add a seem into the DIB data reader that injects its own DIBV5 header. I’m now reading it in. Now I have read it in, I actually have to get it to draw. Here’s hoping this will be easier to implement!