Hello Patrick, On 11/02/2011 01:33 PM, Patrick Hartling wrote: > On Nov 1, 2011, at 7:01 PM, Carsten Neumann wrote: >> what does custom glyph rendering mean in this context? Do you want to be >> able to render glyphs that are not part of a font? Apologies if this is >> a term with a specific meaning in "FTGL speech", I don't know that lib >> very well. > > Our current need is to be able to apply borders to the glyphs in order to > improve readability. I haven't been able to figure out how to do that with > OSG::TextTXFFace, but I may not have looked at the code thoroughly enough. > Borders are our starting point, and we may need to manipulate the glyphs > further in the future.
ok, I see, thanks for the explanation. This is currently not directly possible. I'll need to look closer at the existing code and get a better understanding of it before I could make any suggestions on how/if this could be added. Adding a different backend (based on the existing freetype one?) could be one way to get some control over the rendering of glyphs into textures, although not exactly a neat one ;) >>> * Full Unicode support using UTF-8 as the input encoding—unless >>> ICU4C or something equivalent were added as a dependency. I do not >>> want to get into the mess of wchar_t and std::wstring as that has >>> not worked out well for me in the past. This will most likely >>> require multi-font support to allow for fallbacks when a needed >>> glyph is not supplied by the primary font in use. >> >> AFAIK you can just feed a UTF-8 string to the OpenSG font functions and >> as long as there are appropriate glyphs in the font it will work. I >> don't think there is any fallback atm, but that would be an interesting >> addition. > > That was my understanding as well, but I have not been able to make it work. > I can only get code points in the range 0x20 to 0x7E (ASCII) to render > correctly. One thing that I have run up against is that I cannot determine > what encoding is produced by utf8Char2Unicode() in > Source/System/Text/OSGTextFace.cpp. It looks like it might be UTF-16, but > that would mean that this implementation does not support code points beyond > 0xFFFF. It can't be treated as UTF-32 on Windows because wchar_t is only 16 > bits wide on that platform. This makes it very difficult to know how to > interact with the various text-related objects except through the use of > UTF-8. Perhaps I am just spoiled because I have gotten used to ICU4C dealing > with encoding details in our code. That said, the FTGL demo program was able > to display whatever I threw at it with no special effort, and that was a big > selling point for me. See TextTXFParam::setCharacters(), it selects which character glyphs are stored in the texture. Concerning the use of UTF-16, ideally I would like to get rid of it, use UTF-8 throughout (or at least for user facing API) and only convert to other encodings when necessary (i.e. freetype seems to want UTF-32, windows APIs probably have UTF-16 interfaces). I haven't looked if that would result in many conversions or similar unwanted side effects, but my hope would be that it is not to difficult to do. >>> * Provide good performance and scalability. In our use cases, we >>> could very easily have hundreds or thousands of text billboards, >>> and we need to make efficient use of texture memory. While I have >>> no plans to limit things to texture-mapped text, that will be our >>> focus. Nevertheless, FTGL already implements multiple techniques, >>> and I see no need to apply limitations in that regard. >> >> with the current text code you should need only have on TextTXTFace >> object per font (meaning one texture) and can have arbitrary amounts of >> text generated from it. So, I'm not sure what causes you to be concerned >> about memory usage with the existing text implementation, can you give >> more details? > > I meant that what we do must be at least as efficient as what > OSG::TextTXFFace provides now. ok. >> I'm not sure if anyone strongly cares for anything other than texture >> mapped text these days. >> A really nice addition would be to support something like >> <http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf> >> which from the images in the paper would improve the looks of magnified >> text quite a bit. > > I can take a look at that. Anything that will improve readability is of > interest to me. On that note, another thing that FTGL supports is kerning. > >>> Basically, we want to be able make use of what FreeType, FTGL, and >>> OpenSG offer without being impeded by abstraction layers. That does not >>> necessarily mean that the API will be harder to use than what OpenSG >>> provides now, but my conclusion is that we need something new to do what >>> we want. >> >> Hmm, I'm not sure I've fully understood where you are expecting large >> obstacles in making OpenSG's text support do what you want. > > I hope that my answers above have clarified things. yes, I definitely have a better understanding of what issues you are attempting to solve. I'm still a bit unclear on where the existing code is preventing you to make the necessary additions/modifications, but it's entirely possible that is because I'm not familiar enough with it to spot the problems or because I'd much rather see you improve OpenSG than cooking up your own solution ;) >> As far as >> FTGL is concerned I'm somewhat indifferent about it, a downside is that >> is manages its own OpenGL state so is somewhat doing it's own thing >> besides OpenSG. Then again I don't know it well and it may have features >> that easily compensate for this? > > I see that as a downside as well. I don't yet know just how much of a problem > that will be. As mentioned above, I would prefer that you decided to improve the existing text support (no surprise I hope, I am biased in this case ;) ). If you go with FTGL I'd still be very happy if you choose to make it available, perhaps as a contrib library? Cheers, Carsten ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
