VBitText
There have been discussions about text with sloping rather than parallel
vertical edges. For example, see OpenSCAD - Chiseled Font?
http://forum.openscad.org/Chiseled-Font-td28451.html and OpenSCAD -
Chamfered 3D text http://forum.openscad.org/Chamfered-3D-text-td23162.html
Here is my take on a solution to this problem.
https://github.com/DomenicoMarseglia/OneStrokeTextOpenSCAD
https://github.com/DomenicoMarseglia/OneStrokeTextOpenSCAD The name
VBitText is based on the idea of a simulation of a V shaped milling bit in a
CNC router.
I use single stroke fonts. Unlike TrueType fonts which are defined as the
outline of a 2-dimensional area, these fonts are described by the centre
line of the font geometry. I convert these fonts into an OpenSCAD file with
a set of line segments per glyph.
I have also written some OpenSCAD code in to render a string of text using
these tables.
This is the way you might use the code:
use <OneStrokeText.scad>
translate([0,50,0])
VbitText("Hello",40, "Hershey-Sans 1-stroke", 6, 0, 4);
VbitText("Hello",40, "Custom-Script", 6, 0, 4);
This is the kind of effect you can get:
http://forum.openscad.org/file/t3175/sample2.png
The code is very much proof of concept at this stage. It works with some
.svg files. It fails with some others I have seen.
If you have performance issues, then keep the number of fonts to a minimum
and reduce line_segments_per_bezier_segment in the Python script. If you
still have performance issues, then you might consider editing the fonts to
reduce the number of curve segments or glyphs in the font.
What do you think? Does this approach have merit, or am I re-inventing a
wheel?
--
Sent from: http://forum.openscad.org/
Definitely much prettier than the "linear_extrude + offset" answer.
Having to include the definitions of the characters in the source is
painful.
Hmm. Along the same line as functions that extract text metrics, that
return STL files as data, et cetera, it seems like it wouldn't be
terribly hard to have a function that returns text as a series of points
defining paths - an array of paths, each of which is an array of
points. That should be pretty straightforward to extract from the
underlying text layout engine.
Maybe after I figure out how to get objects/structures/dictionaries
working, at least for function returns.
JordanBrown wrote
Along the same line as functions that extract text metrics, that
return STL files as data, et cetera, it seems like it wouldn't be
terribly hard to have a function that returns text as a series of points
defining paths - an array of paths, each of which is an array of
points.
That is what I did isn't it? The Python script extracts the font geometry
from the SVG file and creates a table of X,Y points in OpenSCAD. Then for
each pair of points defining a line segment I put a cone at each end of the
line and connect them with a hull(). I do not create STL files.
--
Sent from: http://forum.openscad.org/
On 3/23/2021 1:28 AM, Domenico Marseglia via Discuss wrote:
JordanBrown wrote
Along the same line as functions that extract text metrics, that
return STL files as data, et cetera, it seems like it wouldn't be
terribly hard to have a function that returns text as a series of
points
defining paths - an array of paths, each of which is an array of
points.
That is what I did isn't it? The Python script extracts the font
geometry from the SVG file and creates a table of X,Y points in
OpenSCAD. Then for each pair of points defining a line segment I put a
cone at each end of the line and connect them with a hull(). I do not
create STL files.
First, the STL reference was to a previous discussion. It's not
directly relevant to this discussion, except in that the functions would
be similar.
Yes, I understand that you extracted font data from some source and
translated it into OpenSCAD language.
That's not what I'm suggesting.
OpenSCAD has its own text handling. The shapes involved in rendering
text are available internally. There could be a function that rendered
text, but instead of rendering it into internal geometry rendered it
into data to return to the OpenSCAD program. It could do that without
needing external processing to convert font data from an external source
into OpenSCAD data.
OpenSCAD mailing list-2 wrote
...
What do you think? Does this approach have merit, or am I re-inventing a
wheel?
...
I did something similar with xy data from postscript in one of the threads
that you linked to. The hard part is getting access to the geometry for the
letters in a nice way. (The lack of userspace access to geometry
information is a big limitation of OpenSCAD in general.)
--
Sent from: http://forum.openscad.org/
Jordan
Are you suggesting a modification to the C++ of OpenSCAD itself, rather than
a .scad library? I agree that would give much better results. (From a speed
and usability point of view, the final .STL files would be identical).
However, I thought the general consensus of opinion was to do as much as
possible in the user code. Have I misjudged that?
To date, I have not even built OpenSCAD from the source, never mind
investigated how to do this kind of modification. I hope to look into that
for my own curiosity if nothing else.
In the short term, I shall restrict myself to creating / improving the
available .SVG fonts. That is a constructive step in the right direction for
this use case and indeed for the other projects that can make use of single
stroke fonts.
--
Sent from: http://forum.openscad.org/
On 3/23/2021 12:20 PM, Domenico Marseglia via Discuss wrote:
Are you suggesting a modification to the C++ of OpenSCAD itself,
rather than a .scad library?
Yes.
However, I thought the general consensus of opinion was to do as much
as possible in the user code. Have I misjudged that?
There's always a balancing act. You don't want to throw stuff into the
core when there isn't a significant win from doing so. At the same time
you do want to put stuff in the core when there is a significant
win. Having to write external processing to convert font data seems
like an unreasonable cost. (Note that OpenSCAD did not always have the
text() module. Before the text() module, there were text libraries that
relied on loading font data as OpenSCAD data. Putting text() in the
core was a big win.)
That said...
In the short term, I shall restrict myself to creating / improving the
available .SVG fonts. That is a constructive step in the right
direction for this use case and indeed for the other projects that can
make use of single stroke fonts.
The fonts that OpenSCAD uses internally are not single-stroke fonts;
they are outline fonts. That makes it unclear whether their data would
be directly helpful here.
However, it'd still be useful, e.g., for curving glyphs around a cylinder.