Text overwriting itself in non wrapping field

[Richard Gaskin]

David V Glasgow wrote:

 > Fixed line height didn’t fix the problem but thanks for the
 > suggestion.
 >
 > However, looking more closely there are 3 visible characters where cr
 > should be.   They are â9u except 9u is constant and the first
 > character is almost always there, but varies wildly.  Often an
 > underscore but also accented a, e or u.  Even more weirdly, if
 > I search the field for ‘9u', several lines are found, but not any
 > in the mutant line.
 >
 > And yet more weirdly again, when the line is displayed in a field
 > with wrap true, the weird three characters appear at the beginning
 > of ‘new lines’ except they are not actually new lines because they
 > highlight as a single block.  An invisible form feed?  or something
 > else between 9 and u  that a wrapping field decides is a wrap point
 > but confuses the hell out of a non-wrapping field?
 >
 > If I thought this was just a weird one off, I would shrug my shoulders
 > and move on.
 >
 > Shall I do that, and we will never speak of this again?

That would deny us a satisfying ending to a good mystery.  Let's see if 
we can address it.

I think there are two issue here: display rendering, and errant data.


The display rendering may be caused by the length of the line. As you 
noted, it's unusually long (thanks to the errant data), and I know 
there's a limit to how many characters can reliably be rendered on a 
single line. My understanding is that it's much shorter than the 64k 
limit for performing operations on lines in variables.

Maybe display limits rendering to the magic 32k limit imposed on other 
rendering like groups?  If the m-square of the text is > 3px (likely 
more like 10), and there's 10k of text in that line, the resulting width 
would exceed 32k px to render.

You can test that hypothesis by attempting to display a single line of 
the same with using the same font and size but with clean characters to 
see how it renders. If it doesn't appear similarly munged, please let us 
know.


That would leave us with the second item, the errant characters in that 
data, which appear to be the reason that one line is so unusually long.

Where does the data come from, and how it is assembled?  Is there any 
way to check the data source to see if erroneous data was somehow 
introduced there, and merely carried forward to your LC app?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com