Here we record some thoughts about the observation of the image plugin we have recorded on Image Plugin Eccentricity
# Journal Growth
Image item creation, with a good caption, is a two step process: 1. dropping image URL or file into factory, and 2. editing the caption. This results in a page JSON with three copies of the image embedded - one in the story, and two more in the journal (in the creation and edit events).
This could be addressed by including the initial edit of the caption as part of the same event that adds the image. This reduce the image copy count by one.
This does not reduce the later growth caused by editing the image item, which adds another copy of the image to the journal. It is probable that this could be addressed, maybe by holding a single copy, but this is likely to have other effects that will need addressing.
# Text or Caption
Currently get both `item.text` and `item.caption`, and only `item.text` is ever edited. This seems to have been the case since at least 2013. However, there are some very early pages where the images were created with just a `caption`.
It is probably safe to drop the `caption` field, removing it from both new images and when saving an edit. However, in the unlikely event that an images is found it should still be used, keeping `item.text ||= item.caption` at those points we determine the caption.
# Adjacent Images
Image plugin size could have some adjustment so that there is less space to the left of two images that float alongside each other. As well as preventing any items, such as short words, getting rendered into the narrow space that has been left.
Image placement might be modified to both improve flow of other items around images, and the visual order of a series of images.
Mock-up of floating second image left
● Should images that in render on the left side of the page be floated left? In **Text or Caption** on Image Plugin Eccentricity we have two images with a paragraph between them. As there is space below paragraph, the second image will float right within that space. The space below image 1, and to the right of image 2 will be left blank. It is possible to detect the placement of the second image, and float it to the left, this would allow the following items to flow into the space to its right.
All images floating right
● When we have a series of images on a page, without any intervening items, the placement on the page is visually out of order with the first image being on right. All the images floating to the right can result in gaps on the right side of the page.
Mock-up floating left those rendered on left.
If we detect where an image has rendered, and change those that get rendered on the left of the page to `float: left;` this gives a more compact layout.
Mock-up using the order of images to guide float
An alternative would be for image placement to be aware of the other images around it, starting a series of images with the first floating to the left. As well as being aware of which side of the page it has been rendered.
The `data` and `chart` plugins using the same placement. Maybe these also need to be included in this handling of adjacent items. But, what about any unknown plugins also using `float: right`?
# Clearing Float
Those plugins that don't work well following an image should be identified, and modified to add `clear: both;` to their containing div's style.
# Image Dialog
The observed rendering problem with markup in the caption is bug that should be addressed.
It would seem that migrating to opening a browser window to display the larger image would be good. This not only gives the user more control of its placement, size and zoom - being able to move it one side so can have the enlarged image in view while reading the wiki page.
# Wide Images
It should be possible to choose between showing an image full or half width, as long as the image is large enough. The current squeeze algorithm targets an image width of 500px. So it is likely most of the current images would be able to be shown at page width.