(Dunno why I didn't think about it before, I was always closing and relaunching the emulator when hacking test HTML files to check cre tweaks :)

Probably 'cause it sounds like it'd only work for some subset of changes? :-)

Sharing my test files for reference and enjoyment: test-epub-svg-test.zip
It includes a big epub with all the SVGs referenced in
https://commons.wikimedia.org/wiki/User:JoKalliauer/SVG_test_suites/resvg_Issues_details.

Also for reference, another test suite related to EPUBs, with some related to the usage of SVG in EPUB, that I haven't checked (as it's mostly niche, and even Calibre doesn't care):
https://w3c.github.io/epub-tests/

@zwim: as the scientist / maths'ist among us, if/when you have some bit of time, could you have a look at ImageViewer and its zoom in/out factor depending on pinch/spread distance and swipe along the left or right screen edge - it always feels frustrating to me - but that's as much as my math skills got me to implement when I added it.
Frustrations:

• it does not (always?) reflects the distance: a spread starting from the edges of a small object in the image should have this object enlarged to fit where you release your fingers.
• once you have zoomed in, the spread/swipe distances have little effect, you need to do a lot of them to zoom in further

(I also had that same skills limitation and frustration with zoom in BookMap - but that's less annoying.)

@poire-z No problem, I will look into it as soon I have some spare time (this week is stressful, but latest on Fr. afternoon I will have time.)

Well not quite the problem you have addressed, but it is easy to poduce crashes when zoom in and in and in and in ...

It seems, if the memory runs out (even on a mobile with 6GB ) the assertion in ffi/blitbuffer.lua line 1905 bites us.

I have also found other crashes when zoom in excessively with an horizontal spread (was something like a arithmetic on nil with 'self._bb_xxxx'), but can not reproduce it on the mobile quite now.

Anyway: A crash is not accaptable!
So a possible solution might be to check the available memory bofore a zoom in and ... dont zoom, show a message ...

Unfortunately I am not really familiar with the whole thing (mupdf, imageviewer +widget, blitbuffer ), so I can not fix it right now.

As I dont really use the zoom feature myself and I wont have time the next few weeks, should I open a bug report on that (for reference), or i this message enough (@poire-z, @NiLuJe )?

This message is enough.
But well, open a super big epub, and it might crash.
Open a PDF with a scan dust on a blank page and with some option to zoom to content, it might crash.
Same with this zoom in: of course, you could ultra zoom in and build a super wide bitmap, and it might crash.
But let that to the user sense: the time it takes to draw such a bit bitmap, he will stop zooming-in before it's too late :) Also, I played a lot these last weeks with SVG, zooming in country maps to see the nice details and place names written in a nice font, without getting a single crash: the zoom-in I needed were enough for me, and not too radical to cause a crash.
So, I'd say : let's not worry.

Fine with me for now. But the time will come, someone opens an epub with large images. Not crash. Zoom only a few times -> crash.
I insist that a crash is not accaptabe (if we can avoid it)!

For someone familiar with the interactions of blitbuffer, mupdf and imageviewer it might be easy to show an info message "Mem out." before doing the action, so we can avoid crashes. That can not de difficult. We know the size of the image and the scale factor. So size times scale factor squared is the new size. Try to allocate mem of that mew size. If Ok release that mem and go on as now, if not ok stop the action (with a message? )
For tiny images below an MB the procedure can easily be optimized.

@zwim: I wouldn't mind the exact stack strace from the non-malloc related crash, to see if it can be dealt with ;).

I'd be veeeery wary of doing any kind of pre-malloc guard in bb:new or bb:copy itself, for the simple reason that we do a lot of bb allocs, and the exceedingly vast majority of them are fine.

What I could see happening is:

• Either handling the checks on the individual actually potentially problematic call sites, with the obvious drawback that it's potentially still a lot of them. And I definitely wouldn't do it with an extra malloc->free pass, but some kind of heuristics based on screen size and bitdepth to limit the requested pixmap sizes to something sensible, but device-specific.
  (Could possibly be made less painful by offloading most of it to dedicated checked_new and checked_copy bb methods?).
• or softening the assert to a logger.err, and returning a fixed-size and/or capped to screens-size BB8 with a "broken image" (e.g., the checkerboard pattern used as an icon fallback). I'm not quite sure how callers would react if given a different-than-expected bb size, though. And the BB might need to be tagged as "broken" somehow (I think we still have space for something like that in the config byte).

Sidenote: I'm not quite sure where bb:copy is even involved here, I don't see it used anywhere outside of rotation handling in imagewidget?

(I would vastly prefer the first approach, although parts of the second idea might make sense in the first, or vice-versa).

This is the stack trace of a crash (when zooming with a diagonal gesture):

xxx self.scale_factor	6.1944949103205	max_width	nil
09/16/22-15:52:04 DEBUG ImageViewer:_clean_image_wg
09/16/22-15:52:04 DEBUG setDirty via a func from widget table: 0xb20e3058
09/16/22-15:52:04 DEBUG not painting 1 covered widget(s)
09/16/22-15:52:04 DEBUG painting widget: table: 0xb20e9cb8
09/16/22-15:52:04 DEBUG ImageWidget: _render'ing data 1440 1920
09/16/22-15:52:04 DEBUG ImageWidget: scaling by 6.1944949103205
09/16/22-15:52:04 DEBUG RenderImage:scaleBlitBuffer: scaling
./luajit: ./ffi/blitbuffer.lua:1905: cannot allocate bb copy buffer of size 137788.62kB
stack traceback:
	[C]: in function 'assert'
	./ffi/blitbuffer.lua:1905: in function 'copy'
	./ffi/mupdf.lua:922: in function 'scaleBlitBuffer'
	frontend/ui/renderimage.lua:305: in function 'scaleBlitBuffer'
	frontend/ui/widget/imagewidget.lua:348: in function '_render'
	frontend/ui/widget/imagewidget.lua:386: in function 'getSize'
	frontend/ui/widget/container/centercontainer.lua:10: in function 'paintTo'
	frontend/ui/widget/verticalgroup.lua:51: in function 'paintTo'
	frontend/ui/widget/container/framecontainer.lua:124: in function 'paintTo'
	frontend/ui/widget/container/widgetcontainer.lua:83: in function 'paintTo'
	frontend/ui/widget/container/inputcontainer.lua:85: in function 'paintTo'
	frontend/ui/uimanager.lua:1147: in function '_repaint'
	frontend/ui/uimanager.lua:1354: in function 'handleInput'
	frontend/ui/uimanager.lua:1460: in function 'run'
	./reader.lua:300: in main chunk
	[C]: at 0x000140bd
!!!!
Uh oh, something went awry... (Crash n°1: 09/16/22 @ 15:52:07)
Running FW 4.33.19759 on Linux 4.9.56 (#53 SMP PREEMPT Thu Jun 2 15:26:41 CST 2022)
Attempting to restart KOReader . . .

And this is the stack trace of a zoom by horizontal pinch:

09/16/22-16:22:35 DEBUG Contact:voidState Contact lift detected
09/16/22-16:22:35 DEBUG AutoSuspend: onInputEvent
09/16/22-16:22:35 DEBUG ImageViewer:_clean_image_wg
09/16/22-16:22:35 DEBUG setDirty via a func from widget table: 0xb21b7c10
./luajit: frontend/ui/widget/imagewidget.lua:395: attempt to perform arithmetic on field '_bb_w' (a nil value)
stack traceback:
	frontend/ui/widget/imagewidget.lua:395: in function 'getPanByCenterRatio'
	frontend/ui/widget/imageviewer.lua:673: in function 'handleEvent'
	frontend/ui/widget/container/inputcontainer.lua:263: in function 'handleEvent'
	frontend/ui/uimanager.lua:808: in function 'sendEvent'
	frontend/ui/uimanager.lua:52: in function '__default__'
	frontend/ui/uimanager.lua:1316: in function 'handleInputEvent'
	frontend/ui/uimanager.lua:1410: in function 'handleInput'
	frontend/ui/uimanager.lua:1460: in function 'run'
	./reader.lua:300: in main chunk
	[C]: at 0x000140bd
!!!!
Uh oh, something went awry... (Crash n°1: 09/16/22 @ 16:22:36)
Running FW 4.33.19759 on Linux 4.9.56 (#53 SMP PREEMPT Thu Jun 2 15:26:41 CST 2022)
Attempting to restart KOReader . . .