From: Fabien C. <fab...@go...> - 2010-06-22 10:17:04
|
On Tue, Jun 22, 2010 at 03:02, Peter Mousley <scr...@mo...>wrote: > On 22/06/2010 2:17, Fabien Chéreau wrote: > > Hi thanks for the effort! This is quite similar to the previous code > > we had in Stellarium, but we had to change to support international > > characters. I think you code suffers from the same problems that our > > had. Namely, if you want to display e.g. a chinese character, you need > > to use a font which supports it, otherwise you end up with a broken > > character. Qt solves this by reverting to other fonts if it sees that > > it's not supported by the base font. Also your code won't handle > > characters's linking, like in arabic. > > > > Actually there is also another quite easy way to fix the problem: > > render the text in a QImage or QPixmap and just dump the image on the > > screen. This is is probably easier than your solution, and could even > > also allow performances improvement by using caching of the whole > > words. I never did it so far because I always hoped that Qt will fix > > the problem, but now it indeed seems that they lack motivation for > > working on that.. > > Fabien > > I can't read Chinese but it looks okay to me (the planet labels match > the info box characters - they overlap slightly but that should be easy > to fix). This is surprising, DejaVu doesn't support Chinese characters. Probably the win32 API (CreateFontW) also provides a replacement character from another font by itself. > You are correct about Arabic; it will not link the > characters. But which is better - characters that aren't linked or > characters that looked like squashed tomatoes? It would be best left to > someone fluent in Arabic, etc. The font can be anything (just remove > the hard-coded selection I put in and pick up the current app font), > although for me it uses DejaVu Sans for Arabic and Chinese by default > anyway. > Should it prove usable, this type of code should only be a fall-back, > not the default; it should be similar to the already included OpenGL > '--safe-mode'. Perhaps '--safe-fonts'? Or, just make it an extension of > the existing --safe-mode, i.e. if safe-mode is active, use the alternate > text drawing method. > > But that's jumping ahead - this (or something else) needs testing. What > I would like to know is, "Do you want this as a solution (in which case > I'll get it properly tested and finished) or do you want to use > something else?" > I am quite unsure. My main subjective feeling is that it would be a regression to come back to such hacks after all our efforts to move to Qt completely. But I also agree that this bug is so annoying that we should really do something, and I really appreciate your efforts! > RE: Other solutions > > I'm all for a simpler/better solution. But this code is simple to use, > fast when running and once the 'ReplacementFont' code is moved out of > StelPainter, it would hardly look any different to what's there now. > I'll take a look at QImage/QPixmap if you want, but you could probably > do it in 10% of the time (I'll then test it for you). > > Before deciding whether to merge or not in trunk, I would really like to see an alternative Qt based solution, not involving win32 API. I just played a bit with the QImage/QPixmap idea, and it works more or less, although it's a bit slow. See the attached 10 lines patch. Fabien |