This object is in archive! 

Geocaching: line breaks are ignored

Guest shared this problem 4 years ago

This is an explanation of the thread in the German forum:

Since some weeks or even months Locus has the following problem displaying Cache listings:

Line breaks (html line-breaks "<br>" if listing source is written in HTML, as well as plain text line breaks if the listing is written without HTML) are ignored. That results in the problem that many listings loose their structure and they are just long sausages of text. Very difficult to read and for example to find where the description of the next stage of a Multicache starts.

An example of a non-HTML listing:

After the words "The final position of the" is 1 line-break, and after the coords "N46°45.154 E13°51.677." are 2 consecutive line breaks (= 1 blank line)

Another special example of a HTML listing:

Here after the words "fließt dann weiter" and after "durch die Untersteiermark" is one line-break each.

The desired behavour of Locus should be like's Browser-rendering: IGNORE 1 line break (otherwise the Text of GC2ZZ8R would perhaps look very "frayed", meaning the text could be broken after just 1 or 2 words in a line). But this case is not clear, cause on the other side respects even 1 linefeed in the case of listing GCGH8J

But Locus should at least respect 2 consecutive line-breaks by adding 1 blank line.

Replies (2)


Hello sonny,

thanks for the bug report!

First cache GCGH8J

Thanks, you are right. I've improved this so, in next version, it should be ok.

Second cache GC2ZZ8R

I do not see any problem here. In GPX is clearly defined that text is "HTML" and also contains directly defined line-breaks by ".<br /> tags, so I'm sure that on the Locus side it is correctly displayed.




Hi Menion, you are right, sorry for confusing. The source code of the 2nd cache is in HTML. So even if there are a lot of "CRLF" characters within the text, in this case just the "<br>" code ist relevant for creating a line feed.

Replies have been locked on this page!