SSD1322 Display Component Fonts

[canary_wharfe]

Will someone knowledgeable with the SSD1322 buffered component please clarify how the 4 fonts available in the Flowcode component are made available?
To be precise, are the 4 fonts simply for Flowcode simulation or do these fonts selections get compiled and control the actual fonts seen on the real OLED display? If the latter, whereabouts does this font creation process take place because my reading of the way this display works is that the fonts are effectively bitmaps and glyphs that at some point must get created from c code that creates an array or something that can be understood by the driver chip? There are some resources on the web where people are using Python scripts to parse and convert bitmaps and so on but other than this the entire font thing in the SSD1322 is a mystery to me.
My reason for asking is to determine whether it would be feasible to create my own font within the Flowcode environment. Of course if the 4 fonts referred to above are only for simulation then my questions are basically invalid. Any help appreciated.

[chipfryer27]

Hi

In component properties you can set how many fonts you wish (1 to 4) and their properties (0 - 3)

Then in the component macro you can choose which font you wish to use (0 to 3).

How the fonts are created would need Matrix to explain.

Regards

PS
Sorry, forgot to say that it works in Hardware as well as simulation

[BenR]

Hello,

Designing your own font is possible. You would effectively open the font component source from here. Add your font data to the ev property macro and then export and you will overrode the local font component used by the glcds.

https://www.flowcode.co.uk/wiki/index.p ... l_Library)

If you wanta specific font adding then I can maybe help with this. The fonts should be in the same format as arduino so you can maybe borrow data from an arduino font if required.

[canary_wharfe]

Thanks for the reply Ben. Do you have a url to an arduino fonts library by any chance? Had a look online but couldn't see any specific libraries, just a few fonts people had developed plus an arduino font generator which could be the way to go. However, there doesn't seem like any point reinventing the wheel so to speak if there's a library with examples and I might be able to find one that is close or matches what I'm looking for. Otherwise I could try playing with the font generator.

[canary_wharfe]

Chipfreyer27
Thanks for confirming the fonts are hardware specific and not just simulation based.

[canary_wharfe]

One further question. By font do you mean a single character as in 1, 2, 3, A. B. C or do you mean a design shape that is a family and applicable to all keyboard characters. Just wondering if I want the alphabet a to z in a particular style then we would need to create 26 individual arduino based fonts? Or is it one font in a particular style that can be applied to all 26 letters? Forgive my ignorance but I'm new to the entire GLCD tech having mostly used alpha numeric display previously.

[BenR]

Hello,

The font generator is the way to go. Each font can either be simply numeric, i.e. the numbers and some basic characters like : and -. Or the font can be a full set which generally includes ASCII characters 33 to 126.

See here for details of the included characters.
https://www.asciitable.com/

Each font is stored as a ROM array and can be fixed width or variable width. For variable width fonts there is a second ROM array containing the character pixel sizes. The ROM array data is populated inside the Font component Ev_Property macro based on the user font selection.

Hope this helps to give some additional information.

[canary_wharfe]

Right so each font can be a class or group or set (whichever teminology suits) of ascii characters. I'm I correct that the font generator (are we talking about the Mikroelektronica generator?) produces a bitmap of a single ascii character, So how do we combine all individual bitmaps in to one rom array so that we get a font data set that represents a group of ascii characters?
Also doesn't the amount of available ROM memory become a limiting factor in the process? Thank you again Ben for your patience with these questions.

[BenR]

Hello,

What font would you like to see and I'll see if I can document the process. Have you looked at the font component source code I pointed to as that might answer some of your questions. Yes the available ROM is a factor in font selection, usually the more pixels a font has in the X,Y axis the more data will be required to store it. Most of our fonts are therefore fairly small in terms of pixels but can be scaled up allowing for large fonts with small ROM overhead. The number by the font specifies the number of pixels per column, the larger the number the more ROM will be required to hold the font.

[canary_wharfe]

Hello Ben

Apologies for the delay in responding. Yes, I have reviewed the font component source code this morning and I am sort of getting the gist of it but I think the easiest way of getting to grips with it is to send the font I'm interested in as you suggested and then see if you can document the process.
I now have the font both in windows ttf and otf so I just need to convert the ttf to a bitmap with the MikroE font generator and post it here. As soon as I've got the generator tool I'll post the bitmap here. Thanks again. The MikroE generator is the correct tool right?