Change SFD's image storage to PNG #3801
Conversation
|
The general arrangement seems fine to me. I'll review the code a little closer Saturday if nobody else gets to it first. |
Also fix some SFD versioning issues noticed by @skef
|
I think this is OK to merge now. Here's what I did:
|
* Add UNKNOWN to enum * ImageX -> Image2 * Only bump to 3.0 on !UndoRedoLimitToSave if already 3.1
|
@ctrlcctrlv This is probably there or very close by now but I want to look at it with fresh eyes tomorrow to be more confident. I promise I'll be prompt. |
There was a problem hiding this comment.
This started as just a review, but it turned out easier to just test it out myself.
I've made relevant changes here: jtanx@6528b87
@ctrlcctrlv on those exit statements, yeah not a fan of those ones either. But those ones are slightly more justified; they are error conditions on an internal inconsistency, whereas in some cases, this image2 code is just exiting because it hasn't been compiled with the support in.
My commit changes that to just skip loading the image, which I think is nicer behaviour.
At the very least, that EndImageX needs addressing.
Also an img NULL check for bitmaps
|
✔️ ❓ |
Turns out it's not rusty at all but rather OG Thanks @jtanx
|
It didn't seem like I slept that long... |
|
I'm okay with all this. |
Assuming libpng is in use, a `WritePNGInSFD` exists so users can disable this new feature.
Even with the low compression setting to keep speed the same as writing uncompressed bitmaps (on my system), this saves 60% over the previous method.
Unfortunately this doesn't really fix the speed problem, but it does make my SFD file size much more manageable for putting on GitHub et cetera.
This was a lot of work. I also added a new setting, WritePNGInSFD, so this version of FontForge can generate SFD 3.1 files. It's not quite #3800, but it should be enough for a merge before the next release.