Check out Alice Chess, our featured variant for June, 2024.


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

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order LaterLatest
Diagram Designer. Lets you display diagrams without uploading any graphics.[All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 01:03 AM UTC in reply to H. G. Muller from Wed Dec 28 08:17 PM:

Okay, I have added a fen shortcode. If you have already set the set or the cols value with the set or cols shortcodes, it will use those values. For example:

You can also include extra parameters after the fen code, just as you would in a query string, because it's just going to plug your FEN code into a query string.

As an editor, just check the source code to see what the shortcodes look like.


H. G. Muller wrote on Thu, Dec 29, 2022 08:39 AM UTC in reply to Fergus Duniho from 01:03 AM:

You can also include extra parameters after the fen code, just as you would in a query string, because it's just going to plug your FEN code into a query string.

A smart and convenient trick. This means we really don't need the 'cols' and 'set' shortcodes. The latter doesn't seem to be working anyway.

The purpose, however, is to make it as easy as possible for a noob user, who doesn't know the ins and outs of the Diagram Designer, and probably doesn't even know it exists. We cannot expect such users to know the 'cols' keyword, or query-string syntax, the 'set' keyword or the names of the available sets, etc. So it is important that we invoke the Diagram Designer with the most useful default values. To which we then append &code= plus the string between the fen tags. This would still allow 'power users' to overrule the defaults by adding parameters at the end of the FEN in query-string syntax, as in case of duplicat specification of a key, the one encountered latest will prevail.

set - I think auto-alfaeriePNG35 would be the best default here, (or an equivalent overly large set forced to display at reduced size) because:

  • It has the largest number of pieces.
  • It is small, allowing representation of large boards without problems.
  • Orthodox pieces use their conventional icons, which each chess player will recognize.
  • Pieces can be indicated by {name}. Apart from the orthodox pieces there are no universal single-letter abbreviations for chess pieces, and the alphabet is not large enough anyway, so non-obvious abbreviations would be more the rule than the exception. Users would know that they wanted a camel, giraffe or rhino, but even if these had letters assigned to them, these would not be C (cannon), G (griffon) or R (rook), and the users would be clueless as to what letter to use.
  • For compactness the orthodox pieces and most-common fairies (Archbishop, Cannon, Elephant, Griffon, Marshall) can also be indicated with a single letter.

cols - This still should be automated. I propose to treat a setting cols=10000 (or some other large value that can never be used in practice) on the Diagram Designer as a special value, which would derive the true value from the length of the first row of the FEN in the code parameter. This would not interfere with the normal processing during the first row because it will be large enough to never make the board 'wrap' to the next rank automatically. And when the first slash is encountered, before padding the rank with 'holes', it can set $cols to the current length of the rank if it was 10000, and then proceed as normal. The fen shortcode can then invoke the DD with the parameter cols=10000.

colors - This is more a matter of taste, but I feel that the default colors are a bit 'loud' for embedded diagrams that only serve as illustration for what is explained in the surrounding text. I would prefer 'softer'colors (with a somewhat lower saturation), and a less prominant board margin, like

Other proposals are of course welcome.


H. G. Muller wrote on Thu, Dec 29, 2022 09:59 AM UTC in reply to Fergus Duniho from Tue Dec 27 02:22 AM:

With that in mind, I think it would be good to have SVG images of other piece sets.

I also found SVGs in the XBoard themes collection for the orthodox pieces in Motif. The unorthodox Magnetic pieces seem to be mostly cut & paste jobs of the orthodox pieces, and should be easy to create that way from the orthodox SVG. I will have a go at it.

[Edit] OK, this is done. The original Magnetic set actually has two kind of pieces: outline and solid. As is usual for XBoard with its native pieces too, the solid pieces are used for black there. But it seems we only use the outline pieces on CVP, and just color those differently depending on whether they are used for white or black. So I did not bother to create unorthodox solid piece.

The entire set is now in /graphics.dir/magneticSVG.

[Edit 2] I now also did Motif. They are in /graphics.dir/motifSVG.


🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 04:50 PM UTC in reply to H. G. Muller from 08:39 AM:

cols - This still should be automated.

It now is. Since the fen shortcode operates before including an image link to drawdiagram.php, it will use the length of the longest rank if the ranks are divided up by forward slashes and a value for cols has not already been supplied. This behavior is not built into drawdiagram.php itself, which will just use the default value if none is supplied. Here are some examples without any value for cols being specified.


🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 05:51 PM UTC in reply to H. G. Muller from 08:39 AM:

I would prefer 'softer'colors (with a somewhat lower saturation), and a less prominant board margin

I don't like the colors in your example. I favor some variation on beige and olive, as these are the normal colors for tournament Chess boards. The coloring of the comments is based on beige and olive, though I substituted darkkhaki for olive, because olive was too light. Here's an alternative using the comment colors with wood for the border.

Too much of darkkhaki makes me feel queasy, though. Another alternative is the color scheme I used for Chess:

The dark squares may be a bit too loud while the light squares are too close to the background. Let's try bringing those colors closer together:


H. G. Muller wrote on Thu, Dec 29, 2022 06:10 PM UTC in reply to Fergus Duniho from 05:51 PM:

I do like the third. The pale green contrasts well with both red and blue:


🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 06:50 PM UTC in reply to H. G. Muller from 06:10 PM:

I do like the third. The pale green contrasts well with both red and blue:

From a distance, the blue and green kind of blend together, because both feel like background colors. Let me see if I can tweak something. Here I've increased the red and blue components of the blue color for the black pieces. Blue is still the largest component, but it's a little more purple for a better contrast with green, though not technically purple, since the red component is still lower than the green component.


H. G. Muller wrote on Thu, Dec 29, 2022 06:59 PM UTC in reply to Fergus Duniho from 06:50 PM:

Something strange is happening: 6 comments ago (in the DD topic) I posted an 8x8 diagram, and as I recall it that looked OK. But now the coordinates run a-l, like there are 12 files (but files i-l stay empty), and the lowest rank with pieces is entirely missing.


🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 08:39 PM UTC in reply to H. G. Muller from 06:59 PM:

the coordinates run a-l, like there are 12 files (but files i-l stay empty), and the lowest rank with pieces is entirely missing.

The function for calculating the longest rank was not handling braces correctly. I have now fixed that.


H. G. Muller wrote on Thu, Dec 29, 2022 09:03 PM UTC:

I started working on the 'small' set:



Jean-Louis Cazaux wrote on Thu, Dec 29, 2022 09:19 PM UTC:

Why only the number of columns can be entered and not the number of rows?


Greg Strong wrote on Thu, Dec 29, 2022 10:49 PM UTC in reply to Jean-Louis Cazaux from 09:19 PM:

Why only the number of columns can be entered and not the number of rows?

Because it will keep making new rows until it reaches the end of the FEN.


🕸💡📝Fergus Duniho wrote on Thu, Dec 29, 2022 11:59 PM UTC in reply to H. G. Muller from 08:39 AM:

set - I think auto-alfaeriePNG35 would be the best default here, (or an equivalent overly large set forced to display at reduced size) because:

I have made auto-alferie-svg the default set. This is a new set I created today. You can now see it being used in earlier comments.

It has the largest number of pieces.

I believe that it is based on the SVGs Greg has made. So, I expect the total pieces may be the same. It looks like there are fewer SVGs, but that may only be because the SVGs are in only one color. While this set should have as many pieces as alfaeriePNG35, alfaerie-many has more than both, as several alfaerie pieces have not been converted to SVG yet.

It is small, allowing representation of large boards without problems.

SVGs are scalable. Larger images should simply display at a smaller size to fit the screen.

Orthodox pieces use their conventional icons, which each chess player will recognize.

I have assigned labels to many pieces. These mostly use letters and sometimes + signs for promoted pieces or numbers. I have favored single letters for pieces that are widely used or widely combined with other pieces in compounds. Compounds normally have two or more letters, though some common compounds have 1 letter. Double letters are also used for various multi-syllabic pieces. I'm avoiding piece labels with arbitrary use of punctuation.

Pieces can be indicated by {name}.

Same.

For compactness the orthodox pieces and most-common fairies (Archbishop, Cannon, Elephant, Griffon, Marshall) can also be indicated with a single letter.

Mostly the same. The Griffon is GR, because the General is G, as the General is widely combined with other pieces, and "General" also appears in the name of various pieces. Likewise, the Dragon is DR, because D is used for the Dabbabah or War Machine in many compound pieces. The Archbishop is also BN, and the Marshall is also RN.


Greg Strong wrote on Fri, Dec 30, 2022 01:25 AM UTC:

I have made auto-alferie-svg the default set. This is a new set I created today.

Thank you.  I'm pleased to see the alfaerie set as default, since it is the most complete and most recognizable.  What is 'auto-alferie-svg'?  This doesn't seem to be a GC piece set.  I'd like to see an index.

While this set should have as many pieces as alfaeriePNG35, alfaerie-many has more than both, as several alfaerie pieces have not been converted to SVG yet.

For sure.  There are dozens, possibly hundreds, of pieces that haven't been converted.  Some are obscure, some have unknown purpose, and some just look terrible.  I'd like to expand the set in a controlled manner.  And there are even a few that have been converted that I'm not happy with.  There are also a few more that are done and still need to be added.  I have a few days off so I'll try to get a handle on this.

A lot is happening recently.  Very happy to see it!  Happy New Year, everyone!


🕸💡📝Fergus Duniho wrote on Fri, Dec 30, 2022 02:43 AM UTC in reply to Greg Strong from 01:25 AM:

This doesn't seem to be a GC piece set. I'd like to see an index.

I have added it to sets.php, and it's now displaying properly.


Jean-Louis Cazaux wrote on Fri, Dec 30, 2022 06:51 AM UTC:

I don't know where you see the default as Alfaerie-SVG. What I see on this page when I open it is the Set as Abstract 1: Compound & Misc.


H. G. Muller wrote on Fri, Dec 30, 2022 09:40 AM UTC in reply to Fergus Duniho from Thu Dec 29 11:59 PM:

While this set should have as many pieces as alfaeriePNG35, alfaerie-many has more than both, as several alfaerie pieces have not been converted to SVG yet.

This should be viewed as a temporary situation. In the process of putting Interactive Diagrams in existing articles, I create new SVG (and corresponding PNG and PNG35) when these use alfaerie-many pieces that had not been converted yet.

I can add that many images in the alfaerie-many set are duplicats or transforms (i.e. rotated or recolored pieces). The latter we don't really need; the DD already supports recoloring SVG, and it could be made to support general rotation of SVG pieces as well. In the CGI rendering engine I did this through allowing > and < characters in the FEN for indicating rotation of the preceding piece. In the alfaerie-many set the rotated pieces have ma,es that end in <number> pluc 'cw' or 'ccw' (for clockwise and counter-clockwise, respectively, the number indicating the rotation angle in degrees). The DD could recognize these character combinations as suffixes, and apply the requested rotation. So that, say, {frog180cw} would give you an upside-down black Frog. The suffix 'rev' is generally used for indicating a horizontally flipped piece. (Unfortunately for piece names that ended in a number, because these were duplicats, the number is again appended to the suffix, so a flipped camel2 is camelrev2 rather than camel2rev.)

As to the duplicats: there are alternative Camels and Elephants. I cannot imagine why a piece theme would need duplicats; I do not consider those Alfaerie pieces. When you start to represent the same pieces by other glyphs you are in fact making another font.

These mostly use letters and sometimes + signs for promoted pieces or numbers.

Because the + prefix is a well-established convention in Shogi, it might be a good idea to allow such prefixes to appear in FEN without the need for enclosing braces. (WinBoard does this, for instance.) So a + would automatically be grouped with the single letter that follows it.


H. G. Muller wrote on Fri, Dec 30, 2022 10:14 AM UTC in reply to Jean-Louis Cazaux from 06:51 AM:

Jean-Louis Cazaux wrote on 2022-12-30 UTC

I don't know where you see the default as Alfaerie-SVG. What I see on this page when I open it is the Set as Abstract 1: Compound & Misc.

I suppose that what Fergus meant is that the use of this set is default in diagrams embedded in comments through use of the fen tag. The Diagram Designer itself cannot change its default set, because this would break all diagrams on the website that rely on the current default (and are using piece names that are only known in that set, or which might mean something different in the new default set).


🕸💡📝Fergus Duniho wrote on Fri, Dec 30, 2022 01:57 PM UTC in reply to H. G. Muller from 09:40 AM:

there are alternative Camels and Elephants.

I see a Mammoth in addition to an Elephant, but I don't see any alternative Camels. What is the alternative Camel called?

One of the main duplications I see is between General and Guard, which are the same piece with different designs and names. Since they start with the same letter, I have given labels to the General pieces and not to the Guard pieces.

Because the + prefix is a well-established convention in Shogi, it might be a good idea to allow such prefixes to appear in FEN without the need for enclosing braces.

Maybe in the future. I first have to finish getting the scale parameter to work while drawing the board in all shapes and rendering methods.


H. G. Muller wrote on Fri, Dec 30, 2022 02:38 PM UTC in reply to Fergus Duniho from 01:57 PM:

I see a Mammoth in addition to an Elephant, but I don't see any alternative Camels. What is the alternative Camel called?

I meant in the old GIF pieces (Auto All Alfaerie). That has a camel2 and an elephant2. The Mammoth, Scorpion, Sabretooth and Owl were added by me to the SVG set, and do not exist as GIF images.


🕸💡📝Fergus Duniho wrote on Fri, Dec 30, 2022 03:22 PM UTC:

Here's a color for Black I want to try out. It's sort of a dark chocolate color with more red than blue and more blue than green. It seems to contrast well with the beige and olive spaces, and it looks more like black than the usual red and blue colors we've used for pieces. I'll test it out more later.


Greg Strong wrote on Fri, Dec 30, 2022 03:38 PM UTC in reply to Fergus Duniho from 03:22 PM:

Here's a color for Black I want to try out. It's sort of a dark chocolate color with more red than blue and more blue than green

I'm sorry, I don't like that one at all.  I think it's too dark and I consider it quite unattractive.

Can't we just stick with the default colors we've been using?  They have served us well for a long time.  The yellow is a bit more mustard than I would like but we're unlikely to find anything that is perfect for everyone.

 


🕸💡📝Fergus Duniho wrote on Fri, Dec 30, 2022 04:24 PM UTC in reply to Greg Strong from 03:38 PM:

I'm sorry, I don't like that one at all. I think it's too dark and I consider it quite unattractive.

In my mobile tests, it does appear too dark, and it even shows up as black in A2 mode on my Likebook Mars e-ink device.


🕸💡📝Fergus Duniho wrote on Fri, Dec 30, 2022 04:30 PM UTC in reply to Fergus Duniho from 04:24 PM:

This increases the green and blue values for a more plum color.

It's still too dark on mobile devices, though at least it's not black in A2 mode.


Jean-Louis Cazaux wrote on Fri, Dec 30, 2022 05:49 PM UTC in reply to H. G. Muller from 02:38 PM:

I had already mentioned that: the Owl doesn't fit well with the SVG set. The strokes are too thin. And the design is not very nice. Not in harmony with the rest.

Mammoth, Sabretooth are nice. Scorpion is nice too, maybe just a bit too big.


25 comments displayed

EarliestEarlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.