Geometry nodes/Text Object: negative space character width #102593

New Issue

Vyacheslav Kobozev · 2022-11-17T22:05:29+01:00

2022-11-17 22:05:29 +01:00

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.95

Blender Version
Broken: version: 3.5.0 Alpha, branch: master, commit date: 2022-11-18 20:01, hash: c0f33814c13c
3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9
2.79b at least with Text Objects.

Short description of error
When I have zero word space and character space, the size of space-character is negative.
{F13938068 size=full}
2022-11-17_23-59-38.mp4

**System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.95 **Blender Version** Broken: version: 3.5.0 Alpha, branch: master, commit date: 2022-11-18 20:01, hash: `c0f33814c13c` 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: `b292cfe5a9` 2.79b at least with Text Objects. **Short description of error** When I have zero word space and character space, the size of space-character is negative. {[F13938068](https://archive.blender.org/developer/F13938068/изображение.png) size=full} [2022-11-17_23-59-38.mp4](https://archive.blender.org/developer/F13938062/2022-11-17_23-59-38.mp4)

Vyacheslav Kobozev commented

2022-11-17 22:05:29 +01:00

Added subscriber: @Vyach

Vyacheslav Kobozev changed title from ~~Geometry nodes: negativ space width~~ to Geometry nodes: negative space character width

2022-11-17 22:07:40 +01:00

Charlie Jolly commented

2022-11-18 12:54:40 +01:00

Added subscriber: @CharlieJolly

Evan Wilson commented

2022-11-18 23:54:38 +01:00

Added subscriber: @EAW

Evan Wilson commented

2022-11-19 00:45:36 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Evan Wilson commented

2022-11-19 00:45:36 +01:00

While I can confirm this issue, I checked and it has existed since at least 2.79 in Font Objects.

The work around, until this issue gets resolved, is the set the word spacing to 2 when the character spacing is 0. Note that this only works for left aligned text.

While I can confirm this issue, I checked and it has existed since at least 2.79 in Font Objects. ![#102593 2.79.png](https://archive.blender.org/developer/F13943347/T102593_2.79.png) The work around, until this issue gets resolved, is the set the word spacing to 2 when the character spacing is 0. Note that this only works for left aligned text.

Evan Wilson changed title from ~~Geometry nodes: negative space character width~~ to Geometry nodes/Text Object: negative space character width

2022-11-19 00:50:00 +01:00

Charlie Jolly commented

2022-11-19 16:43:16 +01:00

Added subscriber: @howardt

Charlie Jolly commented

2022-11-19 16:43:17 +01:00

The issue is that the character spacing is fixed and not relative to the character size. This results in a negative offset.

Here is a fix that limits the negative spacing to the character width: P3328 and D16556

Tagging @Harley (sorry tagged Howard previously)

The issue is that the character spacing is fixed and not relative to the character size. This results in a negative offset. Here is a fix that limits the negative spacing to the character width: [P3328](https://archive.blender.org/developer/P3328.txt) and [D16556](https://archive.blender.org/developer/D16556) ![image.png](https://archive.blender.org/developer/F13946245/image.png) Tagging @Harley (sorry tagged Howard previously)

Charlie Jolly commented

2022-11-19 16:51:53 +01:00

Added subscriber: @Harley

Charlie Jolly commented

2022-11-19 16:52:09 +01:00

Removed subscriber: @howardt

Harley Acheson commented

2022-11-29 20:39:51 +01:00

The issue here is that zero character space will cause negative movement and is not something that can be corrected for in any meaningful way.

Word-Spacing is very straight forward. It is a value that is simply multiplied by the space character's advance (width of the character itself plus right-side margin). So a value of 1 keeps it the same, zero makes it take no space, and 2 will make the word gap twice as large.

But Character spacing (also known as letter spacing or tracking) cannot be done in the same way. Otherwise narrow characters, like "i" will get less of in increase than wider characters, like "w". The result is not usable in any typographic way.

Instead, character spacing is done by adding (or subtracting) the same value to all characters. This can be something that is scaled by the font size, but the important part is that it cannot differ depending on the character widths. So both "i" and "w" get the same value increase.

In Blender we have a slider for character spacing that starts with a value of zero. In order for 1 to be "normal" we take that value, divide it in half and then subtract 0.5. This means a character spacing value of 1 gives an increase of zero. When character spacing is set to zero it means that the increase is "-0.5". This means that we change the horizontal movement by half the width of an "em_square". So setting the spacing to zero means that each character gets a leftward nudge by about the width of a letter "n".

Because characters are different widths this means a "w" is moved about half its width leftward, an "e" is moved almost all of its width, and most importantly, any character narrower is moved left more than its width. This means that if the first letter of the word is an "i" then the entire smushed-up word will be to the left of the origin. But if the first letter is a "W" then the word will be smushed up in a different way but it will all be to right of the origin.

The following is the best illustration of why you get negative movement, and how it depends on the string contents:

{F13979709,width=100%}

You can try to fight some of this. You can clamp the leftward movement to be no more than the character's width. But that means that any character width setting that involves any clamping at all is typographically wrong and so that part of the character spacing range becomes useless. You really just can't use this setting to make any characters "line up" in any way (even at origin), in the same way that you can't set it to some larger value that makes them equally apart. This only works for monospaced fonts.

The issue here is that zero character space will cause negative movement and is not something that can be corrected for in any meaningful way. Word-Spacing is very straight forward. It is a value that is simply *multiplied* by the space character's advance (width of the character itself plus right-side margin). So a value of 1 keeps it the same, zero makes it take no space, and 2 will make the word gap twice as large. But **Character** spacing (also known as letter spacing or tracking) cannot be done in the same way. Otherwise narrow characters, like "i" will get less of in increase than wider characters, like "w". The result is not usable in any typographic way. Instead, character spacing is done by adding (or subtracting) the **same** value to all characters. This can be something that is scaled by the font size, but the important part is that it cannot differ depending on the character widths. So both "i" and "w" get the same value increase. In Blender we have a slider for character spacing that starts with a value of zero. In order for 1 to be "normal" we take that value, divide it in half and then subtract 0.5. This means a character spacing value of 1 gives an increase of zero. When character spacing is set to zero it means that the increase is "-0.5". This means that we change the horizontal movement by half the width of an "em_square". So setting the spacing to zero means that each character gets a leftward nudge by about the width of a letter "n". Because characters are different widths this means a "w" is moved about half its width leftward, an "e" is moved almost all of its width, and most importantly, any character narrower is moved left **more** than its width. This means that if the first letter of the word is an "i" then the entire smushed-up word will be to the left of the origin. But if the first letter is a "W" then the word will be smushed up in a different way but it will all be to right of the origin. The following is the best illustration of why you get negative movement, and how it depends on the string contents: {[F13979709](https://archive.blender.org/developer/F13979709/iWWi.gif),width=100%} You can try to fight some of this. You can clamp the leftward movement to be no more than the character's width. But that means that any character width setting that involves any clamping at all is typographically wrong and so that part of the character spacing range becomes useless. You really just can't use this setting to make any characters "line up" in any way (even at origin), in the same way that you can't set it to some larger value that makes them equally apart. This only works for monospaced fonts.

Vyacheslav Kobozev commented

2022-12-01 14:42:21 +01:00

In #102593#1453264, @Harley wrote:
The issue here is that zero character space…

But why space have zero width? It is character. And it should have width. For example there are regular space and fine space

So the formula for full character space shold look like:

Character_width + kerningA + spacingB

Another approach is to count word spacing as addend.
So initially we will have 0 addition to word spacing, and if we increase that number, there will appear and additional space after each group of non-space visible characters.

So if we want to use word spacing, we should take whole sum of spaces between words: kerning, spacing, spaces, tabs and multiply it to our coefficient.
Or we should count as word all, that is not space between word.
So in case [lettters+space+digits+space+tab+tab+tab+letters] the part with [ tab tab] will be counted as word.

So eventually we should decide, what is addend and what is multiplier,
stop to use meters for multipliers, stop to subtract addends.

For me is the most sane way is:

use multiplier for character width only for ability to overlap characters, initially 1
use addends for kerning and spacing (lets assume we will have ability to change individual character kerning), initially 0
3.use addend to word spacing, initially 0
count space as regular character with it width.

> In #102593#1453264, @Harley wrote: > The issue here is that zero character space… But why space have zero width? It is character. And it should have width. For example there are regular space and fine space ![изображение.png](https://archive.blender.org/developer/F13984070/изображение.png) So the formula for full character space shold look like: Character_width + kerning*A + spacing*B Another approach is to count word spacing as addend. So initially we will have 0 addition to word spacing, and if we increase that number, there will appear and additional space after each group of non-space visible characters. So if we want to use word spacing, we should take whole sum of spaces between words: kerning, spacing, spaces, tabs and multiply it to our coefficient. Or we should count as word all, that is not space between word. So in case [lettters+space+digits+space+tab+tab+tab+letters] the part with [ tab tab] will be counted as word. So eventually we should decide, what is addend and what is multiplier, stop to use meters for multipliers, stop to subtract addends. For me is the most sane way is: 1. use multiplier for character width only for ability to overlap characters, initially 1 2. use addends for kerning and spacing (lets assume we will have ability to change individual character kerning), initially 0 3.use addend to word spacing, initially 0 4. count space as regular character with it width.

Harley Acheson commented

2022-12-01 16:44:14 +01:00

@Vyach - But why space have zero width? It is character. And it should have width...

Space is a character and it does have width, but you tell it to move in a negative direction by giving it a negative advance when you set Character spacing to zero, which is what your example does.

Lets recap first:

Neither of these Spacing settings affect the "width" of any character. They affect the "advance", which is the amount of space from one character to the next, so they affect the placement of following characters.

Setting Word Spacing affects only the regular space character (currently not other types of spaces like thinspace, hairspace, em space, en space, etc). It changes the advance of the space character by multiplying its usual advance by the "word spacing" value. Therefore at one you get a regular advance, while at zero it has zero.

Setting Character Spacing affects all characters, including the space character. It changes each character's advance by adding the same value to each. When set to 1 the spacing is normal. But at zero each character is having the same value subtracted that is about equal to the width of an "e".

Each of these settings is useful and normal with the existing rules. Word spacing is working correctly and Character spacing is working as you'd want it to. Importantly, you would not want to change "character spacing" and not have it affect the space character. It does and has to, otherwise it would be wrong, look funny, and people would rightly complain.

The problem here is that you are setting BOTH of these things to zero.

When both are set to zero you are saying that the space character should have zero advance AND that all characters (including space) should have a large value subtracted from them. Your space ends up with a negative advance about the width of an "e". It is working as designed and you are getting what you request for those values. If we try to add some clamping or change of rules for the behavior for only when both of these settings are set near their lower bound, then the normal usage of these settings will break.

> @Vyach - But why space have zero width? It is character. And it should have width... Space is a character and **it does have width**, but you tell it to move in a negative direction by giving it a negative advance when you set Character spacing to **zero**, which is what your example does. Lets recap first: Neither of these Spacing settings affect the "width" of any character. They affect the "advance", which is the amount of space from one character to the next, so they affect the *placement* of following characters. Setting `Word Spacing` affects only the regular space character (currently not other types of spaces like thinspace, hairspace, em space, en space, etc). It changes the advance of the space character by multiplying its usual advance by the "word spacing" value. Therefore at one you get a regular advance, while at zero it has zero. Setting `Character Spacing` affects all characters, *including the space character*. It changes each character's advance by adding the same value to each. When set to 1 the spacing is normal. But at zero each character is having the same value subtracted that is about equal to the width of an "e". Each of these settings is useful and normal with the existing rules. Word spacing is working correctly and Character spacing is working as you'd want it to. Importantly, you would not want to change "character spacing" and not have it affect the space character. It does and has to, otherwise it would be wrong, look funny, and people would rightly complain. The problem here is that you are setting **BOTH** of these things to zero. When **both** are set to zero you are saying that the space character should have zero advance AND that all characters (including space) should have a large value subtracted from them. Your space ends up with a negative advance about the width of an "e". It is working as designed and you are getting what you request for those values. If we try to add some clamping or change of rules for the behavior for only when both of these settings are set near their lower bound, then the normal usage of these settings will break.

Harley Acheson commented

2022-12-01 17:34:13 +01:00

Another way to show that this is only Character Spacing. Don't touch Word Spacing at all, leave it always at 1.

Now swap your space character for a thinspace - U+2009, " ". Change only Character Spacing and notice it behaves consistently along the range of values, but at 0.0 still leaves you with a similar result to this complaint.

This might be less confusing if the Character spacing lower bound showed as "-0.5" instead of zero, normal was instead shown as "0", and the label said something like "Additional character spacing (in em)". Then this would then be exposed to users like CSS letter-spacing . This is just made confusing by our desire for 1 to be normal, which means our "0" here is an arbitrarily-chosen negative value.

Another way to show that this is only `Character Spacing`. Don't touch `Word Spacing` at all, leave it always at 1. Now swap your space character for a `thinspace` - U+2009, " ". Change only `Character Spacing` and notice it behaves consistently along the range of values, but at 0.0 still leaves you with a similar result to this complaint. This might be less confusing if the Character spacing lower bound showed as "-0.5" instead of zero, normal was instead shown as "0", and the label said something like "Additional character spacing (in em)". Then this would then be exposed to users like [CSS letter-spacing ](https://developer.mozilla.org/en-US/docs/Web/CSS/letter-spacing). This is just made confusing by our desire for 1 to be normal, which means our "0" here is an arbitrarily-chosen negative value.

Vyacheslav Kobozev commented

2022-12-01 20:23:16 +01:00

@Harley

Space is a character and it does have width

by design of font or by design of Blender/library?

Setting Word Spacing affects only the regular space character
Setting Character Spacing affects all characters, including the space character

So we have conflict with character size and space size.
As I said, any space character should have width.
And word space should be determined smarter way, not just «only regular space character»

And what kind of size characters have?
In case of character space=0 they have negative order
Look at examples!

@Harley > Space is a character and it does have width by design of font or by design of Blender/library? >Setting Word Spacing affects only the regular space character >Setting Character Spacing affects all characters, including the space character So we have conflict with character size and space size. As I said, any space character should have width. And word space should be determined smarter way, not just «only regular space character» And what kind of size characters have? In case of character space=0 they have negative order Look at examples! ![изображение.png](https://archive.blender.org/developer/F13984439/изображение.png) ![изображение.png](https://archive.blender.org/developer/F13984442/изображение.png) ![изображение.png](https://archive.blender.org/developer/F13984447/изображение.png)

Harley Acheson commented

2022-12-01 20:40:39 +01:00

@Vyach -

Space is a character and it does have width

by design of font or by design of Blender/library?

Space characters always have a positive advance, otherwise they wouldn't separate words. This by design of the font, design of Blender, and design of all languages. Space characters take up space. Not sure what you are asking here.

So we have conflict with character size and space size.

No conflict, but two separate settings that affect different things in different ways, used for different purposes. One changes the advance of the space character, while the other makes all characters use more or less space. If you choose to do both you get both effects. They both have less useful effect at their lower bounds, and putting both to zero looks nonsensical, as it should.

As I said, any space character should have width.

All space characters have width. Well, except for zero width space (U+200B), zero width no-break space (U+FEFF), and Mongolian space mark (U+180E). It is just that Blender's "Word Spacing" doesn't change those. But "Character Spacing" will alter their width. In most languages we use the regular space character to separate words, and we generally don't use thinspace, em space, en space, etc to do so.

In case of character space=0 they have negative order. Look at examples!

Yes, I've explained this already. If you select 0 for Character Spacing you are subtracting 1/2 of an em square (about the width of an "e") from all characters. So a character with no advance will end up at -0.5 em, as requested.

> @Vyach - >> Space is a character and it does have width > by design of font or by design of Blender/library? Space characters always have a positive advance, otherwise they wouldn't separate words. This by design of the font, design of Blender, and design of all languages. Space characters take up space. Not sure what you are asking here. > So we have conflict with character size and space size. No conflict, but two separate settings that affect different things in different ways, used for different purposes. One changes the advance of the space character, while the other makes all characters use more or less space. If you choose to do both you get both effects. They both have less useful effect at their lower bounds, and putting both to zero looks nonsensical, as it should. > As I said, any space character should have width. All space characters have width. Well, except for zero width space (U+200B), zero width no-break space (U+FEFF), and Mongolian space mark (U+180E). It is just that Blender's "Word Spacing" doesn't change those. But "Character Spacing" will alter their width. In most languages we use the regular space character to separate words, and we generally don't use thinspace, em space, en space, etc to do so. > In case of character space=0 they have negative order. Look at examples! Yes, I've explained this already. If you select `0` for Character Spacing you are subtracting 1/2 of an `em square` (about the width of an "e") **from all characters**. So a character with no advance will end up at -0.5 em, as requested.

Vyacheslav Kobozev commented

2022-12-01 20:46:24 +01:00

So the issue is that character space is initially was set as 1m for character that have different widths.

It should set as initial multiplier 1 (character place width) + addend (spacing)
Thats how it work for text software.
Initial spacing (tracking) starts with 0 and you can do negative, if toy want to shift all characters to the same amount of width

Kerning, if you want to shift exact character

And sometimes character width multiplier. So zero multiplier + spacing produce monospace from any font for example or do not blow spacing for thin characters as «;» or «l»

So the issue is that character space is initially was set as 1m for character that have different widths. ![изображение.png](https://archive.blender.org/developer/F13984454/изображение.png) It should set as initial multiplier 1 (character place width) + addend (spacing) Thats how it work for text software. Initial spacing (tracking) starts with 0 and you can do negative, if toy want to shift all characters to the same amount of width ![изображение.png](https://archive.blender.org/developer/F13984469/изображение.png) Kerning, if you want to shift exact character ![изображение.png](https://archive.blender.org/developer/F13984476/изображение.png) And sometimes character width multiplier. So zero multiplier + spacing produce monospace from any font for example or do not blow spacing for thin characters as «;» or «l» ![изображение.png](https://archive.blender.org/developer/F13984486/изображение.png)

Harley Acheson commented

2022-12-01 20:53:56 +01:00

In Blender, as shown in your example, normal word spacing, but with zero character spacing. As mentioned this character spacing means a -0.5em advance change.

{F13984500,width=100%}

In css the same setting is "letter-spacing". Setting letter-spacing:-0.5em on the same "abc def" string gives the identical:

{F13984503,width=100%}

In Blender, as shown in your example, normal word spacing, but with zero character spacing. As mentioned this character spacing means a -0.5em advance change. {[F13984500](https://archive.blender.org/developer/F13984500/image.png),width=100%} In css the same setting is "letter-spacing". Setting `letter-spacing:-0.5em` on the same "abc def" string gives the identical: {[F13984503](https://archive.blender.org/developer/F13984503/image.png),width=100%}

Harley Acheson commented

2022-12-01 20:58:31 +01:00

@Vyach - So the issue is that character space is initially was set as 1m for character that have different widths.

Nope. Ignore the "m" after it. A setting of "1" means "do not add or subtract anything from the character spacing". 2 is "add 1/2 em to all characters". 0 is "subtract 1/2 em from all characters".

It should set as initial multiplier 1 (character place width) + addend (spacing)
Thats how it work for text software.

Nope. Tracking is never a multiplier. Tracking is always the same value added to every character, regardless of width.

Initial spacing (tracking) starts with 0 and you can do negative, if toy want to shift all characters to the same amount of width

Ours is the same, just that the normal position - shown in other programs as zero - is shown in Blender as 1. But setting less than that is negative.

> @Vyach - So the issue is that character space is initially was set as 1m for character that have different widths. Nope. Ignore the "m" after it. A setting of "1" means "do not add or subtract anything from the character spacing". 2 is "add 1/2 em to all characters". 0 is "subtract 1/2 em from all characters". > It should set as initial multiplier 1 (character place width) + addend (spacing) > Thats how it work for text software. Nope. Tracking is never a multiplier. Tracking is always the same value added to every character, regardless of width. > Initial spacing (tracking) starts with 0 and you can do negative, if toy want to shift all characters to the same amount of width Ours is the same, just that the normal position - shown in other programs as zero - is shown in Blender as 1. But setting less than that is negative.

Vyacheslav Kobozev commented

2022-12-02 00:38:40 +01:00

In #102593#1454177, @Harley wrote:

@Vyach - So the issue is that character space is initially was set as 1m for character that have different widths.

Nope. Ignore the "m" after it. A setting of "1" means "do not add or subtract anything from the character spacing". 2 is "add 1/2 em to all characters". 0 is "subtract 1/2 em from all characters".

If there is nothing to add or sibstruct, it is zero and nothing else.
If we add or subtract em, it should be reflected accordingly.
AFAIK 1/2em is 1ex. So let`s use +1ex for add and -1ex to subtract.

It should set as initial multiplier 1 (character place width) + addend (spacing)
Thats how it work for text software.

Nope. Tracking is never a multiplier. Tracking is always the same value added to every character, regardless of width.

Correct, sorry for confusing description: tracking and kerning are separate addends (common and individual)
And there can be separate multiplier of character-place width.

Ours is the same, just that the normal position - shown in other programs as zero - is shown in Blender as 1. But setting less than that is negative.

So let`s get rid of this confusing thing. and «m» too. em or ex please. Zero is zero.

> In #102593#1454177, @Harley wrote: >> @Vyach - So the issue is that character space is initially was set as 1m for character that have different widths. > > Nope. Ignore the "m" after it. A setting of "1" means "do not add or subtract anything from the character spacing". 2 is "add 1/2 em to all characters". 0 is "subtract 1/2 em from all characters". If there is nothing to add or sibstruct, it is zero and nothing else. If we add or subtract em, it should be reflected accordingly. AFAIK 1/2em is 1ex. So let`s use +1ex for add and -1ex to subtract. >> It should set as initial multiplier 1 (character place width) + addend (spacing) >> Thats how it work for text software. > Nope. Tracking is never a multiplier. Tracking is always the same value added to every character, regardless of width. Correct, sorry for confusing description: tracking and kerning are separate addends (common and individual) And there can be separate multiplier of character-place width. > Ours is the same, just that the normal position - shown in other programs as zero - is shown in Blender as 1. But setting less than that is negative. So let`s get rid of this confusing thing. and «m» too. em or ex please. Zero is zero.

Harley Acheson commented

2022-12-02 01:04:26 +01:00

@Vyach - If we add or subtract em, it should be reflected accordingly.

Yes, the range of values you select from is confusing, misleading, and should be improved. I plan on doing so fairly soon, but not right away.

AFAIK 1/2em is 1ex. So let`s use +1ex for add and -1ex to subtract.

No, we wouldn't use x-height as a measurement, as that differs too much between fonts in ways that most users don't realize. Both letter-spacing and word-spacing would just use portions of an "em". With both the default value would be zero and you could make either positive or negative. Basically this would align with CSS "line-spacing" and "word-spacing"

So let`s get rid of this confusing thing. and «m» too. em or ex please. Zero is zero.

Again, it can be improved and I plan to do so.

and «m» too.

That, by itself, would be a valid bug report. I might file one myself for that.

Otherwise his is just a feature request resulting in confusing caused by some confusing settings.

> @Vyach - If we add or subtract em, it should be reflected accordingly. Yes, the range of values you select from is confusing, misleading, and should be improved. I plan on doing so fairly soon, but not right away. > AFAIK 1/2em is 1ex. So let`s use +1ex for add and -1ex to subtract. No, we wouldn't use x-height as a measurement, as that differs too much between fonts in ways that most users don't realize. Both letter-spacing and word-spacing would just use portions of an "em". With both the default value would be zero and you could make either positive or negative. Basically this would align with CSS "line-spacing" and "word-spacing" > So let`s get rid of this confusing thing. and «m» too. em or ex please. Zero is zero. Again, it can be improved and I plan to do so. > and «m» too. That, by itself, would be a valid bug report. I might file one myself for that. Otherwise his is just a feature request resulting in confusing caused by some confusing settings.

Vyacheslav Kobozev commented

2022-12-02 03:05:17 +01:00

In #102593#1454223, @Harley wrote:

@Vyach - If we add or subtract em, it should be reflected accordingly.

Okay, thanks for replies and inderstanding the situation.

Yes, character-space width multilier now looks as feature request, I agree.

> In #102593#1454223, @Harley wrote: >> @Vyach - If we add or subtract em, it should be reflected accordingly. Okay, thanks for replies and inderstanding the situation. Yes, character-space width multilier now looks as feature request, I agree.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry nodes/Text Object: negative space character width #102593