[osg-users] osgText::Text character spacing
Thorsten Brehm
I'm having a problem with osgText::Text since r12068. Everything is fine
up to r12067, so I'm absolutely certain it's related to this commit:
http://www.openscenegraph.org/projects/osg/changeset/12068
With this change, osgText::Text has excessive character spacing.
Characters are so far apart that any text is unreadable (only 2-4
characters fit on the screen using "usual" character sizes/widths...).
I've attached a patch which "fixes" the issue for me and restores
"normal" spacing. However, it's simply reverting the relevant changes of
r12068. There probably was a good reason to change these lines in the
first place. But I'm at loss why it's not working for me. Maybe
something was broken - or is there anything that requires applications
to be adapted when using >=r12068 osgText::Text?
That's a sample of how the application is using osgText - nothing fancy
really:
text = new osgText::Text;
text->setFont(font);
text->setCharacterSize(0.06);
text->setColor(osg::Vec4(1, 1, 1, 1));
text->setPosition(osg::Vec3(0, 0.82, 0));
text->setAlignment(osgText::Text::CENTER_CENTER);
text->setText(Message);
Any ideas?
cheers,
Thorsten
Robert Osfield
What happens when you run osgtext and osgtext3D? The spacing is
correct for me for svn/trunk for these two example applications.
What OS/Build tools are you using? What version of freetype?
Robert.
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Thorsten Brehm
On Sun, May 8, 2011, Robert Osfield wrote:
> What happens when you run osgtext and osgtext3D? The spacing is
> correct for me for svn/trunk for these two example applications.
The osgtext example also works for me. osgtext3D just exits with
errorcode 1 - but that's likely an unrelated issue. So it must be
triggered by something that our application does differently compared to
the osgtext example.
> What OS/Build tools are you using? What version of freetype?
Linux/x86_64, gcc 4.4.1. Freetype 1.3.1.
Application is FlightGear. We got several reports on this issue -
involving different compilers/OS/... etc. AFAICS OSG >=2.9.11 is the
only thing common to all reports. Also, according to our devel list, no
one has reported any success with osgtext/OSG>=2.9.11 yet. So, it either
has to be a problem with OSG, or a problem with the way our own sources
use osgText (maybe we're somehow relying on some bug which was fixed by
r12068 or the osgText change reveals some problem on our side which so
far had no effect).
What exactly was the intention of the particular change (see diff in
previous email)?
cheers,
Thorsten
Robert Osfield
On Sun, May 8, 2011 at 4:35 PM, Thorsten Brehm <bre...@gmail.com> wrote:
> The osgtext example also works for me. osgtext3D just exits with errorcode 1
> - but that's likely an unrelated issue. So it must be triggered by something
> that our application does differently compared to the osgtext example.
Curious that osgtext3D is failing. I wonder if you system is picking
up fonts that don't have support for reading polygonal descriptions of
the fonts. Or perhaps it's the freetype version.
>> What OS/Build tools are you using? What version of freetype?
> Linux/x86_64, gcc 4.4.1. Freetype 1.3.1.
I'm using Kubuntu 11.04 with g++ 4.5.2 and freetype version 2.4.4.
Could you try updating your freetype version. It might be worth
checking what fonts you are using, perhaps these are returning
incorrect kerning information.
Robert.
Thorsten Brehm
On Sun, May 8, 2011 at 6:37 PM, Robert Osfield wrote:
> Curious that osgtext3D is failing. I wonder if you system is picking
> up fonts that don't have support for reading polygonal descriptions of
> the fonts. Or perhaps it's the freetype version.
> It might be worth
> checking what fonts you are using, perhaps these are returning
> incorrect kerning information.
Yes, it's the font which makes the difference! We're using txf font
files - not freetype. None of our txf fonts works with >=r12068. Maybe
our files are broken somehow, and don't supply the required kerning
info. But I suspect that it's rather the TXFFont plugin itself which
requires an update. The freetype plugin was adapted as part of changeset
12068, but TXFFont wasn't touched since. For example,
TXFFont::getKerning just returns (0,0). And it never calls any of the
new Glyph::setWidth/setHeight methods. I guess that's the likely cause?
cheers,
Thorsten
Robert Osfield
On Sun, May 8, 2011 at 6:49 PM, Thorsten Brehm <bre...@gmail.com> wrote:
> Yes, it's the font which makes the difference! We're using txf font files -
> not freetype. None of our txf fonts works with >=r12068. Maybe our files are
> broken somehow, and don't supply the required kerning info. But I suspect
> that it's rather the TXFFont plugin itself which requires an update. The
> freetype plugin was adapted as part of changeset 12068, but TXFFont wasn't
> touched since. For example, TXFFont::getKerning just returns (0,0). And it
> never calls any of the new Glyph::setWidth/setHeight methods. I guess that's
> the likely cause?
Good news, it does rather sound like it's a problem with the txf
plugin that hasn't been
updated correctly to handle the revisions to osgText. Could you send
me an example
txf file so that I can test it at my end.
Thanks,
Robert.
Thorsten Brehm
On 09.05.2011 09:28, Robert Osfield wrote:
> Good news, it does rather sound like it's a problem with the txf
> plugin that hasn't been
> updated correctly to handle the revisions to osgText. Could you send
> me an example
> txf file so that I can test it at my end.
Oh, of course, that's our main font:
Plenty more txf fonts available here:
http://www.gitorious.org/fg/fgdata/trees/master/Fonts
cheers,
Thorsten
Robert Osfield
On Mon, May 9, 2011 at 6:41 PM, Thorsten Brehm <bre...@gmail.com> wrote:
> Oh, of course, that's our main font:
>
> http://www.gitorious.org/fg/fgdata/blobs/raw/958c11a1b8e67c24035c19d2ef75aeeec387c58b/Fonts/Helvetica.txf
>
> Plenty more txf fonts available here:
> http://www.gitorious.org/fg/fgdata/trees/master/Fonts
Thanks for the pointer, using the Helvetic.txf I've recreated the
problem by running osgtext3d --2d -f Helvetica.txt, this co-opting the
osgtext3D example to render some text in 2D, but it does nicely
demostrate that the both the spacing and the sizing of the text is
wrong. If you run osgtext3D --2d it'll use ariel.ttf as the font and
it's able to show how the new osgText support can properly place both
the 3D and the 2D text in exactly the same place, this was broken
previous to the changes to osgText, but alas this improvements have
obviously not been properly handling in the txf plugin. I'll look to
fixing this today.
Robert.
Robert Osfield
I have tracked down the problem to the txf plugin not setting the
width and height of the glyph, adding this addressed the
sizing/spacing problems I saw when running the osgtext3D --2d --no-3d
-f Helvetica.txf test. My fix is now checked into svn/trunk.
Could you please test svn/trunk and let me know whether this addresses
the problems you've been seeing.
Thanks,
Frederic Bouvier
I simply merged r12395 in my 2.9.14 branch and got this :
http://frbouvi.free.fr/flightsim/fgfs-txf-fonts.jpg
oversized font!
Regards,
-Fred
----- "Robert Osfield" a écrit :
> Hi Thorsten,
>
> I have tracked down the problem to the txf plugin not setting the
> width and height of the glyph, adding this addressed the
> sizing/spacing problems I saw when running the osgtext3D --2d --no-3d
> -f Helvetica.txf test. My fix is now checked into svn/trunk.
>
> Could you please test svn/trunk and let me know whether this
> addresses the problems you've been seeing.
Robert Osfield
I've just modified the osgtext example to use the Helvetica.txf and
see the problem with oversized text.. The text has the right spacing,
but is just too large... I didn't spot the size problem yesterday as
the osgtext3D usage had the viewer moving the eye point back to view
the whole text so what ever size it was in object coordianates it only
took up the same size on screen.
Not sure where the culprit lies, it might be lack of scaling on the
osgText side, or perhaps just needing to rescale the sizes in txf. I
will dig into the code and see what is going on.
Robert.
Magnus Kessler
> Hi Robert & Thorsten,
>
> I simply merged r12395 in my 2.9.14 branch and got this :
> http://frbouvi.free.fr/flightsim/fgfs-txf-fonts.jpg
>
> oversized font!
Yes, I see the same with yesterday's head revisions of OSG and
flightgear/simgear.
Regards,
Magnus
>
> Regards,
> -Fred
Robert Osfield
On Fri, May 13, 2011 at 9:14 AM, Robert Osfield
<robert....@gmail.com> wrote:
> Not sure where the culprit lies, it might be lack of scaling on the
> osgText side, or perhaps just needing to rescale the sizes in txf. I
> will dig into the code and see what is going on.
I have tracked down the problem to fact that osgText now assumes that
all fonts handle their
own scaling to a unit font size of 1.0, rather than have each font
come in at any size and then
require osgText itself to rescale these. The freetype plugin honoured
this, but the txf font didn't
scale it's glyph settings to be against a unit size. I have now added
this and checked it in. Could
you please test this out?
In test with the txf plugin with a tweaked version of the osgtext
example I found that while the
scaling issues now looked to be resolved quite a few of the character
representations on screen
were corrupted or just blank. Initially I thought that it was down
the txf plugin becasue the freetype
and default fonts all worked correctly, but after much digging the
culrprit for these rendering problems
looked to be the mechanism for placing the glyph images into the
GlyphTexture (which works as
texture atlas). I haven't yet established exactly what is going
wrong, but as a workaround
increasing the margin size between the glyphs in the GlyphTexture
resolves the rendering problems.
Increasing margin size really is just a hack that happens to work for
this particular font, I don't see
it as a resolving the bug so I won't check this hack. Curiously this
bug will have been lurking
unseen for a while, and mainly just luck that it hasn't appeared with
the freetype fonts.
Robert.
Magnus Kessler
> Hi Frederic and Magnus,
>
> On Fri, May 13, 2011 at 9:14 AM, Robert Osfield
>
> <robert....@gmail.com> wrote:
> > Not sure where the culprit lies, it might be lack of scaling on the
> > osgText side, or perhaps just needing to rescale the sizes in txf. I
> > will dig into the code and see what is going on.
>
> I have tracked down the problem to fact that osgText now assumes that
> all fonts handle their
> own scaling to a unit font size of 1.0, rather than have each font
> come in at any size and then
> require osgText itself to rescale these. The freetype plugin honoured
> this, but the txf font didn't
> scale it's glyph settings to be against a unit size. I have now added
> this and checked it in. Could
> you please test this out?
Thanks, Robert. Your fix seems to work fine in FlightGear now. Text is now
rendered at the right size and with suitable spacing between letters again.
I notice a slight kerning issue, but that might very well have been there
before.
Magnus
Robert Osfield
On Fri, May 13, 2011 at 5:16 PM, Magnus Kessler <Magnus....@gmx.net> wrote:
> Thanks, Robert. Your fix seems to work fine in FlightGear now. Text is now
> rendered at the right size and with suitable spacing between letters again.
Good to hear it working once more. I still haven't tracked down the bugs
I'm seeing on rendering using txf with the osgtext example, so there is
chance that you might see problems later with more intensive use. I'm
still hunting this bug down so fingers crossed I'll nail it soon.
> I notice a slight kerning issue, but that might very well have been there
> before.
txf itself doesn't seem to support kerning, with the plugin just
returning a 0,0 offset
for kerning, both older and newer versions use this same default kerning value.
However, the code to advance between characters is a little changed,
the old code add
an arbitary extra 0.1 of height to the advance. I didn't maintain
this as it rather looked
like a hack. I can add this add back in if you feel that it would be
better to maintain
the extact spacing before, even if it doesn't actually match what the
font itself specifies.
Robert.
Robert Osfield
On Fri, May 13, 2011 at 5:45 PM, Robert Osfield
<robert....@gmail.com> wrote:
> I still haven't tracked down the bugs
> I'm seeing on rendering using txf with the osgtext example, so there is
> chance that you might see problems later with more intensive use. I'm
> still hunting this bug down so fingers crossed I'll nail it soon.
After a rather exhusting and perplexing debug session I finally
conerned the bug to
the way that the src/osgText/Font.cpp was caching seperate sets of
osgText::Glyph for
different font resolutions. This is correct behviour for formats like
FreeType or QFont,
but for fonts like the osgText::DefaultFont and the TXF fonts it's not
appropriate as these
only support a fixed resolution size, so if you request a different
font resolution you don't
actually get a different glyph, so it's inappropriate to cache it
multiple times. It's this
sharing of single Glyph between multiple apparent font resolutions
that caused the problem
with rendering of osgtext when using with Helvertica.txf.
I have now changed osgText::Font::FontImplementation so it can
automatically tell osgText::Font that
it's inappropriate to use the font resolution requested as guide, and
to just use a single glyph cache
for this fixed size. I had to update the freetype, DefaultFont,
osgQt::QFontImplementation and
txf plugin all to provide the correct setting, and this is all now checked in.
Curiously this particular bug will have been in the OSG for a very
long time, almost as long as osgText,
but was just never detected or characterised.
I also spotted and fixed a bug in handling of the
Object::resizeGLObjectLists request that may have meant
that opening new contexts whilst using fonts would have resulted in
the texturing of the text quads going astray.
All these changes are now checked into svn/trunk.
Cheers,
Thorsten Brehm
thanks for looking into the txf font issue. Your patch fixed the issue
for me - thanks resolving this so quickly!
I got one report though, saying the txf font is still slightly larger
than it used to be - so some of our text labels don't fit any longer. I
haven't been able to see/compare this myself though. I'll try that in a
few days.
And btw: we've been presenting FlightGear at LinuxTag/Berlin last week.
We were busy all days, so people obviously really liked our "little"
flight-sim setup - with 10 TFT displays driven by a single system with 5
graphics cards:
http://img607.imageshack.us/img607/3381/08stand2.jpg
We used another smaller setup to show stereoscopic (anaglyphic) view -
both proved to be real eye catchers. A number of people specifically
asked which graphics engine enabled this. So, thanks to you - and
everyone else here contributing to osg!
cheers,
Thorsten
Robert Osfield
On Mon, May 16, 2011 at 10:55 PM, Thorsten Brehm <bre...@gmail.com> wrote:
> thanks for looking into the txf font issue. Your patch fixed the issue for
> me - thanks resolving this so quickly!
Good to hear things working better again.
> I got one report though, saying the txf font is still slightly larger than
> it used to be - so some of our text labels don't fit any longer. I haven't
> been able to see/compare this myself though. I'll try that in a few days.
Text sizing will be a little different as I there were bugs in the way
that 2D and 3D
text was sized, while now the two are consistent, and different
resolutions of the
glyphs don't affect the results. These bug fixes will lead to changes in sizes
which is difficult to avoid - the new sizing should be more accurate
to what size
is actually requested, but this doesn't help you if the original coder
has adjusted the
sizing to account for the previous sizing.
I guess the best way to handle it would be to adjust the sizing depending
upon OSG version, or simply reduce the label sizing so that the new text labels
are correct w.r.t OSG svn/trunk. The later approach would lead to labels that
are too small but if the difference isn't significant you might be
able to get away
with this.
I'll be releasing the next dev release this week and I really don't want OSG-3.0
to be too far out, so shoudl be out in time for the next rev of
OpenFlight unless
this is imminent. What is the schedule for the next OpenFlight release?
> And btw: we've been presenting FlightGear at LinuxTag/Berlin last week. We
> were busy all days, so people obviously really liked our "little" flight-sim
> setup - with 10 TFT displays driven by a single system with 5 graphics
> cards:
> http://img607.imageshack.us/img607/3381/08stand2.jpg
> We used another smaller setup to show stereoscopic (anaglyphic) view - both
> proved to be real eye catchers. A number of people specifically asked which
> graphics engine enabled this. So, thanks to you - and everyone else here
> contributing to osg!
10 displays, that's impressive number to be driven by a single machine. What
is the framerate like?
Robert.
Thorsten Brehm
> Text sizing will be a little different as I there were bugs in the way
> that 2D and 3D
> text was sized, while now the two are consistent, and different
> resolutions of the
> glyphs don't affect the results. These bug fixes will lead to changes in sizes
> which is difficult to avoid - the new sizing should be more accurate
> to what size
> is actually requested, but this doesn't help you if the original coder
> has adjusted the
> sizing to account for the previous sizing.
too large, sometimes too small, and sometimes almost unchanged. Example:
http://imageshack.us/photo/my-images/101/osgtxfcomparison.jpg/
Top part is OSG2.8.3, bottom is OSG2.9.15 (r12419).
The change of font size is significant here (some parts are unreadable).
Not sure whether it only affects our project, only the txf font or
others too.
The problem in our specific case is that font sizes can also be
configured in custom files (i.e. in our aircraft models which provide
custom instruments) - and these sometimes don't belong to our project
directly. It will be very difficult to have them all changed - almost
impossible really. And obviously we cannot just introduce a factor in
our core program to restore the original font size (there is no constant
factor).
Even if the font size is correct now, one could still consider it a
regression. Not sure how you usually handle such cases for OSG. Are
there any chances to (optionally) switch OSG to the old behaviour (yes,
I know that meant extra hassle...)?
> I'll be releasing the next dev release this week and I really don't want OSG-3.0
> to be too far out, so shoudl be out in time for the next rev of
> OpenFlight unless
> this is imminent. What is the schedule for the next OpenFlight release?
I know nothing about OpenFlight. But for FlightGear the next release is
still weeks away (at least).
>> And btw: we've been presenting FlightGear at LinuxTag/Berlin last week. We
>> were busy all days, so people obviously really liked our "little" flight-sim
>> setup - with 10 TFT displays driven by a single system with 5 graphics
>> cards:
>> http://img607.imageshack.us/img607/3381/08stand2.jpg
> 10 displays, that's impressive number to be driven by a single machine. What
> is the framerate like?
Yes, the setup was a little extreme. We actually had to disable some of
our fancy graphic options to make the setup work. Managed about 30fps
eventually - though frame delays weren't quite even, so the perceived
frame rate was even lower (which may well be a problem with our own
code). Another issue were rapid changes of view direction, i.e.
extremely sharp 180 degree turns, which sometimes caused noticeable
stutters. But it worked well enough for a demonstration. I'd still
recommend to use a few separate but synchronized systems to drive so
many displays (which we hope to do one day).
cheers,
Thorsten
Robert Osfield
On Wed, May 18, 2011 at 9:00 PM, Thorsten Brehm <bre...@gmail.com> wrote:
> I was able to reproduce the problem now. Sometimes the font is slightly too
> large, sometimes too small, and sometimes almost unchanged. Example:
> http://imageshack.us/photo/my-images/101/osgtxfcomparison.jpg/
> Top part is OSG2.8.3, bottom is OSG2.9.15 (r12419).
Could you create a small example that prints the a set of different
fonts at different
sizes against quad the same hight as the font for reference. Running
this against
OSG-2.8.x and OSG-2.9.15+/svn/trunk will reveal a bit more what is happening
w.r.t sizing.
> Even if the font size is correct now, one could still consider it a
> regression.
I believe we've fixed bugs in osgText and the sizes should now be
more realiable and consitent across different font types and means
of rendering.
Breaking code that relied upon the original bugs is a tricky area, to
call fixing a bug a regression is not really appropriate.
> Not sure how you usually handle such cases for OSG. Are there
> any chances to (optionally) switch OSG to the old behaviour (yes, I know
> that meant extra hassle...)?
I can't see a way of re-introducing the original buggy scaling, the intention
of the changes was to make things more consistent so users needn't use
awkward scaling factors to workaround the original scaling problems. I
suspect users have adjusted scaling iteratively to workaround the orignal
scaling inconstenicies so may have not realized that it was broken - it
was only when I put Text3D and Text fonts side by side did I found out
that the scaling was broken for both types of Text and different types of
fonts.
I guess you might be able come up with a workaround to apply the the txf
plugin, perhaps as post process scaling.
>> I'll be releasing the next dev release this week and I really don't want
>> OSG-3.0
>> to be too far out, so shoudl be out in time for the next rev of
>> OpenFlight unless
>> this is imminent. What is the schedule for the next OpenFlight release?
>
> I know nothing about OpenFlight. But for FlightGear the next release is
> still weeks away (at least).
Ooops I meant FlightGear ;-)
Do you have a date for the FlightGear release?
Robert.
Thorsten Brehm
> On Wed, May 18, 2011 at/14:18:05/, Robert Osfield wrote:
> Could you create a small example that prints the a set of different
> fonts at different
> sizes against quad the same hight as the font for reference. Running
> this against
> OSG-2.8.x and OSG-2.9.15+/svn/trunk will reveal a bit more what is happening
> w.r.t sizing.
Ok, I'll try to prepare something here. I'm also curious how the effect looks
with different fonts.
> >/ Even if the font size is correct now, one could still consider it a/
> >/ regression./
> I believe we've fixed bugs in osgText and the sizes should now be
> more realiable and consitent across different font types and means
> of rendering.
>
> Breaking code that relied upon the original bugs is a tricky area, to
> call fixing a bug a regression is not really appropriate.
Yes, I know that osgText is improved and a bug is fixed now, so "regression"
probably wasn't the right word to use in the context of osg (I apologize).
Just meant that the behaviour of an existing feature in the osg library is
about to change in between released versions - and in the context of an
application using it, this may lead to issues of osgText looking differently
or (as in our case) also being unreadable - which potentially triggers loads
of issues for existing applications. Some libraries/products try to avoid such
issues - even at costs - but I know things like this can also cause huge hassle.
> I guess you might be able come up with a workaround to apply the the txf
> plugin, perhaps as post process scaling.
I'd probably need to find someone knowing more about osg to do that. Currently
I'm also trying to find out/estimate how many of our aircraft are affected. Not
sure how we'll proceed eventually.
> Do you have a date for the FlightGear release?
Just announced today: we're aiming to branch the next release in mid-July,
with the final release planned for mid-August. Any osg 3.0 estimates?
cheers,
Thorsten
Robert Osfield
I'm just following up of the txd font sizing issue, looking to resolve
outstanding issues before I tag the OSG-3.0 branch tomorrow.
> I'd probably need to find someone knowing more about osg to do that.
> Currently
> I'm also trying to find out/estimate how many of our aircraft are affected.
> Not
> sure how we'll proceed eventually.
Did you establish the extent of the sizing issue?
>
>> Do you have a date for the FlightGear release?
>
> Just announced today: we're aiming to branch the next release in mid-July,
> with the final release planned for mid-August. Any osg 3.0 estimates?
The current aim is for OSG-3.0.0-rc1 tomorrow, with the final OSG-3.0.0. going
next week.
Robert.