Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!sun-barr!ccut!kogwy!wnoc-tyo-news!sragwa!sravd.sra.JUNET From: erik@sravd.sra.JUNET (Erik M. van der Poel) Newsgroups: comp.windows.x Subject: Re: Language dependent application defaults Keywords: Localization, Application Defaults Message-ID: <1462@sragwa.sra.co.jp> Date: 17 Feb 90 14:29:56 GMT References: <898@ztivax.UUCP> <3890@srava.sra.co.jp> <2803@bacchus.dec.com> Sender: news@sragwa.sra.co.jp Reply-To: erik@sra.co.jp (Erik M. van der Poel) Organization: Software Research Associates, Inc., Japan Lines: 64 In article <3890@srava.sra.co.jp> I write: asente@decwrl.dec.com (Paul Asente) writes: > Close, but there's more to it. Yes, you're right, there's a lot more to it. What we've discussed so far is just the tip of the iceberg. And what follows won't get us much further either, but I want to continue the discussion... > You really need to customize more resources than just strings (fonts, Here in Japan, the X applications that are used daily (terminal emulators, editors, etc) usually use 2 fonts: font (for English) and kanjiFont (for Japanese). I suppose the Chinese would also want to have 2 fonts, while the Europeans could probably get by with one font, using 8-bit characters (umlaut, etc). So the number of fonts depends on the type of text. This area needs standardization. > widget sizes, Widget sizes? As in width and height in pixels? I have seen several programs that specify sizes of widgets that contain text, and the result is that the text gets truncated on displays that have very small dots. Users on such displays tend to choose fonts with many dots for legibility. Application programmers should not specify the sizes of such widgets. Instead, they should let the user choose a font and let the widget choose it's own `best' size. After that the programmer can adjust the widgets so that, for example, all the buttons are the same size. Better yet, the programmer could throw a composite widget around the buttons so that they are automatically aligned. (This message is not directed at you, Paul. :-) > printing direction...) There is some support for this in X already: a negative character width causes the next character to be printed to the left of the current character. Vertical printing is not directly supported, though. Top-to-bottom printing could be achieved by drawing the text one character at a time, in a vertical fashion. So one would need resources to specify vertical printing. Erik M. van der Poel erik@sra.co.jp (Japan) SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku erik%sra.co.jp@uunet.uu.net (USA) Tokyo 102 Japan. TEL +81-3-234-2692 erik%sra.co.jp@mcvax.uucp (Europe)