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
 ____________________________________________________________________
 ambassa...@fourthworld.com                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to