Potential "hatching" script

[Ofnuts]

How would that work?

• I assume we can't avoid specifying an angle and a spacing.
  
• Should the script do the path rendering (and so take a thickness as a parameter, and may be some "dot ratio"), 
  
• Should the path be kept
  
• Or two options above combined in render and discard path/don't render and path (as written, calling the script  on the same layer with the same specs will always produce the same lines, so successive hatchings in different areas will remain aligned
  
• Should the script be able to separate odd/even lines
  
• Ini file for defaults?
  
• Ini files for several defaults?
  

Current status:

• Creates path lines with spacing and angle that cover the active drawable.
  
• Rendering is manual (and so abides to any existing selection)
  

A 30° Hatching, with 4px spacing and .8px line width:

   

[denzjos]

Ofnuts, thank you for the effort to create this script. Some remarks (as you ask I presume)
I assume we can't avoid specifying an angle and a spacing. (OK)
Should the script do the path rendering (and so take a thickness as a parameter, and may be some "dot ratio"),(same lines as in the stroke style / line style would be nice) 
Should the path be kept (toggle button yes/no is preferable)
Or two options above combined in render and discard path/don't render and path (as written, calling the script  on the same layer with the same specs will always produce the same lines, so successive hatchings in different areas will remain aligned
Should the script be able to separate odd/even lines
Ini file for defaults? 
Ini files for several defaults?(if possible,yes, spacing, line width and line style)
Current status:
Creates path lines with spacing and angle that cover the active drawable.(already ok) 
Rendering is manual (and so abides to any existing selection) (yes, no problem)

Some examples :
   

[Krikor]

The current status already seems very good. If it is possible to meet the ideas of the denzjos it would be excellent.

[Ofnuts]

(08-29-2020, 05:49 PM)denzjos Wrote: Ofnuts, thank you for the effort to create this script. Some remarks (as you ask I presume)
I assume we can't avoid specifying an angle and a spacing. (OK)
Should the script do the path rendering (and so take a thickness as a parameter, and may be some "dot ratio"),(same lines as in the stroke style / line style would be nice) 
Should the path be kept (toggle button yes/no is preferable)
Or two options above combined in render and discard path/don't render and path (as written, calling the script  on the same layer with the same specs will always produce the same lines, so successive hatchings in different areas will remain aligned
Should the script be able to separate odd/even lines
Ini file for defaults? 
Ini files for several defaults?(if possible,yes, spacing, line width and line style)
Current status:
Creates path lines with spacing and angle that cover the active drawable.(already ok) 
Rendering is manual (and so abides to any existing selection) (yes, no problem)

Some examples :

I assume that all these examples will still have variable spacing and line thickness (depending on the image scale).

For the rest (at least for those that have a single direction) it could be possible to have a "cycle" on dot ratio (100% for continuous line, and 0% for missing lines) as well as dot offset (which is the sore point here, my lines start on the edges of the layer, to have the dots aligned all lines should have an origin on the edges of some rotated rectangle, so I have to give this some further thought).

[Ofnuts]

Matter of convention: something that goes up as it goes to the right (as in my example above) has a positive or a negative angle?

[denzjos]

You mean something like the ANSI38 for aluminium? No need for that. There are a lot of hatch types for different materials, this should be to difficult with a lot of parameters to to make a script for all the types.  Ex. : https://www.reddit.com/r/coolguides/comm...different/

[Ofnuts]

Making some progress: presets allow to generate some complex stuff:

   

Basically a "style" is an angle, a spacing and  a thickness. In addition one of more dash patterns can be applied cyclically to the lines. Values can be left unspecified so that they take their value from the parameter dialog. So you can for instance have a style that is always at 45° and another one that takes whatever angle is specified in the UI.

Now, one last question, should the thickness of the lines be expressed as an absolute size , for instance 5px, or should it be a ratio of the spacing? Since everything that defines the dash patterns is expressed as a ratio of the thickness, having the thickness expressed as as ratio of the spacing would make the whole preset scalable by just changing the spacing.

Donning my spanish cardinal hat: one more last question: the presets are kept in a file which is loosely based on the .ini but it is not very practical. Would JSON format be too technical? All decent text editors support it:

Current INI:

Code:

[Complex]
angle: 45
dashPeriod1: 20
dashPeriod2: 4
dashPeriod3: 20
dashPeriod4: 4
dashPeriod5: 20
dashRatio1: 100
dashRatio5: 100
dashRatio2: 50
dashRatio3: 50
dashRatio4: 50
dashOffset1: 0
dashOffset2: 0
dashOffset3: 0
dashOffset4: 0
dashOffset5: 0

The equivalent JSON would look like:

Code:

{
    "Name":"Complex",
    "Angle": 45,
    "Dashes": [
        {   
            "dashPeriod":20,
            "dashRatio":100,
            "dashOffset":0
        },
        {   
            "dashPeriod":4,
            "dashRatio":50,
            "dashOffset":0
        },
        {   
            "dashPeriod":20,
            "dashRatio":50,
            "dashOffset":0
        },
        {   
            "dashPeriod":4,
            "dashRatio":50,
            "dashOffset":0
        },
        {   
            "dashPeriod":20,
            "dashRatio":100,
            "dashOffset":0
        }
    ]
}

One benefit of JSON is that if you use several dash patterns you don't have to keep track of their index which is implicitly determined by their position.

[Krikor]

It would be much easier to give an opinion if it were possible to verify the differences in these options in practice.

But from the above, it seems that the thickness could be a ratio of the spacing and the JSON format for the presets seems to be the best option here.

[denzjos]

Nice work ofnuts. The thickness of the lines would be not dependent from the spacing. If one have a big drawing then the lines would be to thick if they are depending from the spacing. Otherwise, in a small drawing the spacing could be to small. There would be only a few dimensions of drawings where the ratio looks nice. It is preferable to have a parameter to choose the line thickness and a parameter to choose the spacing. (if it is possible) Thanks for the work that is already done.   

[Ofnuts]

OK, found a way to support both absolute width and spacing-scaled width. To wit, the benefits of autoscaling: