Usage of X(Y) offset string codes in NewGRFs

[Rubidium]

Due to OpenTTD's support for right-to-left languages like Hebrew and Arabic support for the string codes for X(Y) offset, respectively 1 and 1F, is currently broken in trunk, i.e. the stable release still works fine. OpenTTD's development for supporting fonts with larger font size will also make X(Y) offset behave in an unwanted manner for NewGRF authors, for example the authors cannot just assume that the default font is 10 or 11 pixels high.

I would like to know in which cases manually changing the X(Y) offset is done and whether that is really needed or whether it is working around a 'flaw' in the drawing/aligning code.

For example we got the vehicle names. Some of these, e.g. the '2-8-8-2 Mallet' engine from NARS, use a X offset to prevent the text to be drawn over the sprite. To me aligning all vehicles in the "New Vehicle" window based on the width of the widest (visually) vehicle sprite seems the better solution. This is for example already be done in the 'Train Details' 'Information'-tab and the X offset from the vehicle name makes the gap between the sprite and name larger than for the names without X offset in them. The X offset also causes the centering code to place the vehicle name a bit off-center (half the offset).

I am asking this here because the easiest and most future proof method, primarily for larger fonts, seems to be scrubbing the X(Y) offset from the (NewGRF) strings and do a better job of handling longer vehicles in OpenTTD itself. The benefit of 'just' scrubbing the X(Y) offset from the strings is that you can keep them for TTDPatch compatability.

So, NewGRF authors, please tell me about more uses of X(Y) offsets in NewGRFs, why they are needed and whether there is a better solution for those strings that doesn't require X(Y) offsets.

[DJ Nekkid]

I bet the 2cc trainset is even worse here, as it have the flag, as well as the propultion icon... most names (that is, engines) usually contain 17 "space"'es before the actual text.

Code: Select all

-1 * 0  04 00 7F \b3 \b*3200 
	C3 9E "                 KZ2A"					00 // \b3200
....

[andythenorth]

If we're talking about the offsets here: http://wiki.ttdpatch.net/tiki-index.php ... ht=offsets

...I've never used them and can't think of a case where I would. In the case of the vehicle buy menu, I just truncate sprites.

Years of writing html and css makes me wary of specifying text positions absolutely and in pixel dimensions. This is just bad voodoo on my part in the case of apps that support positioning properly, but it's certainly not a sane thing to do in a web browser environment (and I guess it's become a habit).

cheers,

Andy

[DaleStan]

These codes are not (as I first thought) "offset from end of previous character", but rather "offset from beginning of first character".
This is a very important distinction. The implementation is such that TTD can have:
FOOSTRING_WITH_CHECKMARK_PTR = "{CHECKMARK}{OFFSET:12}<foostring>";
and
FOOSTRING_WITHOUT_CHECKMARK_PTR = FOOSTRING_WITH_CHECKMARK_PTR + 1;

Assuming it is implemented thus in OpenTTD, just subtract the X offset instead of adding.

[Rubidium]

DaleStan, it is not about where to use the X(Y) offset in TTD(Patch)/OpenTTD, but whether they are need to be supported for NewGRFs.

As I already told using the X offset (or a series of spaces) in the vehicle name will cause that string to be shown off-center in the vehicle news/preview offer windows. This behaviour seems an unwanted side effect of using X offset (or spaces) to align the text in the buy vehicle window.

Also the X offset might not be enough if someone makes a checkmark sprite that is twice as wide and twice as high, which seems to be sensible for the high DPI big screens that are getting more and more common. In OpenTTD this will probably lead to the removal of X(Y) offsets as they only lead to problems in a scalable user interface.

But to know whether it is feasible to just remove all support (and strip them from the strings) I need to know how and where it is used in NewGRFs.

[PikkaBird]

Nowhere except vehicle names, afaic.

[FooBar]

Nowhere except vehicle names, afaic.

And if the texts in the purchase window will respect the width of the widest preceding (vehicle) sprite, that can become "Nowhere. Period." IMO.
As I neither can think of another place where one would want a text offset.

[OzTrans]

String code 0x01 is used widely in Canadian sets. It is employed in purchase lists of vehicles, stations and objects to add additional information that line up (used as SetTab, as DaleStan mentioned rightly, 0x01 is not variable space). Purchase detail screens use 0x01 for indents of multi line information. Also, some lists use the length of the first entry to determine the width of the window; there 0x01 is used as hard space to give the window a width that accommodates all entries. Industry windows use string code 0x01 too.

String code 0x1F hasn't been used so far but there are experiments under way and if successful it will be used in purchase detail windows.

BTW, future Canadian sets will use their own Canadian Font (normal and large) to make sure the limited space available can be utilised to its fullest.

[Eddi]

Congratulations. Forcing a font on people is yet again a non-solution and denying the existence of a feature. what about people who use a 32768x18432 resolution on their 52" display? what about people who use russian or chinese or persian translations, you honestly want to include a full unicode font?

i can promise you, there will always be the next feature and the next flexibilisation in OpenTTD, and each one will horribly break your previous attempts of keeping everything as it was. If you continue down this path, people will simply stop using your GRFs.

[wallyweb]

Congratulations. Forcing a font on people is yet again a non-solution and denying the existence of a feature. what about people who use a 32768x18432 resolution on their 52" display? what about people who use russian or chinese or persian translations, you honestly want to include a full unicode font?

i can promise you, there will always be the next feature and the next flexibilisation in OpenTTD, and each one will horribly break your previous attempts of keeping everything as it was. If you continue down this path, people will simply stop using your GRFs.

Maybe he will include a parameter to turn it on or off. Then again maybe he won't.
Congratulations! You've turned a perfectly legitimate question into a flame.
Wouldn't it be more polite to ask first before blowing steam?

[DaleStan]

What about people who use russian or chinese or persian translations, you honestly want to include a full unicode font?

I assume that if his strings start using those characters, he will start including them in his font.

[Rubidium]

What about people who use russian or chinese or persian translations, you honestly want to include a full unicode font?

I assume that if his strings start using those characters, he will start including them in his font.

Once a non-(New)GRF font gets loaded (i.e. one via freetype) it overrides the (New)GRF font. Simply said this means that unless the NewGRF font has the appropriate glyphs for the language OpenTTD will favor the freetype font. OpenTTD automatically tries to find a font that supports the chosen language.

[Eddi]

Congratulations! You've turned a perfectly legitimate question into a flame.

be assured that there was a lot of thought going into that post, to reduce the possibility of a flamewar to a minimum.

now, to turn that into a more constructive argument.

try not to take this offensively, OzTransLtd, but you're quite obviously a control freak. that's not necessarily a bad thing, but in order to achieve a compromise in a community, one has to give up a certain level of control.

the current level of control is easily described, you can plan every bit of text accurately to the pixel. the question is, is that level of control actually needed to fulfil the targets of the positioning, and what level of control is the minimum required to achieve these goals.

so far, i have read out of these posts, that there are three different places that use these positioning codes.

1. preventing overlapping of sprites and text in the buy list
2. indenting multi-line text
3. aligning information in columns

thus, the question is, how can these things be encoded without giving absolute numbers in pixels, but enough hints that OpenTTD can recalculate the positioning by itself.

[andythenorth]

so far, i have read out of these posts, that there are three different places that use these positioning codes.

1. preventing overlapping of sprites and text in the buy list
2. indenting multi-line text
3. aligning information in columns

thus, the question is, how can these things be encoded without giving absolute numbers in pixels, but enough hints that OpenTTD can recalculate the positioning by itself.

Ahem, with one or more languages that off control over style and layout? Looking around, I'd say one or two people find html and css useful, but don't just take my word for it

However I have no opinion on whether being able to render html and css in OpenTTD is possible or desirable. I have no current use case that isn't covered by current control characters.

cheers,

Andy

[DaleStan]

Simply said this means that unless the NewGRF font has the appropriate glyphs for the language OpenTTD will favor the freetype font.

Now that's all sorts of bassackwards. Let me guess: Next you're going to favour the non-newgrf vehicles if the grf doesn't redefine all 256 of them.

Or maybe you're going to favour the non-newgrf cargos if the GRF doesn't redefine all thirty-two of them.

[planetmaker]

DaleStan, concerning the font, favouring a font which actually enables the user to use the interface of the game is preferable over one which leaves the user with many boxes (as the glyphs cannot be displayed) and renders the game already on the general interface not usable. Nothing like this will happen for what newgrfs do in general: providing game content, e.g. re-defining cargos, vehicles etc and their respective behaviour.

If you ever looked at the game what it looked like in the case of more than one missing glyphs - it's plain ugly and depending on the extend un-usable. So far you can join any server regardless of your language settings. Allowing the newgrf to force a font with missing glyphs on you is guaranteed to break this.

Thus, user interface and map / game itself should be two independent things; the (definition of the) user interface should not be subject to change to newgrfs loaded with a map. It's an entirely different thing, if you install them locally as static grfs as your preferred font settings (or menu icons or whatever).

[Rubidium]

Simply said this means that unless the NewGRF font has the appropriate glyphs for the language OpenTTD will favor the freetype font.

Now that's all sorts of bassackwards. Let me guess: Next you're going to favour the non-newgrf vehicles if the grf doesn't redefine all 256 of them.

So you want to mix fonts?

Does that really look better than if I were to override your individual font glyphs with a unified one for all the characters you use? Or is it that you can't stand that some features overrule NewGRF?

Even so I reckon that people (with high resolution screens) are going to favour fonts that can be made larger when the GUI properly supports that. Having the characters that a NewGRF forces at 10 pixels and the rest at 20 pixels will again look really odd, actually it would be seen as flawed behaviour thus we would have to favour overriding NewGRFs, especially if people start making monolithic NewGRFs instead of modular ones.

[DaleStan]

DaleStan, concerning the font, favouring a font which actually enables the user to use the interface of the game is preferable over one which leaves the user with many boxes (as the glyphs cannot be displayed) and renders the game already on the general interface not usable.

Whatever gave you the idea I was advocating this solution?

You can replace some of the vehicles. You can replace some of the cargos. You can replace some of the industries. You can replace some of the houses. Why can't you replace some of the glyphs?

So you want to mix fonts?

Please explain how this is different than mixing and matching e.g. train sets, which Open does allow.
Also, please explain how the user is forced to use a GRF that produces results that they find unsightly.

Do what the GRF says. Full stop. Then, if something appears that the user doesn't like, then you can blame the GRF. If it comes out ugly because you failed to do what the GRF says, then you have to find some way to fix it.

[planetmaker]

]Please explain how this is different than mixing and matching e.g. train sets, which Open does allow.
Also, please explain how the user is forced to use a GRF that produces results that they find unsightly.

Do what the GRF says. Full stop. Then, if something appears that the user doesn't like, then you can blame the GRF. If it comes out ugly because you failed to do what the GRF says, then you have to find some way to fix it.

The difference is simple really:

A trainset is for all players exactly the same. Required by GRFID and MD5 sum. It works and looks graphically and functionality-wise exactly the same. It's part of the map you download from a server so to say (though you have to have the newgrf files locally available).

Fonts on the other hand, are - rightfully I dare say - a user setting. Think of multiplayer servers. User A may use font A with language A, user B font A with language B, user C font C with language B, user D font D with language D. Things will therefor look very much differently on different computers, and you're bound to break GUI layouts and especially string representations, if you then have a grf overwrite your language settings or replace single glyphs within your font.
Otherwise it is something like "load a document in Word which contains cyrillic letters - so let's just change the interface of Word such that all menus are now shown in the Russian translation".

Therefore: the purpose of non-static newgrfs must not be to modify the user interface. That includes explicitly all sprites not drawn on the map and fonts.
I dare say I once included a newgrf in a map which replaced the buttons of the menu bars. I cannot say I liked the subsequent flaming and complaints by players I got. And they were right. It doesn't add to the game itself. Changing the fonts is exactly the same, just another flavour.

[DaleStan]

A trainset is for all players exactly the same.

I said "mixing and matching trainsets". Plural. Generally, when I use the plural form, that is because I mean to use the plural form.

OpenTTD allows attaching UKRS wagons behind USSet or DBSet[XL] locomotives. Why is this mixing and matching different having all capital letters in 10pt Arial and all lowercase ones in 12pt Courier?

I dare say I once included a newgrf in a map which replaced the buttons of the menu bars. I cannot say I liked the subsequent flaming and complaints by players I got. And they were right.

And if they start flaming OzTrans, they'd be less right? Or more right? Or... Anyway, why are you trying to protect OzTrans from this flaming that you think he'll get? If OzTrans wants to do something that you think is ill-advised, tell him so, but don't prevent him from doing it.