Transport Tycoon Forums

By and large the current discussion around fonts has been valid and informative. Unfortunately it has also involved the activity of one particular nfo coder who happens to be one of the most productive and reliable coders on these forums. I will openly defend OzTransLtd in this matter. Yes, he pushes the limits, but then throughout history, people pushing limits got things done. Too often, when someone sought to try something new or different in both OTTD and TTDPatch, the response has been "impossible". This does not satisfy OzTransLtd. If he can't do something one way, he will try another. I'm not exactly sure as to why he felt a new font was required for Canadian Train Set (CanSet), but I can assure you his reasons must have seemed valid to him. However, I have yet to see anybody in this topic inquire of him in a constructive manner as why he felt there was a need for a new font. I have yet to see anybody in this topic inquire of him as to how or whether his font will support the glyphs required by foreign languages. Instead of jumping to conclusions and accusations, why doesn't someone simply politely ask him about his reasoning and how he intends to support the players who make up the diversity of this community? I can assure you that he wants the sets he works on to be playable by everybody. Why else would anyone want to compose code for a game?

DaleStan wrote: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?

Simple:

Engine pool: the map creator needs to select *two* newgrfs which are incompatible. E.g. it's a short-coming of the map creator who didn't consider cross-talk between newgrfs.
A newgrf with glyph replacement: the map creator selects *one* newgrf. It will break as soon as a player uses in his user settings a different font than this newgrf supports. E.g. a glyph replacement is bound to break in 100% of the cases with the choice of this single newgrf as different players DO have different fonts in usage.

Further, the player may have chosen a certain font for readability reasons - depriving him of this choice when logging in to a multiplayer server is just rude. IMO. such grf cannot be considered multiplayer safe.
EDIT: e.g. size etc. may be chosen for very valid reasons differently than the default. And afaik it is being worked on allowing even more flexibility in this respect.

planetmaker wrote: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.

Assuming that he reads this thread (he posted here), I might or might not succeed here in doing so. My worry is that not. And then the bug reports will not only reach him, but will pop up everywhere. Glyph replacing newgrfs is definitely not something which I would want to use on multiplayer servers for the reasons lined out above.

planetmaker wrote:Assuming that he reads this thread (he posted here), I might or might not succeed here in doing so. My worry is that not. And then the bug reports will not only reach him, but will pop up everywhere. Glyph replacing newgrfs is definitely not something which I would want to use on multiplayer servers for the reasons lined out above.

Will you be the one to ask him if he has addressed this concern? Perhaps he has included a parameter setting, but we don't know that yet.

wallyweb wrote:

planetmaker wrote:Assuming that he reads this thread (he posted here), I might or might not succeed here in doing so. My worry is that not. And then the bug reports will not only reach him, but will pop up everywhere. Glyph replacing newgrfs is definitely not something which I would want to use on multiplayer servers for the reasons lined out above.

Will you be the one to ask him if he has addressed this concern? Perhaps he has included a parameter setting, but we don't know that yet.

Why should I (or anyone else for that matter) go and grovel and beg to shed some light onto us un-enlightend people? I'm happy to listen, if the reasons which lead to that are explained, though.

But unless proven otherwise I hold up the position that a newgrf cannot accomodate different fonts at the same time unless it does a complete font replacement of all possible glyphs in all possibly languages (consider also right-to-left languages!) at different sizes concurrently, but distinctly different for different clients (I always consider the multiplayer-case across continents).

planetmaker wrote:Why should I (or anyone else for that matter) go and grovel and beg to shed some light onto us un-enlightend people?.

Asking a question or two in order to gain more information upon which to base a decision or confirm an opinion is not groveling and begging.

I'm happy to listen, if the reasons which lead to that are explained, though.

Those reasons will not be forthcoming unless you seek them out.

But unless proven otherwise I hold up the position that a newgrf cannot accomodate different fonts at the same time unless it does a complete font replacement of all possible glyphs in all possibly languages (consider also right-to-left languages!) at different sizes concurrently, but distinctly different for different clients (I always consider the multiplayer-case across continents).

I fully agree with that, but you have not stopped to consider whether or not this has been addressed. Perhaps OzTransLtd has done a complete job. My assessment is that he has the required talent. But, then again, perhaps he did abbreviate the process. We do not know this and never will until we ask him or simply wait around for the release. Would it not be better to ask him now before he commits his code just in case any shortcomings must be brought to his attention?

wallyweb wrote:My assessment is that he has the required talent. But, then again, perhaps he did abbreviate the process. We do not know this and never will until we ask him or simply wait around for the release. Would it not be better to ask him now before he commits his code just in case any shortcomings must be brought to his attention?

While he surely is a talented newgrf coder, I'm quite sure that neither TTDP nor OpenTTD allow per-client configuration of newgrfs for the simple reason that it's a first-class reason for desyncs.

EDIT: as this string discussion is a bit off-topic here (or at least became), maybe this could be split into a separate thread?

planetmaker wrote:EDIT: as this string discussion is a bit off-topic here (or at least became), maybe this could be split into a separate thread?

Better yet, as all of the questions seem to have been asked, why don't we wait to see if OzTransLtd has any comments?

Regarding OzTransLtd's plans to include a custom font in his NewGRF (also holds for anyone else who wants to do this). The font will always be overridable by another font in both OpenTTD and TTDPatch, so he can never be sure about the size of the font.
I make this claim on the following 'simple' assumption: OpenTTD and TTDPatch allow overriding of a glyph by another NewGRF or it will disallow this. In the former case you can load a NewGRF with glyphs that override OzTransLtd's NewGRF font and in the latter case you can load a NewGRF with overriding glyphs before OzTransLtd's NewGRF font effectively making OzTransLtd's NewGRF font unable to 'work'.

Given this information it would be unwise to assume things about the exact size of the font.

Even so, if you want to align things maybe there is a concept that can be used than forcing the 'tab' locations. With such a concept you can still have control over the looks while having support for differently sized fonts.

Could we try to keep this mostly on topic, planetmaker and wallyweb.
If OzTransLtd wants to explain his idea and how it works fine, however I don't feel arguing over how important this opinion is warranted.

[Edit] For multiplayer wouldn't it be better for force a true-type font, or inbuilt font, so that you know all clients will have the same font with all glyphs.
For the initial starting X coordinate of the string, you could put it after the sprite and workout the largest string scaling the window accordingly?

~ Lakie

Lakie wrote:[Edit] For multiplayer wouldn't it be better for force a true-type font, or inbuilt font, so that you know all clients will have the same font with all glyphs.

I doubt that there is one single font which has Cyrillic, traditional Chinese, simplified Chinese, Kanji, extended Latin, Thai, Arabic alphabet and whatever alphabets I forgot. Mind: each client can run a different language.

Ok, I extract the following information from this topic and my explorations:

1) SETXY (code 0x1f) has not been used in any newgrf ever. It has also never been used in any built-in text. So it perfectly fine to
1a) define it as TTDP only feature,
1b) let OTTD ignore it,
1c) let grfauthors disable their newgrf for OTTD if they want to use TTDP only features,
1d) discuss again about a new interpretation for non-default fonts and fontsizes when someone actually uses it.

2) SETX (code 0x01) is used for
2a) indenting when there is a big sprite in front of it,
2b) indenting of paragraphs in multiline texts,
2c) for aligning columns.
One could deal with those by
2a) Ignoring indenting of single line texts and instead start the text after the sprite,
2b) Allow indenting in multiline texts, but scale the specified number of pixels by the ratio of the widths of the character "A" in the used font and in the default font (both wrt. "normal size")
2c) Align columns using the broadest text and adding some defautl padding. (Note: The first column might be empty and could be distinguished from indenting by putting a space into it)

Though the stuff in 2) might not be that easy to implement.

It may not be the right design pattern for OpenTTD., but a huge number of people have spent the last 15 years of web design realising that presentation and content should be separable.

A web page can specify preferred font(s) for any suitable element in the DOM.

In the case of none of those fonts being available, most browsers (user agents) will default to an available system font.

In most user agents, the user is free to specify their preferred default font(s) and sizes.

In most user agents, the user can specify an alternative style sheet.

Most credible html/css developers and web designers do not expect nor try to precisely control the presentation on every device and in every context. We aim for a certain amount of control, and then cede the remainder to the device, user agent and/or user, allowing them to best determine their own needs.

The above is more or less factually established. It's the product of intensive, extensive debate involving many person hours of thought and argument. Tens of thousands of people have come to accept it as the preferred method for dealing with the problems of web design.

How does this relate to OpenTTD? If I've understood correctly, Rubidium's suggestion seems comparable. A grf indicates a preferred format for display, and OpenTTD acts on behalf of the user to try and ensure they can actually use the content (i.e. they can read it). I think that's a desirable solution.

However DaleStan makes an interesting point about respecting what grfs do. I think that's valid, and given that we work on OpenTTD for fun and for free it might be the more pragmatic and future-proof solution.

But then again it's a question of proper domain. As the player, I want to be sure I can use the interface on my device. I think the grf is content, and the interface is presentation, and I should be able to override the grf when it comes to presentation.

Sorry, long post. If I'd had more time, I'd have written something shorter.

andythenorth wrote: But then again it's a question of proper domain. As the player, I want to be sure I can use the interface on my device. I think the grf is content, and the interface is presentation, and I should be able to override the grf when it comes to presentation.

i think this is the important part of the post.

OpenTTD has the ability to use "static newgrf", which is there precisely for purely graphical interface changes, e.g. fonts.

for the problem at hand this would (imho) mean that if Oz wants to provide a canadian font, he is free to do so, but he should please do this as a separate newgrf which contains only the font (and thus can be used client-side as static newgrf). and in the rest of the grf he should not rely on this font being present (i.e. he cannot rely on font sizes and widths, he can also not check if the grf is present, because static grfs can not be used in these checks [nasty desync hazard])

that is why this discussion is happening, to introduce a system for aligning text that does not rely on font sizes, which may be different on each client joined to a network game.

A question ...
In many of the TTDX menus accessed via the toolbar, the menus are not resizable. What happens if the coder writes text that spans most of the width of the menu and then a player opts for a larger font than was used by the coder? Will the menus expand themselves accordingly?

wallyweb wrote:A question ...
In many of the TTDX menus accessed via the toolbar, the menus are not resizable. What happens if the coder writes text that spans most of the width of the menu and then a player opts for a larger font than was used by the coder? Will the menus expand themselves accordingly?

That is the final goal, yes, including growing menubars when using bigger icons. Note the difference between "final" and "already archieved"

note that this is not only a GRF problem, also translations have problems with fitting the text into the available space.

DaleStan wrote:Why can't you replace some of the glyphs?

You can, just as long as you use a language that already has all required glyphs available in the base graphics set.

EDIT: Or as long as your replacement grf provides all glyphs otherwise missing for the language you're using.
OpenGFX' font for instance supports much more languages than OpenTTD does while using the TTD graphics.

And now for an entirely new question:
What happens if OzTransLtd uses only code points from the Unicode private use area in his strings, and supplies glyphs for all the code points he uses?

Would OpenTTD display a bunch of square boxes? Or would it display OzTransLtd's glyphs?
And, more significantly, which is the correct behaviour?

In that case it /should/ use OzTransLtd's glyphs and the (O)TTD glyphs for all other characters. Again provided that there are glyphs available for all characters to be used in the game.

If it doesn't do that *I* consider that a bug, but an ottd dev could consider it a feature...


I'm unsure of the behaviour in case a language is used for which there no glyphs available for certain characters. In that case the game will switch to freetype mode, but obviously there's no font available with correct definitions for the private-use area. Ofcourse it could be a feature not to support the full unicode character set.


Correct behaviour? Making sure that at least the default game interface texts are fully readable in the language of choice has priority if you ask me. If a newgrf author wants to do some fancy-pants stuff, it has to do that within the game's limits. This can be one of those limits, as mixing two different typefaces isn't a proper solution either.


EDIT: as for the string offsets, I think implementing some sort of \t might be a nice feature. With a \t at the beginning of a line creating an offset and the text after each nth \t being aligned below one another automatically. The latter might be a bit difficult to implement, but would be rather nice though.

i.e. the string "text\ttext\ntexttexttext\ttext\n\ttexttext\ttext" would yield rather than the usual

It should use OzTransLtd's glyphs provided he did not use the area 'reserved' for OpenTTD magic glyphs which are also somewhere in the private area.