More on text alignment

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

More on text alignment

JordanBrown

I've been noticing a few more "odd" cases.  I'd like opinions on whether or not they are bugs.

--- valign ---

valign=top doesn't always slam the top of the string against the X axis.  If the glyph is below and not touching the baseline, it only adjusts the baseline up to the X axis.  Thus text("_",valign="top") has the underscore a bit -Y below the X axis.

Similarly with valign="bottom", if the glyph is above and not touching the baseline.  text(" ' ", valign="bottom") has the apostrophe well +Y of the X axis.



--- halign ---

Some fonts want to put ink left of the origin, or right of their nominal width.  This mostly happens in script and italic fonts.

text("A", font="Freestyle Script", halign="left") has part of the left tail of the A left of the Y axis.

Similarly, text("A", font="Freestyle Script", halign="right") has part to the right of the Y axis.

---

For all of these...

Feature?

Bug that should be fixed?

Regrettable legacy behavior that shouldn't change?




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz
Administrator

Those are cases of font properties.

 

 

The glyph can be written anywhere, including negative places. The valign etc is based on the cell (cell height x advance) not the glyph.

 

'Nice' fonts fit in the cell.

 

I'm still looking at your ttb/bbt post.

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
Sent: Mon, 28 Dec 2020 15:16
To: OpenSCAD general discussion
Subject: [OpenSCAD] More on text alignment

 

I've been noticing a few more "odd" cases.  I'd like opinions on whether or not they are bugs.

--- valign ---

valign=top doesn't always slam the top of the string against the X axis.  If the glyph is below and not touching the baseline, it only adjusts the baseline up to the X axis.  Thus text("_",valign="top") has the underscore a bit -Y below the X axis.

Similarly with valign="bottom", if the glyph is above and not touching the baseline.  text(" ' ", valign="bottom") has the apostrophe well +Y of the X axis.

 

 

--- halign ---

Some fonts want to put ink left of the origin, or right of their nominal width.  This mostly happens in script and italic fonts.

text("A", font="Freestyle Script", halign="left") has part of the left tail of the A left of the Y axis.

Similarly, text("A", font="Freestyle Script", halign="right") has part to the right of the Y axis.

---

For all of these...

Feature?

Bug that should be fixed?

Regrettable legacy behavior that shouldn't change?

 

 


Virus-free. www.avg.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz'

or probably cell = (Em Height x Advance)... been a while since I did all that...

 


From: Discuss [mailto:[hidden email]] On Behalf Of MichaelAtOz
Sent: Mon, 28 Dec 2020 15:29
To: 'OpenSCAD general discussion'
Subject: Re: [OpenSCAD] More on text alignment

 

Those are cases of font properties.

 

 

The glyph can be written anywhere, including negative places. The valign etc is based on the cell (cell height x advance) not the glyph.

 

'Nice' fonts fit in the cell.

 

I'm still looking at your ttb/bbt post.

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
Sent: Mon, 28 Dec 2020 15:16
To: OpenSCAD general discussion
Subject: [OpenSCAD] More on text alignment

 

I've been noticing a few more "odd" cases.  I'd like opinions on whether or not they are bugs.

--- valign ---

valign=top doesn't always slam the top of the string against the X axis.  If the glyph is below and not touching the baseline, it only adjusts the baseline up to the X axis.  Thus text("_",valign="top") has the underscore a bit -Y below the X axis.

Similarly with valign="bottom", if the glyph is above and not touching the baseline.  text(" ' ", valign="bottom") has the apostrophe well +Y of the X axis.

 

 

--- halign ---

Some fonts want to put ink left of the origin, or right of their nominal width.  This mostly happens in script and italic fonts.

text("A", font="Freestyle Script", halign="left") has part of the left tail of the A left of the Y axis.

Similarly, text("A", font="Freestyle Script", halign="right") has part to the right of the Y axis.

---

For all of these...

Feature?

Bug that should be fixed?

Regrettable legacy behavior that shouldn't change?

 

 

 

Virus-free. www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz'

and on the max/min of the set of the glyphs in the text() call.

 

Compare the full block (occupying the Decent and Internal leading), with just the 'Z'

 

block="\u2588Z";

//block="Z";

text(block,size=30,valign="baseline");

translate([60,0,0]) text(block,size=30,valign="top");

translate([120,0,0]) text(block,size=30,valign="bottom");

 


From: Discuss [mailto:[hidden email]] On Behalf Of Michael Marx
Sent: Mon, 28 Dec 2020 15:33
To: 'OpenSCAD general discussion'
Subject: Re: [OpenSCAD] More on text alignment

 

or probably cell = (Em Height x Advance)... been a while since I did all that...

 


From: Discuss [mailto:[hidden email]] On Behalf Of MichaelAtOz
Sent: Mon, 28 Dec 2020 15:29
To: 'OpenSCAD general discussion'
Subject: Re: [OpenSCAD] More on text alignment

 

Those are cases of font properties.

 

 

The glyph can be written anywhere, including negative places. The valign etc is based on the cell (cell height x advance) not the glyph.

 

'Nice' fonts fit in the cell.

 

I'm still looking at your ttb/bbt post.

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
Sent: Mon, 28 Dec 2020 15:16
To: OpenSCAD general discussion
Subject: [OpenSCAD] More on text alignment

 

I've been noticing a few more "odd" cases.  I'd like opinions on whether or not they are bugs.

--- valign ---

valign=top doesn't always slam the top of the string against the X axis.  If the glyph is below and not touching the baseline, it only adjusts the baseline up to the X axis.  Thus text("_",valign="top") has the underscore a bit -Y below the X axis.

Similarly with valign="bottom", if the glyph is above and not touching the baseline.  text(" ' ", valign="bottom") has the apostrophe well +Y of the X axis.

 

 

--- halign ---

Some fonts want to put ink left of the origin, or right of their nominal width.  This mostly happens in script and italic fonts.

text("A", font="Freestyle Script", halign="left") has part of the left tail of the A left of the Y axis.

Similarly, text("A", font="Freestyle Script", halign="right") has part to the right of the Y axis.

---

For all of these...

Feature?

Bug that should be fixed?

Regrettable legacy behavior that shouldn't change?

 

 

 

Virus-free. www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
In reply to this post by MichaelAtOz
On 12/27/2020 8:28 PM, MichaelAtOz wrote:
The glyph can be written anywhere, including negative places. The valign etc is based on the cell (cell height x advance) not the glyph.

Yes, understood.  And is that the right answer for OpenSCAD's halign?  Or is the right answer that halign=left always puts the left edge of the object at the Y axis?

(And the valign/underscore/apostrophe question is more artificial - OpenSCAD just doesn't believe that the bottom of a glyph can be above the baseline, or that the top can be below the baseline, and so doesn't allow ascent or descent to be on the "wrong" side of zero.)

For the text metrics stuff, my goal is to report all of the interesting metrics, notably including the bounding box that precisely surrounds the actual ink.  The question here is whether we want to tweak the OpenSCAD halign/valign behavior.  Whatever the answer is, I'll make the text metrics stuff report the matching numbers.


Thanks for the pointer to \u2588.  I'd been thinking that there should be a Unicode code point (or a couple) devoted to marking the various font metrics.  Full block is certainly a good start on that.  (And my metrics line up with it, give or take epsilon.  There's no visible difference, but they aren't quite the same since I'm only getting Z-fighting on one side.)



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

Troberg
In reply to this post by MichaelAtOz'
MichaelAtOz' wrote
> and on the max/min of the set of the glyphs in the text() call.

Yep, and that's a huge problem. It makes any align except the baseline
pretty much useless if you want to line up several texts. For example, "g",
"a", "A" and "Å" will line up completely different. To be useful, it
shouldn't work on the actual text, but of the highest and lowest character
in that font.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

lar3ry
I think it should line up with the height of \u2588.
But is it a 'block' in all fonts?




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
In reply to this post by Troberg
On 12/28/2020 8:07 AM, Troberg wrote:
> MichaelAtOz' wrote
>> and on the max/min of the set of the glyphs in the text() call.
> Yep, and that's a huge problem. It makes any align except the baseline
> pretty much useless if you want to line up several texts. For example, "g",
> "a", "A" and "Å" will line up completely different. To be useful, it
> shouldn't work on the actual text, but of the highest and lowest character
> in that font.

Yes, though one can equally say that it should be based on the text
being rendered.  E.g., don't force me to have a margin for descenders
underneath my string that doesn't have any descenders.

My text metric work will let you answer this question however you want
for your particular application, by giving you both the metrics of the
particular string and the font-wide metrics.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

Troberg
In reply to this post by lar3ry
lar3ry wrote
> I think it should line up with the height of \u2588.
> But is it a 'block' in all fonts?

Nope, for me, it's like a mirrored, tipped over L.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
On 12/28/2020 12:48 PM, Troberg wrote:
> lar3ry wrote
>> I think it should line up with the height of \u2588.
>> But is it a 'block' in all fonts?
> Nope, for me, it's like a mirrored, tipped over L.

Don't fixate on \u2588.  \u2588 may help to visualize the font metrics,
but doesn't define them.

Fonts have defined ascent and descent values, and those values are
accessible from the C++ functions.

But note:  even that isn't exactly the answer.  There's the "typographic
ascent and descent", and they are distinct from the actual minimum and
maximum values.

Ref
https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#ft_facerec 
and the distinction between bbox and ascender/descender.

I think a normal example of the difference is that the ascent value is
the baseline-to-top height of a capital letter, but certain characters
(e.g. parentheses, superscripts) might go higher than that.  And
similarly lower for the descender value.

This is all related to the comments from another thread about glyphs
that extend left or right (or both!) of their nominal character box.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz'
In reply to this post by lar3ry
> But is it a 'block' in all fonts?
>

It is in the default, Liberation Sans.


--
This email has been checked for viruses by AVG.
https://www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

cacb
On 2020-12-29 08:08, Michael Marx wrote:
>> But is it a 'block' in all fonts?
>>
>
> It is in the default, Liberation Sans.

As a general comment to this text() talk, I think the way the text()
'spacing' parameter is implemented must be wrong in OpenSCAD, using
anything but default value gives odd results, try for example

linear_extrude(1)
text("Hello World", spacing=2);

I noticed this since I added (partial) support for text() in .scad
scripts when executed from AngelCAD v1.5-06.


Btw., why is there a need for a "font cache" in OpenSCAD?

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz
Administrator
spacing= makes more sense with mono spaced fonts

linear_extrude(1)
text("Hello World", spacing=2, font="liberation mono");

There are issues with spacing and alignment, which I'll mention under Jordan's 'metrics' thread
later.

> -----Original Message-----
> From: Discuss [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: Tue, 29 Dec 2020 20:30
> To: OpenSCAD general discussion
> Subject: Re: [OpenSCAD] More on text alignment
>
> On 2020-12-29 08:08, Michael Marx wrote:
> >> But is it a 'block' in all fonts?
> >>
> >
> > It is in the default, Liberation Sans.
>
> As a general comment to this text() talk, I think the way the text()
> 'spacing' parameter is implemented must be wrong in OpenSCAD, using
> anything but default value gives odd results, try for example
>
> linear_extrude(1)
> text("Hello World", spacing=2);
>
> I noticed this since I added (partial) support for text() in .scad
> scripts when executed from AngelCAD v1.5-06.
>
>
> Btw., why is there a need for a "font cache" in OpenSCAD?
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


--
This email has been checked for viruses by AVG.
https://www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
In reply to this post by cacb
On 12/29/2020 1:29 AM, [hidden email] wrote:
As a general comment to this text() talk, I think the way the text() 'spacing' parameter is implemented must be wrong in OpenSCAD, using anything but default value gives odd results, try for example

linear_extrude(1)
text("Hello World", spacing=2);

I noticed this since I added (partial) support for text() in .scad scripts when executed from AngelCAD v1.5-06.

It's a straight multiplier on the "advance" value for each glyph.

Yeah, that can go wrong in a couple of ways.  A series of Ws will get a lot more space between them than a series of Is.

You might think that it should be a value that's *added* to the advance value, but that forgets the fact that OpenSCAD (through HarfBuzz) supports ligatures.  If you want even weirder spacing, check out "Difficult" in Calibri:

What's going on there is that "ffi" is compressed down into being one glyph, and *then* the extra spacing is applied.  And since the "ffi" ligature is extra-wide, the extra spacing after it is extra-wide too.

I don't know what the right answer is, but I'm going to draw a line and say that I'm not going to try to fix it as part of my text metrics project.




Btw., why is there a need for a "font cache" in OpenSCAD?

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

cacb
In reply to this post by MichaelAtOz
On 29.12.2020 23:08, MichaelAtOz wrote:
> spacing= makes more sense with mono spaced fonts
>
> linear_extrude(1)
> text("Hello World", spacing=2, font="liberation mono");
>
> There are issues with spacing and alignment, which I'll mention under Jordan's 'metrics' thread
> later.

That is avoiding the issue i mentioned. Spacing should have a meaningful
definition with any font. A natural interpretation is for it to define
the size of the spacing between the characters.

In my opinion, and why I made a comment, it is precisely because it is
implemented incorrectly in OpenSCAD it can't be used for anything but
mono spaced fonts (you could question its use there as well).

Consider this, I would expect zero spacing between the characters:

linear_extrude(1)
text("Hello World", spacing=0, font="liberation mono");

See attached "openscad_spacing0.png", where all characters are drawn on
top of each other, I don't think that is correct.

Compare with the same .scad code executed in AngelCAD, where you get
zero spacing between characters. I don't claim this to be perfect
either, but it makes much more sense to me.

Crsten Arnholm.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

openscad_spacing0.png (71K) Download Attachment
AngelCAD_spacing0.png (75K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

cacb
In reply to this post by JordanBrown
On 30.12.2020 00:14, Jordan Brown wrote:
> It's a straight multiplier on the "advance" value for each glyph.

And I think that is wrong.

> You might think that it should be a value that's *added* to the advance
> value,

I would think so, yes.

> but that forgets the fact that OpenSCAD (through HarfBuzz)
> supports ligatures.  If you want even weirder spacing, check out
> "Difficult" in Calibri:
>
> What's going on there is that "ffi" is compressed down into being one
> glyph, and *then* the extra spacing is applied.  And since the "ffi"
> ligature is extra-wide, the extra spacing after it is extra-wide too.

Fist of all, I don't see the ligature effect you are describing, even in
the very latest nightly: OpenSCAD version 2020.12.27.nightly (git
52eb8ec), see attached. That is probably something unreleased you have
added?

The discussion of ligatures seems to be making things more difficult
(pun intended) than required for the purposes of including text in
3d-printing models. What you showed is surely something different from
current OpenSCAD, even the latest nightly, and it does not seem like an
improvement when it comes to spacings.

Compare with the exact same .scad code Executed in AngelCAD 1.5-06
(attached screenshot), it does not need to be any more difficult than
that. AngelCAD does not use HarfBuzz, btw.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD_difficult2.png (32K) Download Attachment
AngelCAD_difficult2.png (45K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

cacb
In reply to this post by cacb
On 30.12.2020 00:17, Jordan Brown wrote:
> On 12/29/2020 1:29 AM, [hidden email] wrote:
>> Btw., why is there a need for a "font cache" in OpenSCAD?
>
> I believe (somewhat through black-box observation) that there are two.
>
> The Fontconfig library keeps a list of all of the available fonts, for
> each use when doing its fuzzy font matching.  (That's the "updating
> cache" popup you see sometimes.)

So OpenSCAD uses fontconfig "fuzzy font matching" to choose the actual
font file, based on the user parameters in the text() command? That
seems kind of unnecessary, especially since updating the cache takes a
long time, caches are supposed to make things faster, not slower.

Regardless of the time spent, I can't see that "fuzzy font matching"
actually doing anything different from a trivial lookup (see below).

In comparison, AngelCAD's approach is to scan the system font
directories once per .scad file containing text() and record the
correspondence between font name/style contained with the actual font
file name. This is fast. Later, when processing text(), the lookup to
the relevant font file to obtain glyph geometries is direct and immediate.

> It looks like OpenSCAD keeps an in-memory cache of fonts that have been
> used, presumably to avoid rereading the font files on each "text" call.

In memory cache is not the same as file cache. Keeping things in memory
isn't always a good thing either.

Are you saying the file cache contains copies/interpretation of the font
geometries (glyphs)? If so, that can't be any faster than reading the
font files directly. I am guessing the file cache does not contain
copies of the font geometries though.

Reading TrueType font files is very fast using FreeType, and is in any
case orders of magnitude faster than the booleans in CGAL or Carve that
follow, so there should not be any reason to try to optimize on font
file reading, given the side effects that slow things down.

So I still wonder why the font cache exists in OpenSCAD. But ok, it exists.

Carsten Arnholm


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

MichaelAtOz
Administrator
In reply to this post by JordanBrown

valign - I can't see a rational for it doing that. Probably bug.

 

halign - This is the case of the font designers choice,

they wanted that bit intruding outside the normal space.

If in print they had two lines of text that back-intrusion makes it all fit together.

 

a. one view is if you wanted to do the same layout in OpenSCAD it should do as it currently does.

 

b. another is that you shuffle the text up/right to align with the origin, or otherwise for rtl/ttb/btt,

but then you cannot achieve what the font intends, and some fonts are really weird.

 

Leaving it as a. with textmetrics() giving you info to manually shuffle would probably be best.?

 


From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
Sent: Mon, 28 Dec 2020 15:16
To: OpenSCAD general discussion
Subject: [OpenSCAD] More on text alignment

 

I've been noticing a few more "odd" cases.  I'd like opinions on whether or not they are bugs.

--- valign ---

valign=top doesn't always slam the top of the string against the X axis.  If the glyph is below and not touching the baseline, it only adjusts the baseline up to the X axis.  Thus text("_",valign="top") has the underscore a bit -Y below the X axis.

Similarly with valign="bottom", if the glyph is above and not touching the baseline.  text(" ' ", valign="bottom") has the apostrophe well +Y of the X axis.

 

 

--- halign ---

Some fonts want to put ink left of the origin, or right of their nominal width.  This mostly happens in script and italic fonts.

text("A", font="Freestyle Script", halign="left") has part of the left tail of the A left of the Y axis.

Similarly, text("A", font="Freestyle Script", halign="right") has part to the right of the Y axis.

---

For all of these...

Feature?

Bug that should be fixed?

Regrettable legacy behavior that shouldn't change?

 

 


Virus-free. www.avg.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
In reply to this post by cacb
On 12/29/2020 9:25 PM, Carsten Arnholm wrote:
You might think that [spacing] should be a value that's *added* to the advance value,
I would think so, yes.

That's not an unreasonable answer, but isn't current behavior and (except for the default) isn't compatible with current behavior.  Or with the ligature issue discussed below.  (And perhaps others, with combining characters.)

Net, I'm not optimistic about fixing "spacing" in the general case.

First of all, I don't see the ligature effect you are describing, even in the very latest nightly: OpenSCAD version 2020.12.27.nightly (git 52eb8ec), see attached. That is probably something unreleased you have added?

No, it's stock OpenSCAD.  (Right now I'm demonstrating it with 2019.05 on Windows 10.)  But it depends on the font; it only applies to fonts that have ligature support.  Liberation Sans does not seem to have ligature support.  I've been testing it with Calibri.

The discussion of ligatures seems to be making things more difficult (pun intended) than required for the purposes of including text in 3d-printing models.

It depends on how picky you are about your text.  Typographers consider ligatures to be important.  Are they important in 3D design and 3D printing?  If you're just trying to put "ON" and "OFF" labels on a box, probably not.  If you're trying to print plates for a printing press, maybe.

One might also wonder whether kerning, another "advanced" typographic feature that OpenSCAD supports, is "required".  (Compare the spacing between "AAAVVV" and "AVAVAV" - the same letters, just in a different order.)

Compare with the exact same .scad code Executed in AngelCAD 1.5-06 (attached screenshot), it does not need to be any more difficult than that. AngelCAD does not use HarfBuzz, btw.

What does it do with this program and its variants?  (Also attached, in case something mangles the non-ASCII text.)
israel = "יִשְׂרָאֵל";
harfbuzz = "حرف‌باز";
f = "Arial";
spacing=1;
direction = "rtl";

text(israel, font=f, spacing=spacing, direction=direction);
translate([0,-20,0]) text(harfbuzz, font=f, spacing=spacing, direction=direction);
For extra special fun, note that for this Hebrew and Persian text OpenSCAD defaults to right-to-left.

Note:  there's no telling how the RTL text here will be presented by any particular program.  As I compose this, Thunderbird is presenting it correctly, where in "Israel" the first character, the yod, which looks sort of like an apostrophe, is on the right.  I can sort of read Hebrew, so I know which character is which, but I can't read Persian so I can't say a lot about the "harfbuzz".  I can't even really see how the individual characters in that string are constructed into the glyphs that result. But I can tell you that there's a glyph that looks sort of like a semicolon; it's supposed to be on the left.  On the other hand, OpenSCAD's editor kind of mangles it.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

rtl.scad (352 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More on text alignment

JordanBrown
In reply to this post by cacb
On 12/29/2020 9:59 PM, Carsten Arnholm wrote:
So OpenSCAD uses fontconfig "fuzzy font matching" to choose the actual font file, based on the user parameters in the text() command?

Something like that. https://www.freedesktop.org/wiki/Software/fontconfig/ if you want more information.

I'm not looking at that area and so I don't know much about it.

Fuzzy matching lets you say things like "give me a bold italic serif font", and get a reasonable answer without having to know exactly what fonts are installed on the system.  In OpenSCAD, say
text("Hello World", font="serif:italic:bold");

It looks like OpenSCAD keeps an in-memory cache of fonts that have been used, presumably to avoid rereading the font files on each "text" call.

In memory cache is not the same as file cache. Keeping things in memory isn't always a good thing either.

Are you saying the file cache contains copies/interpretation of the font geometries (glyphs)? If so, that can't be any faster than reading the font files directly. I am guessing the file cache does not contain copies of the font geometries though.

Perhaps I didn't make it clear enough that I believe that there are *two* totally independent caches.  Fontconfig's cache is, I believe, a cache of font metadata to make its fuzzy matching fast.  OpenSCAD also has its own in-memory cache (in src/FontCache.cc) that caches the definitions of fonts that you use, at some level.  (I can't tell whether it caches all of the glyph data, but my guess is "yes".)



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org