text/v2: add a way to get the origin position of a glyph image

hajimehoshi / ebiten

Ebitengine - A dead simple 2D game engine for Go

https://ebitengine.org

Apache License 2.0

11.1k stars 665 forks source link

text/v2: add a way to get the origin position of a glyph image #3070

Closed hajimehoshi closed 3 months ago

hajimehoshi commented 3 months ago

Operating System

[ ] Windows
[ ] macOS
[ ] Linux
[ ] FreeBSD
[ ] OpenBSD
[ ] Android
[ ] iOS
[ ] Nintendo Switch
[ ] PlayStation 5
[ ] Xbox
[ ] Web Browsers

What feature would you like to be added?

Now there is no way to get the origin position of the glyph. For example, it is impossible to layout glyphs along with a curved line as if the baseline is bended. (This was what @setanarut was trying to do)

Possible solusions are:

Adjusting the glyph image so that (0, 0) matches the origin position
Adding new members to Glyph struct

Why is this needed?

No response

hajimehoshi commented 3 months ago

Adjusting the glyph image so that (0, 0) matches the origin position

When a glyph image is shifted by some subpixels, (0, 0) doesn't represent the exact origin position. Then, probably adding new members to Glyph would be the only way to go.

tinne26 commented 3 months ago

In etxt (0, 0) is always the origin position of the glyph. This is why I was requesting custom bounds in images in the past, so you can keep the side bearings there and draw directly at the expected position. So, that's doable, and I actually thought you were doing the same in text/v2?

Also, I don't know what you mean by "When a glyph image is shifted by some subpixels, (0, 0) doesn't represent the exact origin position". Subpixels should only be used on subpixel antialiasing, which we are not doing, and position quantization, which we are doing, but results in different glyph masks and images.

hajimehoshi commented 3 months ago

Also, I don't know what you mean by "When a glyph image is shifted by some subpixels, (0, 0) doesn't represent the exact origin position". Subpixels should only be used on subpixel antialiasing, which we are not doing, and position quantization, which we are doing, but results in different glyph masks and images.

With the nearest filter, we cannot use the float rendering position (though GeoM takes float64 values). (0, 0) can never represent the exact origin position when the glyph was shifted by (0.5, 0) for example.

hajimehoshi commented 3 months ago

Subpixels should only be used on subpixel antialiasing, which we are not doing

Glyphs are shifted by subpixels by default. So we are doing it.

hajimehoshi commented 3 months ago

@setanarut I've added OriginX and OriginY to Glyph. Please try

go get github.com/hajimehoshi/ebiten/v2@a3d084e2de1cb619b2636dad3b1c82573e4f1034

Here are the examples to render origin positions:

setanarut commented 3 months ago

thanks i will try