-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression for stem blocks in table (from beta6 to rc2) #1516
Comments
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. |
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. |
Great, thanx for all the work you put into these tools. |
@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. |
Btw, this bug affects all inline images (specifically in table cells), not just those generated by asciidoctor-mathematical. |
- don't mangle character spacing in the line if inline image wraps
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:
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. |
- don't mangle character spacing in the line if inline image wraps
- don't mangle character spacing in the line if inline image wraps
- don't mangle character spacing in the line if inline image wraps
- don't mangle character spacing in line if inline image wraps
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
The text was updated successfully, but these errors were encountered: