API blf.dimensions issue in 4.0b #113312

New Issue

Y.T-LAW · 2023-10-06T00:49:41+02:00

Y.T-LAW commented

2023-10-06 00:49:41 +02:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.34

Blender Version
Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-04 23:50, hash: 2f71d9f807
Worked:

Short description of error
blf.dimensions doesn't match the size

It use blf.load with same ttf file and the display and dimension value is different. (Text rendering settings are the same)
In my project use blf.dimensions to calculate the beam cursor position, it works correctly in v3.6 but not in 4.0.
Is there a way to render the same text and output same dimensions value in 4.0 as in 3.6?

I've provided a script to test, thank you.

import bpy, blf, gpu
from gpu_extras.batch import batch_for_shader


font_path = 'D:\\temp\\droidsans.ttf'    # Blender 3.2 default font
font_id = blf.load(font_path)
font_size = 15
text = "Modifier"
text_position = 100, 100

# get rectangle x_max position (Right Corner)
text_index = 6    # "Modifi"
blf.size(font_id, font_size)
R = text_position[0] + blf.dimensions(font_id, text[: text_index])[0]
#

vertices = (
    (100, 100), (R, 100),
    (100, 130), (R, 130))

shader = gpu.shader.from_builtin('UNIFORM_COLOR')
batch = batch_for_shader(shader, 'TRIS', {"pos": vertices}, indices=((0, 1, 2), (2, 1, 3)))

def draw_callback_px():
    shader.uniform_float("color", (0, 0.5, 0.5, 1.0))
    batch.draw(shader)

    blf.color(font_id, 1, 1, 1, 1)
    blf.position(font_id, *text_position, 0)
    blf.size(font_id, font_size)
    blf.draw(font_id, text)

bpy.types.SpaceView3D.draw_handler_add(draw_callback_px, (), 'WINDOW', 'POST_PIXEL')

blf.dimensions Doesn't look accurate in 4.0/4.1 but not in 3.6

Weird Font spacing in non-monospaced fonts, I wish there was an option setting to change back.

System Information Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.34 Blender Version Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-04 23:50, hash: 2f71d9f80795 Worked: Short description of error blf.dimensions doesn't match the size It use `blf.load` with same ttf file and the display and dimension value is different. (Text rendering settings are the same) In my project use `blf.dimensions` to calculate the beam cursor position, it works correctly in v3.6 but not in 4.0. Is there a way to render the same text and output same dimensions value in 4.0 as in 3.6? ![image](/attachments/a6bd956c-ebfa-4e44-a8af-6d2dfca1f080) ---------------------------------------------------------------------- I've provided a script to test, thank you. ```Py import bpy, blf, gpu from gpu_extras.batch import batch_for_shader font_path = 'D:\\temp\\droidsans.ttf' # Blender 3.2 default font font_id = blf.load(font_path) font_size = 15 text = "Modifier" text_position = 100, 100 # get rectangle x_max position (Right Corner) text_index = 6 # "Modifi" blf.size(font_id, font_size) R = text_position[0] + blf.dimensions(font_id, text[: text_index])[0] # vertices = ( (100, 100), (R, 100), (100, 130), (R, 130)) shader = gpu.shader.from_builtin('UNIFORM_COLOR') batch = batch_for_shader(shader, 'TRIS', {"pos": vertices}, indices=((0, 1, 2), (2, 1, 3))) def draw_callback_px(): shader.uniform_float("color", (0, 0.5, 0.5, 1.0)) batch.draw(shader) blf.color(font_id, 1, 1, 1, 1) blf.position(font_id, *text_position, 0) blf.size(font_id, font_size) blf.draw(font_id, text) bpy.types.SpaceView3D.draw_handler_add(draw_callback_px, (), 'WINDOW', 'POST_PIXEL') ``` `blf.dimensions` Doesn't look accurate in 4.0/4.1 but not in 3.6 ![image](/attachments/53ab351b-e8d9-4272-9976-60abcd8a8e12) Weird Font spacing in non-monospaced fonts, I wish there was an option setting to change back.

image.png

13 KiB

image.png

28 KiB

Y.T-LAW added the

labels 2023-10-06 00:49:42 +02:00

Iliya Katushenock commented

2023-10-06 15:50:09 +02:00

@Harley /

Harley Acheson commented

2023-10-06 19:37:13 +02:00

Hello,

I'm not certain whether you are saying that the result of blf.dimensions is incorrect or that the problem is that the length of the text string differs between Blender versions. For example you say that "display and dimension value is different" but I would expect the length value to be different in your supplied images because the text lengths are different.

There were definitely changes in the way that text is rendered with version 4.0 versus earlier versions. With version 4.0 we have more typographically correct placement, sizing, and rendering. In prior versions all text was placed too close by half a pixel. Because this is not related to text size, this meant that when you increased the font size by 2 the resulting string was not twice as wide.

So yes, things have changed, but for the better.

However the result of blf.dimensions should still be correct for the text that is shown.

In Blender the value for the length of a text string is the sum of the "advances" of the characters. The "advance" is the distance from the start of one character to the start of the next. In a nutshell this means that our lengths include a small amount of space after the last letter. This is by design so that strings can be appended based on that measurement.

I did some testing with your suggested text string to confirm that blf.dimensions is working as expected.

For example at this size it is correctly giving a length of 62, indicated between the blue lines:

Twice as large it is correctly giving a length of 123.

Three times as large and it gives an expected value of 185

So are you saying that the value from blf.dimensions is wrong or just different? Is it just an issue of placing that text caret (blue bar) correctly?

Hello, I'm not certain whether you are saying that the result of blf.dimensions is incorrect or that the problem is that the length of the text string differs between Blender versions. For example you say that "display and dimension value is different" but I would expect the length value to be different in your supplied images because the text lengths are different. There were definitely changes in the way that text is rendered with version 4.0 versus earlier versions. With version 4.0 we have more typographically correct placement, sizing, and rendering. In prior versions all text was placed too close by half a pixel. Because this is not related to text size, this meant that when you increased the font size by 2 the resulting string was not twice as wide. So yes, things have changed, but for the better. However the result of blf.dimensions should still be correct for the text that is shown. In Blender the value for the length of a text string is the sum of the "advances" of the characters. The "advance" is the distance from the start of one character to the start of the next. In a nutshell this means that our lengths include a small amount of space after the _last_ letter. This is by design so that strings can be appended based on that measurement. I did some testing with your suggested text string to confirm that blf.dimensions is working as expected. For example at this size it is correctly giving a length of 62, indicated between the blue lines: ![image](/attachments/7b302ac7-4e46-4e11-b333-84b5db8f0301) Twice as large it is correctly giving a length of 123. ![image](/attachments/8b30daed-52a4-48e2-b1fe-73daba7f7580) Three times as large and it gives an expected value of 185 ![image](/attachments/ba16974d-e110-42ee-9acd-4ef0c992cbeb) So are you saying that the value from blf.dimensions is wrong or just different? Is it just an issue of placing that text caret (blue bar) correctly?

image.png

6.6 KiB

image.png

4.5 KiB

image.png

7.5 KiB

Y.T-LAW commented

2023-10-06 20:10:15 +02:00

Font spacing looks weird in non-monospaced fonts in 4.0/4.1 compare with 3.6
blf.dimensions output not accurate, in 4.0/4.1 compare with 3.6. Especially when the font size is set to a small size.

Thanks for listening, I've provided a test script, see top.

1. Font spacing looks weird in non-monospaced fonts in 4.0/4.1 compare with 3.6 2. `blf.dimensions` output not accurate, in 4.0/4.1 compare with 3.6. Especially when the font size is set to a small size. Thanks for listening, I've provided a test script, see top.

Harley Acheson commented

2023-10-06 20:34:54 +02:00

Font spacing looks weird in non-monospaced fonts in 4.0/4.1 compare with 3.6

As mentioned, the font spacing is more accurate in 4.0/4.1

blf.dimensions output not accurate in 4.0/4.1 compare with 3.6

In your example script you are drawing "Modifier" but showing a box that is the width of the substring "Modifi":

You will notice that the width includes a space after the "i" that is approximately the same width as the width of the stroke of the "i". This is because this is how the "i" is constructed in that font (viewed in FontForge):

So the string length will include the space to the right of the "i". Make the text larger in your script and you will see that it maintains that distance as perfectly as possible, within a pixel.

> Font spacing looks weird in non-monospaced fonts in 4.0/4.1 compare with 3.6 As mentioned, the font spacing is more accurate in 4.0/4.1 > blf.dimensions output not accurate in 4.0/4.1 compare with 3.6 In your example script you are drawing "Modifier" but showing a box that is the width of the substring "Modifi": ![image](/attachments/f533a6a5-ff3c-4e7f-adf5-0dacfe394fa0) You will notice that the width includes a space after the "i" that is approximately the same width as the width of the stroke of the "i". This is because this is how the "i" is constructed in that font (viewed in FontForge): ![image](/attachments/1729b3fc-eeb2-46dc-93e5-5dd25e45695b) So the string length will include the space to the right of the "i". Make the text larger in your script and you will see that it maintains that distance as perfectly as possible, within a pixel. ![image](/attachments/81a36116-ea6e-4392-b248-d043b2c8cc35)

image.png

11 KiB

image.png

14 KiB

image.png

445 KiB

image.png

44 KiB