JavaScript ANTLR target

Tonight I managed to build ANTLR version with JavaScript target.

I must admit it was one of the most bizarre builds I did. The problem was not the target itself. The maintainers did a decent job making it. Although it is in it's early stages (the guys claim it not yet ready for publication) the compilation of the target went smooth. Building ANTLR is another story. The instructions (http://www.antlr.org/wiki/pages/viewpage.action?pageId=732) are less then obvious and only a little bit helpful. And that's a bit strange, because all in all, ANTLR is quite well documented.

[[In situation like this I start to appreciate build tools that are more strict as for defining dependencies in projects, like Maven.]]

Anyway, I did build it, so there is no need to complain.

What is important, that I can theoretically use the Shogi grammars I am working on, to build example browser-side parser for game record. Of course, I could do it earlier, by hand. But it would be much more tedious work. And this also gives me an opportunity to learn new things which is, as usual, great fun :-).

I think my first attempt will be a parser/viewer for format in which Reijer Grimbergen posts games on shogi-l and (most of the time) on his pages.

You can see an example game score in this format here. There are no variations. The file consist of only 3 types of information: tag (game details), move (what move whas made) and comment. The file is well formed -- there are strict rules to determine which line is what. A tag line starts and ends with '[' and ']' respectively. A line with move information starts with integer, followed by a dot, followed by move description, followed by two timestamps. The only exception are the comments. They can appear anytime in the text and couldn't be easily distinguished by the machine.

As I understand it, if I, in my parser, write a rule to recognize comment, which is basically free text, the rule would also consume other part of the file also. In other words every line of the text would satisfy the rule (every line can be treated as a free text), so the parser would be confused which rule to apply.

Actually I am not sure if a grammar file can describe it. (read: I am not sure if I could describe it ;-) ). Well, we'll see about that.

Ok, wish me luck.

JavaScript SFEN parser

Earlier in my posts I described Shogi FEN notation. I also showed SFEN parser -- a Java Web application that creates diagrams from SFEN data.

This time I spent some time learning JavaScript and programing the browser. As a result I came up with JavaScript Shogi Board Viewer and Shogi FEN parser. They have similar functionality as the former, but it's easier to use it on one's own Web pages.

The viewer
JS Shogi Board Viewer is a JavaScript component that makes it possible to generate Shogi position diagram on your Web page.

The viewer consists of 3 elements:

1. JavaScript program to generate the diagram
2. CSS file containing style definitions for the diagram
3. Images representing the board and the pieces

"Interesting" thing about the viewer is the way it is provided with Shogi data.

Well, I wanted my viewer to be "generic" (independent of the position data source) and possibly small. Therefore I decided that the position is provided with a javascript object. Feels like real pain, doesn't it? But fortunately, JSON notation comes to the rescue. Thanks to it we can build JavaScript objects that are understood both by computers and humans.

Besides, JSON is quite popular data exchange format, so there could be converters (i.e. from Shogi FEN or others) easily plugged in to the viewer.

Shogi position data format

The good thing about JSON is that it's very self-descriptive format. Here is how I designed the format.

The description consists of 4 elements:

• side on move
• white pieces in hand
• black pieces in hand
• pieces on the board

and could be expressed as JSON like this:

{
"sideOnMove":"black",
"blackHand":[],
"whiteHand":[],
"pieces":[]
}

Side on move is simple: it can be either "black" or "white".

Pieces in hand data is an array of numbers. Each number represent the count of pieces for a given rank. The rank is indicated by position in the array. Pieces info is stored in a given order:

• Pawn (index 0)
• Lance (index 1)
• Knight
• Silver
• Gold
• Bishop
• Rook (index 6)
  

So, for a Silver and 2 Pawns in hand the data would look like this:

[2,0,0,1,0,0,0,0,0,0]

I am not particularly happy with the format. I don't like the fact that a human has to remember position of piece ranks in the array. The format could be therefore change in the matter. [[Maybe better would be to have pairs rank:count?]]

Pieces on board are given by field:rank pairs. A field is described by 2 chars: column number and row char in the standard Shogi coordinate system. Leftmost column is named '9', rightmost is '1'. Uppermost row is 'a', lowermost is 'i'.

A piece symbol is "borrowed" from Shogi Ladder notation (http://www.shogi.net/ladder/shogiboard.html). The 'w' and 'b' in front of the piece symbol's abbreviations indicate white and black respectively. When a piece is promoted, it will be given with a preceding "+", as in "+bL" or "+wP".

Summing up, here is an example Tsume Shogi position and it's JSON object representation:

tsumeJson = { "sideOnMove":"black", "blackHand":[0,0,0,0,1,0,0,0,0,0], "whiteHand":[0,0,0,0,0,0,0,0,0,0], "pieces":[{"2a":"wK"},{"1a":"wL"},{"3c":"+wR"},{"1c":"+bB"},{"3d":"+bB"}] };

The parser

JS SFEN parser is a JavaScript class that is able to translate generate Shogi position data in SFEN to JavaScript objects. The parser and it's best friend, JS Shogi Board Viewer, make it easy to put a Shogi diagram for given SFEN on your Web page.

I won't explain SFEN here. I did my best on this ShogiTools wiki page so If you are interested in the details, please check it out.

The viewer consists of 2 elements:

1. JavaScript SFEN parser class.
   
2. JavaScript Shogi model classes (SFEN is translated to these objects).

Usage of the parser is simple. You put the following line in your code, to get JavaScript object representing given position:

tsumeJson = SfenParser.parse("7r1/6B1p/6Bsk/9/7P1/9/9/9/9 B 2S");

Then you send it to the viewer and voila!

Please, check out the example to see it in action. You can see a Shogi board here and you are able to dynamically set the SFEN to be shown.

The code is put inside the HTML file, so you can view the source to see what's going on there.

I hope that someone finds it useful...

As usual, any comment are welcomed.

New ANTLR targets

Till now I used javacc (http://javacc.dev.java.net/), the Java Compiler Compiler, for creating my parsers.

Like I said earlier (http://shogi-software.blogspot.com/2008/01/tsume-shogi-parser-or-how-to-store-28k.html) I was hoping to try ANTLR out.

Today I read two interesting pieces of information:

1. There is an IDE to develop and debug grammars, ANTLRWorks.
2. New (3.1) ANTLR would support JavaScript and ActionScript as targets (platforms in which parsers generated by ANTLR can run).

It is certainly big motivation for me to check this tool out. First of all, ANTLRWorks will make designing and testing my Shogi grammars much easier and faster.
Secondly, new targets will allow creation of shogi games browsing/viewing software on these two very popular platforms: JavaScript and Flash/Flex.

I am going to give it a try very soon.

Unicode for Shogi characters

To be able to translate Shogi data between formats you have to know possible piece symbols. I collected  the information I could get (mainly from wikipedia.org) in the following table. Then I found (on http://www.rikai.com/library/kanjitables/kanji_codes.unicode.shtml) unicode values for eaech Shogi piece.
Shogi pieces

English name	Unicode for abbr. Kanji	Kanji	Rōmaji	Meaning	Abbreviations
					Symbol	Kanji	Rōmaji
King (reigning)	738B	王将	ōshō	royal general	K	王	ō
King (challenging)	7389	玉将	gyokushō	jeweled general	K	玉	gyoku
Rook	98DB	飛車	hisha	flying chariot	R	飛	hi
Promoted rook (Dragon)	9F8D or 7ADC	龍王	ryūō	dragon king	+R	龍 or 竜	ryū
Bishop	89D2	角行	kakugyō	angle mover	B	角	kaku
Promoted bishop (Horse)	99AC	龍馬	ryūma or ryūme	dragon horse	+B	馬	uma
Gold general (Gold)	91D1	金将	kinshō	gold general	G	金	kin
Silver general (Silver)	9280	銀将	ginshō	silver general	S	銀	gin
Promoted silver	5168	成銀	narigin	promoted silver	+S	全	—
Knight	6842	桂馬	keima	horse	N	桂	kei
Promoted knight	572D or 4ECA	成桂	narikei	promoted laurel	+N	(圭 or 今)	—
Lance	9999	香車	kyōsha	incense chariot	L	香	kyō
Promoted lance	674F or 4EDD	成香	narikyō	promoted incense	+L	(杏 or 仝)	—
Pawn	6B69	歩兵	fuhyō	foot soldier	p	歩	fu
Promoted pawn (tokin)	3068 or 4E2A	と金	tokin	reaches gold	+p	と (or 个)	to

Coordinates
In KIF files the characters are Shift-JIS encoded. Characters used to describe shogi board coordinates and their unicode values are listed below.

description	char	unicode
1st column	１	FF11
2nd column	２	FF12
3rd column	３	FF13
4th column	４	FF14
5th column	５	FF15
6th column	６	FF16
7th column	７	FF17
8th column	８	FF18
9th column	９	FF19
1st row	一	4E00
2nd row	二	4E8C
3rd row	三	4E09
4th row	四	56DB
5th row	五	4E94
6th row	六	516D
7th row	七	4E03
8th row	八	516B
9th row	九	4E5D

Move modificators
The symbols used in Kifu to identify the piece to move (when there is
a situation in which more then one piece of the same kind can reach
given destination):

symbol	unicode	meaning
直	76F4	move straight
引	5F15	pull (back)
上	4E0A	go forward (literally means “up”)
寄	5BC4	go to the side
右	53F3	right
左	5dE6	left
右引		right-back
右寄		right-go to the side
右上		right up
左引		left-back
左寄		left-go to the side
左上		left up

I hope someone finds this information useful.

Tsumeshogi diagrams with Kanji, part II

The delay

As I wrote earlier I had been planning to produce this version of "my" Tsumeshogi Collection for a long time now. The only thing that was putting me off was weird interpretation of "reference-orientation" XSL-FO attribute. The specification describes it as follows:

The reference-orientation property defines the direction for top for the content-rectangle of the reference-area.

Property Values

Value	Description
0	Default. The orientation of this area has the same orientation as the containing reference-area
90	The orientation is rotated 90 degrees from the orientation of the containing reference-area
180	The orientation is rotated 180 degrees from the orientation of the containing reference-area
270	The orientation is rotated 270 degrees from the orientation of the containing reference-area
-90	Same as specifying 270
-180	Same as specifying 180
-270	Same as specifying 90

The first problem was that in Apache FOP using -90, -180 and -270 as reference-orientation instead of 90, 180 and 270 resulted in content being drawn outside its block.

The first results

The commercial equivalent of FOP, RenderX' XEP, did better in this area. I used to produce my first version of the collection with Kanji for the Shogi pieces.

The power of the Open Source community

Although XEP is a decent piece of software (and the company provides free personal edition) I decided to keep on looking for open source alternative.

I described what I am doing and I asked the question about the strange FOP behaviour on public w3.org lists. I didn't have to wait long for the answer. Jeremias Maerki informed me that the situation I described is a known bug in Apache FOP which hasn't been resolved yet.

Bad news, but at least I finally knew what is going on...

The same day, few hours later, Jeremias posted his second answer: he fixed the bug!

After downloading the newest version of FOP from Apache's site I am now able to produce the collection the way I wanted to.

Tsumeshogi diagrams with Kanji

I have just found a PDF (from xsl-fo) renderer which properly handles rotated text in tables.

I produced Tsumeshogi collection with 300 problems using "international" symbols. After that I decided to do the same thing using Kanji characters.

The PDF generator I used, Apache FOP, acted strange when it came to rotated characters (the idea was to use Kanji representation for Shogi diagrams, black pieces heading up, white pieces upside down). So I gave up.

Few days ago I found out, that there is a commercial implementation of PDF renderer (fortunately, they also provied "personal licence") -- RenderX's XEP (http://www.renderx.com/tools/xep.html).

Thank's to this piece of software I will soon be able to produce my Tsumeshogi collection using Kanji characters.

Just give me a day or two...

Shogi FEN -- similar works

Different FEN

After publication of the post about my proposal for Shogi positional data storage standard, there was some comments on shogi-l.
Bernhard C. März pointed out that there is similar way of storing Shogi positions described earlier. He gave a link to the archived shogi-l message: http://www.shogi.net/shogi-l/Archive/2002/Nsep29-03.txt.
The description differs from mine in 'pieces in hand' part.

There was some discussion about the approach.

>> > *fat bold cyclop* wrote:
>> > > I think the only flaw of it is, I think, it insufficient for
>> > > storing positions with more than 9 pieces in hand.
>> > In my opinion, this is a rather serious problem.
>>
>> Just use A, B, C, ..., H for 10 through 18.
>>
>> Using A through F for 10 to 16 is pretty standard (hexadecimal).
>> This particular extension seems rather obvious.

I have implemened a FEN notation in MacShogi 2 years ago, but I don't
have added the GUI part to use it yet.

I first have chosen the hexadecimal option to store the number of
pawns in hand but finally, I have preferred to use only digits.

The algorithm is pretty simple for pawns: the pieces in hand part in
the notation has 7 digits in all, one digit for each piece type,
except for the pawn where 2 digits can be used. So, if the string
contains 8 digits, the pawn number uses 2 digits, otherwise only one
digit is used for the number of pawn pieces.

It works well. But this is only a matter of personal choice.

Another SFEN

Tord Romstat devised http://www.glaurungchess.com/shogi/usi.html (draft dated 2007-01-24).
Both approaches seem to be identical. Both in contents and name :)

Proposal: Standard for storing Shogi position information

Foreword: I know that similar work have been undertaken by different people already.
I don't claim I am inventing something that others didn't think of before. If you know some sources I'd be glad to put links to them in this post.

That said, I move on to the subject with is a proposal of standard for storing positional data in Shogi. I called it Shogi FEN (or SFEN) because it is derived from FEN standard designed for chess. I write more about the standard itself on ShogiTools project's wiki. Here I try to advocate the need for a standard like SFEN.

Do we need such a standard

I think it is very important to have a standardized way to write Shogi positions. This way data are easily exchanged between programs. Let me give you some examples:

1. Imagine you have a database program that stores tsume Shogi problems. Your computer is Mac with English OS, your friend has Japanese Windows and he uses different database program and you want to share the problems with him.
2. You post some positions from games of masters as a diagram on your web page using some flash application. The application is faulty and you want to switch to other program, let's say Java applet.
3. You want to have a test suit of 100 positions for benchmarking different Shogi engines.
   

In all these situations, if there is a standard way to store positional data, there is no additional work required on your side. Otherwise there should be some conversion mechanism provided. Moreover, to be able to convert between proprietary standards you have to know them both.

What's so good about SFEN

Nothing :-). At least nothing until it becomes a standard. But what are the 'pros' of it?

It's more compact than traditional ASCII-diagram notation. The whole position data fits a sigle text line. In my opinion they are also easier to interpret by programs and quite readable by humans at the same time.

The idea of similar standard succeeded in chess world. I think we could learn from their experience and adopt similar solution.

Why wouldn't we want SFEN

I can think about only one good reason: "We already have a good standard for this and don't need another one".

If this would be the situation, I probably wouldn't bother making this post. But, as I see it, there are some solutions 'on the market', but:

1. They are not really standards -- there is many flavors of single 'standard'.
2. There is no formal specification for them -- at least none non-Japanese.

If you know of some standards, real or almost real, their specification on the net, please drop me a note. I'll be happy to post links to them and discuss them here.

Live demo

I prepared a site where you can see SFEN in action.

It's a nice moment for me, because the puzzles of my ShogiTools project start to fit together. In my earlier post about Tsume Parser I described how I translated tsume problems from shogi-l into computer-readable form.

Here I used the product of that project and made a simple converter to SFEN data.

Finally, I put all (almost 300) tsume on the page. You can see on-line SFEN to diagram conversion (and solve some tsume at the same time! ;-) ).

Note. When runing applications, don't worry if you see something like Can't contact servlet runner at 127.0.0.1:6905. MyJavaServer.com does this kind of things from time to time. Wait few moments and try again. MyJavaServer is down for good. The example has been moved to Google AppEngine.


Note 2. The page is best viewed with Mozilla browser. I could force Internet Explorer to cooperation. The elements are slightly misplaced. I think I finally won the IE battle.

Other works

After publication of the post there was some comments on shogi-l.
Bernhard C. März pointed out that there is similar way of storing Shogi positions described earlier. He gave a link to the archived shogi-l message: http://www.shogi.net/shogi-l/Archive/2002/Nsep29-03.txt.



Thank you for your attention. As always -- any comments and suggestions are welcomed.

Tsume Shogi Parser (or "How to store 28k of data into 802k file and be happy about it")

What is Tsume Shogi Parser?

I am a huge shogi patzer. I am also a poor Java programmer. Well, all in all, I am a miserable creature. But even though I am so old that I remember the era of black&white TV, I think I can improve. (Not in being miserable, I mean. The other way.)

I wanted to strengthen my shogi skills by solving mating problems. You would be surprised how hard it is to find some good materials on the net. If you have some experience with Go or Western Chess you think that the Internet is the ultimate source for this kind of stuff. You couldn't be more mistaken -- at least when you don't read Japanese.

Fortunately, there are good folks out there. Shogi-l email discussion list is a place where people like these meet. Reijer Grimbergen, i.e., posted series of 300 tsume shogi problems. Roger Hare was so kind to collect some of them into a single file:

http://www.shogi.net/arc/shogi-l/tsume_faq.txt.

That's how I got my learning materials. The only problem left was it's form:

...
4. Black: R4d, +B4c, +P2a In hand: G
White: K2c, G3c, S4b, L1b, P4a

5. Black: R2b, G3e, S3a, L2e In hand: None
White: K3c, G4c, S1d, P4e
...

A beginner like me could use some more "visually attractive" format. By the way, it's a human nature I think: people always want more. First I complained that there are no materials at all, and then (after I found them) I wanted them to be full of diagrams and nicely formated.
Anyway, that's how I decided to write a converter for the problems. I called it Tsume Shogi Parser.

The process

Tsume Shogi Parser is intended to be a building block to use in other applications (these applications are meant to provide user interface for user convenience). In the near future I plan to provide a web app that would allow the user to upload a text file and get the resulting pdf. The parser could also be used in shogi game database to produce handouts on the fly.

Ok, let's face it. The parser will be not for much use. After all, there is only one source of data stored in this format. I treat this thing as an exercise before more important challenge: writing a parser for "This week in Shukan Shogi" posted by Reijer Grimbergen on shogi-l. The second benefit from it is trying out the part that generates pdf. That's IS going to be useful in other projects.

Let's go back to the parser. For know I’ll describe the inner mechanics of the Tsume Shogi Parser.

Technologies

For this piece of software I chose to use:

• Java -- of course ;-),
  
• JavaCC -- for defining the input file grammar and automatically generate a parser,
• XML -- for storing the data into format that can be converted into virtually anything else,
• JiBX -- for translating Java objects to XML (marshaling)
• XLS-FO -- for storing information about expected layout of the handout,
• XSLT 2.0 -- for defining a way of injecting tsume data to layout template,
• Saxon -- the only XSLT processor I know that supports XSLT 2.0,
  
• Apache FOP -- for generating PDF.

So, the process can be diagrammed as follows:

Shogi-l file->(.jj + javacc + jibix)->xml file->(xslt 2.0, saxon)->(fo, fo)->pdf

and in the future

-> spd, psn
-> database

Reading tsume

I have put all the tsume problems I found on shogi-l (most of them posted by Reijer Grimbergen) to a single file. If you're interested in it, you can download it from Tsume Shogi Project download pages. I also collected in a single file the answers for the tsume problems.

Then I wrote a JavaCC grammar for the file -- I made the computer understand what which field in the file meant. You can see the grammar on the ShogiTools project's wiki.

It was my first contact with parsers and it cost me a lot of sweat. I am still no expert here but I manage to write a simple grammar and generate a parser from it. JavaCC is of great help here. It automates most of the work so you can focus on the merit, although I had lots of problems with it. Partly because I was a beginner in the matter of parsers, partly because of lousy project documentation and community support. I've read that similar program, ANTLR, is much better in these matters. Next time I should try it so I could make an honest comparison. (If you can share your experience in the subject, please, drop me a note.

The thing is, that with the help of JavaCC and JavaCC Eclipse Plugin I generated a program that read tsume problem file and stored it in memory in Java objects. (The class diagrams of the value object used for it should be on ShogiTools pages.)
It turned out that the input data was a bit inconsistent in form. The parser showed few places and I had to do some corrections by hand. But this was not a big problem.

Producing XML

Now I wanted the data stored into an XML file.

Why XML? It is license-free, platform-independent and well-supported. Also because of the promise of easy transformations to presentation formats (without coding).

Anyway that's what the theory says. I wanted to see this in practice.

The process of transforming the memory representation of an object to a data format suitable for storage or transmission is called Marshaling. So I typed "fastet marshaller" into google search engine and got JiBX on pole position. And I used JiBX.

The interesting thing about JiBX is it's byte-code injection mechanism. In short: you define the mapping between classes and the XML. Then the mapping information is injected into your existing classes' bytecode. This means you can structure the Java classes the way you want -- they doesn't need to match the structure of the XML. It also turns out that this is a fast way do the conversion.

This part was quite quick. The program read 11k of tsume definitions and spat out 802 kB XML file. The description of XML structure can be found on ShogiTools pages.

The output

So, what is so good about having such a huge file instead of small one? And why it is so big?

Let's compare the entry for a single position in input text file and output xml file.
The text entry goes like this:

1. Black:+B3d, +B1c In hand: G
White: K2a, +R3c, L1a

Equivalent XML fragment is:

<Position>
<number>1</number>
<BlackDescription>
<PiecesPositions>
<PiecePosition>
<Piece>
<isPromoted>true</isPromoted>
<rank>B</rank>
</Piece>
<col>3</col>
<row>d</row>
</PiecePosition>
<PiecePosition>
<Piece>
<isPromoted>true</isPromoted>
<rank>B</rank>
</Piece>
<col>1</col>
<row>c</row>
</PiecePosition>
</PiecesPositions>
<Hand>
<Piece>
<isPromoted>false</isPromoted>
<rank>G</rank>
</Piece>
</Hand>
</BlackDescription>
<WhiteDescription>
<PiecesPositions>
<PiecePosition>
<Piece>
<isPromoted>false</isPromoted>
<rank>K</rank>
</Piece>
<col>2</col>
<row>a</row>
</PiecePosition>
<PiecePosition>
<Piece>
<isPromoted>true</isPromoted>
<rank>R</rank>
</Piece>
<col>3</col>
<row>c</row>
</PiecePosition>
<PiecePosition>
<Piece>
<isPromoted>false</isPromoted>
<rank>L</rank>
</Piece>
<col>1</col>
<row>a</row>
</PiecePosition>
</PiecesPositions>
</WhiteDescription>
</Position>

The second fragment is huge. It is well structured, data are organized in logical chunks. You may ask here: So what!?

And I agree. It's is no good to have kosher data structures for the sake of kosherness only. The real issue is what you can do with the data. There are the benefits of data conversion. Let me show you how our XML can be transformed.

My first try was to write XSL transformation to get an ASCII diagrams of the positions. For the given position (XML fragment above) I got this:

1.

White in hand:
9   8   7   6   5   4   3   2   1
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   | wK| wL|a
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |b
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |+wR|   |+bB|c
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |+bB|   |   |d
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |e
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |f
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |g
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |h
+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |i
+---+---+---+---+---+---+---+---+---+
Black in hand:G

The whole file can be downloaded from here.
Surly, we can do better than this! Well, we're almost there :-) This ASCII diagram thing was just a warm up before writing XSLT to produce PDF file. First I had to do xsl-fo my homework. For the PDF renderer I chose apache FOP which is quite well documented. So, I was able to learn some xsl-fo from apache documentation. I also used w3schools tutorials (http://www.w3schools.com/xslfo/default.asp).
I wanted my tsume shogi handout to have 6 problems per page and some tsume definition as an introduction. It was quite a bit of tedious work but I think it was worth it.
Judge for yourself. Here is the output pdf file.

Future development

I have my handouts for doing some shogi exercises off-line. My goal is reached so I stop my experiments for now. Instead I will list possible improvements below.

The pdf I managed to produce has English description of pieces on the board (i.e. wG for white gold, bK for black king). I could use Kanji characters instead. But first I need to know the unicode for each piece character and own some unicode font.

The whole thing is not a big deal. But during the process of converting my tsume text files into pdf I managed to learn few things. I think I also broke fresh ground for future conversion component that could be used in shogi programs. Imagine, you have your shogi database and you are able to add ability to render you games in the format you need just by supplying suitable transformation (XSLT) file.



See You next time...

Shogi Tools

Who is Fat Bold Cyclop?

My real-life alter ego works in the software industry, has a beautiful wife, two great kids and a dog.

We both like the same things but when it comes, after hard day of work, he's time to get rest I take over the control and do some fun stuff. These include playing chess or shogi over the net, watching movies, reading books. He is always puzzled why he is so tired :-)

For more information about me, please visit FBC's homepage.

One of the things of our interest is shogi. The other is developing software.

What are Shogi Tools

The whole idea of this appeared when I was browsing shogi-l discussion list.

I was looking for some tsume shogi problems to solve. Finally, I found in their archives a file http://www.shogi.net/arc/shogi-l/tsume_faq.txt. Roger Hare collected there 131 problems (mostly submitted by Reijer).

I wanted to have the tsume collection in some printable format so I could make a handout.

So I started to write a tool which I called Tsume Parser. It is supposed to read a file in the descriptive format (the format used by Roger) and convert it into more "visually attractive" one.

I also wished I had a program to help me to enhance my "board vision" in shogi. There are some similar programs for chess (i.e. http://chesstraining.sourceforge.net/) but none for Japanese chess.

I have other ideas for software that could help organize my shogi.
These led me to the conclusion that I have to take active part in developing some shogi software.

That's how Shogi Tools appeared as a project on code.google.com. There are two main goals of the project:

• Documenting shogi community standards for storing, representing, transmitting shogi-related data (games, tsume, etc.).
• Building tools to translate between the formats.

Future plans contain, after building mentioned set of tools, production of turn based on-line game server for shogi players.

On the pages of this blog You will be able to trace the progress of my work on the subject. I'll try to describe the problems I encounter and how (or if) I solved them.


See you!