Font/Text Direction

[Hapax]

Spending a bit of time around the SFML text rendering recently, I have noticed that it's locked in to a horizontal direction.
After checking, it looks like FreeType does provide a 2-dimensional (vector) advance but SFML only uses the x component - even in Font/Glyph i.e. it's not just Text ignoring it, it's not available from Font so even a custom text renderer would not be able to use it. This makes Font useless for any non-horizontal direction text renderer.

My suggestion is - at least at first - expose the 2D advance in Font/Glyph allowing separate renderers to use all of the font.
(by simply changing advance to Vector2f instead of float)


Following that, Text could be expanded to also be able to handle it properly. This isn't required but is an option. However, exposing the 2D advance is required before that can even be considered. Of course, exposing it means that Text would need to adjusted to focus on just the one component but it's (obviously) as simple as making a reference, for example. Later, the 2D vector could be used, likely without much disruption to the legibility of the code.
e.g.

position += advance (both floats representing xs)

position += advance (both representing Vector2fs)

[FRex]

I wonder if that advance is ever used in normal LTR text too or just for column writing systems. FT docs don't say. sf::Text and sf::Font are also a bit iffy for RTL text (technically you can reverse your string before inputting it but that's a bit of a hack to make RTL be just LTR backwards), and has 0 shaping needed for cursive scripts (like HarfBuzz has).

[eXpl0it3r]

I believe SFML's font would need to adjust a lot more than just providing the horizontal advance when trying to support non-horizontal layouts.

Meaning, I'm not against changing this, just questioning if that's actually helpful.

Also I found this page and the graphics helpful to understand the terminology.

I wonder if that advance is ever used in normal LTR text too or just for column writing systems. FT docs don't say. sf::Text and sf::Font are also a bit iffy for RTL text (technically you can reverse your string before inputting it but that's a bit of a hack to make RTL be just LTR backwards), and has 0 shaping needed for cursive scripts (like HarfBuzz has).

Eventually, we'll be integrating HarfBuzz, but we'd first have to solve the dependency issue.

[FRex]

Adding vertical advance in sf::Font would unlock one thing: let users write own text code that does the vertical layout. I think this was the point Hapax made.

Same as now sf::Text has no per letter color, style, etc. but you can write a class that does, all using sf::Font, never dealing with FreeType yourself, or how in general you can make own drawables using vertex arrays or buffers.

Now if you want vertical text, you'd have to use FreeType 100% by yourself, just to get that y from advance that sf::Font doesn't expose (I'm not sure if anything else is missing or if just this one field will allow it).

[Hapax]

Indeed, FRex; that was basically the point I was making - that the small change to expose that value would allow custom text classes to make use of it instead of having to skip sf::Font altogether.

The follow-up suggestion of expanded sf::Text's ability would likely be included in sf::Text's overhaul to accommodate the eventual integration of HarfBuzz, if it's what it seems to be to me.

HarfBuzz, by the way, looks like an great thing to be including in SFML if it's possible. Everything being ASCII/English is often due to the simplicity of its use. Making it simple to use any Unicode - ASCII or not - makes it the same to use or not so might as well, right?

[eXpl0it3r]

If you want to PR that change, I'm sure we'd accept it for SFML 3.

My question was more, whether that on its own is really enough/useful if you do want to create your own custom text with vertical layout, or whether one would also need other adjustments.

[Hapax]

I think you may be right; more should be provided for a thorough access to proper vertical advancement.

Exposing just the vertical advance value may give enough information to lay out the text correctly in relation to itself but may be technically incorrect when needing the rest of the information. That is, for example, the vertical baseline (usually the centre).

Note that the change is really in sf::Glyph but would need modifications in its use. Definitely in sf::Text and also a little bit in sf::Font.

Its likely that the terminology wouldn't need to be changed to be 'correct' as I think it'll be understood. For example, "line spacing" still makes sense to be horizontal if it's vertical text.

I'm not sure I fully understand lsbDelta and rsbDelta but since it seems to be used by kerning, and kerning is also needed for vertical text, these could either be renamed as something else (presuming lsb is left-side-boundary or similar, it could be least-side-boundary and most-side-boundary, for example) or the vertical ones could be included in addition (tsbDelta and bsbDelta - top and bottom).