Issues with stroke join for text

[dhowe]

Note that this only occurs when strokeWeight is large in relation to textSize
Setting strokeJoin(ROUND) or strokeJoin(BEVEL) eliminates the problem

Related to #3035 -- steps to reproduce: show font with stroke and large relative strokeWeight:

function setup() {
  createCanvas(750, 500);
  background(150);

  textFont(kingthings);
  textSize(42);

  strokeWeight(4);
  //strokeJoin(ROUND);//BEVEL
  stroke(0);

  fill(255);
  text("if I found a fun igloo", 100, 200);
}

Most appropriate sub-area of p5.js?

• Accessibility (Web Accessibility)
• Build tools and processes
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Friendly error system
• Image
• IO (Input/Output)
• Localization
• Math
• Unit Testing
• Typography
• Utilities
• WebGL
• Other (specify if possible)

Details about the bug:

• p5.js version: p5.js v1.4.0
• Web browser and version: Firefox 92
• Operating System: OS X

[limzykenneth]

Is it the same problem as #3035?

[dhowe]

Definitely related, as noted above...

[limzykenneth]

Does it also happens if this font is rendered in something like Illustrator? Shall we reconsider adding a new miter limit function as proposed before?

[golanlevin]

So, this visual glitch is 'expected behavior', as others have pointed out. If a font (or other shape) has a zig-zag with sufficiently pointy angles, then this is what will happen, period. It is a fundamental geometric property of 2D graphics.

Just my two cents, but:

• having a function to adjust miter limit is a standard feature of professional graphics tools.
• if an end-user is observant enough to notice a miter problem, then this topic is not too arcane for them.

Possible solutions to the issue, from most to least preferable in my opinion, are:

• Add a strokeMiterLimit() function
• Make the problem disappear by lowering the default miter limit (generally values around 4 work well, but perhaps it needs to be smaller). Possibly, use a different miter limit for fonts
• Make the problem disappear by changing the default strokeJoin for fonts to be ROUND (as PhotoShop does)
• Leave things as they are and tell people to deal with it.

[limzykenneth]

I tend to lean towards adding a new function to control this as well. I found before that setting a lower default may cause other drawing issues such as not being able to draw star shape with strokes so I wouldn't recommend it.

However also to add that with the native canvas API, the miter limit can be set with something like below:

canvas = createCanvas(200, 200);
let context = canvas.elt.getContext("2d");
context.miterLimit = 2;

[dhowe]

Easy enough to add a strokeMiterLimit() or similar function... though, as there are existing options, setting strokeJoin() or canvas miter limit (also canvas lineJoin property), perhaps documentation somewhere would suffice (maybe an example on the strokeJoin page)?

[outofambit]

I'm on board with adding a new function for setting a stroke miter limit and adding documentation in strokeJoin, but I'm also really curious about:

Make the problem disappear by changing the default strokeJoin for fonts to be ROUND (as PhotoShop does)

Are there any significant downsides to doing this? It seems like barely perceptible difference for the (probably) vast majority of cases and makes this not an issue folks would hit when playing with large stroke widths.

I think configurability for this is good, but good defaults are good too!

[limzykenneth]

Make the problem disappear by changing the default strokeJoin for fonts to be ROUND (as PhotoShop does)

For a star shape it would mean the points are not "pointy" as they will be rounded, not inherently a problem but also not an uncommon thing that is expected by the user. It can work as a default but we may also need configurability for it.

[munusshih]

Hi! I'm working on this issue as part of my GSoC project. I think adding a textMiterLimit() function makes sense. I'm wondering more about if there's any push back against changing the default context.miterLimit = 1?

[limzykenneth]

@munusshih Instead of textMiterLimit(), the proposed strokeMiterLimit() will probably be more intuitive since this affects all shapes drawn with strokes too.

I would prefer leaving the HTML canvas default (10.0) instead of changing it to 1 as the default here or it could break the behaviour of existing sketch. We can add a short note in the relevant documentation pages hinting that strokeMiterLimit() can be used to change the behaviour.

[davepagurek]

Although WebGL text doesn't support strokes, WebGL strokes for other shapes also have a bit of a miter limit going on in here:

p5.js/src/webgl/shaders/line.vert

Lines 178 to 186 in 6792185

	// When lines are thick and the angle of the join approaches 180, the
	// elbow might be really far from the center. We'll apply a limit to
	// the magnitude to avoid lines going across the whole screen when this
	// happens.
	float mag = length(offset);
	float maxMag = 3. * uStrokeWeight;
	if (mag > maxMag) {
	offset *= maxMag / mag;
	}

It's probably fine to not implement this for WebGL too at the same time, but if we don't, we can maybe make an issue for it so that we remember to implement it there too eventually!

[munusshih]

This is in the making here #6331