Duplicate inline image rendering

[karanmalhi]

For large images, the image gets rendered twice.
The first image renders on its own page and is fully rendered.
The second image shows up on the next page, left aligned and is only partially visible i.e. the left half is missing.
Using Prawn

[mojavelinux]

Can you please provide a link to an image that can be used for testing? The original image size is ideal since we don't want the problem to be lost in transfer.

[ShaKeSPeaR]

A little example for issue (see included zip):

• big_image_test.txt - example project
• big_image.png - original image [1274x1215]
• image.png - a little scale of original image [944x900]
• small_image.png - half scale of original image [500x477]

As you may see in big_image_test.pdf:

• big image not show at all
• middle image have twice rendered (with strange crop)
• small image render as expexted

big_image_zip.zip

Some remarks:

• If I manually set a width to fit the image into the page (image:big_image.png[width="100"]) it scaled well and render normally
• I played with image sizes - in some cases it may render thrice.

[roentgenium]

I also encounter the same issue.
And the problem may be using inline image "image:" (one colon) instead of "image::" (two colon).

[mojavelinux]

As @roentgenium points out, you are using an inline image when you mean to use a block image. Use two colons after image in the image macro instead of one. (e.g., image::filename.png[]).

Inline images are meant to fit without the line of text (i.e., the line height). If they exceed that area, then the behavior is undefined.

[mojavelinux]

I figured out why this is happening. It has to do with how we arrange inline images. We first put blank spaces where the image will go. Then we come back and lay the image into the place. However, if that blank space wraps, then we end up displaying the image multiple times, once for each line. (We also have a rounding error that causes this blank space to be too large in certain conditions).

We need to figure out some way to detect the end of the line and only allow the image to be as wide as the remaining space on the line (or wrap it to the next line so it does have enough space).

We may have to solve this one in stages since there are several problems at play here.

[mojavelinux]

This is related to #620.

[mojavelinux]

Actually, this is simpler than I thought. The spacer is wider than the line width and Prawn attempts to render the image again on each wrapped line. We just need to ensure the spacer is no wider than a single line (naturally restricting the image to the width of a single line).

Unfortunately, we still have the problem that the spacer width is only approximate (so the placement of the image will be a little off). We essentially have to trick Prawn into leaving us space to render the image. But we can only reserve space by using repeating characters. We might be able to use character_spacing to get the width to be more precise. Long term we need to get Prawn to allow us to make proper spacer fragments.

[mojavelinux]

(As an aside, inline image rendering is always going to be a little quirky because of how Prawn works).

[mojavelinux]

Here's my proposal:

if (spacer_cnt = (fragment[:image_width] / spacer_w).ceil) * spacer_w > available_w
  spacer_cnt -= 1
end
fragment[:text] = ImagePlaceholderChar * spacer_cnt

I'm still looking to see if we can fine-tune that spacing using character spacing on the last character.

[mojavelinux]

@fap- Did you want to send a PR?

[fapdash]

Yeah, I'll get to it tomorrow, if that's alright.

[mojavelinux]

Absolutely. I just wanted to make sure to give you the chance to author it. I'll wait for your PR.

[mojavelinux]

I'm excited to say that the character spacing works perfectly to allow us to fine-tune the reserved space. I'm able to get an inline image to line up exactly with a block image on the previous line for just about all permutations.

The one case we're still not handling is when the inline image is taller than the height of the content area. I'll handle that in a separate issue...but all the groundwork is in place.

[bartlomiejcieszkowski]

I'm seeing this issue with the asciidoctor-pdf-1.5.0.beta.2

[mojavelinux]

Please provide a test case.