Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[TonyZ]

Hi all,

Using Screen Editor, I'm able to add a TTF font using the Add Content feature. Then I'm able to add text in this custom font to the window. But when I export the project, only the font data block is created, not the font metric block. Am I missing something? Or do I have to create it manually?

Thanks,
Tony

[FTDI Community]

Hello,

If you ensure that the 'Compressed' option is unselected in the Content pane for your custom font the resulting output from your export will include the metric block data at the start of the file.

Best Regards,
FTDI Community

[TonyZ]

Hello,
Thank you for your reply.

I had actually already tried unchecking the "compressed" option and I can, indeed, see the metric block at the beginning of the output data. However, the
the starting address of RAMG always appears as 0,0,0,0 regardless of what I set it to in the screen editor. Is this a bug, or is the starting address irrelevant?

Note that I'm using SETFONT2, not SETFONT in my software.

Regards,
Tony

[FTDI Community]

Hi Tony,

In the output code file, you should see a definition corresponding to the 'address' field of the font properties. We used Consola here and so your definition may be different.


In the code below we set the start address defined as 1000 and so we got:

#define RAM_FONTS_CONSOLA 1000
static ft_uchar8_t fonts_consola[] = {
   /*('file properties: ', 'resolution ', 16, 'x', 22, 'format ', 'L8', 'stride ', 16)*/0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
[remainder of font data]


Then later at the bottom of the code you should see the following where the code is loaded into RAM_G beginning at location 1000
   Ft_Gpu_Hal_WrMem(phost,RAM_FONTS_CONSOLA, fonts_consola, sizeof(fonts_consola));
   Ft_Gpu_CoCmd_SetFont2(phost,0, 1000, 32);

Does this match what you see?

If you have some screenshots or further information you can also send it to our support address support1@ftdichip.com.

Best Regards, FTDI Community

[TonyZ]

Hi,

Yes, I do see the "1000" in both places as the RAMG starting address. I see this in the code that the Screen Editor exports. This is good!

But my question was that the "1000" does not appear in the font metric block itself. There is a field toward the end of the 148 byte font metric block
that is supposed to hold the RAMG starting address. And the Screen Editor ALWAYS outputs 0 for this field, regardless of the specified starting address you use in Screen Editor.
(note: if I use FNT_CVT to convert a font, then the RAMG starting address does, indeed, show correctly in the font metric block)

Perhaps this field is not used by SETFONT2, since the actual starting address is passed as an argument in the SETFONT2 function. I haven't tried running the code
with an actual LCD screen, so I'm not sure if this matters.

On a related issue, do you know the name of the built-in fonts (ROM fonts) for handles 16, and 26-29. They look like "Ariel", but I wasn't sure.

Thank you,
Tony

[FTDI Community]

Hello,

This sounds like an issue with EVE Screen Editor, I will pass this onto the development team as there is a new release due out soon.

As for the inbuilt fonts:

• 16-19 - CP437 from the FreeBSD distribution's console
• 20-25 - helvR08, etc from X11
• 26-29 - Roboto Regular

Best Regards,
FTDI Community

[TonyZ]

Thank you.
It would be great if the "Compressed" feature were also fixed in the next release. My custom fonts are using up more than half of my FLASH, and being able to compress
them and then using the INFLATE function would be great.

Regards,
Tony

[FTDI Community]

Hello,

The compressed option in ESE does output compressed files with which the INFLATE command can be used.

Best Regards,
FTDI Community

[TonyZ]

Hello,

But in your first reply in this thread, you instructed me to "insure that the compressed option is UNSELECTED". I understood this to mean that
there is a bug in Screen Editor, and that for custom fonts you should not use the compressed option. What am I missing?

Regards,
Tony

[FTDI Community]

Hello,

This is because you were looking to obtain the font metric block data, which is obscured when using the compressed option.

Best Regards,
FTDI Community

[TonyZ]

Hello,

Thank you for your continuous help and support.

So are you saying that using the "compressed" option in ESE generates ONLY the font data without the font metric block, or
are you saying that it generates both the font metric block and font data, but the font metric block portion is corrupt and unusable?

Thank you,
Tony
PS. All my posts still have to be approved by the moderator. Can this restriction be removed? I am a legitimate FTDI customer.

[FTDI Community]

Hello,

ESE generates the metric block and font data, when the compressed option is selected both the metric block and font data are compressed. Again, the values from the metric block are obscured due to them being compressed. To read these you would need to un-compress the output.

Best Regards,
FTDI Support

[TonyZ]

Hello,

OK, we seem to be going around in circles here. So I'll state my issue a different way:

I wish to add a custom font, and it must be generated in compressed form because I have limited flash memory on my microcontroller to store it.
If I use ESE with the compressed option, then use INFLATE when loading RAMG, it does not work. The characters on the screen look like random bitmaps.
On the other hand, if I use FNT_CVT, this does indeed work, but FNT_CVT does not have a "compressed" option.

Therefore, I either need to figure out why ESE is not producing valid compressed data, or I need to find
a way to compress the output of FNT_CVT.

Any suggestions would be much appreciated.
Tony

[FTDI Community]

Hello,

Could you give me an example of the output you are getting? the code you are using and the compressed font data?

Best Regards,
FTDI Community

[Kaetemi]

The practical use of the glyph address in the font metric block is to allow the font bitmap to be loaded at any RAM address easily. Under ESE it is assumed that you'll manually write the address where the font bitmap is loaded into the address value, after having loaded the data into RAM_G.

Sample code exported from ESE should demonstrate this behaviour.