MC-195473Wall signs are higher resolution than other blocks
Signs have 12 pixels from top to bottom. However, there are another 4 block pixels above and below the sign, which total to 20, rather than the 16 that would be expected. Also, the sign is 24 pixels wide, rather than the expected 16.
This (alongside several other sign issues such as MC-2836, MC-28561, MC-157547 and MC-195472) could be fixed by using block models for signs rather than entity rendering, and adjusting the proportions for the signs.
Linked Issues
is duplicated by1
Attachments1
Created Issue:
Wall signs are higher resolution than other blocks
Signs have 12 pixels from top to bottom. However, there are another 4 block pixels above and below the sign, which total to 20, rather than the 16 that would be expected. Also, the sign is 24 pixels wide, rather than the expected 16.
This (alongside several other sign issues such as MC-2836, MC-28561, MC-157547 and
MC-195472) could be fixed by using block models for signs rather than entity rendering, and adjusting the proportions for the signs.
Attachments1
Signs have 12 pixels from top to bottom. However, there are another 4 block pixels above and below the sign, which total to 20, rather than the 16 that would be expected. Also, the sign is 24 pixels wide, rather than the expected 16.
This (alongside several other sign issues such as MC-2836 , MC-28561 , MC-157547 and
MC-195472) could be fixed by using block models for signs rather than entity rendering, and adjusting the proportions for the signs.
Signs have 12 pixels from top to bottom. However, there are another 4 block pixels above and below the sign, which total to 20, rather than the 16 that would be expected. Also, the sign is 24 pixels wide, rather than the expected 16.
This (alongside several other sign issues such as MC-2836 , MC-28561 , MC-157547 and
MC-195472) could be fixed by using block models for signs rather than entity rendering, and adjusting the proportions for the signs.
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
is duplicated by
Thank you for your report!
However, we are already tracking this issue, and this report is a Duplicate of MC-195473, which has been marked as Works as Intended - this is an intentional game feature. If you have a different opinion, please visit the Feedback website.
Please use the search function in the future to prevent duplicate reports.
Quick Links:
📓 Issue Guidelines – 🛠 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
💬 Mojira Subreddit – 💬 Mojira Discord
May relate to MC-195473 and/or MC-170902.
The bug
The sign texture has a texture for the "front" of the sign, which is the base plank type, but lightened slightly as to make it look less "noisy" and improve readability of the text, due to this formerly being the only surface of the sign on which can be written.
This was mentioned by [Mojang] Jasper Boerstra on this comment in MC-199453: "It's to be more readable for text, the contrast is lowered on the front."
As of 23w12a, functionality was added for writing on the back of signs. However, the back texture of the sign has not been changed to account for this, which seems like an oversight.
How to reproduce
- Place a standing sign
- Inspect the front
- Inspect the back
Expected results
The front texture is slightly "more faded"/"less noisy" than the texture of the plank block used to make it. By extension, this should also apply to the back texture in the latest snapshots.
Actual results
The back of signs remains unchanged, making text slightly more difficult to read there.
Further notes
The Programmer Art resource pack makes this difference much more obvious, as the difference between the front and back is much more significant there than in the current default textures there. Fixing this issue for both the current textures and Programmer Art is unlikely since the latter is not supported to the same extent as current textures, but would be preferable for accessibility.
Can confirm. (In 1.16.1)