The Chess Variant Pages
Custom Search




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
This item is a desktop publishing resource
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-05-21
 By H. G.  Muller. Diagram Editor with scalable graphics. An easy-to-use tool for drawing boards and pieces of any size and color.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-08-15 UTC

Ok, new pegasus:

Much less ambiguous indeed! I uploaded it:

 


Greg Strong wrote on 2020-08-15 UTC

Ok, new pegasus:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wpegasus2.svg

The 2 was added to the filename to get around caching, but should be saved without the 2.


Greg Strong wrote on 2020-08-14 UTC

That's different than what I was thinking but I do like it and will give it a try.


H. G. Muller wrote on 2020-08-14 UTC

For XBoard I did it like this (second on fourth rank):


Greg Strong wrote on 2020-08-14 UTC

In the old one, the "wings" looked artificial and didn't really match - jagged right angles whereas the horse is smooth curves. But I see how this could look like the horse's mane rather than a wing. I have an idea how to make it more wing-like...


H. G. Muller wrote on 2020-08-14 UTC

You really think that is an improvement over the old one? It looks more like a horse with unruly hair to me than as something with wings...


Greg Strong wrote on 2020-08-14 UTC

Ah, yeah, the zip could be cached. Here is the fixed pegasus SVG:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wpegasus.svg


H. G. Muller wrote on 2020-08-14 UTC

The should be there now. Still t=newalfa.

[Edit] I probably missed that update. (Caching...)


Greg Strong wrote on 2020-08-14 UTC

File updated - there was a glitch with the Pegasus


Greg Strong wrote on 2020-08-14 UTC

I've uploaded an update to the SVG Alfaerie set here:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/GS-2020-08-14.zip

This file contains everything - not just the new graphics.  There are about 35 new images and some updates.  The set is now up to 130 pieces!  And that's just one color and does not include the compound pieces that are generated by the rendering tool on this page.  We now have enough to switch over almost all the Alfaerie-based piece sets.

H.G., can you extract this to wherever your rendering engine is pulling from, overwriting any existing files with the same name?  No need to render the set to PNG, I have a script to do that.


Fergus Duniho wrote on 2020-08-03 UTC

I found glibconfig.h in another directory and copied it over. I jumped through a bunch of hoops, and now it reports undefined references to several functions in cairo. It could be that render.c relies on an earlier version of cairo that had many functions no longer available in the new version.


Fergus Duniho wrote on 2020-08-03 UTC

See if there's a dnf/yum package for cairo-dev or something like that. On Ubuntu it is called "libcairo2-dev"

I got the correct name by piping "dnf list" into a file and searching it. I installed cairo-devel.x86_64 and librsvg2-devel.x86_64. It no longer complained about not finding cairo/cairo.h, but it still complained about not finding librsvg/rsvg.h. I found the correct directory and modified the #include lines appropriately, but then it complained that it cannot find glib-object.h. I made corrections in the glib include files to account for it being in the glib-2.0 directory, and I kept doing that for a while, but now I am at an impasse. It says it can't find glibconfig.h, and I can't find that include file in any of the glib-2.0 directories.


Greg Strong wrote on 2020-08-03 UTC

See if there's a dnf/yum package for cairo-dev or something like that. On Ubuntu it is called "libcairo2-dev"


Fergus Duniho wrote on 2020-08-03 UTC

I have not compiled it. I have only put the .c file there. I did just try to compile it, but it complained that I need <cairo/cairo.h>. I probably need the other one too, but compilers will stop with the first error.


H. G. Muller wrote on 2020-08-03 UTC

I tried to access https://www.chessvariants.com/cgi-bin/render (or render.cgi), but it gives me a 404 error.


Fergus Duniho wrote on 2020-08-03 UTC

I installed gcc and dnf. It looks like dnf is just an update of yum. So, maybe yum would do as well. Yum says that cairo and librsvg2 are already installed. Nothing came up when I tried to list librsvg by itself.

I placed a copy of the C file in /cgi-bin/ with a modified value for SVG_DIR.


H. G. Muller wrote on 2020-08-03 UTC

I made it on an old Ubuntu Linux (10.04), but the drawing code was taken from XBoard, which is used on many different Linux distros. So I suppose it should work on CentOS without problems. I did indeed use gcc to compile it. I suppose libcairo and librsvg are available from the distro repositories. For compiling you would also need the developer (-dev) packages for those (to have the #include files).


Greg Strong wrote on 2020-08-03 UTC

GCC should certainly do it.

I think our server is running CentOS, so we should be able to install the libraries with the dnf command.


Fergus Duniho wrote on 2020-08-03 UTC

I haven't compiled a C program in a while. It looks like I first need to install a C compiler. Will GCC do? And how should I make sure I have these libraries installed?


H. G. Muller wrote on 2020-08-03 UTC

It is a compiled C program. I posted the source at winboard.nl/render.c. I also posted the executable (winboard.nl/render). I am not sure whether that can be transferred to another machine; for Linux it is usually safer to recompile. The program uses the 'cairo' library for drawing, and librsvg for importing the SVG images.

It might not be completely trivial to get it running here.


Fergus Duniho wrote on 2020-08-02 UTC

Note that I do not want to keep the rendering engine on my website; I would be perfectly happy if it were on this website. It is just that there is no way for me to get it there, lacking ftp access.

If you can upload or email a zip file of your code, I'll look into installing it. From the .cgi extension, I'm guessing it's in Perl, but I don't think that extension is exclusive to Perl like .pl is.


H. G. Muller wrote on 2020-08-02 UTC

The page actually does produce a PNG image that can be uploaded to this website, when you hit the 'Draw' button. It also prints the URL for direct access to the renderer; this seemed useful for people that want to post a diagram on a site where they cannot upload stuff. I am not even sure that people who don't have contributed articles here can upload anything, e.g. for posting an image in a Comment.

The illustrations in the article can easily be replaced by uploaded images, and for some of those this would indeed be better. But it is very useful that a potential user can have some advance warning in the rare case that the rendering engine is off-line or unreachable, before he spends a lot of effort on composing a diagram that in the end will not render. Having an image on the page that directly samples the renderer seems a good way to do that. (Frankly, I do not know another way; browser security policies prevent probing another website in the background through JavaScript directly.)

Note that I do not want to keep the rendering engine on my website; I would be perfectly happy if it were on this website. It is just that there is no way for me to get it there, lacking ftp access.

The warning message is not really a technical problem; I can make it disappear through editing (the JavaScript embedded in) this page. So there is no need to build any special provision in the database for that. It is purely a policy matter whether it should be there and what it should say. When I first submitted the article I had in fact replaced it with a message explaining the purpose of the off-site images for the editors, but an editor commented that out of the script. That was fine with me; it meant he had seen it. For this occasion I temporarily re-instated the alternate warning.


Fergus Duniho wrote on 2020-08-02 UTC

I would prefer not to encourage the use of an external image rendering engine in IMG URLs on this site. If it can produce images that can be uploaded here, that is a different story, and this page could easily include uploaded copies of images created with his engine. But if that's not what it's for, and if H. G. wants to keep the rendering engine on his own site, it may be more appropriate to just have a link page to a page on his own website. A page on his own website would more easily have the same lifespan as the engine itself. If the engine were used on this site, images would break if anything happened to his site.


Greg Strong wrote on 2020-08-02 UTC

Fergus, I'm thinking the editors should have a flag we can set to suppress the "External image links detected!" warning for specific pages. While we generally don't want external images, the entire purpose of this page, for example, is to document and provide examples for an external image rendering engine. So external images here seem reasonable to me.

If you agree, I can add the sql flag and update the page logic.


H. G. Muller wrote on 2020-07-29 UTC

I unpacked your latest zip file in the winboard.nl/graphics.dir/svg/newalfa folder, and rendered them all (I hope). This time with the correct color blue. They can be downoaded from http://winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG35.tar.gz and http://winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG50.tar.gz .

If I inadvertantly forgot to render one, you could get it directly from the renderer.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.