Regression for stem blocks in table (from beta6 to rc2)

[rillbert]

Hello there,

First off, thanks for these awesome tools to work with asciidoc...

I am currently working with making equations from stem macros render correctly in pdf. I use the recommended asciidoctor-mathematical gem for this and discovered what I believe is a regression from asciidoctor-pdf beta6 to rc2.

We use inline stem blocks within table cells and in beta6 this renders ok (although the typesetting could be better but that is another question).

In rc2 though, the lines in paragraphs containing stem blocks are not calculated accurately. With the default theme, the kerning seems to be off but with our custom theme, the svg images from the stem blocks exends past the table cell border.

See the attached pdf's and the adoc source that generates those pdfs.

pdf_stem_bug_beta6.pdf
pdf_stem_bug_rc2.pdf
pdf_stem_bug_rc2_custom_theme.pdf

The source that generates the pdf is also attached
pdf_stem_bug.txt

Regards
/Anders

[mojavelinux]

To make the content fit, it seems that prawn-table is not honoring the width of the fragments. The reason this comes up is because we switched from using space characters to using an explicit width for the image fragments. And that approach doesn't seem to be compatible with prawn-table.

[mojavelinux]

Okay, I think I got it. I found an area of the line wrapping logic in Prawn that does not honor the width of the fragment. I think we can patch it. That will allow us to continue to use to more accurate strategy for placing an inline image (without this bug, of course). I'll also file an issue upstream.

[rillbert]

Great, thanx for all the work you put into these tools.

[mojavelinux]

@rillbert you're welcome. 🍻 And I'm really grateful that you found this before the 1.5.0 release, because it's a pretty major issue.

[mojavelinux]

Btw, this bug affects all inline images (specifically in table cells), not just those generated by asciidoctor-mathematical.

[mojavelinux]

We were assuming that Prawn always respects the assigned fragment width (which is reserved for the image), but this turns out to not always be the case. The exception is in the line wrap / text arranger. If an image does not fit on the line, the fragment gets moved to the next line. But when this happens, the fragment width gets lost. And that causes other characters in the line to overlap the image. (I can't exactly explain why, but it's clear this is what happens).

Fixing this problem is difficult because, at some point, the line wrap / text arranger stops working with fragments and only works with text (the string). Since the text for an image is empty, the reserved space is lost with no easy way to recover it. It gets even worse if the image fits, but then gets pulled to the next line by an adjacent character that doesn't fit.

I did come up with several approaches that will work. I'll document them here for future reference.

Although the line wrap / text arranger doesn't respect the fragment width, it does always respect the character spacing (which follows each character), which can be used as a mechanism to reserve space. With that in mind, here are several approaches to the problem:

• set the text of the image fragment to \u2063 (invisible separator) and use the character spacing to set the width; override width_of_string to return the character spacing for the \u2063 character
  • we can't use \u0000 as the text since the line wrap will collapse it into the previous character when it falls the end of the line
  • the downside is that we're giving special meaning to the \u2063 character
• set the text of he image fragment to '.' (period) and use the character spacing to set the width (minus the width of '.')
  • the downside is that the image fragment cannot be narrow than the width of '.'
• set the text to repeating \u0000 to represent the width (where each \u0000 represents 0.01 points); override width_of_string to treat \u0000 as 0.01 points
  • the downside is that the fragment text is very long and it requires the most processing to interpret it

In the end, I decided to go with the first proposal because it's very simple, very clean, and very accurate. The downside is acceptable.