Text scaling in u8g2

[songyw124]

Good afternoon,

First, thank you very much for your wonderful work and library. I've found out that text scaling support has been added to u8x8 library (#41) and it was mentioned that text scaling is not needed in u8g2 library, because fonts with different sizes are provided.

However, I have trouble using u8g2 with Asian characters (like Korean), because there are a lot of glyphs and therefore bigger font size just does not fit to the microcontroller easily. For example, there are only two fonts that supports Korean glyphs (u8g2_font_unifont_t_korean1, u8g2_font_unifont_t_korean2), with same text height.

Therefore, it will be really helpful if we can scale these glyphs for examples from height of 16 to 64 (multiply by 4), to get bigger text in bigger display.

It would be really helpful if you can consider this feature.

Thank you very much.

[olikraus]

This topic has been discussed already several times, so I try to reply with a summary.

Any kind of "on the fly" scaling within an embedded system is slow. Of course modern 32 bit systems (ESP32, STM32) may do this, but for 8 bit AVR this is not usefull.

As a consequence, u8g2 will not do on the fly scaling, instead it should be done off-line.

The mentioned u8x8 scaling is not a real scaling but more a pixel doubling which is still fast.

In your case: Select any .ttf font with the desired glyphs, scale this with otf2bdf or fontforge to your desired pixel size, store that font and load the scaled font into your embedded system.

[songyw124]

Thank you for your response. I fully understand your opinion.

First, as you have mentioned, the pixel doubling (or scaling with the factor of integers) might be the better word to describe the feature I've requested. Also, I've further investigated regarding my original issue, so I would be glad to redefine the problem and reply to your opinion as follows:

The problem was not on converting TTF or OTF font to BDF file or do pixel doubling of the BDF file. The problem occurred when I tried to convert this BDF font to u8g2-compatible font using your bdfconv.exe tool, because it will give an error that the glyph is too large.

This is of course a bigger problem when using larger glyphs such as 64 pixel-height glyphs, because size of each glyph is bigger than 256 buffers even after compression. Intentional reduction of details of font by scaling of smaller bdf file to larger bdf file didn't help because the glyph size is still big. For example, I've tried to do pixel quadrupling of 16 pixel-height BDF file to 64 pixel-height BDF (make 1 pixel to 4x4 pixels) to intentionally reduce the details so that the glyphs can be more compressed, but still it does not fit to 256 buffers.

Therefore, u8g2 pixel scaling (with the factor of integers) may help to resolve these problems because size of each glyphs will remain small. For example, we can use 16 pixel-height font and do pixel quadrupling to show 64 pixel-height text, which was not possible due to 256 buffers limit; but still fast because we are just performing scaling of pixels by integer values.

If we are using high-density display or bigger display, this can be very useful because user may be able to use much larger font which does not fit into 256 buffers restriction.

[olikraus]

Ah, I understand. Integer scaling is more complicated in u8g2 compared to u8x8.
Buffer increase is also difficult...

[songyw124]

Thank you for your response,
I totally understand that the buffer increase will be difficult, because datatype of each glyphs is represented in uint8_t, if I didn't misunderstand.

Are there any reasons why integer scaling is complicated compared to u8x8? But it would be really a nice feature for this library to have...

[olikraus]

hmm... we would need to rewrite "u8g2_font_decode_len" procedure

u8g2/csrc/u8g2_font.c

Lines 387 to 469 in 7395c68

	void u8g2_font_decode_len(u8g2_t *u8g2, uint8_t len, uint8_t is_foreground)
	{
	uint8_t cnt; /* total number of remaining pixels, which have to be drawn */
	uint8_t rem; /* remaining pixel to the right edge of the glyph */
	uint8_t current; /* number of pixels, which need to be drawn for the draw procedure */
	/* current is either equal to cnt or equal to rem */
	/* local coordinates of the glyph */
	uint8_t lx,ly;
	/* target position on the screen */
	u8g2_uint_t x, y;
	u8g2_font_decode_t *decode = &(u8g2->font_decode);
	cnt = len;
	/* get the local position */
	lx = decode->x;
	ly = decode->y;
	for(;;)
	{
	/* calculate the number of pixel to the right edge of the glyph */
	rem = decode->glyph_width;
	rem -= lx;
	/* calculate how many pixel to draw. This is either to the right edge */
	/* or lesser, if not enough pixel are left */
	current = rem;
	if ( cnt < rem )
	current = cnt;
	/* now draw the line, but apply the rotation around the glyph target position */
	//u8g2_font_decode_draw_pixel(u8g2, lx,ly,current, is_foreground);
	/* get target position */
	x = decode->target_x;
	y = decode->target_y;
	/* apply rotation */
	#ifdef U8G2_WITH_FONT_ROTATION
	x = u8g2_add_vector_x(x, lx, ly, decode->dir);
	y = u8g2_add_vector_y(y, lx, ly, decode->dir);
	//u8g2_add_vector(&x, &y, lx, ly, decode->dir);
	#else
	x += lx;
	y += ly;
	#endif
	/* draw foreground and background (if required) */
	if ( is_foreground )
	{
	u8g2->draw_color = decode->fg_color; /* draw_color will be restored later */
	u8g2_DrawHVLine(u8g2,
	x,
	y,
	current,
	#ifdef U8G2_WITH_FONT_ROTATION
	/* dir */ decode->dir
	#else
	0
	#endif
	);
	}
	else if ( decode->is_transparent == 0 )
	{
	u8g2->draw_color = decode->bg_color; /* draw_color will be restored later */
	u8g2_DrawHVLine(u8g2,
	x,
	y,
	current,
	#ifdef U8G2_WITH_FONT_ROTATION
	/* dir */ decode->dir
	#else
	0
	#endif
	);
	}

Would it be ok to ignore font rotation?

Maybe like this: Similar to u8x8, we add a "u8g2_font_decode_len_2x2" procedure. But the setFontDirection (https://github.com/olikraus/u8g2/wiki/u8g2reference#setfontdirection) would be ignored.

[songyw124]

Good afternoon, thank you for your response. I was suffering Covid-19 and just saw your response. I am not familiar with the code yet, but I think we can ignore font rotation if it's hard to implement. I will re-check the code and comment it again.

Thank you for your work.

[olikraus]

ok, then, let me look into this more deeper. Not sure when I will have time to work on this.

[olikraus]

Added X2 procedures. More testing required...

[olikraus]

looks good, setFontMode is supported

[olikraus]

Added
u8g2_DrawGlyphX2
u8g2_DrawStrX2
u8g2_DrawUTF8X2

[songyw124]

Thank you very much!! Let me try on my display to see if this works well...

[olikraus]

Great. New procedures are part of beta 2.33.11

You can download the latest U8g2 beta release from here: https://github.com/olikraus/U8g2_Arduino/archive/master.zip
Arduino IDE:

1. Remove the existing U8g2_Arduino library (https://stackoverflow.com/questions/16752806/how-do-i-remove-a-library-from-the-arduino-environment)
2. Install the U8g2_Arduino Zip file via Arduino IDE, add zip library menu (https://www.arduino.cc/en/Guide/Libraries).

PlatformIO:
platformio.ini (https://docs.platformio.org/en/latest/projectconf/section_env_library.html#lib-deps) should include

lib_deps =
  u8g2=https://github.com/olikraus/U8g2_Arduino/archive/master.zip

[songyw124]

Good afternoon,

I have tested your code today, by using 32-pixel height font and to display it to 64-pixel height using pixel doubling. The code seems to worked very well on STM32 processor, by using current source code on Github repository.

I am attaching the display before and after using pixel doubling.

Thank you very much for your work. I really appreciate it. Also, I am sorry for the late reply to your comment.

Best regards,
Song, Young-woon

Before:

After:

[olikraus]

Great, thanks for the feedback.

[songyw124]

Thank you very much.

Do I have to close this issue, or can you close this issue after the announcement of the new version of this U8g2 library?

[olikraus]

I will close this issue once I have checked and updated the documentation.

[olikraus]

doc updated...