This post does not render correctly.

[anoraktrend]

https://www.tumblr.com/anoraktrend/805613846255517696/proxylynn-book-dragon-not-worm

[serialuart]

ok, so i was expecting that the problem was that fxtumblr just wasn't able to render this absolute image-heavy behemoth of a post... but nope, that it does! as far as i can tell, the images are intact.

i did notice two issues though:

the blockquotes get nested differently - on tumblr, they get flattened down to one level, whereas the fxtumblr renderer nests them correctly. i'll have to investigate why this happens but i suspect it's a case of fxtumblr's renderer being more correct than tumblr's :p

these kinds of blockquotes were returned by tumblr's html api for reblog chains. how exactly they ended up in a post of their own i'm not sure, guess it's just weirdness with the transition to NPF...

• the zalgo text here is broken. this is entirely a setup issue due to missing fallback fonts for unicode support

[serialuart]

somebody has tossed another reblog of this at the post-rewrite renderer and it actually crashed due to a bug with the blockquote handling, which is now fixed.

it turns out that actually, the old renderer wasn't rendering the blockquotes correctly:

• images were shown inside of the blockquote which is not possible (only text blocks can have an indent level)
• the blockquote kept going up after every image, which it shouldn't have.

the new renderer actually handles this correctly:

and is now actually more correct than tumblr's renderer which still flattens the quotes. replicating this in the fxt renderer would probably be a lot of effort for a fairly minor quirk, so i'm willing to keep this in.

as for the zalgo text, that's - partially - fixed too; it doesn't go outside of the block though, for some reason. might need to investigate that.

more to the point though, i realized something that i should've realized far sooner after making that first comment:

yeah, sure, it does render, and it even does so at a pretty decent speed.

but the resulting image is 24 megabytes. Twenty Four Megabytes. i'm willing to bet that's tripping up discord's thumbnailer.

there are two ways i could resolve this:

• compress the PNGs before sending them, which can still only take us so far (cc @lumiscosity)
• use a different format for huge screenshots.

i briefly played with webp, which generally provides better sizes, but is limited to ~16000 pixels width and height. the resulting render here is over 40000 pixels. av1 provides quite nice compression, but i tried opening the resulting image in multiple apps and only one worked, with major slowdowns. jpeg was the most palatable option, crunching the image down to below 2mb, but decimating the quality on the way.

the new renderer has the infrastructure to support other filetypes so i'll probably add jpegs.

however, that still doesn't solve the obvious issue of - the render is so tall that it's not even really useful to display it in an embed. wouldn't be surprised if that was another factor that could affect discord's thumbnailer. that's a problem discussed in #9 which i still haven't found a satisfying conclusion to, but we could do e.g. ranged renders (from post x to post y). it's something i'm willing to explore but it will have to happen later

[lumiscosity]

preeliminary tests show only a 2.4mb improvement on high level png compression, so nothing meaningful. jpeg might be the way to go...