several variations on text() ttb/btt and valign and halign seem wrong

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

several variations on text() ttb/btt and valign and halign seem wrong

JordanBrown
I'm working on a function to extract text metrics (separate message
soon), and so I'm looking carefully at the behavior of the text() module.

Issue 1:  valign

With direction=ttb or btt, setting valign to "top" or "bottom" seems to
produce results that are just wrong.

If you set valign to "top", which normally puts the top of the text at
the X axis, with the text in -Y, you get the text entirely *above*  the
X axis, in +Y.  If you set it to "bottom", you get the text entirely
*below* the X axis.

"baseline" doesn't seem terribly well-defined for ttb or btt text, but
it produces results identical to "bottom".  I can't come up with any
font-metric justification for that, but then again the variations that I
can think of based on font metrics wouldn't be very useful.  If I was
starting from zero, I'd probably have "baseline" align the baseline of
the first character on the X axis, but at this point there's backwards
compatibility concerns.

"center" is the only variation that produces results that look right.

Does anybody know any of the history here?  Is this behavior of "top"
and "bottom" intentional, or did it just kind of fall out of the
implementation?

My work doesn't depend on fixing it - I just want to make sure the
metrics function returns the same results as the text module - but I'm
happy to fix it if nobody knows of a reason why it should stay this way.

My bet is that nobody ever really considered the valign behavior, and
anybody who uses it uses the default valign, or "center".

Proposal:  change top so that it yields text in -Y, bottom so that it
yields text in +Y, baseline so that it leaves the baseline of the first
character on the X axis, and changes the default to top so that the
default behavior remains unchanged.


Issue 2:  halign

With direction=ttb or btt, setting halign seems to produce the wrong answer.

"left" produces results centered on the Y axis.

"center" produces results left of the Y axis, just touching it.

"right" produces results further left of the Y axis.

In all of the variations, the individual glyphs are centered with
respect to each other, which seems sensible.

Having centering be the default makes sense, but when you explicitly say
left/center/right the results are wrong.

Again, this doesn't block my work but while I'm here I'm happy to fix it.

Again, I suspect that nobody ever really considered the halign
variations, and the default is the only variation used.

Proposal:  Keep the individual characters centered against with respect
to each other.  Have "left" yield text in +X, with the left side
touching the Y axis, "right" yield text in -X with the right side
touching the Y axis, "center" yield text surrounding the Y axis, and
have the default be "center" so the default behavior doesn't change.


Any thoughts?


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

Re: several variations on text() ttb/btt and valign and halign seem wrong

JordanBrown

And another, though I think this is in a different part of the rendering pipeline than I've been working in.

When doing vertical layout, as I've noted the characters are centered.  However, they don't seem to be centered based on their individual bounding boxes.

Note that here the Ms are against the left edge but have a little space to their right, while the Ws are against the right edge and have space to their left.

I may look into this a bit more, but I think it's down in the HarfBuzz stuff rather than up in OpenSCAD proper.


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

Re: several variations on text() ttb/btt and valign and halign seem wrong

MichaelAtOz
Administrator
In reply to this post by JordanBrown
Yes.

.
.
.

I reviewed my testing of text(), you are right there was not much attention to ttb/btt.
I went looking to see if there was some obscure reason in other language layouts.
Not in this simplistic implementation, it is actually much more complicated to
do it correctly.
e.g.
https://www.unicode.org/notes/tn22/RobustVerticalLayout.pdf 
https://www.unicode.org/reports/tr50/ 

So I'm presuming the ttb/btt is more for general layout than adaption to other languages.

As such your proposals have merit.

I have Bcc's Torsten to make sure he has seen this, as text() was his baby.

I do wonder if we have any members who actually try to use it for real vertical language display.

> -----Original Message-----
> From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
> Sent: Mon, 28 Dec 2020 11:23
> To: OpenSCAD general discussion
> Subject: [OpenSCAD] several variations on text() ttb/btt and valign and halign seem wrong
>
> I'm working on a function to extract text metrics (separate message
> soon), and so I'm looking carefully at the behavior of the text() module.
>
> Issue 1:  valign
>
> With direction=ttb or btt, setting valign to "top" or "bottom" seems to
> produce results that are just wrong.
>
> If you set valign to "top", which normally puts the top of the text at
> the X axis, with the text in -Y, you get the text entirely *above*  the
> X axis, in +Y.  If you set it to "bottom", you get the text entirely
> *below* the X axis.
>
> "baseline" doesn't seem terribly well-defined for ttb or btt text, but
> it produces results identical to "bottom".  I can't come up with any
> font-metric justification for that, but then again the variations that I
> can think of based on font metrics wouldn't be very useful.  If I was
> starting from zero, I'd probably have "baseline" align the baseline of
> the first character on the X axis, but at this point there's backwards
> compatibility concerns.
>
> "center" is the only variation that produces results that look right.
>
> Does anybody know any of the history here?  Is this behavior of "top"
> and "bottom" intentional, or did it just kind of fall out of the
> implementation?
>
> My work doesn't depend on fixing it - I just want to make sure the
> metrics function returns the same results as the text module - but I'm
> happy to fix it if nobody knows of a reason why it should stay this way.
>
> My bet is that nobody ever really considered the valign behavior, and
> anybody who uses it uses the default valign, or "center".
>
> Proposal:  change top so that it yields text in -Y, bottom so that it
> yields text in +Y, baseline so that it leaves the baseline of the first
> character on the X axis, and changes the default to top so that the
> default behavior remains unchanged.
>
>
> Issue 2:  halign
>
> With direction=ttb or btt, setting halign seems to produce the wrong answer.
>
> "left" produces results centered on the Y axis.
>
> "center" produces results left of the Y axis, just touching it.
>
> "right" produces results further left of the Y axis.
>
> In all of the variations, the individual glyphs are centered with
> respect to each other, which seems sensible.
>
> Having centering be the default makes sense, but when you explicitly say
> left/center/right the results are wrong.
>
> Again, this doesn't block my work but while I'm here I'm happy to fix it.
>
> Again, I suspect that nobody ever really considered the halign
> variations, and the default is the only variation used.
>
> Proposal:  Keep the individual characters centered against with respect
> to each other.  Have "left" yield text in +X, with the left side
> touching the Y axis, "right" yield text in -X with the right side
> touching the Y axis, "center" yield text surrounding the Y axis, and
> have the default be "center" so the default behavior doesn't change.
>
>
> Any thoughts?
>
>
> _______________________________________________
> 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: several variations on text() ttb/btt and valign and halign seem wrong

MichaelAtOz'
To be clear, that was not answering your second post, about centred glyphs. TO DO.

> -----Original Message-----
> From: Discuss [mailto:[hidden email]] On Behalf Of MichaelAtOz
> Sent: Tue, 29 Dec 2020 17:57
> To: 'OpenSCAD general discussion'
> Subject: Re: [OpenSCAD] several variations on text() ttb/btt and valign and halign seem
> wrong
>
> Yes.
>
> .
> .
> .
>
> I reviewed my testing of text(), you are right there was not much attention to ttb/btt.
> I went looking to see if there was some obscure reason in other language layouts.
> Not in this simplistic implementation, it is actually much more complicated to
> do it correctly.
> e.g.
> https://www.unicode.org/notes/tn22/RobustVerticalLayout.pdf
> https://www.unicode.org/reports/tr50/
>
> So I'm presuming the ttb/btt is more for general layout than adaption to other languages.
>
> As such your proposals have merit.
>
> I have Bcc's Torsten to make sure he has seen this, as text() was his baby.
>
> I do wonder if we have any members who actually try to use it for real vertical language
> display.
>
> > -----Original Message-----
> > From: Discuss [mailto:[hidden email]] On Behalf Of Jordan Brown
> > Sent: Mon, 28 Dec 2020 11:23
> > To: OpenSCAD general discussion
> > Subject: [OpenSCAD] several variations on text() ttb/btt and valign and halign seem
> wrong
> >
> > I'm working on a function to extract text metrics (separate message
> > soon), and so I'm looking carefully at the behavior of the text() module.
> >
> > Issue 1:  valign
> >
> > With direction=ttb or btt, setting valign to "top" or "bottom" seems to
> > produce results that are just wrong.
> >
> > If you set valign to "top", which normally puts the top of the text at
> > the X axis, with the text in -Y, you get the text entirely *above*  the
> > X axis, in +Y.  If you set it to "bottom", you get the text entirely
> > *below* the X axis.
> >
> > "baseline" doesn't seem terribly well-defined for ttb or btt text, but
> > it produces results identical to "bottom".  I can't come up with any
> > font-metric justification for that, but then again the variations that I
> > can think of based on font metrics wouldn't be very useful.  If I was
> > starting from zero, I'd probably have "baseline" align the baseline of
> > the first character on the X axis, but at this point there's backwards
> > compatibility concerns.
> >
> > "center" is the only variation that produces results that look right.
> >
> > Does anybody know any of the history here?  Is this behavior of "top"
> > and "bottom" intentional, or did it just kind of fall out of the
> > implementation?
> >
> > My work doesn't depend on fixing it - I just want to make sure the
> > metrics function returns the same results as the text module - but I'm
> > happy to fix it if nobody knows of a reason why it should stay this way.
> >
> > My bet is that nobody ever really considered the valign behavior, and
> > anybody who uses it uses the default valign, or "center".
> >
> > Proposal:  change top so that it yields text in -Y, bottom so that it
> > yields text in +Y, baseline so that it leaves the baseline of the first
> > character on the X axis, and changes the default to top so that the
> > default behavior remains unchanged.
> >
> >
> > Issue 2:  halign
> >
> > With direction=ttb or btt, setting halign seems to produce the wrong answer.
> >
> > "left" produces results centered on the Y axis.
> >
> > "center" produces results left of the Y axis, just touching it.
> >
> > "right" produces results further left of the Y axis.
> >
> > In all of the variations, the individual glyphs are centered with
> > respect to each other, which seems sensible.
> >
> > Having centering be the default makes sense, but when you explicitly say
> > left/center/right the results are wrong.
> >
> > Again, this doesn't block my work but while I'm here I'm happy to fix it.
> >
> > Again, I suspect that nobody ever really considered the halign
> > variations, and the default is the only variation used.
> >
> > Proposal:  Keep the individual characters centered against with respect
> > to each other.  Have "left" yield text in +X, with the left side
> > touching the Y axis, "right" yield text in -X with the right side
> > touching the Y axis, "center" yield text surrounding the Y axis, and
> > have the default be "center" so the default behavior doesn't change.
> >
> >
> > Any thoughts?
> >
> >
> > _______________________________________________
> > 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


--
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