decimal point in text disappearing
On Thu, 2024-09-05 at 21:32 -0700, Curt McDowell via Discuss wrote:
Wow, this is a bug, not an artifact, and it applies to preview, CGAL,
and Manifold, and it has been there since OpenSCAD first got text().
linear_extrude(6) {
difference(){
square(20);
text("3Z");
}
}
text("3Z") or text("ch"): the Z and h don't show up. That 3 and c have
round bottoms seems to be the trigger.
text("4Z"): the Z shows up
text("3O") or text("cb"): the O and b do show up, apparently because
they also have round bottoms
text("oA") or text("oB" or text("o#"): only the holes in A, B and # show up
text("oi") or text("d%"): only the dot on the i and the o's in the % show up
It may be the font used, but in my test "o%" shows properly.
Checking it further (using # before the text) shows that the '/' in the
% character extends below the baseline.
text("o*") or text("o+"): no problem when the second characters don't
touch baseline
text("/A") or text(",A"): certain other characters like / and , also
trigger the problem.
In other weirdness, adding # for #text() shows a +/-0.5 mm extrusion in
red, instead of a 6 mm extrusion.
This is understandable, I think, because text() is a 2D object, and by
itself is shown as if it was extruded a tiny amount.
On 9/5/24 09:12, Raymond West via Discuss wrote:
Testing further.
It seems if the second number is flat at the bottom, 1,2,7 and aligns
with the base of the square, and the first is a 0,2,3,5,6,8,9 then the
second does not f6 render. 4 is interesting. It's the same for letters.
On 05/09/2024 16:27, larry via Discuss wrote:
On Thu, 2024-09-05 at 16:16 +0100, Raymond West via Discuss wrote:
The following code snippet
//linear_extrude(6){
difference(){
square(20);
text("5.5");
}
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Adding valign="bottom" to the text() command appears to correct the issue.
On 9/5/2024 11:16 AM, Raymond West wrote:
The following code snippet
//linear_extrude(6){
difference(){
square(20);
text("5.5");
}
}
////////////////////// end
fn5 render looks ok
fn6 render dp is filled in, but outline remains
allow linear_extrude, decimal point not showing in fn5 or fn6
OpenSCAD version 2024.02.19 (git 5cfd4dbe0) Is it fixed in later
versions?
Thanks,
Ray
On 9/6/2024 6:34 AM, Douglas Miller via Discuss wrote:
Adding valign="bottom" to the text() command appears to correct the
issue.
Anything that moves the text away from the bottom of the square should
be enough. valign=bottom will fix problems with glyphs that have a
horizontal segment at the baseline, but create problems with glyphs that
have a horizontal segment at the bottom-most point in the string. Given
the finicky nature of this bug - see below - it might be hard to build a
test case.
My expectation was that this behavior would not be tied to text() per
se, but rather to subtracting a 2D object with a coincident edge. And
indeed, here's a test case:
difference() {
square(5);
translate([1,0,0]) square(1,center=true);
translate([3,0,0]) square(1);
}
Preview (tilted to make the Z-fighting visible):
Render:
It seems to require both a coincident edge and another subtraction that
crosses the edge; removing the first square fixes the problem with the
second square.
Using an experimental PR#4478 build that can extract the results of a
render, I get:
{ min : [0, 0, 0], max : [5, 5, 0], center : [2.5, 2.5, 0], size :
[5, 5, 0], objects : [ { points : [ [5, 5], [0, 5], [0, 0], [0.5,
0], [0.5, 0.5], [1.5, 0.5], [1.5, 0], [5, 0], [3, 0], [3, 1], [4,
1], [4, 0] ], paths : [ [0, 1, 2, 3, 4, 5, 6, 7], [8, 9, 10, 11] ] } ] }
The intended square-with-two-cutouts has been turned into a figure that
is a square with one cutout overlapping with another square that should
be the second cutout.
Surprisingly, the same pattern does not produce the same result when the
cutouts are along the Y axis rather than the X axis, nor does it produce
the same results when the cutouts are along the top. Even swapping the
two cutouts yields a "correct" result.
The workaround is, like the similar problem in 3D, to avoid having
negative objects with edges coincident with edges on the positive object.
Yes I have been caught out with 2D differences failing with coincident
edges. I was surprised because 3D differences in CGAL work with
coincident faces if they are exactly coincident. And 2D uses fixed point
maths, so it should be easier.
On Fri, 6 Sept 2024 at 18:10, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 9/6/2024 6:34 AM, Douglas Miller via Discuss wrote:
Adding valign="bottom" to the text() command appears to correct the issue.
Anything that moves the text away from the bottom of the square should be
enough. valign=bottom will fix problems with glyphs that have a horizontal
segment at the baseline, but create problems with glyphs that have a
horizontal segment at the bottom-most point in the string. Given the
finicky nature of this bug - see below - it might be hard to build a test
case.
My expectation was that this behavior would not be tied to text() per se,
but rather to subtracting a 2D object with a coincident edge. And indeed,
here's a test case:
difference() {
square(5);
translate([1,0,0]) square(1,center=true);
translate([3,0,0]) square(1);
}
Preview (tilted to make the Z-fighting visible):
Render:
It seems to require both a coincident edge and another subtraction that
crosses the edge; removing the first square fixes the problem with the
second square.
Using an experimental PR#4478 build that can extract the results of a
render, I get:
{
min : [0, 0, 0],
max : [5, 5, 0],
center : [2.5, 2.5, 0],
size : [5, 5, 0],
objects : [
{
points : [
[5, 5],
[0, 5],
[0, 0],
[0.5, 0],
[0.5, 0.5],
[1.5, 0.5],
[1.5, 0],
[5, 0],
[3, 0],
[3, 1],
[4, 1],
[4, 0]
],
paths : [
[0, 1, 2, 3, 4, 5, 6, 7],
[8, 9, 10, 11]
]
}
]
}
The intended square-with-two-cutouts has been turned into a figure that is
a square with one cutout overlapping with another square that should be the
second cutout.
Surprisingly, the same pattern does not produce the same result when the
cutouts are along the Y axis rather than the X axis, nor does it produce
the same results when the cutouts are along the top. Even swapping the two
cutouts yields a "correct" result.
The workaround is, like the similar problem in 3D, to avoid having
negative objects with edges coincident with edges on the positive object.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
It is odd, to me, that it seems to be only on the x axis, and if you
swap around the positions of the squares, then it gives a different
result. The rule seems to be that if there is an object that crosses
the x axis nearer to the origin than others that are all on the x axis
then it does not render as I would expect when differenced from the square.
difference(){
translate([0,10])
square(50);
translate([25,10])
square(10);
translate([5,10])
square(10);
// translate([2,10])
// circle (d=1);
}
uncomment last lines, and fn6 render - squares disappear.
On 06/09/2024 18:10, Jordan Brown via Discuss wrote:
On 9/6/2024 6:34 AM, Douglas Miller via Discuss wrote:
Adding valign="bottom" to the text() command appears to correct the
issue.
Anything that moves the text away from the bottom of the square should
be enough. valign=bottom will fix problems with glyphs that have a
horizontal segment at the baseline, but create problems with glyphs
that have a horizontal segment at the bottom-most point in the
string. Given the finicky nature of this bug - see below - it might
be hard to build a test case.
My expectation was that this behavior would not be tied to text() per
se, but rather to subtracting a 2D object with a coincident edge. And
indeed, here's a test case:
difference() {
square(5);
translate([1,0,0]) square(1,center=true);
translate([3,0,0]) square(1);
}
Preview (tilted to make the Z-fighting visible):
Render:
It seems to require both a coincident edge and another subtraction
that crosses the edge; removing the first square fixes the problem
with the second square.
Using an experimental PR#4478 build that can extract the results of a
render, I get:
{ min : [0, 0, 0], max : [5, 5, 0], center : [2.5, 2.5, 0], size :
[5, 5, 0], objects : [ { points : [ [5, 5], [0, 5], [0, 0], [0.5,
0], [0.5, 0.5], [1.5, 0.5], [1.5, 0], [5, 0], [3, 0], [3, 1], [4,
1], [4, 0] ], paths : [ [0, 1, 2, 3, 4, 5, 6, 7], [8, 9, 10, 11] ]
} ] }
The intended square-with-two-cutouts has been turned into a figure
that is a square with one cutout overlapping with another square that
should be the second cutout.
Surprisingly, the same pattern does not produce the same result when
the cutouts are along the Y axis rather than the X axis, nor does it
produce the same results when the cutouts are along the top. Even
swapping the two cutouts yields a "correct" result.
The workaround is, like the similar problem in 3D, to avoid having
negative objects with edges coincident with edges on the positive object.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
Someone already pointed out that this is a 2D issue. That means another
workaround, for when you don't want to tinker with the position of the
cutaway element, is to convert to 3D before taking the difference.
Both of these work:
difference() {
linear_extrude(6) square(20);
linear_extrude(6) text("5.5");
}
difference() {
cube([20, 20, 6]);
linear_extrude(6) text("5.5");
}
Steve
On 2024-09-06 10:10 a.m., Jordan Brown via Discuss wrote:
On 9/6/2024 6:34 AM, Douglas Miller via Discuss wrote:
Adding valign="bottom" to the text() command appears to correct the
issue.
Anything that moves the text away from the bottom of the square should
be enough.
On 9/6/24 00:33, Curt McDowell via Discuss wrote:
Wow, this is a bug, not an artifact, and it applies to preview, CGAL,
and Manifold, and it has been there since OpenSCAD first got text().
While fixing that, I have another problem that that might be looked at
wxamples:
diatrim=2.7;// adjust to fit current screw being fitted, now cascades
thru to global sz
ver="T-V5.8 D= ";// basic text
tdia=str(diatrim);// diatrim is numeral, make txt out of it
module ver_txt(s,t,sz)
{
echo(79,"ver_txt",s,t,sz);
//diatrim=sz;
//echo(81,sz,diatrim);
tdia=str(sz);//
color("Black")translate([-10,0,0])linear_extrude(height=t)text(ver,font
= "Utopia:style=Bold",size=s,halign="center" );
color("Black")translate([20,0,0])linear_extrude(height=t)text(tdia,font="Utopia:style=Bold",size=s,halign="right");
}; //places text on side of nut so I know tooth shape and size of nut
linear_extrude(6) {
difference(){
square(20);
text("3Z");
}
}
This is further manipulated so it is embossed on the sides of the nut
The problem is that text gets stripped to just "1","2" etc if the
following decimal point is .0 then only the 2 etc gets printed.
technically 2 or whatever is correct but that is not what I think I'm
telling it to do.
What I've done is printed a series of 40 rings, incrementing the size by
.1 and printing that on the handle tab sticking out of the threaded ring
so that I have gages that tell me how big a nut pair I must make for
each screw so each nut fits that screw perfectly. Missing the .0 for
those that are an even mm in size looks unprofessional at best. IMO it
should render and print any numerical value I put in text=.
So while looking, can this be fixed too? Thanks.
text("3Z") or text("ch"): the Z and h don't show up. That 3 and c have
round bottoms seems to be the trigger.
text("4Z"): the Z shows up
text("3O") or text("cb"): the O and b do show up, apparently because
they also have round bottoms
text("oA") or text("oB" or text("o#"): only the holes in A, B and # show up
text("oi") or text("d%"): only the dot on the i and the o's in the %
show up
text("o*") or text("o+"): no problem when the second characters don't
touch baseline
text("/A") or text(",A"): certain other characters like / and , also
trigger the problem.
In other weirdness, adding # for #text() shows a +/-0.5 mm extrusion in
red, instead of a 6 mm extrusion.
Regards,
Curt
On 9/5/24 09:12, Raymond West via Discuss wrote:
Testing further.
It seems if the second number is flat at the bottom, 1,2,7 and aligns
with the base of the square, and the first is a 0,2,3,5,6,8,9 then the
second does not f6 render. 4 is interesting. It's the same for letters.
On 05/09/2024 16:27, larry via Discuss wrote:
On Thu, 2024-09-05 at 16:16 +0100, Raymond West via Discuss wrote:
The following code snippet
//linear_extrude(6){
difference(){
square(20);
text("5.5");
}
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
On 9/6/2024 12:29 PM, Steve Lelievre via Discuss wrote:
Someone already pointed out that this is a 2D issue. That means
another workaround, for when you don't want to tinker with the
position of the cutaway element, is to convert to 3D before taking the
difference.
It's also a well-known 3D problem. The most obvious effect is
Z-fighting in preview, and rendering usually gets rid of it. However,
at least in theory the nominally-coincident faces can be microscopically
misaligned and then rendering could yield ultra-thin walls.
The best plan is to avoid coincident edges and faces.
On 9/6/2024 1:37 PM, gene heskett via Discuss wrote:
The problem is that text gets stripped to just "1","2" etc if the
following decimal point is .0 then only the 2 etc gets printed.
technically 2 or whatever is correct but that is not what I think I'm
telling it to do.
That's actually totally unrelated and, amusingly, not related to text()
per se either.
None of the mechanisms available in OpenSCAD for translating numbers
into text offer any control over the number of decimal places - nor over
any other aspect of the presentation that results. (Offhand, those
mechanisms are str() and echo(), though there might be a few other
places where numbers get automatically converted into strings.)
I think it would be good to add this as a built-in feature, but in the
meantime there's a BOSL2 function that will do what you need:
https://github.com/BelfrySCAD/BOSL2/wiki/strings.scad#function-format_fixed
Jordan,
Thanks for keeping me on the straight and narrow.
Steve
On 2024-09-06 2:00 p.m., Jordan Brown wrote:
On 9/6/2024 12:29 PM, Steve Lelievre via Discuss wrote:
Someone already pointed out that this is a 2D issue. That means
another workaround, for when you don't want to tinker with the
position of the cutaway element, is to convert to 3D before taking
the difference.
It's also a well-known 3D problem. The most obvious effect is
Z-fighting in preview, and rendering usually gets rid of it. However,
at least in theory the nominally-coincident faces can be
microscopically misaligned and then rendering could yield ultra-thin
walls.
The best plan is to avoid coincident edges and faces.