Three possible contributions to text-mode Angband

G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Hi folks, I have three potential contributions to make to the
Angband community. I'm querrying for interest in each to see
how much I should sweat to finish them and send patches.

Before I get into them, I should note that my main thrust is
to improve the text-mode experience. I have been playing the *bands
for 8 years now and thoroughly enjoy the concept of screaming when
running into a 'D' at character level 20. I wish to preserve this
experience, but enhance it with a few choice utilities and features.


Angband Glyph Editor
-------------------
A GTK program that allows one to assign new character glyphs and
colors to items, monsters and terrain features with ease. There is
a screenshot available, which probably explains better:

http://img237.exs.cx/my.php?loc=img237&image=angedit5qd.png

It will be released probably GPL so others can tack on more features,
such as a color editor (I might do that, it's easy), and so on.


GTK2 w/ Pango
-------------
I've fixed the gtk2 support in ToME and will backport it to Angband
in time. GTK is the Gimp Tool Kit used in GNOME, which is available
for Linux, Mac, Windows, and a variety of other systems.


Unicode Support
---------------
I believe that the richer Angband variants, such as ToME, are hurt
by the limited character set. It's painful when we have to reuse
characters to represent different classes of objects, such as '^'
for traps and mountains. I intend to fix that problem by adding
support for unicode. That way, we can represent trees with the spade
or club symbols, walls with the drawing blocks, and, best of all,
uniques with accented versions of their representative characters.
What's cooler than runing into a unique orc with an umlaut? Running
into new monster types represented by greek letters! The task of
re-assigning character glyphs will be made painless with the Angband
Glyph Editor.

I need a little input on how to achieve unicode support. There are
two main problems. The first one is that we will need to create,
modify or recommend a _scalable_ font set to distribute with the
game that has enough of the symbols we need. (I wasn't too happy
with the various bitmap fonts available, they are more graphical
than text-mode, not to mention unscalable.)

I've noticed that most truetype fonts define the accented extended
latin up to 0xFF and most define a few greek symbols, some math
symbols, and a few miscellaneous symbols. It would be most convenient
to create our own, but then aesthetic differences will probably arise.
Still, I recommend a font similar to the freely-available Bitstream
Vera Sans Mono. It is the best one I found after all these years. What
it lacks is a good chunk of symbols. There are also icky licensing
issues.

The other problem relates to the use of char in Angband to represent
internal items. On some machines, like mine, char is unsigned. When
file.c parses a preference file, it assings the long value to a char,
which ends up padding the left bits with 1's. Hence, setting a
permanent wall to the block glyph (UTF 0x2588) results in a char value
of 0xFFFF2588 instead of 0x2588, which makes handling unicode in the
main-xxx.c files impossible. The simplest hack will be to alter file.c
and use our own version of strtol(). I don't know what the
consequences of this method are for other features, such as graphics,
so I need some advice.

I'll be glad to hear any feedback. This is not my real name or email,
but you can reach me at fando.magnet at gmail com. Or just post in
this thread.

Cheers,
Fando
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Hm, I seem to be confused how the char datatype encodes bits above
0xFF. What I need is a way to store a simple UCS encoding, like 0x2588
in the example, in a char. The char should be able to hold it, but I'm
a little murky on how. Any C gurus have any pointers?
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Nevermind, char can't hold enough info. I'll have to find another way,
possibly by turning all occurances of x_char into an unsigned int. That
bites too deeply into angband though...
 

magnate

Distinguished
Dec 31, 2007
192
0
18,680
Archived from groups: rec.games.roguelike.angband (More info?)

Isn't the glyph editor just a standalone GUI of the % function
(interact with visuals)? I can't see any additional functionality -
though that's not to say it wouldn't be welcomed, of course.

As Paul says, I'd stick with Latin-1 rather than go to unicode.

CC
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

"fando" <fando.magnet@gmail.com> wrote:
>Hm, I seem to be confused how the char datatype encodes bits above
>0xFF. What I need is a way to store a simple UCS encoding, like 0x2588
>in the example, in a char. The char should be able to hold it, but I'm
>a little murky on how. Any C gurus have any pointers?

The type 'char' is exactly one byte long i.e. eight bits. There is
absolutely no way to portably store any value larger than 255 in an
unsigned char.

You need to read up on things like "wide characters" and "multi-byte"
characters, and I suggest you take your question to
rec.games.roguelike.development or some similar, more appropriate forum.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

In article <1111566189.941752.51010@z14g2000cwz.googlegroups.com>, fando wrote:
> Unicode Support
> ---------------
> I believe that the richer Angband variants, such as ToME, are hurt
> by the limited character set. It's painful when we have to reuse
> characters to represent different classes of objects, such as '^'
> for traps and mountains. I intend to fix that problem by adding
> support for unicode. That way, we can represent trees with the spade
> or club symbols, walls with the drawing blocks, and, best of all,
> uniques with accented versions of their representative characters.
> What's cooler than runing into a unique orc with an umlaut? Running
> into new monster types represented by greek letters! The task of
> re-assigning character glyphs will be made painless with the Angband
> Glyph Editor.

You could achieve much the same result with less pain by sticking with
latin-1 rather than unicode. You still get a reasonable amount of accents,
without having to go beyond 8 bits.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Yeah, I was confused by the size of the char. Anyway, I don't see how
unicode can be supported without rehauling the way angband stores
characters. I'll take this to developers. Thanks!


magnate wrote:
> Isn't the glyph editor just a standalone GUI of the % function
> (interact with visuals)? I can't see any additional functionality -
> though that's not to say it wouldn't be welcomed, of course.

Yes, but it's a crucial app for unicode support. You wouldn't want to
page manually through thousands of characters just to find the right
glyph. :)
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

It was easier than I thought. Here's a screenshot showing ToME running
with unicode support with GTK2.

http://log4r.sourceforge.net/images/uniangband.png

The clubs, triangles and solid blocks were all specified in the prf
file with their standard unicode id's. The prf file was created by my
glyph editor. Kind of neat, huh? :)

For the programmers, it involves replacing most instances of char with
a new type, u16b which I typedefed to uchr. It worked transparently.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Good show. I have one additional recommendation: The trouble isn't
the char vs unicode per se, the trouble is angband uses old-fashioned
type system.

Recommended practice is to use additional typedefs for distinct logical
classes.

so

// glyph represents symbol drawn on screen. '@'.
typedef u16b glyph ;

// char_t represents a character in a string.
// Angband is not unicode, much less internationalized.
// Doing this requires hack in (r)ecall function.
typedef char_t char;
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

fando wrote:
> It was easier than I thought. Here's a screenshot showing ToME
running
> with unicode support with GTK2.
>
> http://log4r.sourceforge.net/images/uniangband.png
>
> The clubs, triangles and solid blocks were all specified in the prf
> file with their standard unicode id's. The prf file was created by my
> glyph editor. Kind of neat, huh? :)
>
This is beautiful! I would love to see this incorporated into the
standard sources. ToME, alone of variants, I usually play with tiles,
just because I feel I lose so much of the richness of its world when
its viewed through the severely limited ASCII set. I would play
Unicode ToME in a heartbeat!

One question: are these changes specific to GTK-2, or could they be
integrated into any of the ASCII interfaces easily enough (for
instance, Mac OSX)?

Looking forward to seeing more of this! - Robert.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

fando wrote:
> Yes, it would be better to make the glyphs orthogonal to the
> 'character class' of the object. That way orcs and orc uniques
> can have different glyphs (variants of 'o' with accents) and still
> all be recalled using 'o'. This would mean treating x_char as a
> unique ID for a class of object rather than the character to display.
> But it looks like this is going to require more change than my current
> hack, which was mostly a search-and-replace deal.

Easiest might be to implement it by using tiles -- add unicode as a tile
set, and special case it to display unicode symbols rather than actual
graphical tiles.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Christophe Cavalaria wrote:
> As far as I know, Unicode is 32bit, not 16bit. With that, you only
get a
> very small subset of the Unicode range.

Right, but at the moment, support up to 0xFFFF, 16 bits, is sufficient.
The symbol block is around 0x2500 and fantasy scripts go in 0xE000. It
will be trivial to extend it, but without fonts universally supporting
characters above 0xFFFF, I don't see the need yet.

Fando
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Robert Goulding wrote:
> This is beautiful! I would love to see this incorporated into the
> standard sources. ToME, alone of variants, I usually play with
tiles,
> just because I feel I lose so much of the richness of its world when
> its viewed through the severely limited ASCII set. I would play
> Unicode ToME in a heartbeat!

That's the idea. When I first started playing ToME, I had difficulty
getting used to the use of '^' as mountains and the reuse of '#' for
every kind of terrain feature. I feel graphical tiles are overkill, we
just need a few extra symbols to make a text-mode, feature-rich band
enjoyable.

> One question: are these changes specific to GTK-2, or could they be
> integrated into any of the ASCII interfaces easily enough (for
> instance, Mac OSX)?

Any system that can show unicode will be able to handle this. All that
needs to be tweaked are the main-xxx.c files for each platform,
provided that this support is merged into the main tree of your
favorite variant. I work on linux, and unfortunately my Windows HD
crashed so I'm limited to GTK/X11. :(

> Looking forward to seeing more of this! - Robert.

I'm going off on tangets (cirth names for unidentified objects), but
I'll keep the list updated about my experiments. :)

Fando
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Twisted One wrote:

> Easiest might be to implement it by using tiles -- add unicode as a
tile
> set, and special case it to display unicode symbols rather than
actual
> graphical tiles.

Hm, that's an interesting idea. I haven't inspected the graphics system
too closely, but what I understand is that the tiles are also limited
to 256 items. Also, they are referenced by x_char, which isn't
orthogonal at all. Each item needs a brand new field to allow
many-to-one mappings of glyphs/tiles to character ID. This means new
parsing code in file.c, new conditions in z-term.c, etc. It seems like
a lot of extra work, but it's the right way to go if Angband is to be
more extensible.

On the other hand, my search-and-replace char with u16b hack opens up
the possibility of using 65535 tiles too, not just unicode support. And
this hack works transparently with current graphics code; nothing
breaks. It's a hacky hack that just works. :)

It's wise to inspect all approaches. I'm going to see how much work
it'll be to separate the model from the view with respect to Angband
objects.

- Fando
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

fando wrote:

> It was easier than I thought. Here's a screenshot showing ToME running
> with unicode support with GTK2.
>
> http://log4r.sourceforge.net/images/uniangband.png
>
> The clubs, triangles and solid blocks were all specified in the prf
> file with their standard unicode id's. The prf file was created by my
> glyph editor. Kind of neat, huh? :)
>
> For the programmers, it involves replacing most instances of char with
> a new type, u16b which I typedefed to uchr. It worked transparently.
As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
very small subset of the Unicode range.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

On Thu, 24 Mar 2005 23:47:29 +0100, Christophe Cavalaria wrote:

> As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
> very small subset of the Unicode range.

Effectively, the current Unicode standard is 21 bit, containing 16 bit
'planes' - the first of those ("basic multilingual plane")
describes more than 65000 characters - shouldn't that be enough?

--
Christopher
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Christopher Koppler wrote:

> On Thu, 24 Mar 2005 23:47:29 +0100, Christophe Cavalaria wrote:
>
>
>>As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
>>very small subset of the Unicode range.
>
>
> Effectively, the current Unicode standard is 21 bit, containing 16 bit
> 'planes' - the first of those ("basic multilingual plane")
> describes more than 65000 characters - shouldn't that be enough?

It is enouth until you need access to one of the other planes. For
example, Ghotic chars aren't available like that :)

With such big change, it would be a good idea to do it right the first
time. It's not like it'll eat up a lot of memory.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Christophe wrote:
>
> With such big change, it would be a good idea to do it right the
first
> time. It's not like it'll eat up a lot of memory.

Yeah, it doesn't look like it matters. Systems that want to display
unicode are already very buff resource-wise. Here's my current approach
to this hack:

// h-types.c
#ifdef SUPPORT_MORE_VISUALS
typedef uchr u32b; // or u16b
#else
typedef uchr char;
#endif

Then we replace instances of char with uchr where it matters, such as
x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
help convert a uchr array to a UTF-8 encoded string:

/*
* Accepts a uchr array, the length of the array and a buffer to
* write the UTF-8 string to. The buffer must be at least 3*length+1
* (for 16 bit). Returns the number of bytes written (pass it to
* text_hook in place of length)
*/
int uchr_ary_to_utf8_str(uchr *a, int length, char *s);

The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
characters, but graphical tiles also. But I'm still playing with the
semantics, so I'd welcome any suggestions. (Currently I'm using ochr
instead of uchr. It looks ugly though.)

There is not much extra work for main-xxx.c. The arguments to text_hook
now accept a uchr pointer instead of a character pointer. It is up to
the text_hook methods to decide how to display this data. Those that
can't use SUPPORT_MORE_VISUALS won't have to bother with anything
because the input will effectively be a char pointer.

As for making recall work with this system, I figure we can rely on
d_char, the default character to display, as the character class
identifier. All that needs to be done is ensure recall goes by d_char
instead of x_char.

I got vanilla angband to work with this system, it's just a matter of
time before I have a patch ready for testing. :)

Cheers,
Leon
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

"fando" <fando.magnet@gmail.com> wrote in message
news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
> Christophe wrote:
> >
> > With such big change, it would be a good idea to do it right the
> first
> > time. It's not like it'll eat up a lot of memory.
>
> Yeah, it doesn't look like it matters. Systems that want to display
> unicode are already very buff resource-wise. Here's my current approach
> to this hack:
>
> // h-types.c
> #ifdef SUPPORT_MORE_VISUALS
> typedef uchr u32b; // or u16b
> #else
> typedef uchr char;
> #endif
>
> Then we replace instances of char with uchr where it matters, such as
> x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
> help convert a uchr array to a UTF-8 encoded string:
>
> /*
> * Accepts a uchr array, the length of the array and a buffer to
> * write the UTF-8 string to. The buffer must be at least 3*length+1
> * (for 16 bit). Returns the number of bytes written (pass it to
> * text_hook in place of length)
> */
> int uchr_ary_to_utf8_str(uchr *a, int length, char *s);
>
> The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
> characters, but graphical tiles also. But I'm still playing with the
> semantics, so I'd welcome any suggestions. (Currently I'm using ochr
> instead of uchr. It looks ugly though.)
>
> There is not much extra work for main-xxx.c. The arguments to text_hook
> now accept a uchr pointer instead of a character pointer. It is up to
> the text_hook methods to decide how to display this data. Those that
> can't use SUPPORT_MORE_VISUALS won't have to bother with anything
> because the input will effectively be a char pointer.
>
> As for making recall work with this system, I figure we can rely on
> d_char, the default character to display, as the character class
> identifier. All that needs to be done is ensure recall goes by d_char
> instead of x_char.
>
> I got vanilla angband to work with this system, it's just a matter of
> time before I have a patch ready for testing. :)
>
> Cheers,
> Leon
>
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

"Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote in message
news:SIednVGq18Bxx9jfRVn-qw@comcast.com...
>
> "fando" <fando.magnet@gmail.com> wrote in message
> news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
> > Christophe wrote:

My apologies for that previous post that added nothing. Just a stray
mouseclick that happened to be on "send messag".

> >
> > I got vanilla angband to work with this system, it's just a matter of
> > time before I have a patch ready for testing. :)
> >
Personally, I will add this to NPP when it is ready. I have been reading
this post, but I have to admit I don't quite understand the mechanics on how
it works, but I still won't hesistate to use it.

-Jeff
 

valis

Distinguished
Mar 24, 2005
380
0
18,780
Archived from groups: rec.games.roguelike.angband (More info?)

In article <pYmdnf4HxpglxtjfRVn-hQ@comcast.com>,
"Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote:

> "Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote in message
> news:SIednVGq18Bxx9jfRVn-qw@comcast.com...
> >
> > "fando" <fando.magnet@gmail.com> wrote in message
> > news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
> > > Christophe wrote:
>
> My apologies for that previous post that added nothing. Just a stray
> mouseclick that happened to be on "send messag".
>
> > >
> > > I got vanilla angband to work with this system, it's just a matter of
> > > time before I have a patch ready for testing. :)
> > >
> Personally, I will add this to NPP when it is ready. I have been reading
> this post, but I have to admit I don't quite understand the mechanics on how
> it works, but I still won't hesistate to use it.

Not to start another off topic flamewar, but rgr dgr that!

> -Jeff
-Campbell
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Jeff Greene wrote:
> "fando" <fando.magnet@gmail.com> wrote in message
> news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
>
>>Christophe wrote:
>>
>>>With such big change, it would be a good idea to do it right the
>>
>>first
>>
>>>time. It's not like it'll eat up a lot of memory.
>>
>>Yeah, it doesn't look like it matters. Systems that want to display
>>unicode are already very buff resource-wise. Here's my current approach
>>to this hack:
>>
>>// h-types.c
>>#ifdef SUPPORT_MORE_VISUALS
>>typedef uchr u32b; // or u16b
>>#else
>>typedef uchr char;
>>#endif
>>
>>Then we replace instances of char with uchr where it matters, such as
>>x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
>>help convert a uchr array to a UTF-8 encoded string:
>>
>>/*
>> * Accepts a uchr array, the length of the array and a buffer to
>> * write the UTF-8 string to. The buffer must be at least 3*length+1
>> * (for 16 bit). Returns the number of bytes written (pass it to
>> * text_hook in place of length)
>> */
>>int uchr_ary_to_utf8_str(uchr *a, int length, char *s);
>>
>>The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
>>characters, but graphical tiles also. But I'm still playing with the
>>semantics, so I'd welcome any suggestions. (Currently I'm using ochr
>>instead of uchr. It looks ugly though.)
>>
>>There is not much extra work for main-xxx.c. The arguments to text_hook
>>now accept a uchr pointer instead of a character pointer. It is up to
>>the text_hook methods to decide how to display this data. Those that
>>can't use SUPPORT_MORE_VISUALS won't have to bother with anything
>>because the input will effectively be a char pointer.
>>
>>As for making recall work with this system, I figure we can rely on
>>d_char, the default character to display, as the character class
>>identifier. All that needs to be done is ensure recall goes by d_char
>>instead of x_char.
>>
>>I got vanilla angband to work with this system, it's just a matter of
>>time before I have a patch ready for testing. :)
>>
>>Cheers,
>>Leon
>>
>
>
>

Uh ... where's the original text? All I see is fando's post quoted, plus
the attribution and headers ... not even a sig.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Here are a few more screenshots.

1. http://log4r.sourceforge.net/images/unitome2.png

This is a good example of how unicode enhances text-mode. The spades
are "small trees" which can be walked over and the bright green clubs
are "trees" which can't (well not yet). Terrain is much more
distinguishable this way. The infinity sign is a void jumpgate. :)

2. http://log4r.sourceforge.net/images/unitome3.png

I hacked in some Quenya to replace the unknown scroll names. It's just
random gibberish and I think Cirth would look better. It could be
enabled if a user has the right font, which we could supply with the
game. I merged two fonts together to get this result: Bitstream Vera
Sans Mono and one of the free Quenya fonts.

3. http://log4r.sourceforge.net/images/angedit1.png

Buggy screenshot of my glyph editor, used to set the above glyphs.

Does anyone want to take a shot at creating a good monospace Cirth font
that would render well? I can make the font if someone supplies
Scalable Vector Graphics of them. For reference, you could grab,

http://www.evertype.com/standards/iso10646/pdf/cirth.pdf

and screencap the runes, then outline them in inkscape or something.
I've done the first column, but I'm no artist and it's too much extra
work. :(

Imagine the startup screen in Angband lined with Cirth like in the LotR
books.

Cheers,
Leon Torres (my real name)
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

fando wrote:
> Here are a few more screenshots.
>
> 1. http://log4r.sourceforge.net/images/unitome2.png
>
> This is a good example of how unicode enhances text-mode. The spades
> are "small trees" which can be walked over and the bright green clubs
> are "trees" which can't (well not yet). Terrain is much more
> distinguishable this way. The infinity sign is a void jumpgate. :)
>
> 2. http://log4r.sourceforge.net/images/unitome3.png
>
> I hacked in some Quenya to replace the unknown scroll names. It's just
> random gibberish and I think Cirth would look better. It could be
> enabled if a user has the right font, which we could supply with the
> game. I merged two fonts together to get this result: Bitstream Vera
> Sans Mono and one of the free Quenya fonts.
>
> 3. http://log4r.sourceforge.net/images/angedit1.png
>
> Buggy screenshot of my glyph editor, used to set the above glyphs.
>
> Does anyone want to take a shot at creating a good monospace Cirth font
> that would render well? I can make the font if someone supplies
> Scalable Vector Graphics of them. For reference, you could grab,
>
> http://www.evertype.com/standards/iso10646/pdf/cirth.pdf
>
> and screencap the runes, then outline them in inkscape or something.
> I've done the first column, but I'm no artist and it's too much extra
> work. :(
>
> Imagine the startup screen in Angband lined with Cirth like in the LotR
> books.
>
> Cheers,
> Leon Torres (my real name)
>

That looks awesome! Especially the new scroll names. Nice work man. :)
And as far as Quenya vs. Cirth... I think either one will work. In
fact... is there any reason not to use both?
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

BarlowBrad wrote:
>
> That looks awesome! Especially the new scroll names. Nice work man.
:)
> And as far as Quenya vs. Cirth... I think either one will work. In
> fact... is there any reason not to use both?

The quick and dirty answer: No reason at all.

But the long answer is more interesting,

Players will want to use different fonts, and not all of them will have
the desired support for Cirth and Quenya. In fact, I don't think any
popular monospace fonts do. What you saw in the screenshot was
something I glued together as a quick and akward hack. I don't even
like that font, it's too narrow for my tastes. :(

Font coverage is the biggest issue with unicode support in any
application. A font that doesn't support Japanese will be useless to
the Japanese. Likewise, one that doesn't have the symbols we need won't
be useful to us. We are only beginning to see unicode adopted as an
industry-wide standard, so we will either have to wait for someone to
create a monospace Quenya/Cirth font with the desired drawing symbols
or we do it ourselves. We have the advantage of actually having a need
to implement this, so we can become a principle driver for the
ConScript fantasy/sci-fi standard. All we have to do is create the
fonts and distribute it to players.

In fact, some dorks in the Linux community have already made the
Klingon block of unicode pseudo-official by providing font maps for it
that come with Linux. (Check out Documentation/unicode.txt in recent
linux kernel sources and http://www.kli.org/). If you fire up fontforge
under linux, you'll see the Klingon block represented.

We should do the same for Cirth and Quenya. :)

Again, for reference, check out the ConScript unicode registry:
http://www.evertype.com/standards/csur/

- Fando