Hello,
On 17.09.2014 21:38, H.G. Muller wrote: >>> The problem seems to be that you want >>> one and the same texture bitmap to work over a very wide range of board >>> sizes. >> well, yes, of course. > XBoard was just never designed to do that. Before we switched to Cairo > plotting, every single board size needed a separate set of images for > the pieces. but we're no longer in the past :) >> Say hello to non-integer factor image scaling, please. > I tried that, and it looked very ugly on the textures, and in particular > on the Xiangqi board. I'm pretty sure it depends on the kind of texture. And with SVG, scaling should look sharp at any resolution anyway. > The problem is that the way you want it to work would wreck the > behavior I would like to have for the version we distribute. How so? I don't think that's the case if you separate single-field and full-board modes properly. I still hope for that to come. > The Xiangqi > board that goes with the distro (preferably the ones we already have) > should at least display at any standard board size, which means upto 129 > x 129, and in the old code that was not the case, as your initial > screenshot showed. The situation is better now than two days ago (and I would welcome a new release with those patches soon) but I consider the fact it doesn't work for other full board images rather sad. I don't really see why XBoard graphics quality should /not/ be as high as that of http://blog.hartwork.org/__images/setup_imitate_playok.svg viewed in Firefox at any given zoom factor. Maybe that's a goal for XBoard in 2015. > The similarity of the tiles can be further disguised by randomizing > their orientation (although I am not sure XBoard does that. WinBoard > doesn, though). I can confirm that feature is missing in Xboard, yes. It's a cool feature. I would go further and allow/deny mirroring with certain kinds of textures but that would need new switches for a human to control... which I suppose you're not too much of a fan of. > You convinced me that there would be some merit in an option that > forces contiguous cutting, achieved by scaling the texture to exactly > the required size, for Escherian boards. Cool. >> * It's still as broken for other_1800x2000.png . >> >> >> To get it compiling, I needed to apply the gettext 0.18 patch from >> https://savannah.gnu.org/bugs/index.php?39970 . It would be cool to have >> that applied upstream: even Debian stable has gettext 0.18 by now. >> Which distro and version of gettext are you running? > I am running Ubuntu 10.04, which has gettext 0.17 and does not support > higher versions. If that's Ubuntu Desktop version, support for it ran out in May 2013. What does a Ubuntu from 2010 have, that you don't find in 2014 with other releases or distros of Linux? > I don't really know much about Linux, and Arun Persaud does the gettext > and autotools stuff, but this gettext problem seems very tough. The > Debian patch would prevent me to compile it. It seems inconceivable that > it would not be possible to have a version that would work on any > gettext version from version 0.01 and up, as we only use the most basic > features (the _(), N_() macros, and I think one other). This is > confirmed by the fact that we never have to change anything in the > actual C source. It is purely an autoconf problem, which drags a number > of m4 macros from somewhere, which then aren't the version that some > automatically generated Makefile then thinks it must insist on. Frankly I believe you need to get off Ubuntu 10.04: (a) for your own security (you have long run out of security updates, haven't you?) and (b) for developing XBoard against stable or development dependencies, not against old-stable (in Debian terminology). Best, Sebastian
