It is currently November 15th, 2019, 3:45 am

[BUG] AccurateText Bug

Report bugs with the Rainmeter application and suggest features.
Yincognito
Posts: 682
Joined: February 27th, 2015, 2:38 pm

[BUG] AccurateText Bug

Yincognito » January 17th, 2019, 11:13 pm

So, after seeing that there was little interest for the problems I reported here, I have a present for you, maybe this time you'll notice: a bug. Big, ugly, black bug. Since an image is worth a thousand words, I'll let you see for yourself:

Case I. AccurateText=0 : The white text is occupying the same space as the same text beneath it, reporting the same width.

Code: Select all

[Rainmeter]
DynamicWindowSize=1
AccurateText=0

[Styles]

[ParentStyle]
SolidColor=64,64,96,160
StringStyle=Bold
ClipString=2
FontFace=Tahoma
StringEffect=Shadow
FontColor=0,0,0,255
FontSize=12
AntiAlias=1
X=5
Y=5

[ChildStyle]
FontColor=255,255,255,255
W=[MT_String1:W]
H=[MT_String1:H]

---Meters---

[MT_String1]
Meter=STRING
MeterStyle=ParentStyle
Text="DK.W"
UpdateDivider=-1
DynamicVariables=1

[MT_String2]
Meter=STRING
MeterStyle=ParentStyle | ChildStyle
Text="DK.W"
DynamicVariables=1

[MT_Info]
Meter=STRING
FontSize=12
FontColor=255,255,255,255
SolidColor=0,0,0,255
AntiAlias=1
H=20
X=5
Y=50
Text="String1 W: [MT_String1:W], String2 W: [MT_String2:W]; String1 H: [MT_String1:H], String2 H: [MT_String2:H]"
DynamicVariables=1
AccurateText0.jpg
Case II. AccurateText=1 : The white text is truncated with an ellipsis, despite having the same content as the text beneath it and reporting the same width.

Code: Select all

[Rainmeter]
DynamicWindowSize=1
AccurateText=1

[Styles]

[ParentStyle]
SolidColor=64,64,96,160
StringStyle=Bold
ClipString=2
FontFace=Tahoma
StringEffect=Shadow
FontColor=0,0,0,255
FontSize=12
AntiAlias=1
X=5
Y=5

[ChildStyle]
FontColor=255,255,255,255
W=[MT_String1:W]
H=[MT_String1:H]

---Meters---

[MT_String1]
Meter=STRING
MeterStyle=ParentStyle
Text="DK.W"
UpdateDivider=-1
DynamicVariables=1

[MT_String2]
Meter=STRING
MeterStyle=ParentStyle | ChildStyle
Text="DK.W"
DynamicVariables=1

[MT_Info]
Meter=STRING
FontSize=12
FontColor=255,255,255,255
SolidColor=0,0,0,255
AntiAlias=1
H=20
X=5
Y=50
Text="String1 W: [MT_String1:W], String2 W: [MT_String2:W]; String1 H: [MT_String1:H], String2 H: [MT_String2:H]"
DynamicVariables=1
AccurateText1.jpg
Not going to give my detailed specs again, but it's the last Rainmeter beta on Windows 10. Use hardware acceleration is not checked, if it matters. At first I thought it was the padding (the link I posted above), but it was the AccurateText option, since these sample have no padding whatsoever.
You do not have the required permissions to view the files attached to this post.
Last edited by Yincognito on January 20th, 2019, 1:43 pm, edited 1 time in total.
User avatar
eclectic-tech
Rainmeter Sage
Posts: 3597
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: [BUG] AccurateText Bug

eclectic-tech » January 18th, 2019, 1:03 am

So you don't feel ignored... ;-)

Yes, padding needs to be looked at... Brian talked about AccurateText in this post and a few following that.

The padding between the two methods needs to be examined.

Adding 1 to your section variable in the Child Style corrects the clipping, but shouldn't be needed.

Code: Select all

[ChildStyle]
FontColor=255,255,255,255
W=([MT_String1:W]+1)
H=[MT_String1:H]
Yincognito
Posts: 682
Joined: February 27th, 2015, 2:38 pm

Re: [BUG] AccurateText Bug

Yincognito » January 18th, 2019, 1:24 am

eclectic-tech wrote:
January 18th, 2019, 1:03 am
So you don't feel ignored... ;-)
I know you're joking, but it's not about being ignored or not - I'm not one that craves for attention. But I don't usually come up with false problems either, and when I say something is generally after I've tried pretty much everything to fix it myself.
eclectic-tech wrote:
January 18th, 2019, 1:03 am
Yes, padding needs to be looked at... Brian talked about AccurateText in this post and a few following that. The padding between the two methods needs to be examined.
Well, now that's useful - it means the issue is already known. That's all that was needed in my other post - so that I didn't make another one on relatively the same (known) problem.
eclectic-tech wrote:
January 18th, 2019, 1:03 am
Adding 1 to your section variable in the Child Style corrects the clipping, but shouldn't be needed.
Yep, I already noticed that - I was going to edit my post about this, but went for a cigar instead. 8-) As for my case, I reverted back to AccurateText=0 with no padding until this is fixed. I'm not in a hurry about that, by the way.
User avatar
eclectic-tech
Rainmeter Sage
Posts: 3597
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: [BUG] AccurateText Bug

eclectic-tech » January 18th, 2019, 1:54 am

Let's see what "the code monkeys" (as JSMorley likes to refer to them) come up with. :D
Yincognito
Posts: 682
Joined: February 27th, 2015, 2:38 pm

Re: [BUG] AccurateText Bug

Yincognito » January 18th, 2019, 2:03 am

eclectic-tech wrote:
January 18th, 2019, 1:54 am
Let's see what "the code monkeys" (as JSMorley likes to refer to them) come up with. :D
Let's...and then have a party to get JSMorley drunk. :thumbup:
User avatar
Brian
Developer
Posts: 1924
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: [BUG] AccurateText Bug

Brian » January 18th, 2019, 6:18 am

This happens to be one of those rounding errors when converting from a integer based coordinate system (like GDI+) and a floating point coordinate system that D2D (really its DirectWrite) uses.

So what happens is that D2D measures the parent string and returns a floating point number. Since it knows for certain that string will fit within that floating point number, it tells Rainmeter that no clipping is needed (via ClipString=2). So that string is drawn correctly. However, since Rainmeter works with "whole" or integer numbers, the floating point of the number is stripped when the width (and height) is saved back to the meter. Then the child meter (via section variables) asks for the width/height of the parent to use as its own. This value is just the whole number (without the fractional part). Then when drawing, D2D realizes that the child string is not quite wide enough and clips it.

For example:
With AccurateText=0, the width of the string is: 50.9253426. Since the extra padding is added, the child string still fits within the 50 pixel boundary, and is not clipped.
With AccurateText=1, the width of the string is: 44.7031250. Since there is no extra padding, the child string no longer fits within the 44 pixel boundary and is clipped.

While fixing this is trivial, we will need to discuss any backwards compatibility this may cause with some skins since the width/height might increase by 1.

-Brian
Yincognito
Posts: 682
Joined: February 27th, 2015, 2:38 pm

Re: [BUG] AccurateText Bug

Yincognito » January 18th, 2019, 2:02 pm

Brian wrote:
January 18th, 2019, 6:18 am
This happens to be one of those rounding errors when converting from a integer based coordinate system (like GDI+) and a floating point coordinate system that D2D (really its DirectWrite) uses.While fixing this is trivial, we will need to discuss any backwards compatibility this may cause with some skins since the width/height might increase by 1.

-Brian
Yes, since the difference was always 1px (as both eclectic-tech and I have noticed), if I were to guess, I would have suspected a rounding error as well - that's about the only thing that always differs from others by 1 the whole time. The backwards compatibility is indeed tricky, but this could be solved by adding an option like AccurateText=2, that rounds the whole thing properly. This way, the skins now using AccurateText=0 or AccurateText=1 won't be affected at all, while the new AccurateText=2 would fix the issue for "newer" or more "precise" skins in this aspect. Of course, if you think this would be a good idea, a small note in the manual should specify that AccurateText=1 rounds the whole thing down (aka more or less how the Trunc formula works in Rainmeter), while AccurateText=2 rounds the thing up.

This is just an idea, maybe it helps you somehow. Whether you'll choose to make things this way or another, that's up to you. ;-)
User avatar
SilverAzide
Posts: 606
Joined: March 23rd, 2015, 5:26 pm

Re: [BUG] AccurateText Bug

SilverAzide » January 18th, 2019, 2:18 pm

Brian wrote:
January 18th, 2019, 6:18 am
For example:
With AccurateText=0, the width of the string is: 50.9253426. Since the extra padding is added, the child string still fits within the 50 pixel boundary, and is not clipped.
With AccurateText=1, the width of the string is: 44.7031250. Since there is no extra padding, the child string no longer fits within the 44 pixel boundary and is clipped.

While fixing this is trivial, we will need to discuss any backwards compatibility this may cause with some skins since the width/height might increase by 1.
This stuff was actually one of the reasons I submitted this suggestion here: https://forum.rainmeter.net/viewtopic.php?f=14&t=26338

If I recall properly, I had major issues in my skins when I switched them all to AccurateText=1, because of sizing issues similar to those noted by Yincognito (i.e., string meters that fit in a certain space no longer fit). I ended up having to rejigger a lot of meters by a pixel or two to get things back into shape.

So, I was thinking if we had a way to get the internal "measured string width/height" values, then instead of Yincognito doing W=[MT_String1:W], he could do W=Ceil([MT_String1:measuredwidth]) and the result would include that one extra pixel he needs to prevent clipping.
DeviantArt Gadgets More...
Yincognito
Posts: 682
Joined: February 27th, 2015, 2:38 pm

Re: [BUG] AccurateText Bug

Yincognito » January 18th, 2019, 2:39 pm

SilverAzide wrote:
January 18th, 2019, 2:18 pm
This stuff was actually one of the reasons I submitted this suggestion here: https://forum.rainmeter.net/viewtopic.php?f=14&t=26338

If I recall properly, I had major issues in my skins when I switched them all to AccurateText=1, because of sizing issues similar to those noted by Yincognito (i.e., string meters that fit in a certain space no longer fit). I ended up having to rejigger a lot of meters by a pixel or two to get things back into shape.

So, I was thinking if we had a way to get the internal "measured string width/height" values, then instead of Yincognito doing W=[MT_String1:W], he could do W=Ceil([MT_String1:measuredwidth]) and the result would include that one extra pixel he needs to prevent clipping.
Well, lo and behold, I wasn't the first one to have such issues - my bad that I didn't properly search the forum for related issues to mine. :oops:

Your idea, while probably being (or not) considered by the devs, would help me too, since I was also about to suggest a way to measure the actual string width according to the font being used. Some fonts are wider, others are narrower, some are higher, others are shorter, and while my previous system of multiplying with the value of FontSize and a manually inserted Width/Height "Ratio" successfully calculated the width/height of an actual string, it still had parameters that needed to be tweaked by the user (i.e. it wasn't an "automated" solution). Sure, DynamicWindowSize=1 helps here, but it's only for the width/height of the whole skin, and not each of its elements (at least not without any additional computation in the code).

I think in the end the devs will choose the best solution for this, while also not "overcomplicating" things unnecessarily. The latter part is good to consider when designing software, since keeping things as simple as you can generally minimize the chance of future bugs on the matter. Complex code usually multiplies the number of future possible bugs - you only have to look at the Windows OS to see that.

P.S. I also switched to AccurateText=1 recently (since I'm sort of "rewriting" my skins to be up to date with the things that changed from the last time), that's probably why I noticed the issue only now. My first time with AccurateText=1 (which I actually like very much for my minimalistic skins), and I'm already having such small "issues". :D
User avatar
Brian
Developer
Posts: 1924
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: [BUG] AccurateText Bug

Brian » January 19th, 2019, 5:11 pm

This has been fixed for the next beta (r3277). Thanks for reporting.

-Brian