The OLED::charWidth does not work with OLED_TextBox when handling spaces for variable width fonts

[TurbulentCalm]

The current version of FTOLED_Text.cpp has an issue handling spaces correctly in OLED_TextBox when variable width fonts in OLED_text_Boxes are used.

Working through the code I found that the issue was in the method OLED:charWidth.

I have reviewed the code and rewrote some of it to both simplify it and resolve the way the width of a space is calculated. The new code always defaults to the fixedWidth value of the font - this works for both fixed and variable width fonts and is better that using the character 'n'.

I suggest that the new code be incorporated into the official library once it has been reviewed and tested by the library authors:

The changes are listed below:

int OLED::charWidth(const char letter)
{
  struct FontHeader header;
  memcpy_P(&header, (void*)this->font, sizeof(FontHeader));

  if (letter == ' ') {
    // if the letter is a space, ' ', then return the font's fixedWidth, there is no need to for complicated gotos or multiple if then statements (not only does this simplify the code for this method but it also resolves the missing spaces when printing in textBoxes)
    return header.fixedWidth;
  }

  if (letter < header.firstChar || letter >= (header.firstChar + header.charCount)) {
    return 0;
  }

  if (header.size == 0) {
    // zero length is flag indicating fixed width font (array does not contain width data entries)
    return header.fixedWidth;
  }

  // variable width font, read width data for character
  return pgm_read_byte(this->font + sizeof(FontHeader) + letter - header.firstChar);
}

Regards

Paul Greeve

[projectgus]

Hi Paul,

Sorry it's taken me so long to get back to you, I'm the FTOLED author and I've been away.

Thanks for identifying the bug with variable width fonts and TextBoxes. I've merged your suggested charWidth replacement, thanks also for that.

There is a little more to it. The fixedWidth field in a variable width font really doesn't mean anything at all. On most of our fonts (including the large ones) it was set to 10 as this is the default in GLCDCreator2. With commit 2ff8df2 these widths are changed so they approximate the spacing that was intended in the original version of FTOLED (possibly still a little wide by typography standards.)

I added a note to the wiki so GLCDCreator2 users know to use the "Width" field as the width of a space character when creating variable width fonts.

This is much less complex and error-prone than the 'n' heuristic we were using before, thanks for suggesting this approach.

Please let me know if these changes resolve the problems you were seeing, and I'll close the issue.

[TurbulentCalm]

Thanks for the reply and glad I could help.

The OLED display is a fun add on and a great way to learn the basics of graphics in code, given how complex it has become on main stream devices.

I started coding in 1978 (I was 12) and all I had was LEDs to display binary. Next was a pair of seven segment displays that showed the binary in hex.

In 80's I had a C64 and could get my head around graphics and resorted to character based drawing.

When I saw the Apple Lisa and the Mac and the many different fonts, I can remember thinking, "How the hell do they do that!?".

The same was with early PCs. No useful libraries in those days. I was trying to reinvent the wheel. In the end I gave up.

It is fun to be able to peek behind the curtains and see what I was missing back then.

Regards

Paul Greeve

On 26 May 2014, at 11:02, Angus Gratton notifications@github.com wrote:

Hi Paul,

Sorry it's taken me so long to get back to you, I'm the FTOLED author and I've been away.

Thanks for identifying the bug with variable width fonts and TextBoxes. I've merged your suggested charWidth replacement, thanks also for that.

There is a little more to it. The fixedWidth field in a variable width font really doesn't mean anything at all. On most of our fonts (including the large ones) it was set to 10 as this is the default in GLCDCreator2. With commit 2ff8df2 these widths are changed so they approximate the spacing that was intended in the original version of FTOLED (possibly still a little wide by typography standards.)

I added a note to the wiki so GLCDCreator2 users know to use the "Width" field as the width of a space character when creating variable width fonts.

This is much less complex and error-prone than the 'n' heuristic we were using before, thanks for suggesting this approach.

Please let me know if these changes resolve the problems you were seeing, and I'll close the issue.

— Reply to this email directly or view it on GitHub.

[TurbulentCalm]

And yes you can close the issue.

Regards

Paul Greeve

On 26 May 2014, at 11:02, Angus Gratton notifications@github.com wrote:

Hi Paul,

Sorry it's taken me so long to get back to you, I'm the FTOLED author and I've been away.

Thanks for identifying the bug with variable width fonts and TextBoxes. I've merged your suggested charWidth replacement, thanks also for that.

There is a little more to it. The fixedWidth field in a variable width font really doesn't mean anything at all. On most of our fonts (including the large ones) it was set to 10 as this is the default in GLCDCreator2. With commit 2ff8df2 these widths are changed so they approximate the spacing that was intended in the original version of FTOLED (possibly still a little wide by typography standards.)

I added a note to the wiki so GLCDCreator2 users know to use the "Width" field as the width of a space character when creating variable width fonts.

This is much less complex and error-prone than the 'n' heuristic we were using before, thanks for suggesting this approach.

Please let me know if these changes resolve the problems you were seeing, and I'll close the issue.

— Reply to this email directly or view it on GitHub.

[projectgus]

Thanks Paul. :)