Feature Request: Vertical font gap

Started by JanetC, Thu 02/03/2017 17:10:28

Previous topic - Next topic

JanetC

Not sure if this has been asked before, but importing fonts into AGS is difficult because there is no way to change the vertical line gap and AGS seems to ignore the Ascent and Descent font settings. So I end up fiddling round with the Em size to get fonts with an acceptable vertical gap, which is not the way it is supposed to be used! I'd like to be able to either alter the vertical font gap within the editor, or for AGS to pay attention to the Ascent/Descent settings.

Crimson Wizard

#1
I already added vertical offset in this beta: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54431.0
Is the gap customization also required?

I suppose it won't be difficult to add.

The question is, whether it is really gap or font height that needs adjustment? For example, is the single line of text is correctly vertically centered?
Hmm, no that's a wrong question; let me think more about this...

Snarky

Quote from: Crimson Wizard on Thu 02/03/2017 18:06:55
I already added vertical offset in this beta: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54431.0
Is the gap customization also required?

Vertical offsetting won't change the line spacing, so if it's a problem, then yes.

JanetC

#3
Quote from: Snarky on Thu 02/03/2017 19:36:24
Quote from: Crimson Wizard on Thu 02/03/2017 18:06:55
I already added vertical offset in this beta: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54431.0
Is the gap customization also required?

Vertical offsetting won't change the line spacing, so if it's a problem, then yes.

I just tried the beta and found this same problem. Putting a negative vertical offset moved the text *up* but didn't make lines in a wrapped paragraph any closer together.

Crimson Wizard

#4
I was thinking maybe use overriding custom Ascent and Descent parameters instead of vertical offset and gap?

According to my previous research, AGS knows font height, but it zeroes Descent and adds its former value to ascent which makes total font height to stay about the same, thus aligning font's Baseline to the bottom of the text line (we may say it applies positive Y offset to the letters).

In other words AGS currently assumes that every font has Ascent but does not have Descent (D = 0).

Knowing that, I guess, it may be possible to apply custom Ascent and Descent parameters in following way:

The font height, used in all the line wrapping etc, will be instead calculated as (custom) A* + D*.
The text position will be offsetted by -(H - A*); where H is a known font height and A* is custom ascent.


EDIT: Hmmm, no I realized this will be very inconvenient for real users. Better stick to relative values, like vertical offset. I guess, to decrease vertical gap we need something like "text line height adjustment".

Gurok

[img]http://7d4iqnx.gif;rWRLUuw.gi

Snarky

It's usually called "line spacing" (or in professional typography, "leading" â€" pronounced LEDDing).

It might not be a bad idea to change how AGS calculates the default line spacing, but I think for users it is most intuitive and convenient to just define that each line is e.g. 30 pixels below the last (so neither in terms of ascenders/descenders nor as an adjustment to some unknown value calculated internally, but just an absolute number).

Crimson Wizard

#7
IIRC AGS does not calculate line spacing at all, it just draws line of font after line of font, advancing by font height.

EDIT: I clicked on post too early...

I wanted to say, that there is a question of whether line spacing a property of font or property of place where text is printed.

I do not see how font looks like in Janet's example, but if she is saying that gap is too large, probably there is something wrong with how font height, baseline, ascent, etc are defined (because AGS is not supposed to add any extra spacing). So this is rather about font property (the leading, as you say).


There may be an issue with defining absolute value between lines, because ascenders/descenders are messed up in the current library, and we cannot know for sure where the line visually appears (at which vertical position).
In other words, person types in 10 pixels, but visual result can be completely different.
That is why it may be better to rely on relative offsets for now.

Gurok

Quote from: Snarky on Fri 03/03/2017 14:47:08
It's usually called "line spacing" (or in professional typography, "leading" â€" pronounced LEDDing).

It might not be a bad idea to change how AGS calculates the default line spacing, but I think for users it is most intuitive and convenient to just define that each line is e.g. 30 pixels below the last (so neither in terms of ascenders/descenders nor as an adjustment to some unknown value calculated internally, but just an absolute number).

It is line-spacing when it's measured from baseline to baseline. Bonus points for being extra patronising with the pronunciation guide. We aren't specifying the total distance here, however, just an adjustment added between lines, in pixels.

I still recommend "vertical gap" or something similar. Thinking about it, "line gap" might be best.

CW: Some fonts specify things like ascenders/descenders incorrectly. I'm not saying it's a great solution, but that might be why Allegro uses height. I agree that a relative solution is best for now.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Snarky

#9
Quote from: Crimson Wizard on Fri 03/03/2017 15:16:30
IIRC AGS does not calculate line spacing at all, it just draws line of font after line of font, advancing by font height.

Well, at some level (presumably in the font rendering library) it is calculating line spacing. Fonts do not define an unambiguous default value for line spacing (or even a single value for "font height"): it's up to application developers to set it based on the font metrics (cf. https://grahamwideman.wikispaces.com/Font+Vertical+Metrics).

Quote from: Gurok on Fri 03/03/2017 16:07:10
It is line-spacing when it's measured from baseline to baseline. Bonus points for being extra patronising with the pronunciation guide. We aren't specifying the total distance here, however, just an adjustment added between lines, in pixels.

And I'm saying that specifying the total distance would be the best solution: that way you can adjust it at will, whether the default is too much or too little, in an intuitive way. Sorry you found the aside on pronunciation patronizing, it's just a counterintuitive pronunciation if you're not familiar with the jargon.

Crimson Wizard

#10
I was giving this some thinking, and I guess it may be possible to use absolute line spacing value, under condition that we add some way for user to know default font height and/or reset property to that value, otherwise user may find hard times trying to figure out where to begin at.
Perhaps adding readonly property of "Font Height" to the property panel may serve as a hint.

In the engine code, it does not make much difference whether we use absolute value or relative one, because the number of changes will be about same.

BTW, I found an interesting thing. in AGS TTF fonts return text height as a maximal height of all letters in font (literally, font height), but WFN fonts calculate maximal height of only letters used in the given string. Although WFN data format supports different heights for each character, that does not seem like something we have often (I am not even sure if existing WFN editors allow having characters of varying sizes). But this is something to consider... TBH I do not think that's a good idea to use such calculation when arranging text on screen, because it may result in lines of text being placed unevenly.

Danvzare

Quote from: Crimson Wizard on Mon 06/03/2017 09:12:10
(I am not even sure if existing WFN editors allow having characters of varying sizes)
Well I don't know about all WFN editors, but I'm fairly certain that Radiant's Font Editor allows for characters of varying height. And considering that editor is quite simple, I assume the others will allow it too.
Although like you said, not many WFN fonts do have varying height. It seems to be something we all naturally avoid for some reason. Probably because this feature of how the line heights are calculated based on which characters are used, can mess up how the font looks if you use varying heights.

Crimson Wizard

#12
I set up a test build over 3.4.1 that features custom font line spacing:
http://www.mediafire.com/file/rqoc5399t2o9zbg/AGS.Editor.3.4.1--linespacing.zip

It is supposed to work as before for older games.
It may work slightly different in new games, because line spacing no longer takes outlining pixels into account, but that is not final.

New properties are added to the Font:
* FontHeight - displays actual font height in pixels. This is a readonly property used for reference when you configure line spacing. For TTF fonts it almost always equal to PointSize, but for WFN it is calculated on its own (because WFN does not have point size parameter).
* LineSpacing - a size of step between two lines of text. Note that means distance between same points in two lines, e.g. between tops, bottoms, middle-line, etc, not distance between bottom of first line and top of the next one. Value = 0 means "use font height" (default). Setting value = font height will make no extra gap between lines. Set value > font height and you get extra gap, set value < font height, and text lines will overlap (which may also be an interesting effect).

EDIT: BTW, I just realized that outlining font's own LineSpacing is ignored when it is used for outlining... well, at least it supposed to.


New script functions:
* GetFontHeight() - returns font height, in pixels. This is useful if you need to calculate the size of exactly one line of text.
* GetFontLineSpacing() - self explanatory.

NOTE: the height of the text, returned by GetTextHeight, is actually calculated as:
Code: ags

int text_height = GetFontLineSpacing(font) * (num_lines - 1) + GetFontHeight(font);

SMF spam blocked by CleanTalk