Larger versions for symbols.

[Leartin]

The Icons for pax, mail, goods, electricity, city and the season indicator in all paksets were made to fit the standard font size. Same is true for all the waytype-icons indicating which types of vehicle can service a stop.
If one increases the font size, they simply become too small in comparison and are likely unreadable.

Of course, just increasing the icon sizes for everyone is not an option - if you play on low-resolution they would be way too big.

I think there are 3 possible ways to tackle this:
1) Outsource those icons to themes. This way, a large theme could bring larger icons that fit the larger font the theme would expect. However, this would be a bit chaotic for the waytype-icons, since different paksets use the various rail-variations differently, and even for pax/post/freight, there are no icons consistent through all paksets, and chances are nobody would want to edit all the station-icons that incorporate them.
(an exception would be the icons for different kinds of notifications. Since they are only one graphic as-is, they need to be seperated anyway, and since they are completely independent of the pakset they should be moved to themes in any case)

2) Allow for various sizes to be provided. So besides the regular symbol, there could be a graphic defined to be used whenever the font size is of a certain size. Eg:

Code Select Expand

Obj=symbol
name=Post
Image[0]=> ./images/symbols.0.1
Image[15]=> ./images/symbols.1.1
Image[19]=> ./images/symbols.2.1
Such that the existing image with the largest number lower or equal font size is used. This wouldn't work for season indicators, so it's not how it could be done - it's just to bring the point across.
[Note: If something like this was done, perhaps the same could be done for icons in menus, such that they can have dedicated larger graphics rather than the game upscaling them]

3) Just upscale. Double the size for font size 18 or above. Not pretty nor flexible, but would solve the issue at hand and even for older paksets. Plus, it wouldn't exactly clash with the second option since it could act as a fallback.

[Andarix]

Why not create a large icon by default. They can then also be zoomed in smaller if the icon size is set via theme.

[Leartin]

While making a larger graphic smaller usually yields better results than making a small graphic larger, they won't ever look as good as graphics designed for a specific size. However, that's regarding how pretty they are - for symbols, it's more important to be legible. If you scale down a graphic, you always lose information, therefore the symbol might no longer be legible. But if you design the symbol to be legible at the smaller scaled, you won't lose information when you upscale, so it's still legible. It just doesn't look good, which is secondary.

However, this is not about menu icons, but symbols. Those currently don't scale at all. If they were scalable in the same way as the menu icons are, perhaps it could indeed be up to the pakset designers whether they design larger symbols and downscale them or smaller symbols and upscale them. However, since they are so closely linked to the font size, which can change entirely independently of the theme, would a seperate setting really make sense?

EDIT: Also, I think the happy and sad face in the station window need to be replaced by graphics as well. Currently, they are glyphs that don't exist in most fonts - eg. Arial, Calibri,...

[Vladki]

EDIT: Also, I think the happy and sad face in the station window need to be replaced by graphics as well. Currently, they are glyphs that don't exist in most fonts - eg. Arial, Calibri,...

I would go the other way round - use as many emojis as possible. With the option to select special font for these (and providing one with all necessary symbols, or picking some that is preinstalled at least on Win/Linux/Mac). There are emojis not only for smileys, but also for transport modes: https://unicode.org/emoji/charts/full-emoji-list.html#transport-ground

[RESTRICTED ACCOUNT]

Also, I think the happy and sad face in the station window need to be replaced by graphics as well. Currently, they are glyphs that don't exist in most fonts - eg. Arial, Calibri,...

I initially tried to implement it in Extended. It also considered porting to standard. The initial proposal can be ported to standard by simply removing the "Too slow" indication.
If the pakset does not have those symbols, the old display is used.

(The patch eventually got a lot of feedback and ideas, and as a result, it was drastically transformed and implemented in extended.)


I spent a lot of time but eventually gave up because the standard compilation didn't work properly.
I'll try compiling again when extended gets more code out of the standard and the differences are smaller, which may take years or I'm dead.
I asked a Japanese BBS about the patch's implementation of the standard, but unfortunately no one showed any interest(´・ω・｀)
I don't think it's difficult, so I think anyone interested can try it.


I think this commit on this branch is helpful.
Ignore gui/convoi_detail_t.cc and skinverwaltung_t::railway_signal things.
Later commits added tooltips around the symbol.

The icon I made with the sample is pasted on this thread. The copyright of those symbols is waived. Feel free to use it.

EDIT: btw, emoji is Japanese word(絵文字) and I didn't know that they are called emoji. 

[Leartin]

I would go the other way round - use as many emojis as possible.

I'd agree if I had an easy way to create a custom pixelated emoji font, of if Simutrans would render Text with aliasing. Since both is not the case, I'm not sure there is any emoji font aut there that would look reasonably good, especially with small fonts.

[prissi]

Almost all emojis are on the extended unicode code pages and they are colored. Both are not supported by freetype fonts in simutrans. Just adding this for an emoji seems overkill. A symbol is much more portable choice, and could fit simutrans better.

It would be easy to scale the few images on the occasion with a routine display_fit_img_to_height() similar to display_fit_img_to_width().

One just need to identify all places.

In principle a theme could define alternative graphics, the theme reader just reds them as normal pak files. So they should register with the symbol images.

Unfortunately due to the new display system, the patch is not so helpful. But it is not difficult. Also there were symbols in the past, since there are still the smily and unhappy smily in image 4.0 and 4.1 of ls-symbols in pak64.So readding them is relatively straight forward.