On Nov 3, 2011, at 2:42 PM, Carsten Neumann wrote: > 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 ;)
I hadn't considered that option, but I see how that could be useful. I guess the issue would then be how the backend is chosen. OSG::TextFaceFactoryBase is designed to make that decision at library compile time, and I'm sure that that is fine for 99.9% of use cases. I think that some refactoring of OpenSG text support is going to happen at some level, but because the big picture is not yet clear to me, I don't know where that will happen. >>>> * 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. I have been tweaking 16text_txf.cpp by changing what is passed to OSG::TextTXFParam::setCharacters(), and that is why I have been frustrated by this. It seems like it should be straightforward, but something is not working. I need to pursue it further, but at the moment, I am wrapped up in a completely different approach based on the PDF from Valve that you referenced. I have no doubt that I will get back to OSG::TextTXFParam very shortly, though. > 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. Your conclusions sound solid to me. I have found UTF-8 to be the path of least resistance, especially when interoperability of any form is needed. We currently have Unicode support based on a complex combination of QString, icu::UnicodeString, and Py_UNICODE. Under the hood, I think all of them use UTF-16 (mostly due to legacy decisions as I understand it), but conversion to and from UTF-8 ends up being the lynchpin for us. I was just looking at libunistring, and it appears to be a little bit too low-level/cumbersome for my current tastes. ICU4C is at the other end of the spectrum in that it provides far more functionality than what we need, but we were already using it to support other Unicode-aware libraries. Something in between the two that was STL-friendly out of the box would be a blessing for us. I imagine that the same could be said for OpenSG. >>>> * 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? My goal is to contribute something to OpenSG one way or another. While FTGL looked really promising at the beginning of this week, the feedback that you and Dirk have offered has made that seem like a less sound approach. I will probably have something further to report next week after we evaluate the distance field approach and how it could be applied to the current OpenSG text support. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ The information transmitted in this communication is intended only for the person or entity to which it is addressed and contains proprietary material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please destroy any copies, contact the sender and delete the material from any computer. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
