(07-02-2025, 07:49 AM)jim_chapman Wrote: I say 'reasonable' because in fact Freda was then being so assiduous about preserving whitespace that it also preserved the new-line characters, which meant that little white squares were appearing at the end of each line. That's a bug really! I'm planning a bug fix release for Freda in the next week or so, and in that update I will fix this, so those ugly little squares won't appear any more.Good to know! I'm not in a rush -- I can update the files later. This drives home the fact that it would be prudent if I added the CSS white-space: pre-wrap to test this in many other readers to make sure that there are not any unexpected results.
Just to clarify, this behavior would still be different than the default of the other readers that I tried. They all ignored multiple white spaces as Freda does. It was only where I inserted explicite non-breaking space characters (  or  ) that they displayed multiple spaces.
Adding the explicite space entities seems to be what other people publishing poetry eBooks are doing, as that's where I got the suggestion from others with the same issue. The other solutions aren't practical -- the spacings are unique for each word-gap in the lines, so tables wouldn't work, and controlling positioning with CSS would be a whole lot of extra work to do for one reader -- I want to transfer files from the print book with the least amount of extra work possible. I could experiment with adding the CSS white-space: pre-wrap, but that would just resolve the issue for my book, but not for most others.
Wouldn't it be more HTML standards compliant to ignore multiple white spaces, but to not ignore explicite spaces? Then the behavior would be the same as you would expect in a web browser. I don't know what the behavior of other readers is as far as wrapping, and if I'd get better results on small screens using something such as an n-space instead of an nb-space.