Empty space beween image and details too large

[hartenthaler]

[Neriderc]

So the root of the problem is not related to the oval shape, but that Graphviz renders the image as a square - but because the image is rectangle it is aligned to the left of the invisible square. You can see in this image how the browser has a square box but the image does not fill it:

Now, how to resolve this? I am not sure. I cannot find a simple setting that helps, I think this will involve changing how the tile is assembled. I will attempt this at some point, but I cannot promise it will be resolved any time soon.

[hartenthaler]

Is it possible to center the image instead of aligning it to the left? This would not solve the issue, but would make it more acceptable.

[Neriderc]

Using Graphviz settings, it does not seem to be possible. The tile is assembled with what Graphviz calls an "HTML-like label", which looks much like an HTML table that you may be familiar with. Graphviz allows you to change the alignment of the cell,however, this only aligns the "image" (which is considered square). The <img> tag in the HTML-like label does not allow the "align" option, so we can't center the actual image within the <img> box.

I think the crux of the issue is one of the settings that lets you set the size. Disabling this, however, makes the photos way too large, and for some reason I can scale them up from there but they won't scale down.

We could attempt to apply an after-Graphviz fix, but as with the photo shapes, this wouldn't work for server-side generation. And on top of this, it gets a little tricky. Graphviz creates an SVG, which is very specific about placement. For example, if we move the words to the left, the box will not automatically shrink to fit, we need to also adjust the box.

And one big problem with this is that we don't actually know the aspect ratio of the photo. There is a gap here for photos that are portrait (taller than they are wide), but photos could be landscape (wider than they are tall) where this would not cause the same issue and trying to change the layout could prevent these from working correctly.

I think the ideal situation would be to use PHP to get the size of the photo (which I'm assuming is possible, since we have the files on the server), then rewrite the tile Graphviz code to work nicely with a photo set to a specific height and width.

I would guess what we want is possible, but it appears to need a fair bit of work to do it. Redoing this code is probably inevitable at some point, but it will be on the long term list of things to do unless I get a sudden brain wave (or someone else volunteers to have a go at it).

[hartenthaler]

ok, it is not worth to go the hard way you sketched out.

[Neriderc]

I'd like to keep this on the list of things to do in future. This is not the first time I've had issues with the structure of the tiles, and I think eventually we will need to re-do this code, at which point we will resolve this.

[schuco]

In the context of future to-dos concerning photos please consider the problem, that PDFs including photos often get much bigger than diagram-PDFs without photos. I observed cases for the same diagram with photo 10MB but only 100KB without. You can compress such a PDF without noticable loss in quality by a PDF editor down below 1MB.
I know that the reason for big PDF-diagrams are too big jpg-files and I remember, that you already explained that it is impossible to get thumbnail-jpg directly from webtrees.

[Neriderc]

What happens if you reduce the DPI setting? Does that help at all?

[schuco]

What happens if you reduce the DPI setting? Does that help at all?

That helps a lot.
But if you have a mixture of photos with very different size and basic resolution a general reduction of DPI may not be good in all cases.

[Neriderc]

I've added #395 to discuss this as it's separate and I think easier to resolve now that I've done a bit more research.

[Neriderc]

Also I've tagged this "Help wanted" since I haven't been able to figure out a simple way to solve this but perhaps someone else can.