Text window text offset

[Dave Gilbert]

Hi all. I am using a custom text window and this is the result:



For some reason, the text offset is further down and to the left than it should be. Both the top/bottom and left/right images have the same amount of black space so theoretically the text should be right in the middle? Is there a way to offset the Y position of the text so it displays a few pixels higher?

Any help is appreciated!

-Dave

[Danvzare]

I know this isn't the type of solution you want. But you could just add more black space to the bottom image. That way it would appear as though the text is more centered. The only downside, is huge amounts of black space on the top and bottom of the text window.

I suggest you only do that though, if you can't find a proper solution.

[Dave Gilbert]

Yeah that's what I tried doing, but as you say it adds a LOT of extra black space which I don't like. If there's a way around it, I'd prefer doing it that way.

[Gurok]

Are you using a TrueType font? Bitmap font? Does anything change if you switch between the two? Hope it's not too much to ask, but if that doesn't change anything, could you try the same setup in 3.3?

[AnasAbdin]

In addition to what Gurok said, does the resolution of the custom text window elements have inconsistencies? (Corners are the same size, corners width = side width, corner height = top/bottom height)..

[Crimson Wizard]

For me it looks like AGS does not use (or not enough) middle vertical part of the text box. Probably because of the way it finds the "best" combination of border parts.

It would be a great help for diagnosing the problem if you could provide the resources you are using in this example, or at least sizes of all graphic items in the text box (including font).

[Dave Gilbert]

I've experimented with a bunch of different true type fonts in different sizes and the result is the same, but the font in the screenshot is called "Prospero Bold" and was imported at size 10.

And here are the asset images!

   

         

   

[Crimson Wizard]

One thing I can confirm is that when using TTF font the text is (or may be) printed lower than needed. I can clearly see that some letters are drawn over the bottom border.
This is reproduceable both in 3.3.5 and 3.4.0.6.
I am not sure about horizontal position, if I remember correctly, the text in the speech box is always left-aligned; but I would need to check the engine code to clarify this.

I could not get the font Dave uses, so I downloaded first random free font which looked distinct enough: http://www.webpagepublicity.com/free-fonts/c/CarawayBold.ttf

The reason is either AGS not using TTF data right, or font itself has incorrect ascent/descent property.

[Crimson Wizard]

I made a very simple test, and found out that AGS does not properly deduce the possible TTF height. It seem to not take font descent into account (that is - parts of letters that appear below font baseline).

Explanation of font values: http://i.stack.imgur.com/LwZJF.png

This is very easy to see with following script:

Code: ags

    String test_string = "I guess you want to know?";
    int hh = GetTextHeight(test_string, eFontFont3, System.ScreenWidth);

    DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
    ds.DrawingColor = Game.GetColorFromRGB(255, 255, 255);
    ds.DrawLine(0, 100, System.ScreenWidth, 100);
    ds.DrawLine(0, 100 + hh, System.ScreenWidth, 100 + hh);

    ds.DrawingColor = Game.GetColorFromRGB(255, 0, 0);
    ds.DrawString(20, 100, eFontFont3, test_string);
    ds.Release();

What this code does: it draws two white lines with red text in between. The white lines are separated by the font's height, at least they should be, but in reality some letters may appear partly beyond bottom line.
Probably AGS gets TTF's height as a difference between Ascent and Baseline, and not Ascent and Descent, as it should have.


EDIT: Scrapped the conclusion, I am not sure yet. Something is wrong either with font data, or library that reads it.
I need to experiment with the FreeType library code first.

EDIT2: It also could be that the font height is correct, but the text is drawn lower than expected. Still this mistake occurs somewhere in the FreeType library.

[Snarky]

Unfortunately, I've found, the ascender/descender metrics embedded in the font data are not very reliable as indicators of how far up or down the character glyphs can go. And I actually don't think that's really the purpose: they're more sort of reference lines for the "typical" ascender/descender. (But even for that use, the values are not set correctly for many fonts.) I don't know of any accessible values that define any kind of bounding box that characters are guaranteed to fit within. This is part of what makes font rendering so tricky and bug-prone. It could very well be that FreeType has bugs that are more evident in low-resolution contexts like AGS games than in most other applications.

[Danvzare]

This is part of what makes font rendering so tricky and bug-prone.

That actually explains a lot. Now I know why I've always had weird bugs when using fonts in all sorts of different applications.

[Dave Gilbert]

Huh. Interesting that this is the first time this issue has come up? Or is this something specific to TTF fonts?

That said, instead of playing around trying to fix out the font issue, a cheap fix would be to give the developer the ability to offset the x/y position of the text within the window? That's what I was hoping to do in the first place.

[Crimson Wizard]

I was going to try out a newer version of FreeType library, because AGS uses a very old version of it, to see if that may help.

As for the workaround, this is a viable idea as well, although I believe this offset property should be applied to Font rather than Text Window, because it will be drawn wrong anywhere in game.

[Snarky]

Or is this something specific to TTF fonts?

Yes, it is. These issues I've mentioned don't apply to bitmap fonts (although there are some other issues here with lack of control over how text is positioned inside the text frame that do).

[Crimson Wizard]

Wow. My plays with library code actually gave result. I was able to fix this error.

It appears that Allegro Font library does not tell REAL graphical height of the font, but the height you (AGS) asked it to use. Apparently it does not always match the size of letters, which could be smaller or higher, depending on how precise this font can scale up and down.
Frankly, this is quite weird...

To fix it I had to include FreeType library headers directly though, because I needed to know internal font structure.

[Dave Gilbert]

That's amazing, CW! Thanks so much. Will this be in the next update of 3.4?

[Crimson Wizard]

That's amazing, CW! Thanks so much. Will this be in the next update of 3.4?

That may be, if I figure out how to organize these changes properly... also I would need to test this out on some existing games which use TTF to be sure they still run okay.

[Dave Gilbert]

You're welcome to use mine once you get to that point. Just let me know.

[Crimson Wizard]

I have an update. Some of information here is rather little help for end-user, but I wanted to post it nevertheless, for history.

The Font library AGS uses (AlFont) is of an old version, and even probably modified by Chris Jones. The latter cannot be confirmed, because we do not have its original source code, but I found that our Linux port does not use standard AlFont library, but a modified source, with changes by Jochen Schleu (JJS), and his comments in the code mention that he had to reverse-engineer some modifications from the Windows version to make Linux port work same way.

(I vaguely remember reading some post by CJ himself about modified libraries, but I cannot find it right now.)


I updated the library to the latest version available in the Web. The immediate result was that the text offset error is gone.
Applying modifications by JJS on top of that version made error return.

This means that either old versions of this library had this behavior, or it was introduced by some CJ's changes (if there were any). (And Linux port simply simulates it for consistency).

However, another comment by JJS mentions that these changes are necessary because otherwise some font heights do not work well. This makes the situation more complicated. It is possible that there was another issue with some another font long ago, that required these changes.
I may try to look into JJS's bug tracker he had when he was working on his ports alone, to find any information on why these changes were deemed necessary.


In either case, I think updating to most recent library is the way to go anyway (that was actually done for Linux port). But we will have to make sure that TTF fonts work as expected in AGS after this. We will have to edit the library source code ourselves if something is not right, because apparently it is no longer maintained (also some things may be AGS-specific).



Anyway, here is an engine built with the newest library (based on 3.4.0.6):
http://www.mediafire.com/download/j2w18bxw1yzh7o0/acwin_3.4.0.6--alfont-new.zip
Remember, this is for test only!

Git branch:
https://github.com/ivan-mogilko/ags-refactoring/commits/libs--alfont

[Crimson Wizard]

Alright, the situation proved to be more complicated, but at least I clarified the reasons behind the changes mentioned above.

As I said in this thread before, the real (true type) fonts have Ascend and Descend parts (- upper and lower components, positioned above and below baseline). The problem with them is that if they are defined incorrectly (e.g. larger than required), the text line may appear being offset or vertically unaligned (although mathematically not being so), e.g. higher or lower than needed.
Similar thing may occur, if the font has particular letters (maybe even special characters) that have higher height, or have to be drawn higher or lower than most letters. Even though the game text may never have these characters, the font is still drawn having these in mind, which may cause text line look like it is shifted up or down.

The fonts library used by AGS had modifications that aligned font's Baseline with the bottom line of the user-defined height, making whole text being drawn slightly (or not slightly) lower than it logically should have be.

Why this was done? I cannot tell for certain, but there is one guess I have after experimenting with some games. It looks like most TTF fonts used in AGS games had increased Descend parameters (for the reasons I told above), and when they were drawn properly, having full font height in mind, most of the text appeared offset upwards. I guess someone (maybe it was Chris Jones) simply removed Descend parameter from calculations, thus fixing alignments for these fonts.

This worked well, until people started using TTF fonts with more explicit Descend usage, like the font Dave uses in his game. AGS simply draws lower parts of letters "outside" text bounds.



Now, this is real problem, because if I return the default fonts library behavior, some of the fonts will appear unaligned (this will have most effect when text is vertically aligned to center or bottom).


The only solution I see now is to add some per-font options that would control how the particular font is drawn.
For example:
- Font's height only counts Ascender (upper part). This will be backwards-compatible too.
- Font's height counts both Ascender and Descender.