Lines pattern scaling

Hi. I am a new user. After several days of exploring LibreCad I have noticed, that the different line patterns actually have sizes in pixels, not in physical units (mm for example). This way, when you zoom the drawing, the pattern of the line actually changes (in mm):

You can see, that on both screenshots, the size of the dash is always 48px, while the elements in mm change in size.

Is it intentional, because of some reason, or this is known problem, that can't be fixed for some reason?





Here is the text from "About":

Version: 2.2.0-undef
Compiler: GNU GCC 13.2.1
Compiled on: Nov  7 2023
Qt Version: 5.15.16
Boost Version: 1.83.0
System: Manjaro Linux

We reworked line patterns in. 2.2.1( to be released soon, pending Linux snap support).

Please try 2.2.1 or even 2.2.2 available at our GitHub page.

Thanks. I am compiling right now. BTW, according to the documentation, it needs qmake, but with the recent versions, you need (at least in Arch) to use qmake6, or else "make" breaks with error.

Well, I have tried:

Version: 2.2.2_alpha1-207-g7838da61f
Compiler: GNU GCC 14.2.1
Compiled on: Dec  2 2024
Qt Version: 6.8.0
Boost Version: 1.86.0
System: Arch Linux

But the line patters seems to be still in pixels, as shown in the my first post.

Or maybe I am doing something wrong? Should I activate some option or something?

I am attaching a file with a test project that illustrates the difference. The left dash-dot line is as it should be (IMHO) and the right dash-dot line is as it is now. Try to zoom in-out and export to pdf in order to see the difference.

good-lines-bad-lines.gz

Well, today I have fixed the line pattern scaling (well, or changed it as I like, if not broken):

The source code diff here

And also, changed this annoying dash line selection to something better:

Better selection tool here

Oh, that's great - I'll take a look on this in details, especially for the pattern scaling.  I'm slightly concerned there regarding different drawing units, so I think we have to check this deeper.

As for using alpha approach - well... I suspect that some quite interesting side effects may occur there - especially with combination with antialiasing, and so far I'm not sure about rendering performance if lot's of entities are selected. Probably it will look better in some environments, yet it's necessary to check how portable is such approach.

I think I'll pick your changes, test them and probably add an options that will define how to select entities.
Just changing default selection mode may be confusing for existing users.

sand1024 wrote

Oh, that's great - I'll take a look on this in details, especially for the pattern scaling.  I'm slightly concerned there regarding different drawing units, so I think we have to check this deeper.

Oh, wait a minute. This is not the correct solution. Now I know what is the problem and think I have the correct solution. It is simple and will commit it tomorrow. The trick is that Qt does not measure the line patterns in pixels, but in line widths. So we need to convert from mm to line widths, not to pixels.

Well, it seems I have a working solution of the problem with the line scaling.

Here is the commit:

https://asm32.info/fossil/librecad/info/679836fcf52e840c

But some bugs and glitches are possible.

I have tested it on the display, print preview and pdf export and everything seems to be OK. But still there are too many combinations between the different line widths and line screen widths and this makes the code too complex.

Here is a dxf file, I used for the tests:

dashed-lines.dxf

The left "center line" and the right "fake center line" should always look equal if everything is OK.

Hi johnfound,

Just want to be confirm with you on a few items:

1. in rs_linetypepattern.cpp, it is stated the patterns are defined in pixels. I few we may have to redefine this one. Better to make LibreCAD patterns defined in physical distances, like mm/inches. By defining line patterns in display/rendering space allows zooming in/out, with roughly the same line pattern appearance;
2. Qt line patterns are defined in line widths, and line width is taken as 1 pixels, if defined to be 0;
3. If we define LibreCAD line patterns in mm,
    p_Qt = p_LC * dpmm/(lineWidth)

with p_Qt and p_LC as the pattern values for QPen and LibreCAD (rs_linetypepattern), dpmm as the standard dots per mm, and lineWidth the line width in pixels.

A few things need improvement:

1. the cap style effects on line patterns;
2. DPMM may not be reliable;
3. connected entities, like polylines and splines.

johnfound wrote

Well, it seems I have a working solution of the problem with the line scaling.

Here is the commit:

https://asm32.info/fossil/librecad/info/679836fcf52e840c

But some bugs and glitches are possible.

I have tested it on the display, print preview and pdf export and everything seems to be OK. But still there are too many combinations between the different line widths and line screen widths and this makes the code too complex.

Here is a dxf file, I used for the tests:

dashed-lines.dxf

The left "center line" and the right "fake center line" should always look equal if everything is OK.

dxli wrote

1. in rs_linetypepattern.cpp, it is stated the patterns are defined in pixels. I few we may have to redefine this one. Better to make LibreCAD patterns defined in physical distances, like mm/inches. By defining line patterns in display/rendering space allows zooming in/out, with roughly the same line pattern appearance;

Actually, the patterns are not defined in pixels and I think they never was. In the official versions, they are converted to pixels by multiplying with some constant and displayed this way.

In my version, they are interpreted as a millimeters and displayed this way.

dxli wrote

2. Qt line patterns are defined in line widths, and line width is taken as 1 pixels, if defined to be 0;
3. If we define LibreCAD line patterns in mm,
    p_Qt = p_LC * dpmm/(lineWidth)

with p_Qt and p_LC as the pattern values for QPen and LibreCAD (rs_linetypepattern), dpmm as the standard dots per mm, and lineWidth the line width in pixels.

This formula is not working in the current implementation, because there dpmm is simply a constant, somehow related to the screen/paper size. For correct work, we need dpmm = (pixes_size_on_the_screen/object_mm_size). But if so, then for some line dpmm = lineWidth_px/lineWidth_mm and then the formula becomes:

p_Qt = p_LC_mm/lineWidth_mm

My changes, provide exactly this - correct conversion from mm (in rs_linetypepattern.cpp) to relative units, needed by Qt.
Here is a link to rs_painter.cpp/ RS_Painter::SetPen() in my version:  

The conversion

How the k constant is computed

And you can check it simply by pulling the recent commit from my working repo: jf_fixes branch and test it.

If you don't want to mess with fossil, here is a download link for the source: LibreCad_jf_fixes.tar.gz

just checked the latest master.

I can see patterns are actually scaling with the entities.

This is wrong, so your fix is needed to make the pattern size defined in the viewing space, so the sizes stay roughly the same when zoomming in/out.

johnfound wrote

dxli wrote

1. in rs_linetypepattern.cpp, it is stated the patterns are defined in pixels. I few we may have to redefine this one. Better to make LibreCAD patterns defined in physical distances, like mm/inches. By defining line patterns in display/rendering space allows zooming in/out, with roughly the same line pattern appearance;

Actually, the patterns are not defined in pixels and I think they never was. In the official versions, they are converted to pixels by multiplying with some constant and displayed this way.

In my version, they are interpreted as a millimeters and displayed this way.

dxli wrote

2. Qt line patterns are defined in line widths, and line width is taken as 1 pixels, if defined to be 0;
3. If we define LibreCAD line patterns in mm,
    p_Qt = p_LC * dpmm/(lineWidth)

with p_Qt and p_LC as the pattern values for QPen and LibreCAD (rs_linetypepattern), dpmm as the standard dots per mm, and lineWidth the line width in pixels.

This formula is not working in the current implementation, because there dpmm is simply a constant, somehow related to the screen/paper size. For correct work, we need dpmm = (pixes_size_on_the_screen/object_mm_size). But if so, then for some line dpmm = lineWidth_px/lineWidth_mm and then the formula becomes:

p_Qt = p_LC_mm/lineWidth_mm

My changes, provide exactly this - correct conversion from mm (in rs_linetypepattern.cpp) to relative units, needed by Qt.
Here is a link to rs_painter.cpp/ RS_Painter::SetPen() in my version:  

The conversion

How the k constant is computed

And you can check it simply by pulling the recent commit from my working repo: jf_fixes branch and test it.

If you don't want to mess with fossil, here is a download link for the source: LibreCad_jf_fixes.tar.gz

dxli wrote

just checked the latest master.

Hm, what you actually checked? What master?

I mean the master branch 2.2.2_alpha.

1, draw a dashed line(or any curves, the curve type is not the concern here).

2, To test, zoom in and out.

Expected behavior:

The line dash size should be roughly preserved, not sensitive to zooming factors.

The actual behavior:

The line dash size scales with zooming, so dash sizes get larger when zoomed out.

johnfound wrote

dxli wrote

just checked the latest master.

Hm, what you actually checked? What master?

dxli wrote

I mean the master branch 2.2.2_alpha.

Oh. I see.

Hm, do you actually read my post, about that I have a working fix for the lines pattern scaling. And I have posted several times a links to the sources. With the fixed problem with the line scaling.

On the LibreCad I am using right now, the line patterns scale properly.

Or we are talking about something else? I am actually confused.

What are we talking about? Please, explain.