June 2002 - openSUSE M17n - openSUSE Mailing Lists

CJK-LyX 1.2.0 package available for SuSE Linux 8.0
by Mike Fabian 20 Jan '03

20 Jan '03

An updated CJK-LyX package is available for SuSE Linux 8.0: ftp://ftp.suse.com/pub/people/mfabian/8.0-i386/cjk-lyx-1.2.0-0.i386.rpm For some screenshots and SuSE specific notes see http://www.suse.de/~mfabian/suse-cjk/cjk-lyx.html >From the /usr/share/doc/packages/cjk-lyx/NEWS file: What's new in version 1.2.0? ---------------------------- LyX 1.2.0 is the version where many of changes in the 1.1.x series really begin to pay off. It should prove to be a very solid base for further developments. As of this version, we use (yet another) new versioning scheme: next major version will be 1.3.0, and 1.2.x will be just incremental fixes (like the `fix' series used to be for 1.1.5 and 1.1.6). This version sees the introduction of the so-called `new' insets, which can contain arbitrary text. As a consequence, many new features are now possible: - Floats, footnotes and margin notes are now real insets. The positional parameters of figure, table and algorithm floats can be set float-by-float - Most problems with the new table inset of 1.1.6 have been addressed (memory consumption, file bloat, spell-checking, search and replace...). Better longtable header/footer support was implemented. - TeX mode has been superseded by the ERT inset, which is foldable, or can be shown inline - Notes inset can now contain arbitrary LyX constructs; they will not appear in the output. - New minipage inset Note that another consequence of these changes is that older LyX versions will almost certainly fail to read files produced by LyX 1.2.0. Other more traditional insets have been improved too: - New graphics inset with support for hassle-free inclusion of various image formats (GIF, JPEG, PNG and EPS by default) and a new rendering scheme that should fix the bugs we had with the older ghostscript method. - Support for natbib for bibliography citations The math editor has been mostly rewritten. This begun as a general cleanup, but it turns out that many new features happened in this process, among which: - many of the known bugs or annoyances in mathed have been fixed. - possibility to display all standard latex and amsmath symbols (and also the \mathcal, \mathbb, and \mathfrak fonts)as long as the relevant fonts have been made available to the X server - support for many amsmath features Commands: xrightarrow, xleftarrow, substack, underset, dddot over/under arrows (e.g. underleftarrow). Environments: align, alignat, xalignat, xxalignat, multline, gather split, gathered, aligned, cases, subarray, pmatrix, bmatrix, vmatrix, Vmatrix - Preliminary support for xymatrix - Support for horizontal and vertical lines in arrays. - Improvements to the parser - Improvements to math text mode - (Better) support for nested macros - Enable size changes to arrays after creation (add/delete rows/columns) - Support for changing font or displaystyle on a selection - GUI support provided for many more features -- Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

3 4

Re: [m17n] Suse 8.0: Japanese printing problem?
by Wolfgang Slany 23 Jul '02

23 Jul '02

On Wed, 19 Jun 2002, Mike Fabian wrote: > > Am Montag, 17. Juni 2002 08:28 schrieb Wolfgang Slany: > >> Since updating to suse 8.0 the following problem appeared: > >> > >> I cannot print Japanese pages from netscape (nor mozilla): only bakemoji > >> result. Printing to file and inspecting the file via gv on the screen > >> works fine, but printing the same file via gv results in the same bakemoji > >> output. Printing Japanese pages from konqueror (with option embed fonts) > >> works OK (though konqueror has some other problems when printing Japanese, > >> i.e., the characters are printed but there is no space between them, and > >> often characters are overwritten with the following text etc). Print > >> command in all cases was lpr. > >> > >> Cjk-LaTeX postscript prints fine. > >> > >> Could it be that the update reset the print filter so that lpr since then > >> can print only embedded fonts? Any fix for this known? > > > Thats the same problem I had. Mike helped me to solve it. Shortly, > > use qtconfig to choose the right fonts as substitution (see als > > Mike's CJK-manual). Since this time everything worked fine. > > Wolfgangs problem seems to be different. Printing with embedded fonts, > e.g. from KDE3 works for Wolfgang. What does not work is Japanese > printing when the fonts are not embedded but only font names to use > like "Ryumin-Light" or "GothicBBB-Medium" are specified in the > PostScript files. Netscape 4.x does print like this, it doesn't embed > fonts. Mozilla does the same. > > To print such files, you need to do one of the following things: > > 1) use a Japanese PostScript printer and setup your printing > queue with YaST2 to use a PostScript device I have only a HP Laserjet 5L without postscript, so this was never a possibility in my case. > or > > 2) use any printer (PostScript or not) and setup your printing queue > with YaST2 *not* to use PostScript but a printer specific > format instead (for example ljet4, deskjet, epson, necp6, ... > whatever). But even if your printer is a PostScript printer, > do *not* configure it as a PostScript printer! Configure > the printer specific driver instead, then Ghostscript will > be used automatically to render the fonts. I tried it but it did not work: lj5mono driver with ghostscript produced only garbage (the output was not recognized as pcl5 from the printer despite claiming to be so from the one line that printed), and the ljet4 driver produced the same result (mojibake for Japanese) as before when I install a new ljet4 printer via yast2 and printed to it. > or > > 3) Preprocess the file manually with Ghostscript, for example: > > gs -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=file.pswrite file.ps > > Instead of 'pswrite' you can use a printer specific device > like 'ljet4'. If you use a printer specific devide, you > can print the result on a raw printer queue, which does > nor further filtering. In that case you need to setup > such a queue with YaST2. > > If you use 'pswrite', Ghostscript will write PostScript > output again, but embed *all* used fonts as Vector graphics > in the file. I.e. you can print such a file on any > any PostScript printer, no matter what fonts the printer has. > I manually use Ghostscript with the 'pswrite' device to > preprocess Japanese Postscript files quite often, because > this allows me to correctly print them on systems > where I have no idea how the printing queue is setup and > whether the printer has Japanese fonts or not. > > For example, here at SuSE I often print using some network > print server, like: > > lpr -P printername@servername filename > > I am not the sysadmin of this server and therefore I cannot > install Japanese fonts for Ghostscript and setup a printer > queue to use Ghostscript. And the printers here in Germany > don't have Japanese fonts. > > But if I preprocess the PostScript file locally with > Ghostscript's 'pswrite' device, I can send the result > even to such a printer queue and have it printed correctly. > > Usually I use the attached 'ps2dev' script for that purpose: > > ps2dev file.ps > > which will then produce file.pswrite. Or use it like > > ps2dev -sDEVICE=ljet4 file.ps > > to produce file.ljet4 which can be sent via a raw queue > to a HP Lasejet4. > > The 'pswrite' output device is also useful if you want > to create portable PostScript file which you can take > with you and print somewhere else on some unknown > System, where you don't know what type of printer is used > there (therefore you may not want to use something > like 'ljet4') and you don't know what fonts are available. > > A file preprocessed with Ghostscript using the 'pswrite' > device can be printed almost everywhere. This (both via ps2dev as via gs -sDEVICE=ljet4 and printing to lp-raw) finally worked. I still do not understand what goes wrong with the normal print queue since it is sure that it must also use gs (as I have no postscript printer) and the same device ljet4 (where I specified the ljet4 printer name). In netscape I can now specify gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ljet4 -sOutputFile=- - |lpr -Plp-raw or gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ljet4 -sOutputFile=- - |lpr or gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=- - |lpr as printer and it will print correctly. The last one (with the pswrite) is the best as the others feed some empty pages after the actual printing. What I cannot currently explain is that being able to see the correct characters on the screen using gv and printing from gv still produces only mojibake (romaji appear correctly, as do graphics), as if gv knew the Japanese fonts only for the screen but not for the printer, while at the same time printing is only possible directly via gs with the ljet4 device specified. Basically, why does gs know the Japanese fonts when it is called directly but not when it is called implicitly in the print queue? Does the print queue use a different gs? Best regards, Wolfgang Wolfgang SLANY mailto:wsi@dbai.tuwien.ac.at

2 1

Re: [m17n] usage of kinput2 and canna
by Mike Fabian 23 Jul '02

23 Jul '02

Bernhard Rulla <b.rulla(a)arcor.de> writes: > thanks for your support Mike. Although it > does not work fully, yet, I am at least able to > see some hiragana. :) > > What did I do: > > 1) I returned my system to German values, as > you advised in your last mail. > 2) I proceed, after booting, with the following > commands: > export XMODIFIERS="@im=kinput2" > LANG=ja_JP kinput2 -xim -kinput -canna & > LC_CTYPE=ja_JP kmail > > OK, then I can activate the XIM as before but > when I push Return, everything converts to > small squares. There are no question marks anymore, > because I changed the font to jis-fixed and activated > unicode for mails. > But still, in a mail that I try to write, I see only > nothing but squares. jis-fixed is not a unicode font. If you want to use jis-fixed, you should not activate the "Use unicode font for messages" checkbox, then the square boxes will disappear and you will see Japanese characters. jis-fixed is a font in jisx0208.1983-0 encoding, you will not be able to write German umlauts using that font.G To write German you have to switch back to a font which can display German umlauts. If you often write both, Japanese and German, having to switch fonts all the time will soon become tedious, than you may want to use a Unicode font which contains glyphs for both languages. For example the GNU-Unicode font is suitable for Japanese and German and it is already available on your machine, because it belongs to one of the YaST2 packages. In the font selection box of KDE2 (i.e. in the KMail setup), the GNU-Unicode font is listed as "unifont". If you want to use that font, please check that you have ":unscaled" appended to the relevant FontPath in /etc/X11/XF86config: FontPath "/usr/X11R6/lib/X11/fonts/uni:unscaled" without the ":unscaled", KDE2 may try to scale this font, which will be extremely ugly. Scaled bitmap fonts are always very ugly. Using the GNU-Unicode font for E-Mails will make both German and Japanese readable, but you have only one size available (16 pixel). On top of that, it is a proportional font and E-Mails don't look nice when proportional fonts are used (at least in my opinion). The efont-unicode package ftp://ftp.suse.com/pub/people/mfabian/8.0-noarch/efont-unicode.rpm will give you fonts in a few more sizes (12, 14, 16, 24 pixels) which are monospaced. Use these which are listed with family "biwidth" by xlsfonts: D13:~ # xlsfonts | grep "efont.*medium-r-normal--24" -efont-biwidth-medium-r-normal--24-240-75-75-p-120-iso10646-1 -efont-fixed-medium-r-normal--24-240-75-75-c-120-iso10646-1 -efont-fixed-medium-r-normal--24-240-75-75-c-240-iso10646-1 D13:~ # They appear in the font listing of KMail just as "biwidth". They have "-p-" in their XLFD which means "proportional" because the CJK characters in these fonts are twice as wide as the latin characters, i.e. technically these are not really monospaced fonts. But all latin characters have the same width and all CJK characters have the same width, i.e. for practical purposes in you e-mail composer you can consider them as monospaced fonts. The efonts listed with family "fixed" are pairs of fonts, the one with the smaller value in the average width field contains the latin characters only, the one with the bigger value in the avarage width field the CJK characters only. You need such pairs of fonts for xterm in UTF-8 mode to display CJK characters. For KMail you need the "biwidth" fonts which contain the whole Unicode range. For other sizes, you could use commercial TrueType fonts like Bitstream Cyberbit or MS Arial Unicode which cover almost everything of Unicode 2.0. But both are not free, both are proportional and Bitstream Cyberbit is also very ugly. Probably the fonts from the efont-unicode package are best for German and Japanese e-mail in KMail in KDE2. Or upgrade to Qt3/KDE3 (distributed with SuSE Linux 8.0), then you will have much more fonts to choose from, because in Qt3 you can combine fonts, you don't need to have one single Unicode font to cover everything. See also http://www.suse.de/~mfabian/suse-cjk/kde-font-setup.html > In mails which I received, however, I can identify some > hiragana, like in your signature. You write > something like XXXX ha i i XX no X da. I see the X > as squares. Maybe we can try a counter-test. Can you > read this? > 日本語は難しいですね。 > I wanted to write "Nihongo ha muzukashii desu ne." Yes, no problem. >> if you have installed xfntjp.rpm you should >> have a quite large selection of Japanese bitmap fonts. > > Obviously, I have not installed this. I looked for it on > rpmfind.org and found some quite large files (16MB), > so I backed away from downloading them. On the German edition of SuSE Linux 7.3 Professional, it is available on CD5: CD5/suse/j2/xfntjp.rpm > Maybe it is a must to do? It is not absolutely necessary, it just gives you some more Japanese bitmap fonts to choose from. The efont-unicode package is probably more interesting for you if you want to use German *and* Japanese in KMail of KDE2. It is also huge (27MB) and unfortunately it is not on the SuSE Linux 7.3 CD set, i.e. you need download it from the URL given above. >> If you want Anti-Aliasing, you can use the free Japanese >> TrueType fonts "Kochi Mincho" and "Kochi Gothic" fonts which >> are available as well on the SuSE Linux 7.3 CD set. > > In the first step, I am keen on seeing complete Japanese > text, anti-aliasing comes later. > I looked for these two fonts anyway but could not find them > on my SuSE CDs. Where do I have to look? CD5/suse/han1/ttf-kochi-gothic.rpm CD5/suse/han1/ttf-kochi-mincho.rpm If you use YaST2 to install additional package, you will find a 'search' button where you can enter 'xfntjp' or 'kochi'. -- Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

2 6

kwrite with kinput2 on SuSE8
by Ichiroh Takiguchi 03 Jul '02

03 Jul '02

Hello, I used kwrite with kinput2 on SuSE7.2. Currently, I'm using SuSE8, but I cannot input any Japanese character on kwrite by using kinput2. On kedit, I can input Japanese characters with kinput2, but preedit string is not displayed on the screen. Do you know something about it? ------ Ichiro Takiguchi IBM Japan Ltd.

2 1

Problem with xkb
by cr0acker 23 Jun '02

23 Jun '02

I have configured xkb! But it seems tht it dose nte work! I have attache XF86Config file to this letter please letter i am using Gnome and IceWM

1 0

Lyx and Turkish Utf-8 locale
by Togan Muftuoglu 21 Jun '02

21 Jun '02

Hi, Looks like I hit another software which does not like me. :-( toganm@earth:~> locale LANG=tr_TR.UTF-8 LC_CTYPE="tr_TR.UTF-8" LC_NUMERIC="tr_TR.UTF-8" LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY="tr_TR.UTF-8" LC_MESSAGES=en_US LC_PAPER="tr_TR.UTF-8" LC_NAME="tr_TR.UTF-8" LC_ADDRESS="tr_TR.UTF-8" LC_TELEPHONE="tr_TR.UTF-8" LC_MEASUREMENT="tr_TR.UTF-8" LC_IDENTIFICATION="tr_TR.UTF-8" LC_ALL= When I have Lyx started the menu comes completely emtpy and here is the Lyx yelling out LyX: menubar::read: Unknown menu tag: `Item' [around line 28 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `New...|N' [around line 28 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `buffer-new' [around line 28 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `Item' [around line 29 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `New from Template...|T' [around line 29 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `buffer-new-template' [around line 29 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `Item' [around line 30 of file /usr/share/lyx/ui/default.ui] LyX: menubar::read: Unknown menu tag: `Open...|O' [around line 30 of file /usr/share/lyx/ui/default.ui] ........ ................ LyX: Toolbar::read: Unknown toolbar tag: `Icon' [around line 310 of file /usr/share/lyx/ui/default.ui] LyX: Toolbar::read: Unknown toolbar tag: `copy' [around line 310 of file /usr/share/lyx/ui/default.ui] LyX: Toolbar::read: Unknown toolbar tag: `Icon' [around line 311 of file /usr/share/lyx/ui/default.ui] I have started Lyx with LC_ALL=en_US.UTF-8 then the menu draw is complete yet the keyboard does not function ( I mean Scedilla (Ş) comes out as degree) I chang default language to Turkish <-> English keyboard null <->turkish<-> english but no Any ideas -- Togan Muftuoglu Unofficial SuSE FAQ Maintainer http://dinamizm.ath.cx

2 5

Bengali, construction of RPMs for SuSE and RPM search tools
by David Fong 21 Jun '02

21 Jun '02

Dear Mark and m17n list members, Are there any SuSE rpms for Bengali? If not, I might try to construct them myself but.... ...is there a 'RPM construction for dummies' instruction list out there? One of the strengths of Mandrake (shhhh!) is the Cooker, where users submit all kinds of RPMs. It would be nice if SuSE had something similar, although I know SuSE is more concerned about stability; and stability is one reason why I use SuSE rather than Mandrake. Also, does SuSE have a tool to search its various archives for RPMs, such as in your directories, Mark? rpmfind.net does not seem list many RPMs which are in the SuSE distribution. Cheerio, David. -- Dr.David.Fong(a)medical.net.au --- Ivanhoe, 3079, Victoria, Australia. http://www.users.bigpond.com/vkelim --- ICQ and PGP available SuSE Linux 8.0

2 3

kinput2 v3.0 package for SuSE Linux 8.0
by Mike Fabian 20 Jun '02

20 Jun '02

SuSE Linux 8.0 contains kinput2-v3.1beta3 and IBMJava2-SDK-1.3 which don't work well together. If you need to do Japanese input with kinput2 when using IBMJava2-SDK-1.3, it is recommended to downgrade to kinput2-v3 which is available here: ftp://ftp.suse.com/pub/people/mfabian/8.0-i386/kinput2-v3-0.i386.rpm ftp://ftp.suse.com/pub/people/mfabian/8.0-src/kinput2-v3-0.src.rpm All other applications except Java work well with kinput2-v3.1beta3, i.e. you only need to downgrade if using kinput2 with Java is important to you. -- Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

1 0

Suse 8.0: Japanese printing problem?
by Wolfgang Slany 19 Jun '02

19 Jun '02

Since updating to suse 8.0 the following problem appeared: I cannot print Japanese pages from netscape (nor mozilla): only bakemoji result. Printing to file and inspecting the file via gv on the screen works fine, but printing the same file via gv results in the same bakemoji output. Printing Japanese pages from konqueror (with option embed fonts) works OK (though konqueror has some other problems when printing Japanese, i.e., the characters are printed but there is no space between them, and often characters are overwritten with the following text etc). Print command in all cases was lpr. Cjk-LaTeX postscript prints fine. Could it be that the update reset the print filter so that lpr since then can print only embedded fonts? Any fix for this known? Best regards, Wolfgang Wolfgang SLANY mailto:wsi@dbai.tuwien.ac.at

2 1

missing packages in 8.0 FTP version
by Mike Fabian 19 Jun '02

19 Jun '02

1 1