Proper text layout dependent on background-color #271

TheEclectus · 2022-01-22T14:50:53Z

TheEclectus
Jan 22, 2022

Greetings. In stapling together my implementation of RmlUi's rendering interface, I've come across some bizarre functionality that I'm not sure is by design or a bug.

My test program consists of RmlUi 4.3 from vcpkg with a full Rml::RenderInterface implementation, and displays a simple .rml file:

<rml>
	<head>
		<title>Example</title>
		<link type="text/rcss" href="base.rcss"/>
		<style>
			p
			{
				display: block;
				margin: 0px 3px;
				background-color: #ccc;
				line-height: 1.0;
			}
			p.title
			{
				display: inline;
				background-color: #0cc;;
			}
			body
			{
				width: 500px;
				height: 200px;
				background-color: #ccc;
				font-family: Volter (Goldfish);
				font-size: 18px;
			}
			div#title
			{
				width: 100%;	
				background-color: #0cc;
				text-align: center;
			}
		</style>
	</head>
	<body>
		<handle move_target="#document">
			<div id="title">
				<p class="title">Title goes here, if there was one</p>
			</div>
		</handle>
		<p>Here are some</p>
		<p>p elements</p>
		<p>to test spacing</p>
	</body>
</rml>

base.rcss was copied directly from https://mikke89.github.io/RmlUiDoc/pages/rml/html4_style_sheet.html.

This is the expected output, which is accomplished with the above .rml and .rcss. However, when omitting the explicit background-color property from p, formatting is broken and it is apparently drawn at position [0,0] (as is corroborated by debugging my RenderInterface implementation, where translation becomes {0,0}):

This behavior is the same if a background-color with full transparency is specified.

Conversely, if p.title or div#title have no specified background-color, formatting remains in-tact. If body is without it, formatting is entirely broken and the text will be rendered in a blob in the top-left corner of the window:

Is this behavior intentional? Am I misinterpreting the sample code, which didn't seem to need a background-color explicitly specified to work? Any advice or guidance would be appreciated. Thank you!

Answered by mikke89

Jan 22, 2022

Hi, and welcome!

The first thing I will say is that in no way should the layout depend on the background-color property. I think there must be something else quirky going on here, I have never seen this behavior.

I tested your code and got the same layout as in your first screenshot. When I changed the background-color of the different rules you mention there is no change to the layout, as we would expect. Only the background changes.

Are you getting any log output / warnings? Please check that first.
Can you post a full example of a faulty render as well, so I can see if it reproduces here?

View full answer

mikke89 · 2022-01-22T17:08:25Z

mikke89
Jan 22, 2022
Maintainer

Hi, and welcome!

The first thing I will say is that in no way should the layout depend on the background-color property. I think there must be something else quirky going on here, I have never seen this behavior.

I tested your code and got the same layout as in your first screenshot. When I changed the background-color of the different rules you mention there is no change to the layout, as we would expect. Only the background changes.

Are you getting any log output / warnings? Please check that first.
Can you post a full example of a faulty render as well, so I can see if it reproduces here?

3 replies

TheEclectus Jan 24, 2022
Author

Greetings!

It's definitely some vexing behavior. I don't believe that it's a rendering problem; I can still post the relevant code if need be (it's a very simplistic OpenGL renderer built with Magnum as an abstraction layer), but an offset of {0.0, 0.0} is being passed to my RenderGeometry() function (when the Document is in the top-left corner of the Context, anyways, The value being passed is always equal to the Document's offset). This seems to come from the result of element->GetAbsoluteOffset(Box::BORDER) being passed to geometry.Render() on line 52 of ElementBackgroundBorder.cpp. Exploring the memory of element, its absolute_offset variable is likewise {0.0, 0.0} at the time it's rendered. So unless I'm mistaken, there is something happening within RmlUi causing this behavior, and that it's not just a rendering bug.

I also feel I should mention I'm not touching Rml's state beyond the initial font loading and state setup, no programmatic layout alterations or anything.

TheEclectus Jan 25, 2022
Author

And now with my foot thoroughly lodged in my own mouth, I realize after stepping through Rml's routines that I'd neglected to multiply by the transform matrix if my Rml::RenderInterface implementation's texture parameter was non-null. Behavior is now entirely as is expected.

mikke89 Jan 25, 2022
Maintainer

Alright, I'm not sure I understand what's going on with the offset, but I'm happy it seems to be working for you now! Cheers.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proper text layout dependent on background-color #271

{{title}}

Replies: 1 comment 3 replies

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Proper text layout dependent on background-color #271

TheEclectus Jan 22, 2022

Replies: 1 comment · 3 replies

mikke89 Jan 22, 2022 Maintainer

TheEclectus Jan 24, 2022 Author

TheEclectus Jan 25, 2022 Author

mikke89 Jan 25, 2022 Maintainer

TheEclectus
Jan 22, 2022

Replies: 1 comment 3 replies

mikke89
Jan 22, 2022
Maintainer

TheEclectus Jan 24, 2022
Author

TheEclectus Jan 25, 2022
Author

mikke89 Jan 25, 2022
Maintainer