Well, space characters at the end of a string are just ignored while getting the width of a string. Now, if we have a space character in a string then we expect it to show up as is. That is if I take a string as Text=" Something "(4 spaces at beginning and end, with quotes) then I expect it to show 4 spaces at the end when I use SolidColor, and the next relative meter should be 4 spaces away.
But the last spaces just don't show up.
Now, it raises the concern of backwards compatibility, so I would suggest make a new option like ShowWhiteSpace or something similiar, so that the terminating spaces are not removed from the meter.
It is currently March 29th, 2024, 2:32 am
[BUG]Terminating spaces are ignored when width is calculated in string meter
-
- Rainmeter Sage
- Posts: 1399
- Joined: April 24th, 2021, 8:13 pm
[BUG]Terminating spaces are ignored when width is calculated in string meter
from the Realm of Death
-
- Rainmeter Sage
- Posts: 5384
- Joined: April 12th, 2012, 9:40 pm
- Location: Cedar Point, Ohio, USA
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
For myself, I never try to use space characters to specify positions; but I do agree with your thinking it should be consider in the width.death.crafter wrote: ↑October 6th, 2021, 6:02 pm Well, space characters at the end of a string are just ignored while getting the width of a string. Now, if we have a space character in a string then we expect it to show up as is. That is if I take a string as Text=" Something "(4 spaces at beginning and end, with quotes) then I expect it to show 4 spaces at the end when I use SolidColor, and the next relative meter should be 4 spaces away.
But the last spaces just don't show up.
Now, it raises the concern of backwards compatibility, so I would suggest make a new option like ShowWhiteSpace or something similiar, so that the terminating spaces are not removed from the meter.
When using the SolidColor option to backfill a String meter, I use the Padding settings to control that size; it is more precise (using pixels) than a space character that can be different widths if the font is changed.
Padding will be used to set the relative position of meters, but again I usually use the R and r parameters in the associated meters to get more precise positioning; sometimes even a pixel can make things look a bit off!
Maybe your suggestion will happen, it would provide a more logical result when using spaces in strings.
:: My DA Gallery :: Rainmeter DA Gallery :: Rainmeter Workshops :: Rainmeter Documentation :: BBCode Guide ::
-
- Developer
- Posts: 22628
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
Yes, this should be done with Padding and SolidColor. Quotes are always ignored, and trailing spaces are always thrown away.
-
- Rainmeter Sage
- Posts: 1399
- Joined: April 24th, 2021, 8:13 pm
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
I am sorry but I quite disagree. How am I to determine the width of a space character in a font.
Seeing this from a logical view point, if spaces at the starting of a string are considered the part of a strign then why not the ones at the end?
And the funny thing is you can't even setup an workaround by creating a dummy string and get it's width, as it will be a space character and not shown by default.
I mean why? If I INTENTIONALLY put spaces in my string using double quotes around it, I expect it to appear.
Well I am not forcing you to do it. But at least think about it.
from the Realm of Death
-
- Developer
- Posts: 22628
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
I think Brian might need to weigh in on the technicalities involved, but at a high level, I'm pretty sure this behavior is very fundamental to how Rainmeter parses option values. Ignoring most white space is just baked in, and I have no idea how we would even attack that in a way that didn't have disastrous impacts on backwards compatibility.
I understand your argument, and don't have any issue with the logic of your position. I would argue however, that using Padding and / or relative positioning is the better way to deal with this, rather than trying to use the width of a "space", which is not a constant. It depends a lot on the font and font size that you use. Rainmeter is pretty much always based on "pixels" and not "characters" for all positioning and spacing.
In any case, you may have a very good reason for wanting to have trailing spaces at the end of a Text (String meter) or String (String meter) option value. The long and the short of it however, is that it just doesn't work that way.
The way that the code works today is that having a Text option like Text=" Hello World " will result in Rainmeter detecting the quotes and evaluating the string to include the spaces required to get to the start of actual characters, so the leading spaces are used. However, when the string is finished being read, any trailing whitespace is just thrown away. If you don't use the "quotes", then the leading whitespace is also thrown away. Again this is fundamental, and is why when you see code like FontColor = 255,255,255,255, Rainmeter doesn't consider the whitespace and mess things up.
I could easily agree with your argument that the ending "quote" should tell Rainmeter to consider and use all characters in between the quotes, including any trailing spaces. I'm just not sure what the implications might be.
I understand your argument, and don't have any issue with the logic of your position. I would argue however, that using Padding and / or relative positioning is the better way to deal with this, rather than trying to use the width of a "space", which is not a constant. It depends a lot on the font and font size that you use. Rainmeter is pretty much always based on "pixels" and not "characters" for all positioning and spacing.
In any case, you may have a very good reason for wanting to have trailing spaces at the end of a Text (String meter) or String (String meter) option value. The long and the short of it however, is that it just doesn't work that way.
The way that the code works today is that having a Text option like Text=" Hello World " will result in Rainmeter detecting the quotes and evaluating the string to include the spaces required to get to the start of actual characters, so the leading spaces are used. However, when the string is finished being read, any trailing whitespace is just thrown away. If you don't use the "quotes", then the leading whitespace is also thrown away. Again this is fundamental, and is why when you see code like FontColor = 255,255,255,255, Rainmeter doesn't consider the whitespace and mess things up.
I could easily agree with your argument that the ending "quote" should tell Rainmeter to consider and use all characters in between the quotes, including any trailing spaces. I'm just not sure what the implications might be.
-
- Rainmeter Sage
- Posts: 1399
- Joined: April 24th, 2021, 8:13 pm
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
Well in the case of serious backward compatibility issues, may be I will have to compromise.jsmorley wrote: ↑October 7th, 2021, 1:30 pm I think Brian might need to weigh in on the technicalities involved, but at a high level, I'm pretty sure this behavior is very fundamental to how Rainmeter parses option values. Ignoring most white space is just baked in, and I have no idea how we would even attack that in a way that didn't have disastrous impacts on backwards compatibility.
I could easily agree with your argument that the ending "quote" should tell Rainmeter to consider and use all characters in between the quotes, including any trailing spaces. I'm just not sure what the implications might be.
But what about adding an extra function, or may be parsing style to accommodate literal string values, e.g. Measure String and Meter String. I'll wait for Brian's response.
from the Realm of Death
-
- Developer
- Posts: 2674
- Joined: November 24th, 2011, 1:42 am
- Location: Utah
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
Rainmeter doesn't actually remove any trailing spaces. The issue is how D2D calculates the width of a text layout. By default, D2D removes any trailing spaces.
Fixing this is easy...however, it most certainly will lead to some backward compatibility issues, especially with skins that display text from the internet since HTML throws away spaces in a lot of cases.
Test skin:
Current behavior:
With the fix:
I think we will have to chew on this a little bit and find the best way to handle this.
-Brian
Fixing this is easy...however, it most certainly will lead to some backward compatibility issues, especially with skins that display text from the internet since HTML throws away spaces in a lot of cases.
Test skin:
With the fix:
I think we will have to chew on this a little bit and find the best way to handle this.
-Brian
You do not have the required permissions to view the files attached to this post.
-
- Rainmeter Sage
- Posts: 1399
- Joined: April 24th, 2021, 8:13 pm
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
Well, as I said, you can have an option in string meter as to how the user wants the trailing spaces to be, and default it to remove trailing spaces. But if that's not possible and there is a possibility of a big compatibility issue, then you can leave it be.Brian wrote: ↑October 8th, 2021, 2:02 pm Rainmeter doesn't actually remove any trailing spaces. The issue is how D2D calculates the width of a text layout. By default, D2D removes any trailing spaces.
Fixing this is easy...however, it most certainly will lead to some backward compatibility issues, especially with skins that display text from the internet since HTML throws away spaces in a lot of cases.
I think we will have to chew on this a little bit and find the best way to handle this.
-Brian
Also, if HTML throws away spaces then it makes it easier doesn't it. You don't have any trailing spaces to start with.
And thank you for looking into this. I am waiting for the day I can do these things on my own.
from the Realm of Death
-
- Developer
- Posts: 22628
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
This issue with trailing whitespace has been addressed and will be available in the next version soon.
-
- Rainmeter Sage
- Posts: 1399
- Joined: April 24th, 2021, 8:13 pm
Re: [BUG]Terminating spaces are ignored when width is calculated in string meter
Thank you jsmorley and Brian.
from the Realm of Death