The Transform 'Y' label has gone missing #62678

New Issue

William Reynish · 2019-03-17T12:35:45+01:00

William Reynish commented

2019-03-17 12:35:45 +01:00

System Information
Operating system: 10.14.3 (18D109)
Graphics card: AMD Radeon R9 M395X 4096 MB

Blender Version
Broken: 2.80 beta, March 17
Worked: 2.80 beta, March 15

Short description of error
The Transform 'Y' label has gone missing

Exact steps for others to reproduce the error

Open Blender
Go to Properties > Object > Transform

Tested at various UI scales and on various systems. Same thing.

**System Information** Operating system: 10.14.3 (18D109) Graphics card: AMD Radeon R9 M395X 4096 MB **Blender Version** Broken: 2.80 beta, March 17 Worked: 2.80 beta, March 15 **Short description of error** The Transform 'Y' label has gone missing **Exact steps for others to reproduce the error** - Open Blender - Go to Properties > Object > Transform ![Screenshot 2019-03-17 at 12.33.07.png](https://archive.blender.org/developer/F6838661/Screenshot_2019-03-17_at_12.33.07.png) Tested at various UI scales and on various systems. Same thing.

William Reynish commented

2019-03-17 12:35:45 +01:00

Added subscriber: @WilliamReynish

William Reynish commented

2019-03-17 12:38:33 +01:00

This comment was removed by @WilliamReynish

*This comment was removed by @WilliamReynish*

Jacques Lucke was assigned by Brecht Van Lommel

2019-03-17 13:07:41 +01:00

Jacques Lucke commented

2019-03-17 13:42:27 +01:00

I can reproduce it, it is caused by my "fix" from friday. Checking what's going on...

I just don't understand why we did not see that earlier. I'm 100% sure that I checked this, and you probably as well.

I can reproduce it, it is caused by my "fix" from friday. Checking what's going on... I just don't understand why we did not see that earlier. I'm 100% sure that I checked this, and you probably as well.

blender-admin commented

2019-03-17 14:15:26 +01:00

This issue was referenced by cfd909f184

This issue was referenced by cfd909f184ccd87ed6dcfa45a5ab93d8fc5cb742

Jacques Lucke commented

2019-03-17 14:17:40 +01:00

Changed status from 'Open' to: 'Resolved'

Jacques Lucke closed this issue

2019-03-17 14:17:40 +01:00

William Reynish commented

2019-03-17 14:44:43 +01:00

I’m puzzled too. I definitely don’t remember this occurring then.

Jacques Lucke commented

2019-03-19 12:35:59 +01:00

hmm, unfortunately I found another case where this problem occurs.
Take a Separate XYZ node and zoom in and out. Sometimes the Y disappears.
The problem is that BLF_width(...) returns 7, but g->width is 9 (g is the glyph).
This is because g->advance is 7.
Not sure at which level this has to be fixed.
All these offsets are a bit confusing. Is this very redundant or does it only feel like it is?

@WilliamReynish, can you reproduce this?

hmm, unfortunately I found another case where this problem occurs. Take a `Separate XYZ` node and zoom in and out. Sometimes the `Y` disappears. The problem is that `BLF_width(...)` returns `7`, but `g->width` is `9` (`g` is the glyph). This is because `g->advance` is `7`. Not sure at which level this has to be fixed. All these offsets are a bit confusing. Is this very redundant or does it only feel like it is? @WilliamReynish, can you reproduce this?

Jacques Lucke commented

2019-03-19 12:36:10 +01:00

Changed status from 'Resolved' to: 'Open'

Jacques Lucke reopened this issue

2019-03-19 12:36:10 +01:00

William Reynish commented

2019-03-19 12:45:39 +01:00

Yes, I can reproduce that case too here.

Maybe it's a hack, but could we just add some padding to the width to ensure that we don't clip the text prematurely?

Although I suppose the correct thing would be to simply calculate the width correctly.

Yes, I can reproduce that case too here. Maybe it's a hack, but could we just add some padding to the width to ensure that we don't clip the text prematurely? Although I suppose the correct thing would be to simply calculate the width correctly.

Jacques Lucke commented

2019-03-19 12:53:41 +01:00

Adding a padding in various places is what the old code did.
That is not necessarily bad, and we might have to do it in the end, but it would still be nice to find the actual issue.

The question is, what is the width of a text (i.e. what should BLF_width return).
Is it the pixel perfect total width (including shadows).
Or should various offsets and kerning information be taken into account?

In the case of Y: advance = 7, width = 9, pos_x = -1.
Is `BLF_width("Y", ...)`` 7, 8 or 9 (there are reasons for every case)?

Adding a padding in various places is what the old code did. That is not necessarily bad, and we might have to do it in the end, but it would still be nice to find the actual issue. The question is, what is the width of a text (i.e. what should `BLF_width` return). Is it the pixel perfect total width (including shadows). Or should various offsets and kerning information be taken into account? In the case of `Y`: `advance = 7`, `width = 9`, `pos_x = -1`. Is `BLF_width("Y", ...)`` 7, 8 or 9 (there are reasons for every case)?

William Reynish commented

2019-03-19 12:59:29 +01:00

I mean, we really need the final size of the text, after kerning and other things, otherwise the width will always be incorrect.