From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23860 invoked by alias); 3 Oct 2004 17:48:20 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 23853 invoked from network); 3 Oct 2004 17:48:18 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 3 Oct 2004 17:48:18 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc11) with ESMTP id <2004100317481801100k1vife>; Sun, 3 Oct 2004 17:48:18 +0000 Message-ID: <41603B5E.1090509@phy.cmich.edu> Date: Sun, 03 Oct 2004 18:36:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Jim Kingdon CC: xconq7@sources.redhat.com Subject: Re: New Proposed Xconq Web Site Online References: <200410010555.i915tAn05390@panix5.panix.com> <415E0BED.6080105@phy.cmich.edu> <200410031559.i93Fxag11465@panix5.panix.com> In-Reply-To: <200410031559.i93Fxag11465@panix5.panix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01329.txt.bz2 Jim Kingdon wrote: >>I think that other font tables, similar to 'fonts.bmp' may need to be >>used for other languages, and the 'draw_string' code will probably >>have to be rewritten to dispatch to new functions such as >>'draw_string_en_US', 'draw_string_eo' :-), etc... as appropriate. > > Well, there is the easy way and the hard way. The easy way is to just > pick up one of the existing rendering packages, such as pango ( > http://www.pango.org/ ) and existing sets of fonts. I was aware of Pango, due to the fact that I have read GTK+ documentation before, and that Pango is fairly heavily required package when one installs a Redhat distro (attempting to do without it breaks a fair number of deps). I just sat down and looked at the Pango docs. It would appear that Pango can pretty much handle everything up to the point of rendering to the output device. I saw a note that it actually does have a function, which is not considered part of Pango proper, that handles rendering to an X11 display. However, this leaves the question of the Mac and Win32 platforms. Unless there is multi-platform, lightweight rendering API that can take a list of Pango glyphs (which I am led to believe is what comes out of the far end of the Pango pipeline) and actually draw them on the display, I am not sure how much use it would be to us. (I don't particularly consider GTK+ to be a lightweight rendering API, and there would be the question of how to get it to render in an SDL window, anyway.) >Something along > these lines is surely the way to go if we see it as a priority to > support a wide variety of modern languages with minimal effort on the > part of the game designer. Possibly. But, I have previously mentioned the possibility of writing labels in runic alphabets (both historical and fictitious): http://sources.redhat.com/ml/xconq7/2004/msg01213.html Of course, in that message, I was assuming that a select set of glyphs would be mapping to US-ASCII (as is currently done with 'font.bmp'). If they are Feanorean runes mapping to a character set representing the lexical tokens of the Quenya language, for example, then the task would be somewhat more complicated, I think (draw_string_quenya ?). And I doubt Pango is up to the task.... > The hard way is more custom, and has as a goal having more of a > distinctive xconq look and/or a look specific to a particular xconq > game. One possible solution which passes the buck to the game > designer (or UI translator): rather than specify a unit name (or menu > item) as text, specify it as a bitmap (in how many sizes? etc). This > pushes all the rendering issues (bidirectional, combining glyphs in > languages like thai, arabic, etc) to design-time than runtime. This > doesn't help with cases in which humans enter text - the chat and "M" > (message) features of a multiplayer game are what spring to mind. > There's also "name a unit". Yeah, it's a thought, but not only does it have the shortcomings you mention, but it would likely lead to an explosion of new bitmaps. I personally would shy away from this solution. Eric