Suboptimal wrapping due to rounding

[benoitkugler]

It is a bit unfortunate that LineWrapper.WrapNextLine and LineWrapper.WrapParagraph take an int for the maximum width.

In one of my use case, the precision loss matters as an unexpected line break is produced by go-text. More precisely, I have a single run of text of advance 45.5 and a max width of 45.8, so that the run is broken by go-text while it should simply fit on the first line.

I think we should change the type used internally, expose two new methods taking a fixed.26_6, and (perhaps) deprecate the current method.

[whereswaldon]

Perhaps this is naive of me, but isn't the maximum width meant to be expressed in pixels? For display purposes, how do we end up in a case where we have 45.8 pixels, but not 46? I'd like to understand the use case better before changing the API.

[benoitkugler]

Well, I use go-text to perform html layout, which implies breaking text into boxes which can have arbitrary width constraint, expressed in floating point units.

[whereswaldon]

In your use-case, what happens visually when the bounding box is 45.8 pixels wide and the text is allowed to fill it? Do you clip and antialias the edge there so that it's 80% text and 20% the background? I guess I'm just confused on what it means to partially fill a pixel with text.

[benoitkugler]

My exemple was not very convincing, but consider instead a case where the run is 44.2 long and the decimal max width allowed is 44.3, rounding (or flooring) will produce an unexpected line break.

Now, if I instead ceil the max width, the text could grow and overflow past its bounding box.

I understand that this behavior may have no visual impact, but I need to check whether or not it breaks the other steps of the layout.
I am a bit worrried that a function which is supposed to return a width under a given threshold actually does not respect that threshold. Imagine for instance that we layout two boxes on the same line, the, say, 0.5 decimal errors would add up and we would be off by one pixel at the end.

[whereswaldon]

I see your point. I wonder whether it might be desirable to actually round the entire sizes of your bounding boxes in order to make them look crisper, but that doesn't detract from the cumulative error that can occur. I'm open to changing to fixed-point widths. I saw that you made a PR, and I'll try to look at it soon.