Non-printing character after LF causes block formatting error

Issue #642 resolved
prl created an issue

If a non-printing character (e.g. <CR>, <SPACE> is considered a printing character) immediately follows a <LF> character ("\n") in a text item with halign="block", the line containing the <LF> and the line following it do not have correct character advances applied.

Replication steps

Insert the following in any skin screen large enough to accommodate it:

            <eLabel position="100,100" size="500,100" font="Regular;18" foregroundColor="white" halign="block" transparent="1" zPosition="20" text="&lt;LF&gt;&lt;CR&gt; bug: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor\n\rincididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris..."/>

The display is as in the image below: the lines "adipiscing...tempor" and "incididunt...ad" do not have correct advances for their characters: render-lf-cr-bug.png

Comments (2)

  1. Peter Urbanec

    Fix bug #642: Non-printing character after LF causes block formatting error

    Only clear nextflags when it has actually been applied to a glyph (via assignment to flags, and use in an appendGlyph() call).

    Otherwise, a non-printing character following an LF can clear the GS_ISFIRST without it ever being applied to a glyph.

    → <<cset f0a991affdd4>>

  2. Log in to comment