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

textWidth() incorrect with default (JAVA2D) renderer and default font #2175

Closed
monkstone opened this Issue Oct 28, 2013 · 6 comments

Comments

Projects
None yet
3 participants
@monkstone

monkstone commented Oct 28, 2013

This is sketch that shows it up...

void setup(){
  size(400, 200);
  String string = "dddddddddddddddd";
  float textlen = textWidth(string);
  text(string, 100, 100);
  stroke(0);
  line(100+textlen, 89, 100+textlen, 102);

  String string2 ="drawerrormmmmmmm";
  float textlen2 = textWidth(string2);
  text(string2, 100, 120);
  line(100+textlen2, 109, 100+textlen2, 122);
}

Works fine with P2D renderer, this issue was reported to me by @marcel12bell over at ruby-processing (it affects his livecoding app which needs to use JAVA2D), and the error seems to be much more pronounced on OSX,

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Oct 28, 2013

Member

Try with a different font and see if it's better. The default font seems to have terrible/frequently incorrect metrics. I'm not sure it's something we can fix (my hands are tied by the metrics returned by Java/the OS) but we may need to change how the default font is handled.

Member

benfry commented Oct 28, 2013

Try with a different font and see if it's better. The default font seems to have terrible/frequently incorrect metrics. I'm not sure it's something we can fix (my hands are tied by the metrics returned by Java/the OS) but we may need to change how the default font is handled.

@benfry benfry changed the title from Error in textWidth in processing-2.1 on linux with default render to textWidth() incorrect with default (JAVA2D) renderer and default font May 10, 2014

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 10, 2014

Member

Updated issue title from "Error in textWidth in processing-2.1 on linux with default render"

Member

benfry commented May 10, 2014

Updated issue title from "Error in textWidth in processing-2.1 on linux with default render"

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone May 11, 2014

If it is fixed on OSX @marcel12bell would be interested. Alignment is perfect on linux when I replace included jvm with a symbolic link to openjdk.

monkstone commented May 11, 2014

If it is fixed on OSX @marcel12bell would be interested. Alignment is perfect on linux when I replace included jvm with a symbolic link to openjdk.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 11, 2014

Member

The OpenJDK fix is probably because it's specific to Lucida, the typeface that's included with the JDK.

Member

benfry commented May 11, 2014

The OpenJDK fix is probably because it's specific to Lucida, the typeface that's included with the JDK.

@quarks

This comment has been minimized.

Show comment
Hide comment
@quarks

quarks Aug 13, 2014

I have experienced the same problem using the Java logical fonts. The way they are mapped to physical fonts means that they do not provide uniform metrics.

Extract from Font.java

    /**
     * Checks whether or not this <code>Font</code> has uniform
     * line metrics.  A logical <code>Font</code> might be a
     * composite font, which means that it is composed of different
     * physical fonts to cover different code ranges.  Each of these
     * fonts might have different <code>LineMetrics</code>.  If the
     * logical <code>Font</code> is a single
     * font then the metrics would be uniform.
     * @return <code>true</code> if this <code>Font</code> has
     * uniform line metrics; <code>false</code> otherwise.
     */
    public boolean hasUniformLineMetrics() {
        return false;   // REMIND always safe, but prevents caller optimize
    }

quarks commented Aug 13, 2014

I have experienced the same problem using the Java logical fonts. The way they are mapped to physical fonts means that they do not provide uniform metrics.

Extract from Font.java

    /**
     * Checks whether or not this <code>Font</code> has uniform
     * line metrics.  A logical <code>Font</code> might be a
     * composite font, which means that it is composed of different
     * physical fonts to cover different code ranges.  Each of these
     * fonts might have different <code>LineMetrics</code>.  If the
     * logical <code>Font</code> is a single
     * font then the metrics would be uniform.
     * @return <code>true</code> if this <code>Font</code> has
     * uniform line metrics; <code>false</code> otherwise.
     */
    public boolean hasUniformLineMetrics() {
        return false;   // REMIND always safe, but prevents caller optimize
    }
@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 12, 2015

Member

Appears to be working properly in 3.0 beta 3.
screen shot 2015-08-12 at 7 53 08 pm

Member

benfry commented Aug 12, 2015

Appears to be working properly in 3.0 beta 3.
screen shot 2015-08-12 at 7 53 08 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment