Empathy List Archives

A

arnholm@arnholm.org

Sat, Nov 16, 2019 7:30 PM

On 2019-11-16 20:17, Torsten Paul wrote:

The question is not so much if it's worth it, but if
someone cares enough to actually spend the time to
DO it.

https://github.com/arnholm/spacelibs/blob/master/spaceio/obj_io.h

On 2019-11-16 20:17, Torsten Paul wrote: > The question is not so much if it's worth it, but if > someone cares enough to actually spend the time to > DO it. https://github.com/arnholm/spacelibs/blob/master/spaceio/obj_io.h

MM

Michael Marx

Sat, Nov 16, 2019 11:33 PM

So, if there was a mode/option/parameter that said 'touch'=='join', is there a down side to

solidify an edge/point to create a solid join?

Seems like a horrible bodge to me. Much better to overlap the cubes if you want then joined or
separate them slightly if you don't.

This is coming from the 'make it easier' perspective for casual users (and experienced ones too).

It is easy to fix with two cubes, what gets me and others as seen in the Forums, is when it is a
co-incident edge or point in the guts of a complex model.

Take this for example (thing to insert into Dyson handstick wall-mount to hold multiple
accessories)

As Doug said 'STL can't represent curved surfaces, it can only represent a polyhedral
approximation'.

That thing has so many curved surfaces [aka flat rectangles at angles] interfacing to each other
and actual flat surfaces, that in it's development I frequently ran into non-manifold conditions,
and also due to (I believe) the small number problem, producing self intersections.

You do some modelling, render, sometimes get the OpenSCAD non-manifold warning, or don't and
export, load it into Netfabb and get the dreaded triangle icon.

Sometimes even a small change in $fn will change alignment of edges and introduce the problem.

Yes there are techniques to reduce the likelihood, but they take a lot of experience to get to that
point.

I then have to drill into the area of the model, work out which cylinder's edge (usual culprit) has
managed to line-up to something.

That thing is also made up of parts, which get positioned and joined to form various
configurations.

e.g. (thing to screw to wall to hold Dyson accessories with a large head, at an angle to it clears
the wall)

See all those curves meeting in the middle?

Or rather all those edges at angles?

It took me days to work out how to get a clean version of that.

If co-incident edges can be detected and (yes) 'fudged' with a little teeny-weeny sub-micron solid
glue it would make life much easier...

(In my experience it is usually only one or two edges causing the issue)

Isn't the whole idea of software to have it do the hard work for you?

Doug's wrong about some other export formats not having the problem BTW, so that can't fix it. But
that's another post...

> So, if there was a mode/option/parameter that said 'touch'=='join', is there a down side to solidify an edge/point to create a solid join? Seems like a horrible bodge to me. Much better to overlap the cubes if you want then joined or separate them slightly if you don't. This is coming from the 'make it easier' perspective for casual users (and experienced ones too). It is easy to fix with two cubes, what gets me and others as seen in the Forums, is when it is a co-incident edge or point in the guts of a complex model. Take this for example (thing to insert into Dyson handstick wall-mount to hold multiple accessories) As Doug said 'STL can't represent curved surfaces, it can only represent a polyhedral approximation'. That thing has so many curved surfaces [aka flat rectangles at angles] interfacing to each other and actual flat surfaces, that in it's development I frequently ran into non-manifold conditions, and also due to (I believe) the small number problem, producing self intersections. You do some modelling, render, sometimes get the OpenSCAD non-manifold warning, or don't and export, load it into Netfabb and get the dreaded triangle icon. Sometimes even a small change in $fn will change alignment of edges and introduce the problem. Yes there are techniques to reduce the likelihood, but they take a lot of experience to get to that point. I then have to drill into the area of the model, work out which cylinder's edge (usual culprit) has managed to line-up to something. That thing is also made up of parts, which get positioned and joined to form various configurations. e.g. (thing to screw to wall to hold Dyson accessories with a large head, at an angle to it clears the wall) See all those curves meeting in the middle? Or rather all those edges at angles? It took me days to work out how to get a clean version of that. If co-incident edges can be detected and (yes) 'fudged' with a little teeny-weeny sub-micron solid glue it would make life much easier... (In my experience it is usually only one or two edges causing the issue) Isn't the whole idea of software to have it do the hard work for you? Doug's wrong about some other export formats not having the problem BTW, so that can't fix it. But that's another post...

MM

Michael Marx

Sun, Nov 17, 2019 3:19 AM

I only have Netfabb Basic, which doesn't do automatic repairs,

Same here, it does have automatic repairs for some things; see Extra/Repair-part. Basic does not
fix self-intersections :-( tho.

That, plus the extra Export repair, is what I applied in my earlier email. The Export repair split
the non-manifold edge as I described.

When import into MeshLab, it detects corruption, and asks if I want to repair it. The dialog says
"Unify duplicated vertices?".

In my experience this is not 'detecting' corruption, it asks that for all STLs.

It does seem to handle bad STLs (I mean really bad like some of the 3D scans), better when you do
unify them, but for others it doesn't seem to do much if anything.

It has not fixed the non-manifold edge, see Render/Show-non-manif-edges (and vertices),
(show-non-faux-edges & show-vertex-dots are good too).

Then I export to an OBJ file, which includes topology information. Then, when I import that same
OBJ file into MeshLab, it does not report any errors.

With the above options, MeshLab shows that the OBJ still has the non-manifold edge. I couldn't
check OFF, my older MeshLab doesn't have it, the latest doesn't run via RDP...

When loading OBJ into Netfabb, Repair/Detect-self-intersections, highlights the line. [what that
means to the future of humanity, nobody knows...]

So the problem is still there. A slicer would still need to figure out whether to do a left or
right turn in the middle.

To me (not someone who studies this topic mathematically) it boils down to: is it two objects or
one?

What says that the surface of one cube is a continuation of the surface of the other? Or not?

Isn't it inherently ambiguous?

So something has to be done to consider it one way or the other.

One could consider some 'accepted practice' [in a particular context] that says, hell they are
touching, so why not consider them whole?

Or, as the designer clearly didn't insert one within the surface of the other, they must have
wanted them separate, so make it so.

OpenSCAD already does the former, for:

cube(10);

translate([10,0,0]) cube(10);

That is a solid 20x10x10, no question about it.

OpenSCAD doesn't need to do anything out of the ordinary to do so though.

I'm suggesting that OpenSCAD remove the ambiguity of touching non-manifolds too, by adding the
smallest amount of solid to the edge.

I only have Netfabb Basic, which doesn't do automatic repairs, Same here, it does have automatic repairs for some things; see Extra/Repair-part. Basic does not fix self-intersections :-( tho. That, plus the extra Export repair, is what I applied in my earlier email. The Export repair split the non-manifold edge as I described. When import into MeshLab, it detects corruption, and asks if I want to repair it. The dialog says "Unify duplicated vertices?". In my experience this is not 'detecting' corruption, it asks that for all STLs. It does seem to handle bad STLs (I mean really bad like some of the 3D scans), better when you do unify them, but for others it doesn't seem to do much if anything. It has not fixed the non-manifold edge, see Render/Show-non-manif-edges (and vertices), (show-non-faux-edges & show-vertex-dots are good too). Then I export to an OBJ file, which includes topology information. Then, when I import that same OBJ file into MeshLab, it does not report any errors. With the above options, MeshLab shows that the OBJ still has the non-manifold edge. I couldn't check OFF, my older MeshLab doesn't have it, the latest doesn't run via RDP... When loading OBJ into Netfabb, Repair/Detect-self-intersections, highlights the line. [what that means to the future of humanity, nobody knows...] So the problem is still there. A slicer would still need to figure out whether to do a left or right turn in the middle. To me (not someone who studies this topic mathematically) it boils down to: is it two objects or one? What says that the surface of one cube is a continuation of the surface of the other? Or not? Isn't it inherently ambiguous? So something has to be done to consider it one way or the other. One could consider some 'accepted practice' [in a particular context] that says, hell they are touching, so why not consider them whole? Or, as the designer clearly didn't insert one within the surface of the other, they must have wanted them separate, so make it so. OpenSCAD already does the former, for: cube(10); translate([10,0,0]) cube(10); That is a solid 20x10x10, no question about it. OpenSCAD doesn't need to do anything out of the ordinary to do so though. I'm suggesting that OpenSCAD remove the ambiguity of touching non-manifolds too, by adding the smallest amount of solid to the edge.

MM

Michael Marx

Sun, Nov 17, 2019 3:28 AM

Doug wrote:

3D printing hardware is somewhat crippled by the software used to drive it. Most slicers only
accept mesh representations of 3D solids, and that's a problem. We've already discussed one issue,
which is STL's problem with representing the 2 cubes model. Other mesh formats like OBJ and 3MF
solve that problem.

What is happening with OpenSCAD 3MF export?

For the two-cube in question it gets:

EXPORT-WARNING: Export failed, the object isn't a valid 2-manifold.

3MF export finished: C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/tests/manifold/non-manifold-b.3mf

Doug, you have said you'd like OpenSCAD to

Support export of valid 3MF files (with correct topology information included, unlike today)

What does 3MF (corrected) say the two-cube would be?

Doug wrote: 3D printing hardware is somewhat crippled by the software used to drive it. Most slicers only accept mesh representations of 3D solids, and that's a problem. We've already discussed one issue, which is STL's problem with representing the 2 cubes model. Other mesh formats like OBJ and 3MF solve that problem. What is happening with OpenSCAD 3MF export? For the two-cube in question it gets: EXPORT-WARNING: Export failed, the object isn't a valid 2-manifold. 3MF export finished: C:/Users/MeB/Documents/3D-REPRAP/Things/My Things/tests/manifold/non-manifold-b.3mf Doug, you have said you'd like OpenSCAD to Support export of valid 3MF files (with correct topology information included, unlike today) What does 3MF (corrected) say the two-cube would be?

RP

Ronaldo Persiano

Sun, Nov 17, 2019 4:06 AM

nop head nop.head@gmail.com wrote:

Yes but they seem to have chosen the wrong interpretation of self
intersections. I.e. exclusive oring overlapping solids instead of unioning
them. So at least slicers will be consistent, i.e. consistently wrong, so
forcing people to fix their models if they slice it with a compliant slicer
before publishing.

That is not right. According to the positive fill rule of the 3MF
specification the filling of two overlapping squares both with
counter-clockwise winding will be their union. If just one has
clockwise winding,
the result will be their difference; and if both have clockwise winding
everything vanishes.

The "exclusive or" of the areas is what OpenSCAD does independent of the
winding.

polygon([ [0,0],[2,0],[2,2],[0,2],[1,1],[3,1],[3,3],[1,3] ],
[ [0,1,2,3], [4,5,6,7] ]);

This is consistent with the OpenSCAD filling of polygons with a hole,
even when the hole is clockwise:

polygon([ [0,0],[2,0],[2,2],[0,2],[0.5,0.5],[1.5,0.5],[1.5,1.5],[0.5,1.5] ],
[ [0,1,2,3], [4,5,6,7] ]);

For a self-intersecting polygon of the figure-8, the positive rule will
keep one ring (the one with counter-clockwise winding) and discard the
other.

To the contrary both are preserved by OpenSCAD:

polygon( [ [-1,-1],[1,1],[2,0],[1,-1],[-1,1],[-2,0] ],
[ [0,1,2,3,4,5] ]);

The filling by the positive rule of polygons with many self-intersections
is hard to anticipate.

nop head <nop.head@gmail.com> wrote: > Yes but they seem to have chosen the wrong interpretation of self > intersections. I.e. exclusive oring overlapping solids instead of unioning > them. So at least slicers will be consistent, i.e. consistently wrong, so > forcing people to fix their models if they slice it with a compliant slicer > before publishing. > That is not right. According to the positive fill rule of the 3MF specification the filling of two overlapping squares both with counter-clockwise winding will be their union. If just one has clockwise winding, the result will be their difference; and if both have clockwise winding everything vanishes. The "exclusive or" of the areas is what OpenSCAD does independent of the winding. polygon([ [0,0],[2,0],[2,2],[0,2],[1,1],[3,1],[3,3],[1,3] ], [ [0,1,2,3], [4,5,6,7] ]); This is consistent with the OpenSCAD filling of polygons with a hole, even when the hole is clockwise: polygon([ [0,0],[2,0],[2,2],[0,2],[0.5,0.5],[1.5,0.5],[1.5,1.5],[0.5,1.5] ], [ [0,1,2,3], [4,5,6,7] ]); For a self-intersecting polygon of the figure-8, the positive rule will keep one ring (the one with counter-clockwise winding) and discard the other. To the contrary both are preserved by OpenSCAD: polygon( [ [-1,-1],[1,1],[2,0],[1,-1],[-1,1],[-2,0] ], [ [0,1,2,3,4,5] ]); The filling by the positive rule of polygons with many self-intersections is hard to anticipate.

A

arnholm@arnholm.org

Sun, Nov 17, 2019 7:28 AM

On 2019-11-17 00:33, Michael Marx wrote:

As Doug said 'STL can't represent curved surfaces, it can only
represent a polyhedral approximation'.

That's true of anything that comes out of OpenSCAD or any other mesh
based modeller, it is nothing particular to STL, OBJ, OFF, AMF or
whatever format you choose. A mesh representation is a finite
approximation, of course it is.

It is not the file format, is the core modeller.

If you took the CGAL library and replaced it with another library based
on CAD BREP style datastructure, for example OpenCASCADE
https://dev.opencascade.org/ the situation would be different, and you
could output STEP files or other formats with accurate respresentation
of curved geometry. But as long as the core model is a mesh
representation, the output will be a polyhedral approximation.

Carsten Arnholm

On 2019-11-17 00:33, Michael Marx wrote: > As Doug said 'STL can't represent curved surfaces, it can only > represent a polyhedral approximation'. That's true of anything that comes out of OpenSCAD or any other mesh based modeller, it is nothing particular to STL, OBJ, OFF, AMF or whatever format you choose. A mesh representation is a finite approximation, of course it is. It is not the file format, is the core modeller. If you took the CGAL library and replaced it with another library based on CAD BREP style datastructure, for example OpenCASCADE https://dev.opencascade.org/ the situation would be different, and you could output STEP files or other formats with accurate respresentation of curved geometry. But as long as the core model is a mesh representation, the output will be a polyhedral approximation. Carsten Arnholm

NH

nop head

Sun, Nov 17, 2019 8:25 AM

I frequently ran into non-manifold conditions, and also due to (I

believe) the small number problem, producing self intersections.

The problem is OpenSCAD snaps to a grid and then stores the result as a
polygon soup. That can create non-manifold geometry whenever there are very
close vertices. It is a massive bug to truncate vertex coordinates and not
fix the mesh.

On Sun, 17 Nov 2019 at 07:29, arnholm@arnholm.org wrote:

On 2019-11-17 00:33, Michael Marx wrote:

As Doug said 'STL can't represent curved surfaces, it can only
represent a polyhedral approximation'.

That's true of anything that comes out of OpenSCAD or any other mesh
based modeller, it is nothing particular to STL, OBJ, OFF, AMF or
whatever format you choose. A mesh representation is a finite
approximation, of course it is.

It is not the file format, is the core modeller.

If you took the CGAL library and replaced it with another library based
on CAD BREP style datastructure, for example OpenCASCADE
https://dev.opencascade.org/ the situation would be different, and you
could output STEP files or other formats with accurate respresentation
of curved geometry. But as long as the core model is a mesh
representation, the output will be a polyhedral approximation.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

> I frequently ran into non-manifold conditions, and also due to (I believe) the small number problem, producing self intersections. The problem is OpenSCAD snaps to a grid and then stores the result as a polygon soup. That can create non-manifold geometry whenever there are very close vertices. It is a massive bug to truncate vertex coordinates and not fix the mesh. On Sun, 17 Nov 2019 at 07:29, <arnholm@arnholm.org> wrote: > On 2019-11-17 00:33, Michael Marx wrote: > > As Doug said 'STL can't represent curved surfaces, it can only > > represent a polyhedral approximation'. > > That's true of anything that comes out of OpenSCAD or any other mesh > based modeller, it is nothing particular to STL, OBJ, OFF, AMF or > whatever format you choose. A mesh representation is a finite > approximation, of course it is. > > It is not the file format, is the core modeller. > > If you took the CGAL library and replaced it with another library based > on CAD BREP style datastructure, for example OpenCASCADE > https://dev.opencascade.org/ the situation would be different, and you > could output STEP files or other formats with accurate respresentation > of curved geometry. But as long as the core model is a mesh > representation, the output will be a polyhedral approximation. > > Carsten Arnholm > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

MM

Michael Marx

Sun, Nov 17, 2019 9:29 AM

I frequently ran into non-manifold conditions, and also due to (I believe) the small number

problem, producing self intersections.

The problem is OpenSCAD snaps to a grid and then stores the result as a polygon soup. That can
create non-manifold geometry whenever there are very close vertices. It is a massive bug to
truncate vertex coordinates and not fix the mesh.

Agreed, however with floats it will still be a problem, perhaps lesser, without the grid.

The two-cube-edge will be a problem regardless of grids/floats.

From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of nop head
Sent: Sun, 17 Nov 2019 19:26
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] Discuss manifoldness, co-incident faces edges etc

On Sun, 17 Nov 2019 at 07:29, arnholm@arnholm.org wrote:

On 2019-11-17 00:33, Michael Marx wrote:

As Doug said 'STL can't represent curved surfaces, it can only
represent a polyhedral approximation'.

That's true of anything that comes out of OpenSCAD or any other mesh
based modeller, it is nothing particular to STL, OBJ, OFF, AMF or
whatever format you choose. A mesh representation is a finite
approximation, of course it is.

It is not the file format, is the core modeller.

If you took the CGAL library and replaced it with another library based
on CAD BREP style datastructure, for example OpenCASCADE
https://dev.opencascade.org/ the situation would be different, and you
could output STEP files or other formats with accurate respresentation
of curved geometry. But as long as the core model is a mesh
representation, the output will be a polyhedral approximation.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

> I frequently ran into non-manifold conditions, and also due to (I believe) the small number problem, producing self intersections. The problem is OpenSCAD snaps to a grid and then stores the result as a polygon soup. That can create non-manifold geometry whenever there are very close vertices. It is a massive bug to truncate vertex coordinates and not fix the mesh. Agreed, however with floats it will still be a problem, perhaps lesser, without the grid. The two-cube-edge will be a problem regardless of grids/floats. _____ From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of nop head Sent: Sun, 17 Nov 2019 19:26 To: OpenSCAD general discussion Subject: Re: [OpenSCAD] Discuss manifoldness, co-incident faces edges etc On Sun, 17 Nov 2019 at 07:29, <arnholm@arnholm.org> wrote: On 2019-11-17 00:33, Michael Marx wrote: > As Doug said 'STL can't represent curved surfaces, it can only > represent a polyhedral approximation'. That's true of anything that comes out of OpenSCAD or any other mesh based modeller, it is nothing particular to STL, OBJ, OFF, AMF or whatever format you choose. A mesh representation is a finite approximation, of course it is. It is not the file format, is the core modeller. If you took the CGAL library and replaced it with another library based on CAD BREP style datastructure, for example OpenCASCADE https://dev.opencascade.org/ the situation would be different, and you could output STEP files or other formats with accurate respresentation of curved geometry. But as long as the core model is a mesh representation, the output will be a polyhedral approximation. Carsten Arnholm _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

NH

nop head

Sun, Nov 17, 2019 11:44 AM

On Sun, 17 Nov 2019 at 09:30, Michael Marx michael@marx.id.au wrote:

I frequently ran into non-manifold conditions, and also due to (I

believe) the small number problem, producing self intersections.

The problem is OpenSCAD snaps to a grid and then stores the result as a
polygon soup. That can create non-manifold geometry whenever there are very
close vertices. It is a massive bug to truncate vertex coordinates and not
fix the mesh.

Agreed, however with floats it will still be a problem, perhaps lesser,
without the grid.

Indeed that is why I truncate. Any reduction in resolution from CGALs
rationals can cause a problem.

The two-cube-edge will be a problem regardless of grids/floats.

Yes but I don't regard that as problem, just a reality of this universe I
find myself in. I can easily specify if I want two separate cubes or a
joined pair.

However, if one unions two curved services with a slight overlap then CGAL
will do a perfect job but OpenSCAD might break the result by truncation.
That I regard as a serious bug.

From: Discuss [mailto:discuss-bounces@lists.openscad.org] *On Behalf Of
*nop head
Sent: Sun, 17 Nov 2019 19:26
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] Discuss manifoldness, co-incident faces edges
etc

On Sun, 17 Nov 2019 at 07:29, arnholm@arnholm.org wrote:

On 2019-11-17 00:33, Michael Marx wrote:

As Doug said 'STL can't represent curved surfaces, it can only
represent a polyhedral approximation'.

That's true of anything that comes out of OpenSCAD or any other mesh
based modeller, it is nothing particular to STL, OBJ, OFF, AMF or
whatever format you choose. A mesh representation is a finite
approximation, of course it is.

It is not the file format, is the core modeller.

If you took the CGAL library and replaced it with another library based
on CAD BREP style datastructure, for example OpenCASCADE
https://dev.opencascade.org/ the situation would be different, and you
could output STEP files or other formats with accurate respresentation
of curved geometry. But as long as the core model is a mesh
representation, the output will be a polyhedral approximation.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On Sun, 17 Nov 2019 at 09:30, Michael Marx <michael@marx.id.au> wrote: > > I frequently ran into non-manifold conditions, and also due to (I > believe) the small number problem, producing self intersections. > > > > The problem is OpenSCAD snaps to a grid and then stores the result as a > polygon soup. That can create non-manifold geometry whenever there are very > close vertices. It is a massive bug to truncate vertex coordinates and not > fix the mesh. > > > > Agreed, however with floats it will still be a problem, perhaps lesser, > without the grid. > Indeed that is why I truncate. Any reduction in resolution from CGALs rationals can cause a problem. > The two-cube-edge will be a problem regardless of grids/floats. > Yes but I don't regard that as problem, just a reality of this universe I find myself in. I can easily specify if I want two separate cubes or a joined pair. However, if one unions two curved services with a slight overlap then CGAL will do a perfect job but OpenSCAD might break the result by truncation. That I regard as a serious bug. > > > > ------------------------------ > > *From:* Discuss [mailto:discuss-bounces@lists.openscad.org] *On Behalf Of > *nop head > *Sent:* Sun, 17 Nov 2019 19:26 > *To:* OpenSCAD general discussion > *Subject:* Re: [OpenSCAD] Discuss manifoldness, co-incident faces edges > etc > > > > > > On Sun, 17 Nov 2019 at 07:29, <arnholm@arnholm.org> wrote: > > On 2019-11-17 00:33, Michael Marx wrote: > > As Doug said 'STL can't represent curved surfaces, it can only > > represent a polyhedral approximation'. > > That's true of anything that comes out of OpenSCAD or any other mesh > based modeller, it is nothing particular to STL, OBJ, OFF, AMF or > whatever format you choose. A mesh representation is a finite > approximation, of course it is. > > It is not the file format, is the core modeller. > > If you took the CGAL library and replaced it with another library based > on CAD BREP style datastructure, for example OpenCASCADE > https://dev.opencascade.org/ the situation would be different, and you > could output STEP files or other formats with accurate respresentation > of curved geometry. But as long as the core model is a mesh > representation, the output will be a polyhedral approximation. > > Carsten Arnholm > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

NH

nop head

Sun, Nov 17, 2019 11:45 AM

Indeed that is why I *said *truncate.

On Sun, 17 Nov 2019 at 11:44, nop head nop.head@gmail.com wrote: