In ST7735_t3 : tft.Print and tft.Println do not print spaces

DrGee · Mar 2, 2020

In ST7735_t3 : tft.print and tft.println do not print spaces on Teensy LC

Teensy LC

ST7735_t3 version download 3/2/2020

spaces inside quoted strings or constants are not printed.

e.g., tft.println("Hello World!"); or tft.print("Hello World!"); output HelloWorld, where earlier version showed the expected Hello World.

Edited to add: This is not a problem on a Teensy 4.0

UHF · Apr 11, 2020

Also a problem on T3.6.

UHF · Apr 12, 2020

Also something's happened with references to fonts between 1.48 and 1.51.

#include <Fonts/FreeSansBold18pt7b.h> or #include "Fonts/FreeSansBold18pt7b.h" no longer work. An absolute reference using the entire path name is the only thing that works. What am I missing here?

In 1.51, tft.setCursor(x,y) now has y values offset by a different value, so all strings displayed have a different vertical position. Is the y origin now taken from the top of a string instead of the bottom?

KurtE · Apr 12, 2020

DrGee said:
Teensy LC

ST7735_t3 version download 3/2/2020

spaces inside quoted strings or constants are not printed.

e.g., tft.println("Hello World!"); or tft.print("Hello World!"); output HelloWorld, where earlier version showed the expected Hello World.

Edited to add: This is not a problem on a Teensy 4.0

I will take a look - Any hints? Which type of font? That is there are probably 6 different output functions, depending on which type of font (built in, GFX, or ILI...) And then there is in most cases Opaque versus Transparent (i.e. setTextColor do you specify one or two colors?)

UHF said:
Also something's happened with references to fonts between 1.48 and 1.51.

#include <Fonts/FreeSansBold18pt7b.h> or #include "Fonts/FreeSansBold18pt7b.h" no longer work. An absolute reference using the entire path name is the only thing that works. What am I missing here?

In 1.51, tft.setCursor(x,y) now has y values offset by a different value, so all strings displayed have a different vertical position. Is the y origin now taken from the top of a string instead of the bottom?

Again it would help to know the whole program... But the library was made to not directly rely on Adafruit_GFX library.
So you might try adding: #include <Adafruit_GFX.h>
before your try to include the font file and see if that helps.

@mjs513 may be able to answer more about the font positioning. I know there was some work done to try to make the positioning of fonts more consistent.

mjs513 · Apr 12, 2020

UHF said:
Also a problem on T3.6.

Just tried tft.println("Hello World") on a St7789 and spaces are being printed to screen correctly. I am using a T3.6 with IDE 1.8.12 and TD1.52 beta2. Have to find my ST7735 and will double check.

Also something's happened with references to fonts between 1.48 and 1.51.

#include <Fonts/FreeSansBold18pt7b.h> or #include "Fonts/FreeSansBold18pt7b.h" no longer work. An absolute reference using the entire path name is the only thing that works. What am I missing here?

using a simple test sketch the Adafruit fonts seem to work. However, now a space is not printed between "Hello World" when using adafruit fonts. Doesn't seem to a problem with the ST fonts included in the lib though. There does seem to be another problem with using the ILI font library.

In 1.51, tft.setCursor(x,y) now has y values offset by a different value, so all strings displayed have a different vertical position. Is the y origin now taken from the top of a string instead of the bottom?

Yes it appears the baseline is the top but don't remember that changing from version to version.

This would of course be easier if you posted your sample code demonstrating the problem. For instance did you remember to include the Adafruit GFX library in your sketch? As well as what Display you are using?

This is the sketch I am using:

Code:

// This Teensy3 and 4 native optimized and extended version
// requires specific pins. 
// If you use the short version of the constructor and the DC
// pin is hardware CS pin, then it will be slower.

#define TFT_MISO  12
#define TFT_MOSI  11  //a12
#define TFT_SCK   13  //a13
#define TFT_DC   9 
#define TFT_CS   10  
#define TFT_RST  8

// Note the above pins are for the SPI object.  For those Teensy boards which have
// more than one SPI object, such as T3.5, T3.6, T4 which have at SPI1 and SPI2
// LC with SPI1, look at the cards that come with the teensy or the web page
// https://www.pjrc.com/teensy/pinout.html to select the appropriate IO pins.

#include <Adafruit_GFX.h>    // Core graphics library
#include <ST7735_t3.h> // Hardware-specific library
#include <ST7789_t3.h> // Hardware-specific library
#include <SPI.h>

// maybe a few GFX FOnts?
#include <Fonts/FreeMono9pt7b.h>
#include <Fonts/FreeSerif9pt7b.h>
#include <Fonts/FreeSansBold18pt7b.h>
#include "st7735_t3_font_ComicSansMS.h"

// Option 1: use any pins but a little slower
// Note: code will detect if specified pins are the hardware SPI pins
//       and will use hardware SPI if appropriate
// For 1.44" and 1.8" TFT with ST7735 use
ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCK, TFT_RST);

// For 1.54" or other TFT with ST7789, This has worked with some ST7789
// displays without CS pins, for those you can pass in -1 or 0xff for CS
// More notes by the tft.init call
//ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

// Option 2: must use the hardware SPI pins
// (for UNO thats sclk = 13 and sid = 11) and pin 10 must be
// an output. This is much faster - also required if you want
// to use the microSD card (see the image drawing example)
// For 1.44" and 1.8" TFT with ST7735 use
//ST7735_t3 tft = ST7735_t3(cs, dc, rst);

// For 1.54" TFT with ST7789
//ST7789_t3 tft = ST7789_t3(TFT_CS,  TFT_DC, TFT_RST);

float p = 3.1415926;


void setup(void) {
  //pinMode(SD_CS, INPUT_PULLUP);  // don't touch the SD card
  Serial.begin(9600);
  Serial.print("hello!");

  // Use this initializer if you're using a 1.8" TFT 128x160 displays
  //tft.initR(INITR_BLACKTAB);

  // Or use this initializer (uncomment) if you're using a 1.44" TFT (128x128)
  //tft.initR(INITR_144GREENTAB);

  // Or use this initializer (uncomment) if you're using a .96" TFT(160x80)
  //tft.initR(INITR_MINI160x80);

  // Or use this initializer (uncomment) for Some 1.44" displays use different memory offsets
  // Try it if yours is not working properly
  // May need to tweek the offsets
  //tft.setRowColStart(32,0);

  // Or use this initializer (uncomment) if you're using a 1.54" 240x240 TFT
  //tft.init(240, 240);   // initialize a ST7789 chip, 240x240 pixels

  // OR use this initializer (uncomment) if using a 2.0" 320x240 TFT:
  tft.init(240, 320);           // Init ST7789 320x240

  // OR use this initializer (uncomment) if using a 240x240 clone 
  // that does not have a CS pin2.0" 320x240 TFT:
  //tft.init(240, 240, SPI_MODE2);           // Init ST7789 240x240 no CS

  Serial.println("init");
  uint16_t time = millis();
  tft.fillScreen(ST7735_BLACK);
  time = millis() - time;

  Serial.println(time, DEC);
  delay(500);

  // large block of text
  tft.fillScreen(ST7735_BLACK);
  tft.setFont(&FreeSansBold18pt7b);
  //tft.setTextSize(3);
  tft.println("HELLO WORLD");
  delay(1000);
  tft.setTextColor(ST7735_GREEN);
  tft.setFont(ComicSansMS_14);
  tft.println();
  tft.println("ComicSansMS 14");
  delay(1000);
  
}

void loop(){}

KurtE · Apr 12, 2020

Good Morning @mjs513 - I think there might be an issue with output spaces with the GFX Font?

I mucked with the ILI_Ada_FontTest4 example using T-LC (probably should not depend on LC)... I mucked up the displayStuff and displayStuff1 methods. to change a couple
of the outputs, in particular:

Code:

  tft.println("!@#$%^|| |&*()-");

The Vertical bars were added so to see the influence of the space on output.

KurtE · Apr 12, 2020

Yep - There was a fix that went into ili9341_t3n for this, which has not made it into st7735_t3 (or ILI9488...)

in void ST7735_t3::drawGFXFontChar(unsigned int c) {
There is the line:

Code:

     if((w == 0) || (h == 0))  return;  // Is there an associated bitmap?

in ILI9341_t3n this was updated to:

Code:

    // wonder if we should look at xo, yo instead?         
    if((w == 0 ||  h == 0)  && (c != 32))   return;  // Is there an associated bitmap?

Which fixes it...

Mike do you want to add to your PR for doubles...

mjs513 · Apr 12, 2020

Morning Kurt
Was just looking at it now.

Just for a point of reference I ran the Adafruit ILI9341 lib to check the spacing. For the font referenced it does show a space but rather narrow one. Tried it with the ILI9488 and seems to have the same problem.

I remember that fix but I thought we had updated all the libs for that issue. Will have to double check now. Guess this is another reason to create a common lib

There is also a issue with using the GLCD fonts have to check that next but want to fix this first.

DrGee · Apr 12, 2020

KurtE said:
I will take a look - Any hints? Which type of font? That is there are probably 6 different output functions, depending on which type of font (built in, GFX, or ILI...) And then there is in most cases Opaque versus Transparent (i.e. setTextColor do you specify one or two colors?)

Again it would help to know the whole program... But the library was made to not directly rely on Adafruit_GFX library.
So you might try adding: #include <Adafruit_GFX.h>
before your try to include the font file and see if that helps.

@mjs513 may be able to answer more about the font positioning. I know there was some work done to try to make the positioning of fonts more consistent.

Program to illustrate the error:

Code:

#include <Adafruit_GFX.h>   // Core graphics library
#include <ST7735_t3.h>     
#include <SPI.h>
#include <Fonts/FreeSansBold9pt7b.h>

// OLED spi pin definitions
#define TFT_SCLK 13  // SCLK can also use pin 14
#define TFT_MOSI 11  // MOSI can also use pin 7
#define TFT_CS   10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST   8  // RST can use any pin

// colors in GBR format
#define ST7735I_BLACK      0x0000 // no change needed
#define ST7735I_WHITE      0xFFFF // no change needed
#define ST7735I_RED        0x001F // 0000000000011111 was 0xF800
#define ST7735I_GREEN      0x07E0 // no change needed
#define ST7735I_BLUE       0xF800 // 1111100000000000 was 0x001F 
#define ST7735I_CYAN       0xFFE0 // 1111111111100000 was 0x07FF
#define ST7735I_MAGENTA    0xF81F // no change needed 
#define ST7735I_YELLOW     0x07FF // 0000011111111111 was 0xFFE0
#define ST7735I_ORANGE     0x041f // 0000010000011111 was 0xFC00

ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_RST);

void setup() {
  tft.initR(INITR_MINI160x80);
  tft.invertDisplay(true);
  tft.setRotation(3);
  tft.setFont(&FreeSansBold9pt7b);
  tft.fillScreen(ST7735I_WHITE);
  tft.setTextColor(ST7735I_BLACK);
  tft.setTextSize(3); 
}

void draw_top_screen() {
  tft.drawLine(0, 0, 160, 0, ST7735I_ORANGE);
  tft.drawLine(0, 1, 160, 1, ST7735I_ORANGE);
  tft.drawLine(0, 29, 160, 29, ST7735I_ORANGE);
  tft.drawLine(0, 30, 160, 30, ST7735I_ORANGE);

  tft.drawLine(0, 1, 0, 28, ST7735I_ORANGE);
  tft.drawLine(1, 1, 1, 28, ST7735I_ORANGE);

  tft.drawLine(159, 2, 159, 28, ST7735I_ORANGE);
  tft.drawLine(158, 2, 158, 28, ST7735I_ORANGE);
  tft.fillRect(2, 2, 156, 27, ST7735I_CYAN);
  tft.setTextColor(ST7735I_BLUE);
  tft.setCursor(37, 10);
  tft.setTextSize(1);
  tft.println("CO  [ppm]");
  //tft.println("CO");
  //tft.setCursor(69, 10);
  //tft.println("[ppm]");
}

void loop() {
  draw_top_screen();
  while(1);

}

Screenshot of ignored space:

Code to avoid printing spaces in tft.println

Code:

#include <Adafruit_GFX.h>   // Core graphics library
#include <ST7735_t3.h>     
#include <SPI.h>
#include <Fonts/FreeSansBold9pt7b.h>

// OLED spi pin definitions
#define TFT_SCLK 13  // SCLK can also use pin 14
#define TFT_MOSI 11  // MOSI can also use pin 7
#define TFT_CS   10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST   8  // RST can use any pin

// colors in GBR format
#define ST7735I_BLACK      0x0000 // no change needed
#define ST7735I_WHITE      0xFFFF // no change needed
#define ST7735I_RED        0x001F // 0000000000011111 was 0xF800
#define ST7735I_GREEN      0x07E0 // no change needed
#define ST7735I_BLUE       0xF800 // 1111100000000000 was 0x001F 
#define ST7735I_CYAN       0xFFE0 // 1111111111100000 was 0x07FF
#define ST7735I_MAGENTA    0xF81F // no change needed 
#define ST7735I_YELLOW     0x07FF // 0000011111111111 was 0xFFE0
#define ST7735I_ORANGE     0x041f // 0000010000011111 was 0xFC00

ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_RST);

void setup() {
  tft.initR(INITR_MINI160x80);
  tft.invertDisplay(true);
  tft.setRotation(3);
  tft.setFont(&FreeSansBold9pt7b);
  tft.fillScreen(ST7735I_WHITE);
  tft.setTextColor(ST7735I_BLACK);
  tft.setTextSize(3); 
}

void draw_top_screen() {
  tft.drawLine(0, 0, 160, 0, ST7735I_ORANGE);
  tft.drawLine(0, 1, 160, 1, ST7735I_ORANGE);
  tft.drawLine(0, 29, 160, 29, ST7735I_ORANGE);
  tft.drawLine(0, 30, 160, 30, ST7735I_ORANGE);

  tft.drawLine(0, 1, 0, 28, ST7735I_ORANGE);
  tft.drawLine(1, 1, 1, 28, ST7735I_ORANGE);

  tft.drawLine(159, 2, 159, 28, ST7735I_ORANGE);
  tft.drawLine(158, 2, 158, 28, ST7735I_ORANGE);
  tft.fillRect(2, 2, 156, 27, ST7735I_CYAN);
  tft.setTextColor(ST7735I_BLUE);
  tft.setCursor(37, 10);
  tft.setTextSize(1);
  //tft.println("CO  [ppm]");
  tft.println("CO");
  tft.setCursor(69, 10);
  tft.println("[ppm]");
}

void loop() {
  draw_top_screen();
  while(1);

}

Screenshot correcting problem by setting the cursor position instead of tft.println with spaces in the string:

Edited to add: Please do not get hung up on the #defined GBR colors. You can replace them with the ones that are pre-defined. They have nothing to do with it.

mjs513 · Apr 12, 2020

@KurtE and others
Updated to fix GFX font spacing. PR updated for the ST7735 library. The fix is also in my fork of the lib if you want to download: https://github.com/mjs513/ST7735_t3

EDIT:
@DrGee - posts crossed. The issue with GFX font spacings has now been corrected in my fork as referenced above. If you download it and update your copy of the lib the spacing problem should be fixed. A PR has been issued to Paul to fix the version that goes into Teensyduino.

UHF · Apr 12, 2020

Here's some code that demonstrates it. Including <Adafruit_GFX.h> before <ST7735_t3.h> clears up the problem with font references. Thanks for looking into this.

On 1.48

On 1.51

Code:

// This Teensy3 native optimized version requires specific pins
#define sclk 20  // SCLK can also use pin 14  
#define mosi 21  // MOSI can also use pin 7
#define cs  2  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define dc   3   //but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define rst  8   // RST can use any pin

#include <Adafruit_GFX.h>
#include <ST7735_t3.h> // Hardware-specific library for T3.x


#include <Fonts/FreeSansBold18pt7b.h>
#include <Fonts/FreeSans12pt7b.h>

ST7735_t3 tft = ST7735_t3(cs, dc, mosi, sclk, rst);

void renderCurrentPatchPage() {
  tft.fillScreen(ST7735_BLACK);
  tft.setFont(&FreeSansBold18pt7b);
  tft.setCursor(5, 53);
  tft.setTextColor(ST7735_YELLOW);
  tft.setTextSize(1);
  tft.println("999");
  tft.drawFastHLine(10, 62, tft.width() - 20, ST7735_RED);
  tft.setFont(&FreeSans12pt7b);
  tft.setCursor(1, 90);
  tft.setTextColor(ST7735_WHITE);
  tft.println("Abcd efg ijk");
}

void setup() {
  // put your setup code here, to run once:
  tft.useFrameBuffer(true);
  tft.initR(INITR_GREENTAB);
  tft.setRotation(3);
  tft.invertDisplay(true);
  renderCurrentPatchPage();
  tft.updateScreen();
}

void loop() {

}

mjs513 · Apr 12, 2020

@DrGee and @KurtE

One of the things that was added to the library was auto centering of the strings in a way that is similar to the RA8875. The change had the side effect that you are seeing in your sketch. Where the text is drawn by default starting at the top.

To change this so the baseline is at the bottom you have to add an additional option to the setCursor command:

Code:

  tft.setCursor(5, 53, true);

this puts the baseline on the bottom.

Edit: You can see this clearly in @KurtE's post #6, https://forum.pjrc.com/threads/5988...t-print-spaces?p=235546&viewfull=1#post235546

DrGee · Apr 12, 2020

mjs513 said:
@KurtE and others
Updated to fix GFX font spacing. PR updated for the ST7735 library. The fix is also in my fork of the lib if you want to download: https://github.com/mjs513/ST7735_t3

EDIT:
@DrGee - posts crossed. The issue with GFX font spacings has now been corrected in my fork as referenced above. If you download it and update your copy of the lib the spacing problem should be fixed. A PR has been issued to Paul to fix the version that goes into Teensyduino.

Thanks much. Because I was working on a particular project where I programmed my way around it, I will wait a few days, but I read your change and am confident that it will work fine.

On a slightly different, but related note. To deal with the wide variety of inexpensive (and largely unsupported by the seller) screens, I end up having to modify st7735_t3.cpp.

For example:

Code:

  Rcmd2green160x80[] = {            // 7735R init, part 2 (mini 160x80)
    2,                              //  2 commands in list:
    ST7735_CASET,   4,              //  1: Column addr set, 4 args, no delay:
	// MODS here (next two lines commented out and replaced)
    //  0x00, 0x00,                   //     XSTART = 0
    //  0x00, 0x4F,                   //     XEND = 79
	0x00,0x19,0x00,0x69,              // modified to
    ST7735_RASET,   4,              //  2: Row addr set, 4 args, no delay:
	//MODS HERE (next two lines commected out and replaced)
    //  0x00, 0x00,                   //     XSTART = 0
    //  0x00, 0x9F },                 //     XEND = 159
	0x00,0x01,0x00,0xa0},                  // modified to

I supposed that I should write my own init routine and call it myself. I did, at one time, follow some of the evolution of ST7735 and can see that there was some consolidation done with initialization in general (take this from here and then this from here, depending on "tab" and so on).

I am not smart enough to know how to access certain variables inside my program (like those modified above).

How would you, or anyone else knowledgeable, suggest the best way to accomplish this accepting that changes (like those that you just made)?

mjs513 · Apr 12, 2020

@KurtE
Think we need to also consider changing:

Code:

void ST7735_t3::setCursor(int16_t x, int16_t y, bool autoCenter) {
	_center_x_text = autoCenter;	// remember the state. 
	_center_y_text = autoCenter;	// remember the state.

Code:

void ST7735_t3::setCursor(int16_t x, int16_t y, bool autoCenterX, bool autoCenterY,) {
	_center_x_text = autoCenterX;	// remember the state. 
	_center_y_text = autoCenterY;	// remember the state.

So we can have a bit more control on how to do the centering.

mjs513 · Apr 12, 2020

DrGee said:
Thanks much. Because I was working on a particular project where I programmed my way around it, I will wait a few days, but I read your change and am confident that it will work fine.

On a slightly different, but related note. To deal with the wide variety of inexpensive (and largely unsupported by the seller) screens, I end up having to modify st7735_t3.cpp.

For example:

Code:

Rcmd2green160x80[] = { // 7735R init, part 2 (mini 160x80) 2, // 2 commands in list: ST7735_CASET, 4, // 1: Column addr set, 4 args, no delay: // MODS here (next two lines commented out and replaced) // 0x00, 0x00, // XSTART = 0 // 0x00, 0x4F, // XEND = 79 0x00,0x19,0x00,0x69, // modified to ST7735_RASET, 4, // 2: Row addr set, 4 args, no delay: //MODS HERE (next two lines commected out and replaced) // 0x00, 0x00, // XSTART = 0 // 0x00, 0x9F }, // XEND = 159 0x00,0x01,0xa0}, // modified to

I supposed that I should write my own init routine and call it myself. I did, at one time, follow some of the evolution of ST7735 and can see that there was some consolidation done with initialization in general (take this from here and then this from here, depending on "tab" and so on).

I am not smart enough to know how to access certain variables inside my program (like those modified above).

How would you, or anyone else knowledgeable, suggest the best way to accomplish this accepting that changes (like those that you just made)?

Since the changes you want to make just seems to be for row and column start position for the display you can simply use the command:

Code:

setRowColStart(uint16_t x, uint16_t y)

Just put in your new row and column start positions. No need to mess with initialization.

DrGee · Apr 12, 2020

mjs513 said:
Since the changes you want to make just seems to be for row and column start position for the display you can simply use the command:

Code:

setRowColStart(uint16_t x, uint16_t y)

Just put in your new row and column start positions. No need to mess with initialization.

Good deal. What about changes to MADCTL?

KurtE · Apr 12, 2020

Hi @mjs513 - I don't think the auto-center stuff was supposed to change what happens if you are not auto centering? But maybe introduced issue?

I also remember discussions about trying to deciding how we should handle different fonts on setting the cursor when we have 3 different fonts.

I am guessing that this issue goes back to when we were removing the usage of GFX. At first I think we removed the capabilities for GFX fonts.

Looks like nothing has changed in the void ST7735_t3::drawGFXFontChar(unsigned int c) function, since we removed GFX... (looking at the Blame view up on github)

Looking at setCursor the only change is to remember the states you mentioned:

Code:

_center_x_text = autoCenterX;	// remember the state. 
	_center_y_text = autoCenterY;	// remember the state.

And check to see if you passed in CENTER for either X, or Y to set the value to the center of the screen and set _center_x_text and/or _center_y_text.

So then the only other main change was in the ::write(buffer, size), which is new in that I get the whole string instead of higher level doing the iterations. I believe only really changed if either(or both) of the _center_x_text or _center_y_text flag is set, in which
case it does call to get the full text bounds and adjust the appropriate cursor values.

So again my guess is that this part has been different since we removed GFX. I am guessing we just decided to use same offsetting as ILI fonts.

So again wonder if we should update the gfx font drawing code to use the same positioning as the Adafruit_GFX code?

KurtE · Apr 12, 2020

Another option is to add yet another color tab like init like there are black_tab, green_tab, ???

mjs513 · Apr 12, 2020

Afternoon @KurtE
Yep all those discussions are coming back to me as I am digging into the code more and remembering.

Think the problem is really in the write function, at least that's where I isolated down to. Its with this section of code:

Code:

	// Lets try to handle some of the special font centering code that was done for default fonts.
	if (_center_x_text || _center_y_text ) {
		int16_t x, y;
	  	uint16_t strngWidth, strngHeight;
	  	getTextBounds(buffer, size, 0, 0, &x, &y, &strngWidth, &strngHeight);
	  	//Serial.printf("_fontwrite bounds: %d %d %u %u\n", x, y, strngWidth, strngHeight);
	  	// Note we may want to play with the x ane y returned if they offset some
		if (_center_x_text && strngWidth > 0){//Avoid operations for strngWidth = 0
			cursor_x -= ((x + strngWidth) / 2);
		}
		if (_center_y_text && strngHeight > 0){//Avoid operations for strngWidth = 0
			cursor_y -= ((y + strngHeight) / 2);
		}
	}

We are adjusting the cursor positions based on whether we are centering for x or for y. How do I know - I added a quick new function called setCenterText as a kludge and called it after setCursor(x, y). Has same affect if I did it within the setcursor function itself. Am attaching the modified .h and .cpp if you want to play.

mjs513 · Apr 12, 2020

KurtE said:
Another option is to add yet another color tab like init like there are black_tab, green_tab, ???

Ok - you lost me on this one?

KurtE · Apr 12, 2020

@mjs513 Good afternoon (Actually still morning here

)

With the above code, it should only modify the cursor position IF the user asked for it change depending on the text.

Code:

// Lets try to handle some of the special font centering code that was done for default fonts.
	if (_center_x_text || _center_y_text ) {
		int16_t x, y;
	  	uint16_t strngWidth, strngHeight;
	  	getTextBounds(buffer, size, 0, 0, &x, &y, &strngWidth, &strngHeight);
	  	//Serial.printf("_fontwrite bounds: %d %d %u %u\n", x, y, strngWidth, strngHeight);
	  	// Note we may want to play with the x ane y returned if they offset some
		if (_center_x_text && strngWidth > 0){//Avoid operations for strngWidth = 0
			cursor_x -= ((x + strngWidth) / 2);
		}
		if (_center_y_text && strngHeight > 0){//Avoid operations for strngWidth = 0
			cursor_y -= ((y + strngHeight) / 2);
		}
	}

i.e. only if the user either did something like: setCursor(x, y, 1); or if setCursor(ST7735_t3::CENTER, y) and/or CENTER for Y....
Otherwise it should logically reduce down to (removing tests for what type of char and processing newline)

Code:

size_t ST7735_t3::write(const uint8_t *buffer, size_t size)
{
	size_t cb = size;
	while (cb) {
		uint8_t c = *buffer++;
		cb--;
		drawGFXFontChar(c);
	}
	return size;
}

Color tabs... There have been a couple of versions of the ST7735 displays that Adafruit has sold. Most of them come with a protective film which has a piece of tape with some color on them.

I believe they changed the color of the tape when they came out with different versions, some of these required changes to the the init code and the like, so for example in our example sketches we see:

Code:

 //tft.initR(INITR_BLACKTAB);

  // Or use this initializer (uncomment) if you're using a 1.44" TFT (128x128)
  //tft.initR(INITR_144GREENTAB);

  // Or use this initializer (uncomment) if you're using a .96" TFT(160x80)
  //tft.initR(INITR_MINI160x80);

If you look at initR you will see that for some of these we choose different command init lists, plus we remember the color.
And if you loook in setRotation, you will see that we check the tab_color and use that in selecting what we do with MADCTL...

mjs513 · Apr 12, 2020

@KurtE
Well still afternoon here - just got back from shopping with wife - food and drug store.

I believe they changed the color of the tape when they came out with different versions, some of these required changes to the the init code

Got it, didn't realize there were additional color tabs on the displays. Just took a look at there st7735 lib and looks like they did have another for a BLACKTAB.

With the above code, it should only modify the cursor position IF the user asked for it change depending on the text.

Yeah - you are of course right was thinking. with that said think I traced the issue to a kludge we put in early on but never went back to see after all the other changes we made to the code.

In drawGFXFontChar:

Code:

		//int8_t y_top_fill = (yo - _gfxFont_min_yOffset) * textsize_y;	 // both negative like -10 - -16 = 6...
		int8_t y_top_fill = (yo - gfxFont->yAdvance/2 - _gfxFont_min_yOffset) * textsize_y;

should change back to the commented line:

Code:

int8_t y_top_fill = (yo - _gfxFont_min_yOffset) * textsize_y;

also this line should change as well:

Code:

int16_t yo = glyph->yOffset + gfxFont->yAdvance/2;

to

Code:

int16_t yo = glyph->yOffset ;

this gets it back fairly close to what DrGee showed. There is one caveat - text centering is a bit off.

UHF · Apr 13, 2020

This is nothing to do with fonts but I'll post here. drawLine(...) causes pixels to be drawn over the screen when diagonal. Horizontal and vertical lines are fine.

Arduino 1.8.12 TD1.51 on a T3.6

Code:

// This Teensy3 native optimized version requires specific pins
#define sclk 20  // SCLK can also use pin 14  
#define mosi 21  // MOSI can also use pin 7
#define cs  2  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define dc   3   //but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define rst  8   // RST can use any pin

#include <ST7735_t3.h> // Hardware-specific library for T3.x

ST7735_t3 tft = ST7735_t3(cs, dc, mosi, sclk, rst);

void setup() {
  tft.useFrameBuffer(true);
  tft.initR(INITR_GREENTAB);
  tft.setRotation(3);
  tft.invertDisplay(true);
//tft.drawLine(20, 50, 20, 80, ST7735_WHITE);//Ok
  tft.drawLine(20, 50, 60, 80, ST7735_WHITE);//Fails
//tft.drawLine(20, 50, 60, 50, ST7735_WHITE);//Ok
  tft.updateScreen();
}

void loop() {
}

mjs513 · Apr 13, 2020

UHF said:
This is nothing to do with fonts but I'll post here. drawLine(...) causes pixels to be drawn over the screen when diagonal. Horizontal and vertical lines are fine.

Arduino 1.8.12 TD1.51 on a T3.6

View attachment 19665

Code:

….

I hooked up my sT7735 128x128 display to the T3.6 and I can not duplicate your problem. I am using the TD152Beta2. What display are you using (size, resolution, link to display). Are you sure you are using the right initR function?

UHF · Apr 13, 2020

Hello, it's a 0.96" ips 160 x 80 spi with a ST7735S. One of these: https://m.aliexpress.com/item/32888...er_id=520a6e2681a2408d99ed20b8abec8841&is_c=Y

This does have a greentab. Using other initialisers give mixed problems like screen flashes and different interpretations of colours. It did all work fine in 1.48.

In ST7735_t3 : tft.Print and tft.Println do not print spaces

Member

Well-known member

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Member

Senior Member+

Well-known member

Senior Member+

Member

Senior Member+

Senior Member+

Member

Senior Member+

Senior Member+

Senior Member+

Attachments

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member