<div dir="ltr">Hi Glenn,<br><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2018 at 12:11, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">While I haven't got to the bottom of the change in behaviour, I am not sure that SCREEN_COORDS scaling is wholly appropriate for you usage case</div></blockquote><div><br></div><div>I have been thinking so more and now wonder if we can check whether the Text::CharacterSizeMode and AxisAlignment should be both checked for in the TextBase::computeMatrix(osg::Matrix& matrix, osg::State* state) const method and have different behaviour based on the different combinations.  The current implementation assumes that AxisAlignment is SCREEN when CharacterSizeMode is SCREEN_COORDS, this is what I'd would normally expect users to set up together as it there isn't an obvious mapping for when AxisAlignment isn't SCREEN when CharacterSizeMode is SCREEN_COORDS.  <br></div><div><br></div><div>I'm not sure what the most robust way to handle SCREEN_COORDS when AxisAlignemtn isn't SCREEN, perhaps one could use AxisAlignment directions so give up and side vectors that one could project onto the screen, or combine both, or perhaps use the normal vector as well when trying to infer what the scaling should be.  <br></div><div><br></div><div>Robert.<br></div><div><br></div><div> </div><div><br></div><div> </div></div><br></div></div>