headers
Jason Dorje Short | 4 Nov 2004 18:13

chess fonts

I'm trying to get GPL'd images for chess pieces in SVG format.

(Background: my chess program loads the SVG images at runtime.  This 
allows dynamic resizing of the chess pieces as the window resizes - a 
very nice effect.  The current images I have were created from the 
xboard bitmaps using autotrace; however this doesn't give very good 
results.  So I have the choice of finding graphics somewhere or 
attempting to draw them myself.)

The README in xboard's bitmaps directory claims that the metafont 
sources for the chess bitmaps may be obtained from the original author 
(Elmar Bartel) under the GPL.  However this notice is 10 years old. 
Does anyone now have a copy of these metafont sources?  If so I would 
like a copy (which I will try to put into SVG using fontforge, which I 
think is possible although I have little experience with this).

I also think if anyone has these sources still, they should/must be put 
into the xboard source distribution or at least made easily available. 
My interpretation of the GPL is that GPL'd image sources (SVG or font 
data)  should follow exactly the same rules as source code for "normal" 
programs.  This may not apply in this case because the copyright is 
still held by the original author, but there's no reason that I can see 
*not* to include them.

Finally I'd suggest that if possible xboard/winboard should also load 
and render the SVG files directly at runtime.  My program uses GTK and 
GDK, so loading SVG is trivial using librsvg.  Using XAW I have no idea 
what, if any, library xboard could use for this.

thanks,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tim Mann | 4 Nov 2004 19:19

Re: chess fonts

On Thu, 04 Nov 2004 12:13:13 -0500, Jason Dorje Short <jdorje <at> users.sf.net> wrote:
> I'm trying to get GPL'd images for chess pieces in SVG format.
> 
> (Background: my chess program loads the SVG images at runtime.  This 
> allows dynamic resizing of the chess pieces as the window resizes - a 
> very nice effect.  The current images I have were created from the 
> xboard bitmaps using autotrace; however this doesn't give very good 
> results.  So I have the choice of finding graphics somewhere or 
> attempting to draw them myself.)
> 
> The README in xboard's bitmaps directory claims that the metafont 
> sources for the chess bitmaps may be obtained from the original author 
> (Elmar Bartel) under the GPL.  However this notice is 10 years old. 
> Does anyone now have a copy of these metafont sources?  If so I would 
> like a copy (which I will try to put into SVG using fontforge, which I 
> think is possible although I have little experience with this).

Did you try asking Elmar or are you just assuming that everything times
out after 10 years?  Anyway, I still have a copy of the elch metafont
sources too.  I'll attach it.

> I also think if anyone has these sources still, they should/must be put 
> into the xboard source distribution or at least made easily available. 
> My interpretation of the GPL is that GPL'd image sources (SVG or font 
> data)  should follow exactly the same rules as source code for "normal" 
> programs.  This may not apply in this case because the copyright is 
> still held by the original author, but there's no reason that I can see 
> *not* to include them.

Well, if you want to get technical about the GPL, saying that you have
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason Dorje Short | 4 Nov 2004 22:17

Re: chess fonts

Tim Mann wrote:
> On Thu, 04 Nov 2004 12:13:13 -0500, Jason Dorje Short <jdorje <at> users.sf.net> wrote:
> 
>>I'm trying to get GPL'd images for chess pieces in SVG format.
>>
>>(Background: my chess program loads the SVG images at runtime.  This 
>>allows dynamic resizing of the chess pieces as the window resizes - a 
>>very nice effect.  The current images I have were created from the 
>>xboard bitmaps using autotrace; however this doesn't give very good 
>>results.  So I have the choice of finding graphics somewhere or 
>>attempting to draw them myself.)
>>
>>The README in xboard's bitmaps directory claims that the metafont 
>>sources for the chess bitmaps may be obtained from the original author 
>>(Elmar Bartel) under the GPL.  However this notice is 10 years old. 
>>Does anyone now have a copy of these metafont sources?  If so I would 
>>like a copy (which I will try to put into SVG using fontforge, which I 
>>think is possible although I have little experience with this).
> 
> Did you try asking Elmar or are you just assuming that everything times
> out after 10 years?  Anyway, I still have a copy of the elch metafont
> sources too.  I'll attach it.

I e-mailed him right before sending my mail to the list, but I haven't 
gotten a reply.  Thanks for your quick response.

>>Finally I'd suggest that if possible xboard/winboard should also load 
>>and render the SVG files directly at runtime.  My program uses GTK and 
>>GDK, so loading SVG is trivial using librsvg.  Using XAW I have no idea 
>>what, if any, library xboard could use for this.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Hoelscher | 5 Nov 2004 01:10

Re: chess fonts

Jason Dorje Short said:
>>>Finally I'd suggest that if possible xboard/winboard should also load
>>>and render the SVG files directly at runtime.  My program uses GTK and
>>>GDK, so loading SVG is trivial using librsvg.  Using XAW I have no idea
>>>what, if any, library xboard could use for this.
...
> For rendering SVG in X11 Cairo looks like the only solution, but I don't
> think it is mature enough yet to add as a hard requirement.  Another
> alternative, of course, is "upgrading" xboard to use GTK.

Jason: Note that Cairo is more of a vector-based graphics output library
than anything... think different output on different types of media, and
eventually a way for toolkits to free themselves from the tyranny of the
pixel. As Cairo nears maturity, there are plans for librsvg to support a
Cairo backend in addition to (or possibly replacing) the libart option.
That said, present-day, there's nothing wrong or improper about using a
SVG library that renders to raster images for use in a computer game.

To support SVG, any library xboard could choose would also have other
dependencies... In librsvg, at a minimum, this would be libart and
libxml2. It's unlikely any SVG library wouldn't rely on at least one XML
library.

<plug> Since you are using Gtk+ in your app, I recommend checking out
games-preimage, part of libgames-support in that I added to CVS
gnome-games a few weeks ago. It's provides a relatively low-hassle way of
loading and scaling both SVG and PNG, and it's being now used in gnome
solitaire and a few other games... You should be able to copy it into your
app and remove the Gnome-VFS part easily. It requires CVS librsvg and a
recent gtk+-2.5 </plug>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Mehrmann | 6 Nov 2004 23:29
Picon
Picon

New wb2 protocol command "gui"

Hello folks :)

After a long time i did something for xboard/winboard.
A lot of engine authors wish to know which wb2 GUI will be used.
A lot of commercial/free GUI's support extend features above wb2 protocol.

With this command the engine now knows which gui running and _can_, not
_must_, support special features for the GUI.

For example its not clear defined how to look the PV string in wb2.
That not bad, because each author can do it yourself and have more free
space to use it :)
Example we send the nice line: "12. de5 Qxe5 13. Ndxe5 a7a8=Q....."

But other GUIs can't read that stuff and want to have:
"d4e5 d7d5 f3e5 a7a8q"

I send my idea to our CVS server but that _not_ mean thats offical !.
I only give you a change to look about, make some "brain stroming".
Allso Tims response is very importend. If no we drop this :(

I post this suggestion to the CCC Forum too.

How it technial works please read the changed engine-intf.html file :)

The DIFF:
---------
backend.c:

+      sprintf(buf, "xboard\ngui xboard %s\nprotover %d\n", VERSION,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Mann | 7 Nov 2004 01:55

Re: New wb2 protocol command "gui"

It would be better to define a new "feature" command for each feature
that other GUIs have and xboard doesn't.  That's how the protocol is
supposed to be extended.

Either way, you'll have to get the other GUI authors to start supporting
this addition for it to be of any use to engine authors.

On Sat, 06 Nov 2004 23:29:03 +0100, Daniel Mehrmann <daniel.mehrmann <at> gmx.de> wrote:
> Hello folks :)
> 
> After a long time i did something for xboard/winboard.
> A lot of engine authors wish to know which wb2 GUI will be used.
> A lot of commercial/free GUI's support extend features above wb2 protocol.
> 
> With this command the engine now knows which gui running and _can_, not
> _must_, support special features for the GUI.
> 
> For example its not clear defined how to look the PV string in wb2.
> That not bad, because each author can do it yourself and have more free
> space to use it :)
> Example we send the nice line: "12. de5 Qxe5 13. Ndxe5 a7a8=Q....."
> 
> But other GUIs can't read that stuff and want to have:
> "d4e5 d7d5 f3e5 a7a8q"
> 
> I send my idea to our CVS server but that _not_ mean thats offical !.
> I only give you a change to look about, make some "brain stroming".
> Allso Tims response is very importend. If no we drop this :(
> 
> I post this suggestion to the CCC Forum too.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Mehrmann | 7 Nov 2004 02:30
Picon
Picon

[Fwd: New wb2 protocol command "gui"]

resending....

-------- Original Message --------
Subject: New wb2 protocol command "gui"
Date: Sat, 06 Nov 2004 23:29:03 +0100
From: Daniel Mehrmann <daniel.mehrmann <at> gmx.de>
To: xboard-devel <at> gnu.org,  buers <at> gmx.de

Hello folks :)

After a long time i did something for xboard/winboard.
A lot of engine authors wish to know which wb2 GUI will be used.
A lot of commercial/free GUI's support extend features above wb2 protocol.

With this command the engine now knows which gui running and _can_, not
_must_, support special features for the GUI.

For example its not clear defined how to look the PV string in wb2.
That not bad, because each author can do it yourself and have more free
space to use it :)
Example we send the nice line: "12. de5 Qxe5 13. Ndxe5 a7a8=Q....."

But other GUIs can't read that stuff and want to have:
"d4e5 d7d5 f3e5 a7a8q"

I send my idea to our CVS server but that _not_ mean thats offical !.
I only give you a change to look about, make some "brain stroming".
Allso Tims response is very importend. If no we drop this :(

I post this suggestion to the CCC Forum too.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mehrmann, Daniel, fiscus GmbH, Bonn | 8 Nov 2004 18:25

AW: New wb2 protocol command "gui"

Hello Tim,

basicly you're right :) But i don't see that as a extension 
in the own reflect of the protocol (feature=x element). Its more a
information for the 
engine, nothing more ! And i thought it should be only support the current
features above wb2
in the GUI's. That shouldn't called that the GUI begin to add new features
!!
Maybe i wrote that wrong in my first message. But okay the rsik is very high
that other GUI's
beginn to add not offical features and than we have a nightmare. 

I don't wanna use the "feature=x" syntax, because that would be a real
extension and all new
real extensions should _not_ go into wb2, it should go into wb3. And at the
moment i don't do 
this job. With the "gui" command its not my target to go to wb3. It should
only be "hotfix"
for all wb2 GUIs.

But okay, i respect your direction and i will remove the stuff soon.

--
Daniel Mehrmann
Softwaredeveloper project Bustra 3.0
fiscus GmbH
http://www.fiscus-gmbh.com
Phone +492282807182
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Mann | 9 Nov 2004 17:11

Re: New wb2 protocol command "gui"

On Mon, 8 Nov 2004 18:25:01 +0100 , "Mehrmann, Daniel, fiscus GmbH, Bonn" <d.mehrmann <at> fiscus.info> wrote:
> Hello Tim,
> 
> basicly you're right :) But i don't see that as a extension 
> in the own reflect of the protocol (feature=x element). Its more a
> information for the 
> engine, nothing more !

If all the GUIs follow the protocol exactly, there's no reason for the
engine to know which GUI it's talking to.  It's useless information.

If some GUI doesn't follow the protocol because of poor programming,
then the GUI author should fix it.  He shouldn't send "gui mumble" to
the engines and expect hundreds of engine authors to change to
deal with his mistake.

If some GUI doesn't follow the protocol because it needs an extra
feature that the protocol doesn't provide, then a "feature" command
should be used if possible.  The feature command is backwards for this,
unfortunately, because it's something that the engine asks the GUI for,
not vice versa.  However, a "gui" command is too vague to deal with a
problem like this.

> And i thought it should be only support the current
> features above wb2
> in the GUI's. That shouldn't called that the GUI begin to add new features
> !!

If there are already some specific things that GUIs need that aren't in
the protocol, let's deal with them one by one.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane