Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align::*Right doesn't work quite right? #37

Open
chconnor opened this issue Nov 30, 2023 · 3 comments
Open

Align::*Right doesn't work quite right? #37

chconnor opened this issue Nov 30, 2023 · 3 comments

Comments

@chconnor
Copy link

I was using URW Gothic Book. This font, as far as I know, has fixed-width numerals.

When I use Align::TopRight or Align::BottomRight for the numerals, however, the alignment changes when a "1" is the last digit drawn to the screen.

E.g. drawing the string "90" and "91" will cause the 9 to be in a slightly different place. The other combinations (92, 93, 94, etc) all align as expected.

If I use that font in LibreOffice and align right, it works as expected.

Here is the original TTF.

Here is the stripped-down version (out of fontforge) that I'm actually using.

Any ideas? Is this a confusion on my part about what to expect from AlignRight? Maybe it goes by the actual glyph contents, rather than the specified character width?

@takkaO
Copy link
Owner

takkaO commented Dec 6, 2023

Thank you for using.

I will try your code. Please give me some time.

(I crezy busy my main business, so it will takes time 🙇‍♂️🙇‍♂️🙇‍♂️)

@chconnor
Copy link
Author

chconnor commented Dec 6, 2023

Thanks @takkaO -- in case it's helpful, below is some demo code.

And here is the reduced URWGothic-Book.h.

Attached is a pic of the output. You can see that the left side of the Align::TopRight section is not even. However the right side of Align::TopLeft section is even. So it would seem that there is a difference when the align is left or right in terms of how it computes the edge of the character.

Attached is also a pic of the "1" and "2" digits in fontforge, in case that's useful.

ofr_render_issue

ofr_issue_chars_ff

#include <Arduino.h>
#include "SPI.h"
#include <TFT_eSPI.h> // screen; uses src/TFT_eSPI_Setup.h after library file User_Setup_Select.h changed to #include <../../../../src/TFT_eSPI_Setup.h> 
#include "OpenFontRender.h"
#include "URWGothic_Book.h"

#define TFT_BLK 4 // pin for enable/disable of screen backlight
static TFT_eSPI tft = TFT_eSPI();
static OpenFontRender ofr;

void setup()
{
  Serial.begin(115200);
  while (!Serial) delay(10);

  pinMode(TFT_BLK, OUTPUT);
  digitalWrite(TFT_BLK, HIGH); // HIGH=screen on
  tft.init();
  tft.fillScreen(TFT_BLACK);

  ofr.setDrawer(tft); // Link drawing object to tft instance (so font will be rendered on TFT)
  ofr.setFontColor(TFT_WHITE, TFT_BLACK); // bg color is for antialiasing
  if (ofr.loadFont(URWGothic_Book, sizeof(URWGothic_Book)))
  {
     Serial.println("font initialization error");
     return;
  }

  ofr.setFontSize(15);

  ofr.setAlignment(Align::TopRight);
  ofr.setCursor(20, 20);
  ofr.printf("90");
  ofr.setCursor(20, 40);
  ofr.printf("91");             // *********** why does this one shift to the right?
  ofr.setCursor(20, 60);
  ofr.printf("92");

  ofr.setAlignment(Align::TopLeft);
  ofr.setCursor(20, 90);
  ofr.printf("09");
  ofr.setCursor(20, 110);
  ofr.printf("19");            // *********** this one looks OK, as expected
  ofr.setCursor(20, 130);
  ofr.printf("22");
}

void loop() { ; }

@larrybud2004
Copy link

Also experiencing this with the stock NotoSans_Bold font. Font size doesn't matter, although it's more difficult to see at small sizes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants