possible text wrapping issue with console width less than 102 characters. #175

New Issue

asdf · 2020-06-17T05:16:57Z

asdf commented

2020-06-17 05:16:57 +00:00

Version: main.version=2.3.1 -X main.build=2020-06-17...
Terminal: Gnome Terminal 3.36.1.1

A possible text wrapping issue when browsing documents in any protocol, affecting the second line onward. The second-last character is not printed, replaced with the following character instead.

With the terminal at 80x24 size, go to a page that is not preformatted to 80 chars. I first saw this on the following page: gemini://gemini.circumlunar.space:1965/servers/
The text appears as:

Below is a list of 50 public Gemini hosts (besides this one!), listed in the ord
er in which Solderpunk became aware of them.  Not all server admins announced te
ir server to the mailing list or contacted Solderpunk directly, and this list ws
 maintained by hand so some servers which *were* announced may have been overlok
ed or entered out or order.  As such, this is not a 100% authoritative list of x
actly...

Expand the console window to greater than 102 characters width to see the content correctly displayed.

The second line should end with th and the next line should follow on with eir. h has been replaced with e, and then the wrap occurs.
All lines after the first line display this issue.
Looking at the same document using gopher (plain text item type) or local protocol has the same issues.
This seems to be an issue with any terminal width below 102 characters. At and beyond 102 characters, the words wrap with no errors.
In version 2.2.0-28-ge06de9b, this issue does not occur, however the final character of lines is sometimes truncated.
Tested also in rxvt and had the same issue.
Occurs on my local system as well as rawtext.club

- Version: main.version=2.3.1 -X main.build=2020-06-17... - Terminal: Gnome Terminal 3.36.1.1 A possible text wrapping issue when browsing documents in any protocol, affecting the second line onward. The second-last character is not printed, replaced with the following character instead. With the terminal at 80x24 size, go to a page that is not preformatted to 80 chars. I first saw this on the following page: gemini://gemini.circumlunar.space:1965/servers/ The text appears as: ```none Below is a list of 50 public Gemini hosts (besides this one!), listed in the ord er in which Solderpunk became aware of them. Not all server admins announced te ir server to the mailing list or contacted Solderpunk directly, and this list ws maintained by hand so some servers which *were* announced may have been overlok ed or entered out or order. As such, this is not a 100% authoritative list of x actly... ``` Expand the console window to greater than 102 characters width to see the content correctly displayed. - The second line should end with *th* and the next line should follow on with *eir*. *h* has been replaced with *e*, and then the wrap occurs. - All lines after the first line display this issue. - Looking at the same document using gopher (plain text item type) or local protocol has the same issues. - This seems to be an issue with any terminal width below 102 characters. At and beyond 102 characters, the words wrap with no errors. - In version 2.2.0-28-ge06de9b, this issue does not occur, however the final character of lines is sometimes truncated. - Tested also in rxvt and had the same issue. - Occurs on my local system as well as rawtext.club

sloum commented

2020-06-17 06:05:50 +00:00

I have replicated this. I am always on a full screen terminal so this just slipped past me it seems. I tried in st and in gnome-term and the issue was present for both, though st actually did not do a proper wrap at all at that size. This is a weird one. I'll pause my work on the in-app help and switch over to this tomorrow.

Thanks for the report @asdf

I think there is a line overflow happening where it is writing more than the width of the screen. For terminals that support turning line wrapping off (gnome-term, for example) this causes an overwrite to occur (I think). For terminals that do not support it (st, for example), breakage will happen to the wrapping. I'll update to see if wrapping to 1 less than the terminal width solves the issue.

I have replicated this. I am always on a full screen terminal so this just slipped past me it seems. I tried in st and in gnome-term and the issue was present for both, though st actually did not do a proper wrap at all at that size. This is a weird one. I'll pause my work on the in-app help and switch over to this tomorrow. Thanks for the report @asdf I think there is a line overflow happening where it is writing more than the width of the screen. For terminals that support turning line wrapping off (gnome-term, for example) this causes an overwrite to occur (I think). For terminals that do not support it (st, for example), breakage will happen to the wrapping. I'll update to see if wrapping to 1 less than the terminal width solves the issue.

asdf commented

2020-06-20 07:22:40 +00:00

Trying to debug this and loving life.

This is the test I'm trying:

    p := MakePage(u, "0123456789 123456789 123456789 123456789 123456789\n", []string{""})
    p.WrapContent(10-1, false)

So to clarify, the test input I can see in p.RawContent is:

    "0123456789 123456789 123456789 123456789 123456789\n"

From this, I think the expected result of p.WrappedContent should be:

[]string{
	"0123456789",
	" 123456789",
	" 123456789",
	" 123456789",
	" 123456789",
	"",
},

But the actual result is:

[]string{
	"0123456789"
	" 123456789 "
	"123456789 1"
	"23456789 12"
	"3456789"
	""
}

So the second line onward is being created as width + 1?

When a line wraps, the counter is set to 0 and then a character is written. If the counter is set to 1 instead, the expected result is received and it works in Gnome Terminal (but st is printing blank instead of the final character, perhaps this is a different issue with the terminal wrap option?).

I don't really understand this, like it's hard to comprehend even watching it go through the debugger one loop at a time. But maybe it is on the right track?

Trying to debug this and loving life. This is the test I'm trying: ``` p := MakePage(u, "0123456789 123456789 123456789 123456789 123456789\n", []string{""}) p.WrapContent(10-1, false) ``` So to clarify, the test input I can see in `p.RawContent` is: ``` "0123456789 123456789 123456789 123456789 123456789\n" ``` From this, I think the expected result of `p.WrappedContent` should be: ``` []string{ "0123456789", " 123456789", " 123456789", " 123456789", " 123456789", "", }, ``` But the actual result is: ``` []string{ "0123456789" " 123456789 " "123456789 1" "23456789 12" "3456789" "" } ``` So the second line onward is being created as width + 1? When a line wraps, the counter is set to 0 and then a character is written. If the counter is set to 1 instead, the expected result is received and it works in Gnome Terminal (but st is printing blank instead of the final character, perhaps this is a different issue with the terminal wrap option?). I don't really understand this, like it's hard to comprehend even watching it go through the debugger one loop at a time. But maybe it is on the right track?

asdf referenced a pull request that will close this issue

2020-06-21 04:29:48 +00:00

Line wrap correction #176

asdf commented

2020-06-21 04:32:36 +00:00

The issue appears to be that when a line is wrapped, the counter is reset to 0 and a character is written but we do not increment the counter as would be required normally when a character is written. As a result, lines that are wrapped are one character longer than requested. I've submitted #176 to work this through.

Just a note for reference: this was a lot easier to comprehend after a break and also by reducing the size of the test data (e.g. debugging with a 2 character line width).

The issue appears to be that when a line is wrapped, the counter is reset to 0 and a character is written but we do not increment the counter as would be required normally when a character is written. As a result, lines that are wrapped are one character longer than requested. I've submitted #176 to work this through. Just a note for reference: this was a lot easier to comprehend after a break and also by reducing the size of the test data (e.g. debugging with a 2 character line width).

sloum added the

rendering

label 2020-06-30 16:34:40 +00:00

asdf referenced this issue

2020-07-01 05:27:42 +00:00

Line wrap correction #179

sloum referenced this issue from a commit

2020-07-02 02:38:38 +00:00

Merge pull request 'Line wrap correction' (#179) from line-wrap-correction into release2.3.2 This is approved/merging in now :) For historical conversation on this PR please see: #175

sloum commented

2020-07-02 02:41:56 +00:00

This has been merged into a release branch. I will close this out once it is released into develop.