Tools > Create Font unable to disable smoothing on macOS

[processing-bot]

Created by: kylemcdonald

Description

When using createFont() or the Create Font tool to create a PFont for a bitmap pixel font with smoothing disabled, there are still grays in the generated font.

Expected Behavior

Created by thresholding the result in Photoshop:

Current Behavior

Generated directly by Processing:

Steps to Reproduce

Here is a link to the font I am using: sg08.zip

PFont font;

void setup() {
  size(512, 512);
  font = createFont("SHAKAGRAPHICS08", 8, false);
  noSmooth();
  textFont(font, 8);
  textAlign(LEFT, TOP);
}

void draw() {
  background(255);
  fill(0);
  noStroke();
  String str = "Forsaking monastic tradition,\ntwelve jovial friars gave up\ntheir vocation for a questionable\nexistence on the flying trapeze.";
  text(str, 20, 20);
}

Your Environment

• Processing version: 4.0b1
• Operating System and OS version: MacOS 11.6

Possible Causes / Solutions

I did some basic checks to see that this is happening at font generation time, and not in the rendering. I don't know the Processing internals enough to advise beyond this. Last time I tried this font was circa 2011 and I know it worked correctly Processing back then :)

[processing-bot]

Created by: kylemcdonald

I was able to confirm that a .vlw file generated from the same font in Processing 1.2 works as expected. Here are two .vlw files from v1.2 and v4.0b1:

vlw-comparison.zip

[processing-bot]

Created by: benfry

Are you sure? Your example is giving me sharp text when I bump things up to textSize(50):

(There might also be minor halos around the edges here from retina display rendering, is that what you're seeing?)

Wouldn't be surprised if something is broken—all the hidpi changes make it really hard to disable smoothing—but I'm having trouble reproducing.

[processing-bot]

Created by: kylemcdonald

Hi Ben! I just tested again using 4.0b2. It's definitely real. I also tried scaling up with textSize(50) and got the same problem.

Because the v1.2 .vlw works and not the v4.0 vlw, I think this means the error is happening at font creation time and not at display time.

For the screenshots above I used this code:

PFont font12, font40b2;

void setup() {
  size(512, 512);
  font12 = loadFont("SHAKAGRAPHICS08-8-v1.2.vlw");
  font40b2 = loadFont("SHAKAGRAPHICS08-8-v4.0b2.vlw");
  noSmooth();
  textFont(font12, 50);
  textAlign(LEFT, TOP);
}

void draw() {
  background(255);
  fill(0);
  noStroke();
  String str = "Forsaking monastic tradition,\ntwelve jovial friars gave up\ntheir vocation for a questionable\nexistence on the flying trapeze.";
  if (keyPressed) {
    str = "4.0b2\n" + str;
    textFont(font40b2, 50);
  } else {
    str = "1.2\n" + str;
    textFont(font12, 50);
  }
  text(str, 20, 20);
}

And I noticed that the lineHeight from createFont and loadFont seem to be different. From your screenshot it looks like you used createFont (like the code I posted originally).

[processing-bot]

Created by: benfry

Yeah, though createFont() should be giving me the same result (that's why it's not loadFont(), it's generating bitmaps at the specified size). Oh, but I need to turn off the built-in native font as well since this is using the default renderer; I'll take a look again…

[processing-bot]

Created by: benfry

Ok, after way too much time on this just now, I think I'm stumped at this point… It works fine when run from a sketch, i.e.:

  font = createFont("SG08.ttf", 8, false, PFont.CHARSET);
  try {
    font.save(createOutput("data/shaka-p5.vlw"));
  } catch (Exception e) {
    e.printStackTrace();
  }

And you can check the work with:

  PImage dimg = font.getGlyph('d').image;
  dimg.save(desktopPath("d-p5.png"));
  PImage pimg = font.getGlyph('p').image;
  pimg.save(desktopPath("p-p5.png"));

…which will save a PNG file that should have nothing around the edges (no black border if you zoom into the image with Preview or whatever).

But somehow it's broken when what should be the same code is called from the Create Font command. At this point, it may be a Java issue, because it seems to be forcing the offscreen buffer to be anti-aliased, even if I reset that when drawing each character.

Perhaps tellingly, checking/un-checking the “Smooth” box in the Create Font tool won't actually disable smoothing. But still, we have it working properly when used inside a sketch.

Also tried launching the PDE with -Dawt.useSystemAAFontSettings=false and that didn't help.

Back to paintComponent() for the preview in Create Font, this output:

System.out.println(getToolkit().getDesktopProperty("awt.font.desktophints"));

will show on macOS that the anti-aliasing is turned on by default. Not sure if that's just the default, and our setRenderingHint() call should fix it, or if it suggests that there's a Swing-based property that's overriding our code. Changing the properties isn't possible because the method is protected:

Map map = (Map) getToolkit().getDesktopProperty("awt.font.desktophints");
map.put(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_OFF);
getToolkit().setDesktopProperty("awt.font.desktophints", map);  // no can do

So… after a few hours I didn't have, I'm gonna have to set this one down for a bit. The workaround for now is to use createFont() and then font.save() like above.

[processing-bot]

Created by: benfry

Tested and working fine on Windows, which probably means it's fine in Linux too, and it's a macOS quirk.

[processing-bot]

Created by: benfry

Just to reiterate: the problem here is only with the “Create Font” tool that's under the Tools menu on macOS. It's a bug in the macOS version of Java.

To get this working, you can either use a Linux or Windows versions of Processing and use the Create Font tool there. Or on macOS, you can write a short sketch to do it manually:

  font = createFont("yourfontfile.ttf", 8, false, PFont.CHARSET);
  try {
    font.save(createOutput("yourfontname.vlw"));
  } catch (Exception e) {
    e.printStackTrace();
  }

That will create a .vlw file in the sketch folder that has the properly bitmapped font.