Max-Max, you state that tte buttons shouldn't contain a pattern because they are to be resized. Can't you use them like a pattern, putting them next to each other instead of stretching them? I don't care too much about the buttons, because a pattern is distracting to the eye when text is involved. But it would be nice to have for scrollbars, which should have a similar 3x3 pattern for scaling. Arrow-buttons next to the scrollbars, too.
If you resize an GUI element in no-pattern-size increments, the pattern will only be half displayed in the end, not aligning up witht he border pieces. Let me illustrate with an example:
The first image is the 3 parts for a button; left middle and right.
In the second image the theme manager has concatenate them into one image and then divide it in a 3x3 grid (well, I have already come up with a better solution. I don't know if it will make it into the next patch although, so we stick to this meanwhile).
Lets assume we increase the width and height one pixel. Because the pattern is repeated every second pixel (2x2 pattern), only half the pattern will be displayed against the edge pieces; picture three.
To solve this my plan is to let the designer tell Simutrans the pattern size. Simutrans will then snap all scaling in multiples of the pattern size to ensure that full pattern is always displayed. But this will be further down the road, for now it will be misaligned if scaled.
Is it planned to enable graphics in places where no graphics were used before, like titlebar, windowborder,... So that one could create a more rounded, modern look.
O'boy, do I have plans
First of all I need to get the theme structure in place and the first goal is to theme the GUI elements already skinned. My intention is to have virtually everything themed but this also requires a new GUI code structure. This will be the second step (new GUI code). Then we can start to do some serious themes
About Fonts... I looked into the Simutrans Font and it wouldn't be too hard to resize/recreate it at 1.5 or 2x scale. But that's only true for the latin alphabet, at least for me, because with kanji I just don't know what is intended to be round, straight,... Wouldn't the same problem arise with any font if it's pak dependant? While big names like Deja Vu might contain all the signs needed, most just don't. While I'd be eager to design my own bitmap font for Simutrans including multiple sizes and every œ, ý , ç and ê, it would be hard (but possible) to include russian/cyrillic, and impossible to do kanji. How could such a problem be solved?
I haven't looked so much at the font system yet, but as to my knowledge it uses both unicode and ASCII encoding.
If a glyph (an image used to build a character) is missing, Simutrans shows a default glyph in its place. The unicode fonts are capable of displaying virtually any character set. Well, traditional Chinese also used in Taiwan, Hong Kong and Macau use BIG5 encoding but the Kangxi radicals (214 Chinese characters) are reserved in the unicode character map U+2F00-2FDF.
If a font becomes popular any one can add the missing glyphs to the unicode font.
At my former work I wrote a couple of True Type to bitmap font converters. Due to copyrights and ownerships I can't publish them. As a parallel project I'm writing a new converter that will allow you to convert a TTF to bitmap font in one single button push. If and when this tools becomes useful, a localised character set can be taken from another font to create a more complete unicode font to use with Simutrans.
A professional True Type font has separate fonts for different styles; Normal, Bold, Italic etc...
When it comes to Simutrans we use the normal styled font and creates shadowed and outlined styles in the drawing process. I think this work quite well except for the outlined font. Maybe it is enough to adjust the algorithm...
In the discussions we have touched the subject of having two font sizes, one normal and one bigger for headlines etc...
But for now, we stick to what we have.