Hi all,

I've also experienced the "font chopping" problem and have also observed 
that the order of initialisation definately makes a difference to the 
output.

My latest 'fix' was to use different fonts for the two sizes of text I 
want to display.

jp

Robert Osfield wrote:
> Hi Jeremy,
> 
> It shouldn't really matter which order you do things in.  The
> GlyphTexture will be populated in a different order but it shouldn't
> make any difference beyond this.   The fact you are observing a
> difference suggests that GlyphTexture population order is affecting
> things in some way.  I can't think off hand what this might be - the
> only very vague guess would that the tex coords are different in some
> way, perhaps this is related to the clipping you've observed.
> 
> FYI, I might be doing some refactoring work of the rendering code
> inside osgText in the not too distant future.  At this point I will
> need to review the lots of code internally with osgText so it'd be a
> good time to have some unit tests to utilise - osgWidget might well be
> a good way to generate unit tests ;-)
> 
> Robert.
> 
> On Wed, Mar 5, 2008 at 10:33 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote:
>> I'd like to add another bit of info to this thread; attached are two
>>  screenshots (good.png & bad.png) rendered using almost identical code:
>>
>>  good.png (sharp, crisp)
>>  --------------------------------------------------------------------
>>
>>         text->setFontResolution(...)
>>         text->setCharacterSize(...)
>>         text->setText(...)
>>
>>
>>
>>  bad.png (very blurry)
>>  --------------------------------------------------------------------
>>
>>         text->setText(...)
>>         text->setFontResolution(...)
>>         text->setCharacterSize(...)
>>         text->update()
>>
>>
>>
>>  Is there something wrong with my 2nd usage of osgText::Text such that I
>>  get the poorer quality? I understand that in the first usage the font
>>  sizes are already set before the initial text is rendered internally,
>>  but shouldn't the 2nd usage produce identical results, given that I call
>>  update after setting the new values? (My assumption here, however, could
>>  be woefully wrong, but will be useful information either way. :))
>>
>>
>>
>>
>>  On Wed, 2008-03-05 at 16:10 -0500, Jeremy Moles wrote:
>>  > I've attached a screenshot of some text rendered in a very standard way
>>  > using osgText:
>>  >
>>  >       text->setFont(std::string("fonts/monospace.ttf"));
>>  >       text->setCharacterSize(size);
>>  >       text->setFontResolution(size, size);
>>  >       text->setText(label);
>>  >       text->setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f));
>>  >
>>  > In the screenshot, a the very bottom, you'll see a bit of text called
>>  > "label 6 (copy)". Take a close look at the following characters:
>>  >
>>  >       a, e, 6, (
>>  >
>>  > ...and you'll notice that the glyphs are 1 (perhaps 2) pixels "chopped"
>>  > off at the left.
>>  >
>>  > I've been hunting this down forever--in fact, I've made a lot of similar
>>  > posts in the past--but I simply cannot prevent this occurrence in a
>>  > predictable way. If I play with the font sizes I can sometimes achieve
>>  > nearly perfect font quality, but it's all guess-work.
>>  >
>>  > So I've decided to go back to square one and ask the mailing lists: can
>>  > anyone with any heavy osgText experience give me any hints as to what is
>>  > going on? I've tried all of the KERNING options (though this is a
>>  > monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph
>>  > absolutely is "pixel aligned", I've tried all manner of different
>>  > fonts--but nothing seems to give predictable rendering results. My
>>  > suspicion is that the GlyphQuads object's _texcoords values are getting
>>  > calculated slightly wrong in some cases, but I'm not sure.
>>  >
>>  > Having precise font quality in osgWidget will be really important, so
>>  > I'm willing to make any code changes necessary to facilitate this...
>>  > _______________________________________________
>>  > osg-users mailing list
>>  > osg-users@lists.openscenegraph.org
>>  > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>> _______________________________________________
>>  osg-users mailing list
>>  osg-users@lists.openscenegraph.org
>>  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail 
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their 
support.

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to