Fix shy #1313

[hvbtup]

As described in #1313, in some cases the PDF rendering of text was not correct, in particular if the text contains soft hyphens.

This PR fixes the errors regarding soft hyphens, and it fixes a subtle rendering error where left-most white space was not omitted.

Output with this PR (justified text):

See how the alignment is working (also works for left-aligned, right-aligned, and centered text).

Note that some of the issues mentioned in #1313 are still present:

Missing letter spacing between letters of the same word with different styles. This also causes an offset in the justification.

A different report, where the text starts with a space, but it is omitted although the dynamic text item is plain text:

[wimjongman]

Thanks, Henning!

[merks]

Note that the next release is 4.14 so any @since should be 4.14 not 4.13.

It would be good if there were a test because everything that isn't tested can be broken later without anyone noticing until much later...

[speckyspooky]

The changes looks good!
Please add the @since-attribute to your new public methods.

[hvbtup]

I added @since tags (and removced the since incorrectly added since tag for the existing class Chunk.
Furthermore I removed some dead code.

[hvbtup]

Regarding "It would be good if there were a test ...".

Of course you are right.
But I don't see a way to write a sensible test case.

I think what the BIRT project really needs is a regression test that allows to find visual differences in output PDFs automatically.
That way we could just create lots of different PDFs from *.rptdesign files, demonstrating various features (including soft hyphenation).

If there is a visual difference, then something has changed, which might be a regression or an improvement.

In the same way, the text for every page of the PDF should be extracted and the resulting output should be compared to the previous build.

Unfortunately I don't know such a tool which is free and good and fast enough.

I don't think that any other way of writing tests is sensible, because the internal code for the rendering is quite a mess and depends on so many things, it is not suited for unit tests.

[merks]

There are places where things appear to be rendered to an image and then the images are compared. E.g., these

I don't claim to know much about how this works nor do I think we should hold things up because there is no test. It's likely that creating a good test would take more time than implementing the feature...

[hvbtup]

I think for LTR text, this PR is definitely an improvement.
I see two possible risks where this PR might result in unintened output differences.

1. RTL text. Do we know anyone who could check if the changes do not harm RTL reports?
   I know exactly nothing about how RTL text should look, so I can't help in this regard.

2. Reports where there are other objects (e.g. inline images) inside a LineArea. The rendering might change here, because the way we are searching for "the last" TextArea in a line (for removal of rightmost white space) has changed.
   However, I consider this to be a rather exotic use case.

So, from my POV, I think it is reasonable to merge this and see if someone should notice an unintended behavior change, we can fix it then.

[hvbtup]

There are places where things appear to be rendered to an image and then the images are compared. E.g., these

I don't claim to know much about how this works nor do I think we should hold things up because there is no test. It's likely that creating a good test would take more time than implementing the feature...

Yes, that's the case here.
The SVG files you mentioned are charts. The chart engine is kind of a super-plugin in BIRT (a very special case) and it completely unrelated to the layout engine for creating PDFs. And of course, comparing SVG files is much easier, because they are really just XML files.