Text overwriting itself in non wrapping field
ambassador at fourthworld.com
Fri Mar 18 16:57:31 EDT 2022
David V Glasgow wrote:
> Fixed line height didn’t fix the problem but thanks for the
> 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
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?
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode