prawn
prawn copied to clipboard
shrink_to_fit does not respect character_spacing
Outputting text which shall shrink to fit the bounding box while using character spacing different from 1, the shrinking is not performed correctly. I think the character spacing is not taken into account when calculating the width of the text at all. It is assumed that character spacing is always 1.
Example:
bounding_box [200, 200], width: 100, height: 100 do
stroke_bounds
font 'Courier', size: 20 do
text '1234567890', align: :center, valign: :center, overflow: :shrink_to_fit, character_spacing: 4
end
end
This will render a pdf with the following:
Not providing the character_spacing parameter results in this:
Yep that sure does look like a bug.
At my initial glance though the code the #shrink_to_fit method is looking to catch a Prawn::Errors::CannotFit
exception to know that the text isn't fitting. It expects the wrap method to throw this exception which internally uses the line_wrap method which calls eventually #update_output_based_on_last_fragment to throw the exception if the line does not fit. So my initial thoughts are this calculation is what is forgetting to take into account the character spacing.
The logic there is a bit dense but it's as good a place to start as any. I'll try to see what I can sort out but at least I'll start with a failing test case on a PR while we try to sort though it.
I don't know if this is related to that same code, but shrink_to_fit also doesn't seem to calculate positioning of some inline formatted items.
This code works correctly:
text_box "123*",
:at => [0, bounds.height],
:align => :center,
:disable_wrap_by_char => true,
:inline_format => true,
:overflow => :shrink_to_fit,
:size => 50,
:width => 70
Result:
When adding <sup>*</sup> the asterisk gets wrapped and shows up in the middle of the text.
text_box "123<sup>*</sup>",
:at => [0, bounds.height],
:align => :center,
:disable_wrap_by_char => true,
:inline_format => true,
:overflow => :shrink_to_fit,
:size => 50,
:width => 70
Result:
@iamjohnford I'm not sure if that is the same bug or not, it could be related to something in the text formatter for inline formatting, where @obfuscoder is probably just failing to a account for a variable when calculating the width. I'm unsure for now.