Fixed image spacing error for the preview

[ajusa]

This pull request is a tentative fix for #68
The issue described an off by one error in the way the images were rendered. After doing a lot of debugging and testing, I realized that this actually wasn't the case. The issue was that the images were very large, and there was padding to the left of the images due to the table in HTML.

To fix this, I added some CSS rules to space out all of the images so that they fit on the screen. While this doesn't fix the issue of the padding on the left, it is unclear what the correct behavior should be. Based on the preexisting table headings, I am assuming that the spacing on the left is intentional and should be left as is.

Fixed version:

So note the spacing on the left is due to the table heading from above the image. My fix now allows all of the previews to be displayed, which made it look like an off by one error when it really wasn't.

Full screenshot:

The large amount of vertical space is part of the original Minecraft schematic, so I wasn't able to do much about that. I would propose we delete the space above the actual build changes, if it is empty. I will look into this in a later PR.

Let me know if there are any issues!

[ajusa]

The Travis CI build appears to be failing for a completely unrelated reason, as it mentions Lua classes I didn't touch or use directly.

[madmaxoft]

Unfortunately this is a completely non-solution to the problem. True, the description in the issue is somewhat unclear, leading to the confusion.

The root of the problem is that the plugin is trying to export too large an area as the image. Instead of exporting only the bounding-box of the changed voxels, it exports the entire gallery area, including the ~180 air blocks above any build and all the way down to the bedrock layer.
The original idea for the export coords is as follows:

1. If the area has a user-defined bounding box (as maintained in the shared DB by the GalExport plugin), use that.
2. If not, use the stored min and max coords of the edits (each block placement and removal should update these).
3. If not (for areas created before the edit-tracking code), calculate the diff of the area with the original area data (as set in the gallery's template schematic)
   It seems part of this decision code is missing, and the third step has the off-by-one problem when diffing.

(Updated the original issue, too)

[madmaxoft]

You really need to download the Gallery backup and check the data from there to see the issue happening properly, and especially see the "good" case, how it is supposed to work (the GalExport-managed data works fine)

[madmaxoft]

As for the CI failure, that's completely unrelated, the plugin checker seems to have some emulated APIs wrong.

[ajusa]

Quick question through: This fix does stop the images from being cut off in the gallery preview, which is a different bug. Would you considering merging it just to fix that? On my laptop, I had to zoom out considerably just to see the images, as I have a low resolution display.

[madmaxoft]

So how exactly does it fix it? Does it scale the images to fit? To fit what? (Sorry, the screenshots you provided are not too clear for me, I don't see a reasonable difference between "before" and "after")

[ajusa]

That's probably because I never attached the before image 😄
As I thought you were referencing it in the original issue. Here is how it normally looks on my laptop:

In the other images I posted earlier, you can see how the images fit into my browsers viewport, whereas before the fix I end up with this cropped image that I can't scroll over to. The only way I can view the image is by zooming out an unreasonable amount of the web page.

So yeah, I added some CSS code that causes the image to be restricted by the width of the parent container, which means it all fits into my browser as in the above images.

[madmaxoft]

I'll try it on the Gallery server...

[madmaxoft]

Looks good enough as a hotfix. Though I'm not sure why there's no horizontal scrolling at all, it had to be possible before when the plugin was first written.