More on text alignment
Locked
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?
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Re: More on text alignment
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. |
Re: 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 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 |
Re: More on text alignment
|
|
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 |
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
|
Re: More on text alignment
|
Administrator
|
Re: More on text alignment
|
|
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 |
Re: More on text alignment
|
|
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)
Re: More on text alignment
|
|
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 |
Re: More on text alignment
|
|
Re: More on text alignment
|
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. |
Re: More on text alignment
|
|
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 |
Re: More on text alignment
|
|
| Free forum by Nabble | Edit this page |