B_MITER_JOIN implementation differs from common miter semantics

[thebuck]

Flow of information when viewing SVG in WebPositive

stroke-linejoin: miter in SVG file

↓ some Webkit code, presumably

LineJoin::Miter

↓ void GraphicsContextHaiku::setLineJoin(LineJoin lineJoin) in haikuwebkit/Source/WebCore/platform/graphics/haiku/GraphicsContextHaiku.cpp

B_MITER_JOIN

↓ inline agg::line_join_e agg_line_join_mode_for(join_mode mode) in haiku/src/servers/app/drawing/Painter/Painter.cpp

agg::miter_join

Semantic difference

agg::miter_join cuts off the corner exactly where the miter limit is located, resulting in a semi-bevelled look.

But agg::miter_join_revert is what provides the correct behaviour:
Switching to bevel when miter limit is exceeded.

Conflicting semantics

SVG, PDF, ... the modern world.

Not observed in BePDF: does it have its own stroking implementation?

Proposed fix:

If BeOS B_MITER_JOIN means agg::miter_join_revert, or the difference would not be noticeable in any other application, just map it that way.

Otherwise, introduce a new B_BINARY_MITER_JOIN/B_MITER_BEVEL_JOIN/B_MITER_REVERT_JOIN style...

[X512]

Can you give a raster screenshot that show difference?

[thebuck]

View in WebPositive. The wedge shapes all have to look identical. Right one is correct. (The older version did additionally cut off at the bottom due to image height and so was a not-so-good demo)

[thebuck]

WebPositive render

[thebuck]

From left to right:

• miter join style set, but no miterlimit set, so default of 4.
• no join style set, so default miter, set a miterlimit of 2.
• bevel join set

[thebuck]

There is demonstrated no case of not exceeding the miterlimit. That would result in a sharp corner.