TextNode: Inconsistency between "getWordWrappedText" and display?


#1

As mentioned in a previous thread, I’m using TextNodes to display paragraphs of text.

As part of this, I place each TextNode-paragraph (save for the first of each page) beneath its predecessor, with an offset to space them out. This is based on the z-coordinate of the bottom of that predecessor, which in turn is calculated by subtracting the TextNode’s height (and a spacing constant) from it’s own z-coordinate.

Which brings me to my problem: every so often, I find a paragraph that’s further from its predecessor than expected.

Thinking that perhaps there were trailing “\n”-characters in some paragraphs, I printed out the result of “TextNode.getWordWrappedText()” for each paragraph, converted to a “bytes” object to . There weren’t any trailing “\n”-characters–but I was surprised to find that the locations of the “\n”-characters that were there didn’t match the line-breaks on-screen!

And indeed, I’m guessing that this is the source of my problem: that every so often the TextNode ends up with one more line than is shown on-screen, due to discrepancies in the line-breaking, and so ends up with a reported height that is greater than its on-screen height!

Example:

Cropped paragraph of text, as shown in-game:
Screenshot%20from%202019-03-02%2001-31-07
Note that there are three lines of text.

Debug printings of “getWordwrappedText” and “getNumRows”, followed by the resultant output. The object named “entry” holds the TextNode that represents the paragraph in question.

print (bytes(entry.textNode.getWordwrappedText(), "utf-8"))
print (entry.textNode.getNumRows())
b'In the lower districts of Tenereth in\nthose days, literacy was all but\nunknown. Who had the money to\nlearn?'
4

Note the number of lines, and the difference in the position of the final line-break.

I don’t think that I’m modifying these TextNodes in any way that seems likely to have an effect here. :/


#2

I don’t know why the reported word-wrapped text would be different than the one shown on screen. That sounds like it should be considered a bug. Can you reproduce this with a simple sample program and file an issue report?

Out of curiosity, do you have Harfbuzz (text-use-harfbuzz) or kerning (text-kerning) enabled in Config.prc?

One thing you could do to work around this problem is to take the resulting word-wrapped text, disable word wrapping on the TextNode, and feed the earlier wrapped text back into that TextNode. That should ensure that the text displayed on screen matches the wrapped text.


#3

I’ll give it a shot, I intend, but it’s proving tricky to reproduce for some reason! :/

Not as far as I see, no.

That’s a good idea I believe–thank you! I may well try that. :slight_smile:


#4

Ah, I believe that I’ve found it! And it was my fault!

In short, it turns out that, elsewhere, in another class that happens to interact with the “document” class responsible for these text-nodes, I was altering the word-wrap value. Since this happened after all of the calculations (and debugging printouts) involving the word-wrapped text, the resultant display didn’t match the strings in those calculations (and printouts).

I’ll probably look into whether I can just use the modified value universally in my project, as it’s pretty close to the current default value.

(I could parameterise it, but if I can use a single value without messing anything up, then it will likely be simpler to do so.)

Sorry about that! ^^;