Hi,
yes, with sign I mean a single digit/letter/dot/etc.. Better would be to say glyph. The idea was to create a PNG file containing images of all needed glyphs (digits, letters, dots, etc.) you want to display on the screen. Then, as described above, you add to your Embedded Wizard project a bitmap resource and configure it with this prepared PNG file. Important here, you should configure the bitmap resource as multi-frame and alpha-only. Once the bitmap resource is available, you can select the individual image frames (the glyphs (digits/letter)) and colorize them at the runtime. This is described in my answer above. The following screenshot demonstrates how the design of such PNG file looks like. Here I used the Affinity Designer. You can use Photohop, etc.:
Anyway, you should consider that this bitmap approach requires a lot of memory. In the above screenshot the bitmap has 2222 x 300 pixel size. This means, 666 kB RAM or ROM when the bitmaps are stored uncrompressed. I don't know your target device, but I fear it will be too large ...
Well, in the few last weeks we have received several requests from other customers asking us to support fonts with > 256 pixel height. In the meantime we have a first adapted version of the Platform Package functionality allowing fonts with up to max. 1024 pixel height. Thus, instead of implementing the above described bitmap approach, you could use this new version and display the large text as usual by using fonts.
This adaptation requires Embedded Wizard 8.20. If you are using an older version, you will need to update to 8.20 first. If you are interesting in this version please contact us via support@embedded-wizard.de
Please note, that with this new adaptation you will eventually need to configure the graphics engine to reserve more memory for the glyph cache. For example, when you intend to display 512 pixel large fonts, the glyph cache should occupy at least 262 kB RAM. This cache memory is needed to store temporarily decompressed glyphs. Does your target system have so much RAM?
There is also another aspect. In your question you are speaking about font scaling. You want the text to flexibly adapt its size to the available area. The problem here is, the font information, (the glyphs) is rasterized already at the code generation time. In other words, you specify the desired font size in your project, and during code generation Embedded Wizard creates small bitmaps with all the signs already rasterized for the specified height. Changing the height at the runtime is not possible.
This limitation results from the lower-end position of the target systems, Embedded Wizard is intended for. Such target systems have usually few RAM and a poor CPU. An alternative approach of rasterizing the font glyphs at the runtime by using a font engine creates too much overweight.
Thus, rasterizing the fonts already at the code generation time avoids the usage of an additional font engine in the target system. On the other hand, the font height can't be changed. To have scalable fonts, you will need several font resources in your project configured with different sizes. For example, font #1: 512 pixel, font #2: 480 pixel, font #3: 450 pixel, and so far. In practice, the number of fonts depends on how fine you want the scaling to work. You can image, this will result in a lot of code occupied by fonts just to show the effect of font scaling ... The question here, is it worth?
An alternative approach would be to use a single font and scale it as image. Embedded Wizard provides a view intended to display a scaled image of a component. In this manner you could prepare the text in a component, which is larger than the screen and display this component scaled down. And again, this approach has also disadvantages. The first is, the scaling is CPU intensive. I don't know how often the screen content should refresh in your application but scaling large screen areas will be slow. The second aspect is the additional RAM needed for the scaled component. This depends on the size of the affected component and the used color format. For example, by 640x512 pixel large component and RGB565 color format, you would need additonal 655 kB RAM. Finally, with scaling the results may eventually appear a little bit blurred.
Well, the combination of very-very big fonts and additionally scaling the fonts will be difficult. Would it be possible to modify your GUI design to use only one large font and avoiud the scaling? If not, I would recomend to limit the font scaling effect to max. 2 fonts.
Best reagrds
Paul Banach
