Line join issues in exported figures

Specific domains Graphics and plotting
1

When drawing thick lines, the way lines look like differs between Scilab figure window and graphics exported to a file in vector format, e.g. PDF or SVG.

In the Scilab figure window (left), at each point (marked red) the lines just end.

In the figure exported to PDF (right), line segments are joined by a miter. Since the angle between the central line segments is small, the miter extends far beyond the data point.

Scilab figure vs export
Scilab figure vs export1030Ă—386 19.7 KB

In PDF, SVG and JAVA there is a parameter allowing to change the line join from miter to round or bevel. Is there any possibility in Scilab to change parameters for the figure export?

Thank you,
Frank

2

Some additional information:
I searched the Scilab 2025.0.0 source for the word “miter” and found this code snipped in G2DStroke.java :

public G2DStroke(float lineWidth, float[] dash, float phase) {
super(lineWidth, CAP_BUTT, JOIN_MITER, 10.0f, dash, phase);
}

That looks like some hard coded settings for line end (CAP_BUT) and line join (JOIN_MITER).

3

And here is some background why I ask:
I often plot measurement data.
Data series can be quite large, i.e. spacing in x can be pretty small.
Since measurement data has noise, data series is wiggling up and down.
Due to above described effect, visual noise in the exported graphics is a lot higher than real measurement noise.
Like this exported graphics is useless.

4

Hello, and welcome to Scilab’s Discourse !

Feel free to create an issue to illustrate the problem you describe in your last message. Please be constructive by comparing exported graph between Scilab and other system that yields more adequate rendering.

S.

5

Hello,
you mean an issue here?

https://gitlab.com/scilab/scilab/-/issues

Thank you,
Frank

1 Like
6

Yes. Please include some example code. Likely, the visual effect only occurs when using extreme values of line thickness, right ?

7

O.k., I will do that.

The visual effect depends on line thickness and point spacing (in x).
If points are close enough, the same problem occurs with normal line thicknesses.
Making lines thinner is not always a viable solution.

8

To illustrate the different line join styles, I imported the PDF into Inkscape.

Join Styles
Join Styles1447Ă—381 24.9 KB

To describe the problem, I used an artifical case.
For real life measurement data, miter join is by far the worst.

9

In fact the problem is easier to solve for exported graphics, but we have also a line joining problem for onscreen rendering, which is not solvable with the same method (allow to customize the line joining method, at the user level). We can create a new setting to control both outputs (onscreen + vectorial export), but I don’t have the solution of the onscreen case.

S.

10

Actually, onscreen is o.k. for me.
I have not yet found a real life case where onscreen was ugly.
My problem is with export only.
And actually it is export to VECTOR graphics only.
Export to pixel graphics looks like onscreen.

11

Onscreen output is ugly when using large thickness (see your first post).

12

True. But I would not consider this a real life case.

13

see Glitches on curves with relatively large thickness (#17017) · Issues · scilab / scilab · GitLab

14

Sometimes I have seen something like that, too.
Indeed, this could be linked to the issue I reported.

15

No, the onscreen rendering of lines is not done by the piece of code you found there : scilab/modules/scirenderer/src/java/org/scilab/forge/scirenderer/implementation/g2d/motor/G2DStroke.java · minor · scilab / scilab · GitLab

16

I created an issue:

1 Like
17

You are right.
My text was somewhat badly formulated.
I wanted to say, that it might be linked to the issue of onscreen line segments just stopping at the data points.

18

Its is a known problem of openGL (Drawing Antialiased Lines with OpenGL | by Mapbox | maps for developers), with no correct solution. Under Windows, the problem is somewhat hidden by the anti-aliasing (although still present on macOS).

S.