Re: ITP: xhangglider
At Sat, 19 Feb 2000 00:09:24 +0900, I wrote: > I indend to package xhangglider. This is a pretty cute demo program > for X. It is under the GPL2, and i believe nothing else has the same > features :) I put xhangglider.deb and related files at http://master.debian.or.jp/~take Please look at them. Thanks. -- Yasuhiro TAKE http://plaza.harmonix.ne.jp/~redstar Debian JP Project : [EMAIL PROTECTED] Osaka Univ Medical School : [EMAIL PROTECTED] NetFort : [EMAIL PROTECTED]
Pre-ITP/RFC: Ng - editor that can handle CJK & Latin.
[ Sorry for cross-posting. Please honor the Reply-To. ] Hello, there. Ng stands for Nihongo Mg, MicroGnuEmacs. Mg appeared more than 10 years ago, and seems to be unmaintained now, while Ng, Japanized version of Mg has been well maintained and improved. Ng is yet another Emacs-like editor. It is console-based, lightweight, easy to use, has familiar key-bindings, and occupies less memory. The most attractive feature of Ng is that it can handle multibyte characters such as Japanese Kana, Kanji(Hanji) and Hangul, as well as singlebyte characters such as ASCII and Latin characters. Talking of CJK support of Ng, it can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and EUC-CN(GB2312). Those who are familiar with coding system may have got the feeling that the support of Chinese and Korean coding systems is not enough for some points. I guess there're otner coding systems that are used to encode Chinese and Korean texts. For example, There're three well-known coding systems that are used to encode Japanese texts, which are ISO-2022-JP, Shift-JIS and EUC-JP. These three coding systems are easy to convert from one to another, and easy to detect which coding system is used. I guess the same idea would be applied to Chinese and Korean. So please let me know what should be done to improve the support of Chinese and Korean. What coding system is used for Chinese and Korean texts other than EUC, and how to detect the coding system would be a great help. In addition, Ng cannot handle the whole content of EUC-CN(CNS 11643-1/2), used in Taiwan. Ng can handle only about the half part of it, so i didn't say Ng can handle EUC-CN(CNS 11643). I wonder there's any demand for the support of this. In fact, Ng also cannot handle the whole content of EUC-JP, but for general use of Kanji, it doesn't matter so i said it can handle EUC-JP. BTW, Ng can also handle Latin characters, as already mentioned above. It can handle ISO-8859-1, 2, 3, 4, ... i'm not sure where to stop the numbering :) Anyway, it can handle all of Latin charsets. However, i'm not sure how to input the characters like á, û, and ë, and whether input method of these characters is included in this editor or not. I hope those who use Latin charsets will tell me if the Latin support of Ng is enough. Finally, the priority of Ng as alternatives of editor is set to 80. I'm not sure this value is desirable or not. Packages are splitted into four packages, ng-common, ng-latin, ng-cjk, and ng-cjk-canna. These are available at: deb http://arashi.debian.or.jp/~take/debian ./ deb-src http://arashi.debian.or.jp/~take/debian ./ As mentioned above, i have several questions, and want the answers before announcing ITP and upload it. Please give me a comment. Regards, -- Yasuhiro TAKE <[EMAIL PROTECTED]> / Debian JP Project "I'd just be the catcher in the rye and all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: x-ttcidfont-conf
Package: wnpp Severity: wishlist x-ttcidfont-conf is a debian specific package that configures TrueType fonts (as well as CID fonts) for X through defoma framework. Yes, thanks to Branden, there's already font configuration framework which works pretty fine for other scalable fonts and bitmap fonts, but there remains some problems about TrueType font configuration. The biggest problem about TrueType font configuration for X is the syntax of .scale file. X provides two backends to handle TrueType fonts, xtt backend and freetype backend. The former features dynamic decoration of TrueType font, which for example creates bold and italic faces from upright medium face. This feature requires additional parameters to .scale file. Its syntax is of course nonstandard, and conflicts with the syntax for the freetype backend. This fact indicates that TrueType font package may need to prepare two scale files, know which backend the scale file should be for, and put the preferred .scale file into the right location. It's a little bit complicated task, so x-ttcidfont-conf manages it. 1) Ask which backend is used through Debconf. 2) generate the .scale file and .alias file suited to the selected backend from registered TrueType fonts. 3) call mkfontdir. When dpkg-reconfigure is called and the selected backend is changed, it automatically regenerate the .scale file and .alias file suited to the newly selected backend. All ttf-packages have to do is just register the truetype font to defoma. I've already thrown this idea to debian-x at about the end of the March, and got the agreeing responce from Anthony (but no responce from Branden).
Re: ITP: x-ttcidfont-conf
At Mon, 23 Apr 2001 12:05:07 -0400, Michael Stone wrote: > > On Tue, Apr 24, 2001 at 12:52:30AM +0900, Yasuhiro Take wrote: > > The biggest problem about TrueType font configuration for X is the syntax > > of .scale file. X provides two backends to handle TrueType fonts, xtt > > backend > > and freetype backend. The former features dynamic decoration of TrueType > > font, > > which for example creates bold and italic faces from upright medium face. > > This feature requires additional parameters to .scale file. Its syntax is > > of course nonstandard, and conflicts with the syntax for the freetype > > backend. > > Since mutating fonts like this usually results in a crappy looking font > anyway, why don't we just configure the fonts we *really have* in a > standard format and leave any other mods to the user? Because there's a consierable amount of demand for having italic and bold faces of a font which has only an upright face, especially in CJK. Only an upright face is ready for CJK fonts in general, while upright, bold, italic, bolditalic faces are ready for Latin fonts. It is the first reason why CJ(K) ttf packages provide the xtt .scale file. The second reason is that XLFDs for dynamically generated italic & bold faces of CJK TrueType fonts are widely used in CJK. Other major Linux distributions in CJK ship the xtt .scale file for CJK TrueType fonts, because there's a demand. It can be said that xtt .scale file is rather standard in CJK. But it is not good that CJK ttf packages provide only xtt .scale file, and should be amended. To have users prepare the xtt .scale file and configure is a bit hard task, so i think it is better that users can choose the backend. If we choosed to 'leave any other mods to the user', the following situation could happen. Mr.J: I installed Debian yesterday. Mr.K: Oh, that's nice. How is it? Mr.J: It's wonderful, except that there's no italic and bold faces available for Japanese TrueType fonts in X. I used Turb*Linux before, and these faces were ready without doing extra byhand configuration. I have no idea what i can do to solve this problem. Debian sucks. Mr.K: ... Thanks, hirot pgp6uZRzwGYiY.pgp Description: PGP signature
Re: Only one who have parse error in /var/lib/dpkg/available?
At Thu, 26 Apr 2001 00:14:01 -0500 (CDT),
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 26 Apr 2001, Shaul Karl wrote:
>
> > Yes there is:
> >
> > [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> > -rw-r--r--1 root root 2547713 Apr 25 00:46
> > /var/lib/dpkg/available
> > [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> > 11557764 c e 9 1 8 0 f a 4 2 d f \n
> > 11560001
> > [12:39:42 /tmp]$
> >
> > and
> > dpkg -l doc-linux-text
> > works too. I do not know what was changed.
>
> No, there is no final new line.
>
> debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
> 23654010 r d . \n \n
>
> It looks like the file got truncated. Disk corruption? What apt-cache
> dumpavail(called from dselect [2]) interrupted?
I guess it is my fault. Maybe the description of ng-cjk lacks final new-line
like below, and i guess that's the cause.
sed 's/^ /+/' control | grep -A 11 '^Package: ng-cjk$'
Package: ng-cjk
Architecture: any
Depends: ${shlibs:Depends}, ng-common
Description: Nihongo MicroGnuEmacs with CJK support.
+Ng is Nihongo Mg, MicroGnuEmacs. It is a small lightweight Emacs-like
+editor. It can handle both Latin and CJK.
+.
+ng-cjk can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and
+EUC-CN(GB only). Latin is not supported.
+
Package: ng-cjk-canna
Architecture: any
I'll fix this right now and dupload it.
Thanks,
hirot
pgp0h8bN2Eevh.pgp
Description: PGP signature
Re: Preview of new Ghostscript packages - please test
[ Ccing to [EMAIL PROTECTED] for notice ] Hello, At 21 Sep 2001 15:39:27 +0300, Samuli Suonpaa wrote: > > > Torsten Landschoff <[EMAIL PROTECTED]> wrote: > > Please take a look at these packages and tell me about any problems > > which are not obvious - there is a lot of stuff still lacking and I > > only want to upload the packages to the archive when they are > > feature complete. > > I really do not know much about gs, but it seems there's something > wrong with fontpaths here. When trying to configure my PSC500 (using > hpijs and DJ8xx drivers now included in GhostScript, thank you for > that), I only get complaint: "Error: /invalid font in findfont" and > something like that. If you are using defoma 0.4.10, it may be a bug of defoma. Please look into /var/lib/defoma/gs.d/dirs/fonts, where is one of the font paths of gs and is managed by defoma. The bug makes creating Fontmap file fail so you may find out that there're symlinks of pfb files of gsfonts but no Fontmap file in the directory. Please update to defoma 0.4.11 i'm just duploading and run: defoma-app update gs Thanks, hirot pgp6xoTdVk25L.pgp Description: PGP signature
Re: New project: Debian-Med
At Mon, 7 Jan 2002 15:46:12 +0100 (CET), Tille, Andreas <[EMAIL PROTECTED]> wrote: > > > Hello, > > a new year seems to be the right starting point for a new project :). > > So here we are: > > _ _ __ ___ > | _ \ ___ | |__ (_) __ _ _ __ | \/ | ___ __| | > | | | | / _ \| '_ \ | | / _` || '_ \ _ | |\/| | / _ \ / _` | > | |_| || __/| |_) || || (_| || | | ||_|| | | || __/| (_| | > |/ \___||_.__/ |_| \__,_||_| |_| |_| |_| \___| \__,_| Sounds great! UNIX systems seems going to be used in hospitals and clinics, and there's already one based on Debian as far as i know. So it maybe nice of us to provide a service specific to medicine. I know two kinds of dictionary for life science including medicine of course, one for English spell check and the other for Japanese Kana-to-Kanji conversion. They seem non-free, but worth including i guess. Here is the URL: http://lsd.pharm.kyoto-u.ac.jp/index.html BTW, Minoru seems derived from Japanese word... Does it have something to do with Japanese thing? Thanks, hirot, commented as a student of medicine :) pgpojRpUB6lFf.pgp Description: PGP signature
