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 |
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 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
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. |
or probably cell = (Em Height x Advance)...
been a while since I did all that... From:
Discuss [mailto:[hidden email]] On Behalf Of 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 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 |
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 or probably cell = (Em Height x
Advance)... been a while since I did all that... From:
Discuss [mailto:[hidden email]] On Behalf Of 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 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 |
In reply to this post by MichaelAtOz
On 12/27/2020 8:28 PM, MichaelAtOz
wrote:
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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. |
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 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.
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 |
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 |
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 |
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 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
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. |
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.) For extra special fun, note that for this Hebrew and Persian text OpenSCAD defaults to right-to-left.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); 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 |
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. 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 |
Free forum by Nabble | Edit this page |