- The end of this discussion has been moved to Template talk:Chess position, and the discussion here seems to be dead
Proposal
edit
|
This is my idea for chess diagrams on wikipedia -- have an image for each piece and assemble it using a table. Some nice things about this method:
Advantages over wikitex:
Disadvantages compared to wikitex:
|
Partial solution to verbosity problem: I have put the script online at http://theory.cs.iitm.ernet.in/~arvindn/chess/. If you type in the position it gives the wikipedia markup.
- Good start. Some comment -- it would be more convenient to include the table commands, the text I got back didn't have any, so I would have had to add each of them in by hand, almost as much work. This is required, since for some Explorer browsers, the other way gives spaces between squares. Also, wouldn't it be possible to incorporate this program you have written to be wiki code, so that one could enter any possible board in terms of pnbqPNBQ..., etc. and have that be all you deal with in any edits? So much of wikipedia's article text are programmed anyway, now. Great job! Revolver 10:47, 5 Apr 2004 (UTC)
- [deleted markup without table tags]
- Ahh, I think I know what's happening. Its a horrible bug in MSIE, which of course Microsoft considers a feature. I've made the server send the response as text/plain, which means that the browser's job is to show it as such without trying to render it. But of course MSIE thinks it knows better and parses it as HTML. It works for me on Mozilla. For the moment you can copy-paste the source code of the page instead of what you see on the page, I'll see what I can do. Arvindn 02:13, 6 Apr 2004 (UTC)
Understood. I always hate programs that think they "know better" what the user wants (without bothering to ask him/her)! And these usually seem to be MS programs -- it's fine if it's what you want, otherwise... Revolver 21:05, 6 Apr 2004 (UTC)
This is a great idea! Revolver 00:21, 21 Mar 2004 (UTC)
I agree. Be bold! All old chess diagrams must be replaced and deleted! - Woodrow 02:33, 4 Apr 2004 (UTC)
In fact, I like this idea so much, I'm using it to start a correspondence chess game! - Woodrow 03:10, 4 Apr 2004 (UTC)
- Yes, this is a very nice idea, and I hope it or something like it becomes standard eventually, but, as Arvindn says, the syntax should be less verbose. This will probably be fixed at some point, but until it is lets not delete any of the old diagrams, please (I've no problem with people making new diagrams in this way). --Camembert
Copied from my talk page Arvindn 03:31, 5 Apr 2004 (UTC)
Hello Arvindn! Neat chess board! I just want to you look at Zwischenzug:
You see I converted the table syntax. What do you like it? The only current problem with putting together chess position from your pieces is that it clutters the wikitext. Do you think it's better with the new syntax? I think we should make all chess positions in this new syntax..
— Sverdrup 16:35, 4 Apr 2004 (UTC)
- Hi! Nice to know you like it. The wiki syntax for the table, unfortunately, doesn't work in the Microsoft browser: there are gaps between the squares.
- As for the clutter, I'm really hoping that once the syntax for extensions is finalized, the little script I wrote to generate the table from a concise description will go into MediaWiki.
- Arvindn 03:18, 5 Apr 2004 (UTC)
Cool chess board, Arvindh! Can I borrow it? --Rj 21:17, Apr 6, 2004 (UTC)
- Of course. That's the point :)
- I should have thought up a short, easy username like yours. I've seen half-a-dozen misspellings of mine so far :) Arvindn 03:23, 7 Apr 2004 (UTC)
- sorry 'bout that :) ...sounds like a subpage User:Arvindn/Misspellings --Rj 08:14, Apr 7, 2004 (UTC)
Travel size
editEy yo, I have a suggestion of a small addition (and a large one); look at Queen (chess). Could we have a set of darker squares (or crossed squares or whatever) to mark areas of the board?
- Ah yes, that would be useful. Making the squares is easy, just one light and one dark square with crosses need to be uploaded.
The large addition would be a set of the same pieces but in 50% scale. This will be inconvenient until we have a simplified syntax, though. — Sverdrup 10:20, 7 Apr 2004 (UTC)
- Good idea! I can put an checkbox in my script that would generate code with "|20px".
The server is down since yesterday, BTW. Anyone want to host the script?Arvindn 03:17, 8 Apr 2004 (UTC)
- couldn't you use brower image resizing instead of having the server dynamically resize the images? I am almost positive cascading style sheets can resize images. -- WhiteDragon 05:24, 9 Apr 2004 (UTC)
I made an experiment to shrink the board, and it works: (however, it causes the server to work alot, having to create lots of thumbnails. — Sverdrup 10:26, 7 Apr 2004 (UTC)
- Hmmm...why don't you just upload the thumbnails, with a different name, then it won't have to create thumbnails each time? Revolver 20:01, 7 Apr 2004 (UTC)
- I think the thumbnails are cached and so won't be recomputed each time. Arvindn 03:17, 8 Apr 2004 (UTC)
- The thumbnails definitely are cached, so no load problem with that. Nice job with these; the only objection I had was the large size, and it looks like that's been solved. - Hephaestos|§ 05:29, 9 Apr 2004 (UTC)
Discussion on simplified syntax
editI take it that there is consensus that a simplified syntax should be implemented in mediawiki. The question is, which one? I'm currently using a 8x8 matrix of letters to represent pieces. The other main option is the wikitex syntax. Then there is the syntax used for recording adjourned positions. Complementary to these is PGN -- if there were a way to display a position by inputting the moves leading to that position, that would surely be very useful: it would be possible to annotate a game without using a separate chess program. So there are two things to be discussed: whether we want more than one of these, and if so, which ones. (I am willing to write the code for whichever formats are chosen.) We also need to decide on the encapsulation syntax, but this is a minor issue. Which format to use for representing positions is the major decision at this point. Any thoughts? Arvindn 15:58, 9 Apr 2004 (UTC)
- I'm not familiar with the wikitex syntax, but if it generates a new file for each distinct board, I don't think that's best. My own opinion is that both the 8x8 matrix and PGN would be useful. The 8x8 would be very helpful if in the middle of an article, you wanted to jump right to a position in the middle of a game, without giving the moves from the beginning, (or if the position didn't come from any actual game at all!). Then, you can just "set up" the pieces on the 8x8 board. If you are annotating a game from beginning, then it certainly makes sense to have PGN available, you could just use the PGN without moving pieces around. As for things like arrows, should we continue to use what's at chess strategy and tactics? Thanks again! Revolver 20:16, 9 Apr 2004 (UTC)
- Let me clarify. By "wikitex syntax" I mean using algebraic notation to represent the board. I don't mean that it would generate an image for the whole board. I shouldn't have called it wikitex syntax, it gives the wrong idea. Algebraic notation would be more compact than 8x8 notation when there aren't many pieces on the board. The syntax would be roughly like "White: Kc5, d5; Black: Ke4, d4". Arvindn 03:38, 10 Apr 2004 (UTC)
- Is there a way to superimpose two images using CSS? If so, arrows might be doable. Otherwise the old method is definitely the only way. Arvindn 03:38, 10 Apr 2004 (UTC)
Note on scope: this discussion pertains only to the table based chessboard; we are not discussing whether or not wikitex should be implemented etc. (I don't see why it shouldn't be: the code its there, the more the merrier :-).
- Just speaking for myself, I'd quite like to see Forsyth-Edwards notation as an option - not the stuff about who can castle and so on, that's not necessary of course, just the bit that describes the position: 3BNK2/8/8/7k/8/8/3p2P1/8 (white plays and draws, V. Kivi, 1934, by the way :). The problem, of course, is that while the simple 8x8 matrix or an algebraic notation is clear to everybody, FEN is probably incomprehensible if you don't know the format. Maybe implement it as an alternative option, though? It's quite concise for the opening, middlegame and endgame alike, and fairly widely used. --Camembert
- Oh, its called that? I didn't know, and called it "the syntax used for recording adjourned positions" above :). Sure, why not? Let's have it as an option too. Shall we have all the four syntaxes listed below, then? (I'd better start coding :-) Arvindn 16:58, 10 Apr 2004 (UTC)
- Ah, I wondered if that's what you meant with adjourned positions, wasn't sure. Yep, having all four sounds good to me (must admit, I'm not quite sure how the PGN thing is going to work, but I'm sure you are :) --Camembert
- We definitely need a simple syntax, and it seems we get three! Very good work Arvindn, I like to be able to choose. Wikisyntax should be easy, so I'd be happy for both the matrix and algebraic syntax to be incorporated to the wikiparser. ✏ Sverdrup 19:37, 12 Apr 2004 (UTC)
I like the 8x8 matrix best. What could be simpler? Of course, One could accidentally put a capital letter instead of a lowercase one (or vice versa), possibly turning the whole situation around (Two white kings?). Of course, this could be easily fixed. 2¢. - Woodrow, Emperor of the United States 20:18, 14 Apr 2004 (UTC)
8x8 matrix notation
editAdvantages
- Easy to visualize the position
- Easy to modify
Disadvantages
- More verbose for endgame positions
- Less robust (easy to put one more or one fewer dot in a line)
Algebraic notation
editAdvantages
- Compatibility with wikitex (markup can be copied over)
- Robust
- Equally easy to modify
Disadvantages
- More verbose for opening and middlegame positions
- Not easy to visualizes
Forsyth-Edwards notation
editAdvantages
- Optimally compact
Disadvantages
- Hard to visualize/understand
Portable game notation
editAdvantages
- Big help for annotating games
- Lots of pgns available on the 'net
Disadvantages
- Hard to code! (parser needs to know how the pieces move)
OK, the code is nearly done! The first 3 are working. Please everyone help test it and find bugs. Thanks. The last one (pgn) is not completely done yet. For example, if you give it "1. e4 d6 2. d4 Nd7 3. Bb5 Nf6" you get the position on the left because the code doesn't yet know about pins etc. This stuff is not easy, but I'll give it a try anyway. Even if I can get it working, its almost certain to have bugs, and so I don't think its a good idea to implement it in the server. So as a compromise, the first 3 can be implemented directly, and the PGN converter can stay on my web page. I'll make it output 8x8 matrix notation instead of the table code, so that one could feed it the PGN, get back the 8x8 and put that into wikipedia, having the best of both worlds. Arvindn 15:06, 11 Apr 2004 (UTC)
- Whatever the problems with the PGN, the other three seem to be working fine. Good job :) --Camembert
- Thanks! Luckily, I found a pgn parser (GPL'd, no less) that has an option to output FEN. I've integrated it with my script. So pgn is taken care of. (although the external dependency means it can't be implemented in MediaWiki itself.) Arvindn 18:31, 14 Apr 2004 (UTC)
Encapsulation syntax
editWhat I currently have in mind is
<chessboard type="TYPE" size="SIZE" style="STYLE"> ... </chessboard>
where TYPE is one of matrix/algebraic/FEN (default: matrix), size is one of small/normal/large (default: normal) and style is any valid CSS style (default is "border:1px solid #8888aa; width:320px; height:320px; float:left; margin-right: 1em;"). Sounds OK? Arvindn 15:50, 11 Apr 2004 (UTC)
- It seems as good as anything. The only thing is that that 'type="TYPE"' stuff is a bit close to html, and html can put people off. I'm don't think I can come up with anything better, though. It should be OK. --Camembert
- Looks like a nice concept. In wiki context I'm a bit of an HTML-phobe, and I'd like it better if it was just <chess> any chess-transcribing syntax here </chess>, but that may not be possible. (Maybe chess tags for matrix and chess-algebra for algebraic notation?). Nice concept overall, though. ✏ Sverdrup 19:41, 12 Apr 2004 (UTC)
- Well, I don't like the idea of putting meta-description inside the <chess>...</chess> tags, because that way its easier to mess up the syntax. As a compromise, why not adopt a syntax similar to what's used for images: <chess X1|X2|...|Xn|Y> position description goes here</chess> where the X's can be any of the keywords {large, normal, small, tiny, matrix, algebra, FEN, left, right} and Y is the description to be used at the bottom of the diagram. Sounds OK to you? Arvindn 18:31, 14 Apr 2004 (UTC)
Also note that this discussion is in the wider context of the meta:Extension Syntax decision, and <chess>...</chess> is currently intended for wikitex. So that would have to be sorted out. Arvindn 18:31, 14 Apr 2004 (UTC)
this is crazy. see how it should be done. look at another game:
http://senseis.xmp.net/?AmateurFuseki6
go there, press edit to see the syntax. its clean and brainless
- While I appreciate your clarity and brainlessness ;^), there's a difference: its simple and natural to use a $$ syntax for go boards in a go wiki, but not in a general encyclopedia.
- That said, I'm starting to realize that HTML like syntax is probably not a good idea. Arvindn 07:11, 13 Apr 2004 (UTC)
I was relatively dormant when this discussion was going on, but I see now it is fantastic stuff. Thanks, Arvindn! What more has to happen before I can type an 8x8 matrix of letters directly into a chess article? I want to replace all the images in the demonstration game; also I'm finding that editing pages (even only editing the text) with all the table syntax around is a bit of a nuisance. But merely to have editable diagrams in any form is fantastic! Thanks, --Fritzlein 19:04, 4 Jun 2004 (UTC)
Parameterised Template
editHow about:
{{chess board| rl|nd|bl|qd|kl|bd|nl|rd| pd|pl|pd|pl|pd|pl|pd|pl| _l|_d|_l|_d|_l|_d|_l|_d| _d|_l|_d|_l|_d|_l|_d|_l| _l|_d|_l|_d|_l|_d|_l|_d| _d|_l|_d|_l|_d|_l|_d|_l| Pd|Pl|Pd|Pl|Pd|Pl|Pd|Pl| Rd|Nd|Bl|Qd|Kl|Bd|Nl|Rd}}
(or some variation thereof)
and let Template:chess board generate the image names and the table markup?
Haven't read everything in this page. Just a thought from the days when MediaWiki was introduced and implenting template parameters was being discussed. -- Paddu 21:44, 10 Jun 2004 (UTC)
On second thoughts, the colour of the square could be shifted to Template:chess board, so this gives simpler syntax -- Paddu 21:44, 10 Jun 2004 (UTC)
- I did a small test, and including images with parametes doesn't seem to work. The images are left as links to the image page rather than including the image itself. Seems like we have to wait for another sw upgrade. ✏ Sverdrup 13:43, 11 Jun 2004 (UTC)
- From http://test.wikipedia.org/wiki/Template_talk:Images, it looked like the parameters are passed to a template after partial-HTMLification (or partial-dewikification, if you like), so I thought the trick in making this work would involve having two templates (one recursively calling the other), but all my trial & error involving User:Paddu/sandbox and User:Paddu/chess image (both acting as templates) was fruitless. -- Paddu 16:44, 13 Jun 2004 (UTC)
- I like this idea a lot. It would allow for future flexibility, including using SVG in the future (or in derivative works) simply by changing the template. David Remahl 14:08, 12 Jun 2004 (UTC)
Parameterised Template (Now working)
editCurrently I am able to use templates to show the board:
Newlines in parameter values are not ignored, hence a comment has to be used to allow subsequent rows to be specified in subsequent lines (leading spaces and underscores are ignored, though). An empty square can be shown in any of the following ways:
|| |_| | | |____ ____ _ |
-- Paddu
The following syntax is possible:
{{chess board| {{chess board| |rd|nd|bd|qd|kd|bd|nd|rd| |rd|nd|bd|qd|kd|bd|nd|rd| |pd|pd|pd|pd|pd|pd|pd|pd| |pd|pd|pd|pd|pd|pd|pd|pd| |__|__|__|__|__|__|__|__| | | | | | | | | | |__|__|__|__|__|__|__|__| (or) | | | | | | | | | |__|__|__|__|__|__|__|__| | | | | | | | | | |__|__|__|__|__|__|__|__| | | | | | | | | | |pl|pl|pl|pl|pl|pl|pl|pl| |pl|pl|pl|pl|pl|pl|pl|pl| |rl|nl|bl|ql|kl|bl|nl|rl| |rl|nl|bl|ql|kl|bl|nl|rl| }} }}
if the template uses parameters 2..9, 11..18, 20..27, 29..36, 38..45, 47..54, 56..63, 65..72 for the pieces and ignores the other parameters.
- (I have made these changes and introduced a size parameter, at User:Sverdrup/test3. ✏ Sverdrup 14:53, 23 Oct 2004 (UTC))
If the images being used are moved to have appropriate names, this is also possible:
{{chess board| {{chess board| |r|n|b|q|k|b|n|r| |r|n|b|q|k|b|n|r| |p|p|p|p|p|p|p|p| |p|p|p|p|p|p|p|p| |_|_|_|_|_|_|_|_| | | | | | | | | | |_|_|_|_|_|_|_|_| (or) | | | | | | | | | |_|_|_|_|_|_|_|_| | | | | | | | | | |_|_|_|_|_|_|_|_| | | | | | | | | | |P|P|P|P|P|P|P|P| |P|P|P|P|P|P|P|P| |R|N|B|Q|K|B|N|R| |R|N|B|Q|K|B|N|R| }} }}
-- Paddu
- I think this solution is ready to publicise -- put it in a template and start using it in articles. Only thing we should discuss is whether we should move the images first or not. Also, there is a number of extra parameters that we perhaps should include. I've included size in mine, and we could possibly use an alignment parameter also. These should be easy to add though, with the parameters for pieces as numbers from {2} to {72}, and the extra parameters like {size} and other as text labels. ✏ Sverdrup 15:02, 23 Oct 2004 (UTC)
- Wow! This is great! That's all I wanted to say. I'll look closer at it later. — David Remahl 22:34, 23 Oct 2004 (UTC)
- We could cut the number of images required in half, and reduce loading time, by using PNGs with transparency or Unicode. However, alpha in PNGs and to some extent Unicode is poorly supported by some user agents (i.e. IE ;-), so the current solution is probably more appropriate for the time being. The fantastic thing about this solution, is that it makes migration trivial! — David Remahl 00:24, 24 Oct 2004 (UTC)
- Sometimes the chess board needs to be annotated in one way or another. For simple cases, such as Image:Cb rook move.png, adding custom cells is sufficient (let xl40.png and xd40.png be light and dark squares with an x). Anyway, here are some suggestions of special cells that we could allow (I think we should specify exactly what parameters are allowed by the chess board template. One should not use the chess board template with parameters that are not specified in the template talk.):
- An X, as in the examples above.
- Arrow dingbats pointing in all directions.
- White / black cells.
- Hilighted empty and filled cells (hilighted by, for example, a coloured outline).
- One thing that we may want to consider adding is an overlay. In more complex cases, an overlay may be required. An overlay is a partially transparent image (PNG) that is composited on top of something else (in this case the chess diagram). I don't know if it is possible to implement an overlay using the limited html allowed by mediawiki, nor do I know wether it can be made to work OK with 'all' browsers. We should 'KISS' for the time being.
— David Remahl 09:12, 24 Oct 2004 (UTC)
Script for Parameterised Template
editOk, I've been playing today...I created a 100-line Python script for generating chess cells with various appearances. And another script for assembling {{chess board|}} syntax into a single image (for testing purposes). I put a subset of the images I generated on my laptop web server, so you can look at them: images (there are 90 of them). That URL is to a directory listing. To see the cells at full-size in a browser, use [1]. The pieces were created by editing glyphs from Arial Unicode MS. I do not think that poses a copyright problem. In any case, it is very simple to generate a new set of cells if we want to use another set of pieces (re-uploading is a different thing entirely...perhaps pywikipediabot can help.).
I also assembled the following wiki syntax (to an image), using the images in the above directory:
{{chess board| |r|n|b|q|k|b|n|r| |p|p|p|p.hilight|p|x|p|_| |_|_|x|_|_|p|x|_| |_|_|_|_|N|_|_|p| |_|_|x|_|_|_|x|_| |_|_|_|x|_|x|_|_| |P|P|P|P|P|P|P|P| |R|N|B|Q|K.hilight|B|_|R| }}
It looks like this. The images in the directory adhere to a naming convention of: Chess_cell-[theme]-[dark or light cell]_[Piece, cap for white, lower for black, _ for empty][.effect, if any, otherwise nothing].png.
Please note that the web server is on my portable computer, so it will not be available 24/7. — David Remahl 22:22, 24 Oct 2004 (UTC)
- Oh, I forgot..The images aren't named completely right. Because my filesystem is case-insensitive, it is not possible to have k.png and K.png at the same time, so I had to name one of them k-.png, for now. — David Remahl 22:38, 24 Oct 2004 (UTC)
- Now I've done an interactive JavaScript application which one can use to create / modify templates like the one above. CCD. When the system is in use, I can arrange for a more permanent location for the page. I've tested it in OmniWeb and Mozilla, and it is XHTML 1 Strict compliant. Tell me if it doesn't work in your browser. — David Remahl 09:59, 25 Oct 2004 (UTC)
- I thought the idea was to not have to use a generator script :-) -- No, seriously, this is great work; you've put quite a lot of time into it. I have a couple of suggestions:
- To make the table look clean and simple at all time, why not use two-character strings to produce all pieces and highlights. A white rook would be r_ or r , while a highlighted rook would be rx</rr>, similar to a highlighted square which is _x. Seeing to that the columns are all aligned, the syntax will be much clearer.
- I actually was sincere -- I don't think we should need a script to generate this. Consistent syntax, with pieces r_ to p_ and R_ to P_ together with modifiers like _x is consistent to me. Also, we could introduce other modifiers than highlighting quite easily. (You mentioned arrows; these could also be coded into a letter each).
- Your example would look like:
{{chess board| |r_|n_|b_|q_|k_|b_|n_|r_| |p_|p_|p_|px|p_|_x|p_|__| |__|__|_x|__|__|p_|_x|__| |__|__|__|__|N_|__|__|p_| |__|__|_x|__|__|__|_x|__| |__|__|__|_x|__|_x|__|__| |P_|P_|P_|P_|P_|P_|P_|P_| |R_|N_|B_|Q_|Kx|B_|__|R_| }}
- ✏ Sverdrup 15:58, 25 Oct 2004 (UTC)
- I very much agree that it should be very easy to edit the template inline with the source. However, people who want a graphical way of doing it and aren't comfortable with the type of "source code" this after all is, would probably appreciate an online generator. But I never intended for it to be anything but an alternative. Mandating (by use of complicated markup) the use of as script for generation – is unwiki.
- Besides, I needed an excuse to polish my xhtml 1 strict and javascript skills ;-). — David Remahl 01:35, 26 Oct 2004 (UTC)
- I now see your intention with the two-characters-wide layout. I agree, that is a nice and consistent solution, one which I support. — David Remahl 01:33, 26 Oct 2004 (UTC)
- I very much agree that it should be very easy to edit the template inline with the source. However, people who want a graphical way of doing it and aren't comfortable with the type of "source code" this after all is, would probably appreciate an online generator. But I never intended for it to be anything but an alternative. Mandating (by use of complicated markup) the use of as script for generation – is unwiki.
- As I'd said earlier, leading spaces & underscores are ignored, at least for the images that I used. Hence one need not be restricted to two character width. Assume we want two modifiers, "x" and "hi" (highlight). The following is possible:
{{chess board| |r|__n|_b|q_|_k|_b|___n|r| |p|__p|_p|px|_p|_x|___p|_| |_|___|_x|__|__|_p|_xhi|_| |_|___|__|__|_N|__|____|p| |_|___|_x|__|__|__|___x|_| |_|___|__|_x|__|_x|____|_| |P|__P|_P|_P|_P|_P|___P|P| |R|Nhi|_B|_Q|Kx|_B|____|R| }}
- One need not use diff. widths for the same board. What I want to say is that
|_B|
,|B|
,|__B|
all refer to the same image. Hence the image name is not restricted. e.g., if later we also want another modifier, we need not change the image names all over again. We could just append that modifier:|Kxhi.new_modifier|
&|K|
can live together. No need to change Image:foobarKbaz.png to foobarK________________baz.png or foobar________________Kbaz.png or anything. BTW David, I think I saw images named foo__bar.png in your site. They must be foo_bar.png.
- One need not use diff. widths for the same board. What I want to say is that
- BTW we could obviously use this for other board games (e.g. Go) as well, perhaps standardise on this notation by adding to the user guide. Just wanted to mention so this didn't get overlooked with chess-centric excitement. -- Paddu 17:41, 26 Oct 2004 (UTC)
- PS: Wow! Remembered to sign my comment this time ;^)
- However, if you want to edit the board and for example highlight a piece in the a file, you'd either have to insert 14 other _'s or break the wikitext visually. ✏ Sverdrup 17:52, 26 Oct 2004 (UTC)
- I agree that two characters is the cleanest and certainly enough. Considering we have the whole Unicode repertoire at our disposal for the second character, that should be plenty :-P. I didn't understand what you said about leading spaces being ignored...That would be a bug, then, wouldn't it? — David Remahl 18:00, 26 Oct 2004 (UTC)
- However, if you want to edit the board and for example highlight a piece in the a file, you'd either have to insert 14 other _'s or break the wikitext visually. ✏ Sverdrup 17:52, 26 Oct 2004 (UTC)
- Oh! That 14-characters thingy was just an exaggerated example. I wanted to make the point that the no. of characters is not fixed but flexible. e.g. with the existing images, we use 2 characters (e.g.
|dr|lr|
instead of|r|R|
).|__|dr|
. produces Image:Chess_l40.pngImage:Chess_drd40.png (Note that it's Chess_l40 and not Chess__l40. That's what I mean by leading _'s ignored. Rather than a bug, I consider it a feature, see below). Now we want to add a modifier `x'. We say|___|__x|drx|_dr|
. This produces Image:Chess_l40.pngImage:Chess_xd40.pngImage:Chess_drxl40.pngImage:Chess_drd40.png. Note that we need not move Image:Chess_rd40.png to Image:Chess__rd40.png. Now assume we want another modifier 'hi'. Not only can we say|____|___x|drhi|__dr|
(Image:Chess_l40.pngImage:Chess_xd40.pngImage:Chess_drhil40.pngImage:Chess_drd40.png), but we can also mix the 'x' and the 'hi'. e.g.|_____|____x|drhix|
(Image:Chess_l40.pngImage:Chess_xd40.pngImage:Chess_drhixl40.png), without having to invent some unintuitive letter for 'x'+'hi'. That's why I say leading-underscores-ignored is a feature, it allows flexibility. This is not to say we should start with 14 characters. I'm just saying it can be seamlessly extended. Note that in a new page if someone wants to use N different modifiers and make the cell N+2 characters wide, the existing pages with N-wide templates need not be touched at all. -- Paddu 19:30, 26 Oct 2004 (UTC)
- Oh! That 14-characters thingy was just an exaggerated example. I wanted to make the point that the no. of characters is not fixed but flexible. e.g. with the existing images, we use 2 characters (e.g.
- What I'd said in the comment just above is for the current case 2 chars. per piece (
|dr|lr|
), but the "flexible-width" stuff holds for 1 char. per piece (|r|R|
) too, only N+2 has to be substituted with N+1. - Turns out the leading-underscores-ignored is because the current images have an underscore just before the piece-name, e.g. Chess_<2 char. for piece><1 char. for colour of square>40.png. If we were to use Chess_<piece>_<square>40.png, trailing underscores would also be ignored. As we can see from my comment above (look for the sentence with the word "move"), the software treats Image:Chess_rd40.png and Image:Chess__rd40.png (or for that matter Image:Chess_______________rd40.png) as pointing to the same image. Hence it would treat Image:Chess_r_d.png, Image:Chess__r_d.png and Image:Chess_r__d.png identically. And we can use the double-underscore version to align with Image:Chess_rx_d.png. Later in another page if we want Image:Chess_rxh_d.png, we could align that with a triple-underscore Image:Chess_r___d.png, without modifying the old pages which use the single- or double-underscore versions.
- Hope I'm at least a wee little bit clearer this time. -- Paddu 19:42, 26 Oct 2004 (UTC)
- BTW one can use spaces instead of underscores, e.g.
| | x|drhix|
. -- Paddu 20:41, 26 Oct 2004 (UTC)
- What I'd said in the comment just above is for the current case 2 chars. per piece (
- I'd suggest naming the images as follows:
- Image:Chess_<squarecolour>40.png (already exist)
- Image:Chess_<piece>_<squarecolour>40.png (e.g. Image:Chess_r_d40.png, Image:Chess_P_l40.png, etc.)
- Image:Chess_<piece><modifier1>_<squarecolour>40.png (e.g. Image:Chess_Qx_d40.png, Image:Chess_bx_l40.png, etc.)
- Image:Chess_<piece><modifier2>_<squarecolour>40.png
- Image:Chess_<piece><modifier1><modifier2>_<squarecolour>40.png
- etc.
- for max. flexibility with spaces around the piece+modifier-sequence in a cell. -- Paddu 21:35, 27 Oct 2004 (UTC)
- (dropping indent). We should choose _one_ naming convention and stick with it. I don't think we should aim for maximum flexibility. It is better to be strict, since that makes it easier to migrate in the future, without having to take a lot of edge-cases into account.. — David Remahl 22:28, 27 Oct 2004 (UTC)
Questions
editThere's a lot of information here, and I am confused. Is there some easy and confirmed way for me to put in some codes like |r|n|b|q|k|b|n|r| to draw a chess board in an article?--Sonjaaa 11:34, Dec 13, 2004 (UTC)
- Yes. See Fork (chess) for an example. dbenbenn | talk 15:15, 10 Mar 2005 (UTC)
Is it possible to add numbers/letters to the rows columns so that articles that use algebraic notation will be easier to follow for viewers? --jacobolus (t) 18:37, 19 May 2005 (UTC)
- Nevermind. I see it is, at Template_talk:Chess_position... this seems like the same discussion as there. maybe there should be a link to that page at the top of this one? --jacobolus (t) 18:43, 19 May 2005 (UTC)
It appears that very few illustrated chess positions included in Wikipedia have a Forsyth-Edwards Notation (FEN) tag. Why? Am I missing something here? A FEN tag would be very handy for copy/paste-entry into user's own chess database.