text wrapping making frame taller than it should be - proposed workaround for this problem.

[vincedarley]

In case of interest, I've got a "not quite a bug fix, but a very sensible workaround" for this issue:

        # One of the possible causes here is that wrap function has used an extra line (because
        #  of some slight mismatch in character widths and a frame that matches too precisely?)
        #  so that a word wraps over when it shouldn't. I don't know how to fix that sensibly.
        #  Increasing the height is NOT a good visual solution, because the line wrap is still
        #  not where the user expects it - increasing the width would almost be more sensible!
        # Another suspected cause is in the use of multiple font sizes in one text. Perhaps the
        #  line scale (interline space) gets confused by this?

in my fork, https://github.com/vincedarley/cewe2pdf (along with a few other fixes, especially one related to vertical text centering). I've run this over 10 different photo-books of mine today and am very happy with the results.

For more detail, what I noticed through careful comparison is that cewe2pdf renders the exact same font very slightly more heavily than CEWE does. Presumably some very subtle differences in the rendering libraries used. This extra heaviness makes the characters a tiny bit bigger - hence this issue. My workaround is (applied only when encountering this issue), to try scaling the font-size to 99% of original size (and then try another 99% if necessary). This imperceptible difference resolves all of my instances of text wrapping when it shouldn't.

[AnEnglishmanInNorway]

That's a useful change. Have you considered making a pull request to bring your code into the base bash0 version? I had a quick look at the differences, and you've obviously done quite a bit of work that might be useful for others. Have you tried running all the tests, runAllTests.py? This gets run on check in to the base, and is a useful way of verifying that you haven't broken existing operation. The tests obviously don't require a cewe installation since they have to run on a github server. Actually, I'd be very interested to know if the tests actually complete successfully on a Mac before your changes were introduced.

[vincedarley]

I just ran all the tests in the original bash0 version and in my changes. The originals do pass: "18 passed, 7 warnings in 31.10s.". This on MacOS Seqouia, Intel CPU.

With my changes, 13 out of 18 fail. Some of those I can see an issue I must have introduced in the background frame of a text box, so I'll look to re-fix/revert the change (*)

However, some of these tests seem to output a lot of warnings about this exact "text wrapping" issue, yet still "pass", so I'm assuming those tests SHOULD fail with my code? Can you clarify please?

Once I've narrowed things down a bit more (fixed most of *), I'll comment further...

[AnEnglishmanInNorway]

I also get 18 passed, 7 warnings on my Windows 11. I haven't run it now, but I'm pretty sure I'll get the same if I fire up Linux as a Window subsystem. And yes, there are quite a lot of warnings about text wrapping. I have looked at these once upon a time, and as far as I remember they're mostly to do with the fact that the tests run with the limited set of fonts available in the local test structure, which obviously doesn't include all the Cewe fonts that we all have installed locally. When a font is missing, then the code makes a "best effort" substitution, and best effort is unlikely to be good enough!

However, the "critical" part of the regressive testing is that many of the tests use a compare-pdf comparison between the document pages they have just created and the the most recently checked in approved test. Basically the pdf pages are turned into an image, and the images are compared. Obviously this is very precise in terms of backwards compatibility, but has the disadvantage that a human might deem the two page images "close enough to be acceptable". If I recall correctly the compare-pdf code can be run by hand, letting you see a side by side presentation of the two images (or an exclusive-or composite). My idea has been that if a programmer thinks the newly generated test page image is "acceptable" when visually compared with the new page image, then he can check in the newly generated pdf as an approved test result. There's a naming convention so that the code can find the latest approved checked in result to compare with.

So ... if your background frame difference is somehow "more correct" than what we do, then your version could be approved. If not, then you should, as you say, "refix" it!

OK? I'm a bit busy with other stuff (just moved house!) so I don't really have a lot of time for programming right now, but will try to give you feedback on what you write here

[vincedarley]

Thank you - super helpful. I'm working through the test suite... Will report back, hopefully with a PR to fix things with (as you say) some test case differences (preferably "more correct", possibly "visually indistinguishable").

[vincedarley]

I've worked through the test suite. After fixing some things, as far as I can see all of the tests which fail are either:

a) My code has made an improvement - so the result is definitely "more correct" - especially in vertical centering of multi-line text, for example. Sometimes a significant improvement, sometimes more minor.

or

b) My code's results are almost or completely visually indistinguishable (the text's position is a fraction of a pixel different when I compare with, say "python compare_pdf/compare_pdf.py --pdf ../testDecorations/previous_result_pdfs/test_decorations.mcf.20250513S.pdf --pdf ../testDecorations/test_decorations.mcf.20251215S.pdf --showdiffs=diffimage"

Having "re-fixed" things today, I now do not see anything in the test suite where the output is "worse".

In many cases, these tiny text differences are not actually what the test is testing - often it is clipart, decorations, rotations, etc - these are entirely unaffected by the code changes.

Could I ask you to take a look at a few of the test results and see if you agree? (I could upload images here if you wish, or you could runAlltests yourself?).

Assuming you agree I'll prepare a proper PR, including the new test result outputs, so that all tests pass. And I'll add a new test to demonstrate more clearly the fixes to text vertical layout, text transparent borders, and the "text wrapping issue".