[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:14402] Re: groff Japanese support breaks PS output for latin2
ä½é‡Žï¼ 浜æ¾ã§ã™ã€‚
groff-ml ã«ä¹…ä¿ç”°ã•ã‚“ãŒå‡ºã•ã‚ŒãŸ request ã«å¯¾ã™ã‚‹å›žç”ãŒ
æµã‚Œã¦ã¾ã—ãŸã。
ã™ããªãã¨ã‚‚ã€ã“ã¡ã‚‰ãŒå‡ºã—ãŸè¦æœ›ã«å¯¾ã—ã¦ã€ã™ãã«è¿”事をãれる
点ã¯ã€groff ã® upstream ãŒåˆ©ç”¨è€…を無視ã—ã¦ã„ã‚‹ã‚ã‘ã§ã¯ãªã„ã¨
ã„ã†ã“ã¨ã‚’示ã—ã¦ã„ã‚‹ã‚ã‘ã§ã€ã‚ã‚ŠãŒãŸã„ã¨æ€ã„ã¾ã™ã€‚
ãªã‹ãªã‹ãã“ã§ã™ãã«åå¿œã—ã¦è°è«–ã«æŒã£ã¦ã„ãã“ã¨ãŒã§ããªã„ã®ãŒ
ツライã¨ã“ã‚ã§ã¯ã‚ã‚Šã¾ã™ãŒã€‚
In <87n168yjuo.wl@xxxxxxxxxxxxxxxxxxxxx>,
on "Fri, 13 Jul 2001 23:32:59 +0900',
with "[debian-devel:14394] Re: groff Japanese support breaks PS output for latin2",
Tomohiro KUBOTA <tkubota@xxxxxxxxxxx> ã•ã‚“ wrote:
> ã“ã‚“ã°ã‚“ã¯ã€‚ä¹…ä¿ç”°ã§ã™ã€‚
ãŠä¸–話ã«ãªã£ã¦ãŠã‚Šã¾ã™ã€‚
> > ã¾ã‚ã„ãšã‚Œã«ã—ã‚ã€ãƒ¡ãƒ³ãƒ†ãƒŠã® Colin Watson ã«ç›¸è«‡ã—ã¦ã¿ã‚‹å¿…è¦ã¯
> > ã‚ã‚‹ã‹ã‚‚。
>
> ãã‚Œãªã‚“ã§ã™ãŒã€groff 㯠base system ã ã‹ã‚‰ãƒ•ãƒªãƒ¼ã‚ºãŒã™ãã ã‹ã‚‰
> æ—©ããªã‚“ã¨ã‹ã—ã¦ãã‚Œã€ã¨ã„ã†ãƒ¡ãƒ¼ãƒ«ã‚’個人的ã«ã‚‚らã„ã¾ã—ãŸã€‚
ãã†ã„ãˆã° woody ã®ãƒ•ãƒªãƒ¼ã‚ºã£ã¦ã‚‚ã†å§‹ã¾ã£ã¦ã„ã‚‹ã‚“ã§ã™ã‚ˆã。
> Colin Watson ã•ã‚“ã¯ã€é€±æœ«ã¯å¤–出ã—ã¦ã€æ¥é€±ã«ãƒ‘ッãƒã‚’検討ã—ã¦ã¿ã‚‹ã¨ã®
> ã“ã¨ã ãã†ã§ã™ã®ã§ã€åˆ¥è§£ã®å®Ÿè£…を考ãˆã¦ã„らã£ã—ゃる方ãŒã„ã¾ã—ãŸã‚‰ã€
> ç§ã‹ã‚‰ã§ã‚‚ã„ã„ã§ã™ã—ã€ç›´æŽ¥ã§ã‚‚ã„ã„ã¨æ€ã„ã¾ã™ãŒã€ãã®æ„æ€ã‚’ä¼ãˆã¦
> ãŠã„ãŸã»ã†ãŒã„ã„ã¨æ€ã„ã¾ã™ã€‚
鵜飼ã•ã‚“パッãƒã«ã¤ã„ã¦ã‚‚ Colin ã«è¦é€£çµ¡ and/or BTS report ã‹ãª ?
> > ãŸã ã®åˆ©ç”¨è€…ã¨ã—ã¦ã€Œæ—¥æœ¬èªžå‡ºãªã„ã®ã¯å›°ã‚‹ã‹ã‚‰æ—©ããªã‚“ã¨ã‹
> > ã—ã¦ãã‚Œã€ã¨é¨·ãã ã‘ãªã‚‰ã§ãã‚‹ã‹ã‚‚ã—ã‚Œã¾ã›ã‚“ãŒã€æ„味ã®ã‚ã‚‹
> > 効果ãŒå¾—られるã‹ã©ã†ã‹ã€ç–‘å•ã ã—。
>
> groff ML ã«ä½é‡Žã•ã‚“ã®ãƒ¡ãƒ¼ãƒ«ãŒæµã‚Œã¦ã„ã¾ã—ãŸã。
直接ã®å½¹ã«ã¯ç«‹ã¡ã¾ã›ã‚“ãŒã€ã¨ã‚Šã‚ãˆãšä½•ã‚‚ã—ãªã„よりã¯ãƒžã‚·ã‹ãªã€ã¨ã€‚
> ç§ã‚‚日本語パッãƒã‚’ã¨ã‚Šã„ã‚Œã¦ãã‚Œã€ã¨ãƒ¡ãƒ¼ãƒ«ã‚’出ã—ã¦ãŠãã¾ã—ãŸã€‚
> Werner LEMBERG ã•ã‚“ãŒã€æ—¥æœ¬èªžãƒ‘ッãƒã®ã“ã¨ã‚’ã©ã†åˆ¤æ–ã™ã‚‹ã‹ã€
> ãã‚Œã¯ã‚ã‹ã‚Šã¾ã›ã‚“ãŒã€‚。。
ã¨ã‚Šã‚ãˆãšè¿”事をã“ã¡ã‚‰ã«è»¢é€ã—ã¾ã™ã€‚
Date: Sun, 15 Jul 2001 17:23:25 +0200 (CEST)
To: tkubota@xxxxxxxxxxx
Cc: groff@xxxxxxxx
Subject: Re: [Groff] Problems with unwanted unicode.
From: Werner LEMBERG <wl@xxxxxxx>
> > I'm going to fix this for groff 2.0 by implementing Unicode,
> > separating input and output encoding, but it won't be a quick
> > development process...
>
> Then, could you think about tentatively integrate Japanese patch
> into official version of Groff?
I would really like to avoid it. Main reason is that the Japanese
patch basically bypasses the way how groff processes input. It
doesn't extend the structures by making it 32bit-aware but adds new
variables instead.
Another problem is how to handle fonts in groff. It seems that we
have to extend the current font file syntax to allow ... what exactly?
Please make suggestions. Some ideas:
. Glyph classes. We'll need that for defining CJK metrics and kerns
in a compact way.
. Subfonts. [I don't mean the splitting of a large font into
entities with, say, 256 glyphs each.] Using a single Unicode font
is nonsense. Instead, groff should provide a means to group fonts
into Unicode blocks. If a new font is registered, it sets some
flags to indicate which block is covered. A mechanism to provide
a fallback font is neeed also. It could also be used for the
other way round: Registering a huge font as many subfonts makes
the loading much faster.
. Interaction between fonts to implement effects like kinsoku shori
(i.e., less space between a CJK and non-CJK character than between
two non-CJK characters). It's not completely clear to me how to
achieve that in a simple way.
What else?
Werner
ç¦å‰‡å‡¦ç†ã®ä»¶ã¯éµœé£¼ã•ã‚“パッãƒã§å—ã‘入れã¦ã‚‚らãˆã‚‹å½¢ã«ãªã£ãŸã®ã‹ãª ?
Glyph class ã‚„ subfont ã®è©±ã¯ã€Unicode ã§ã®å•é¡Œã¨ã—ã¦æŒ™ã’られã¦ã„ã‚‹
ã‚‚ã®ã«ã‚る程度対応ã§ãã‚‹æž çµ„ã¨ã—ã¦è€ƒãˆã‚‰ã‚Œã¦ã„ã‚‹ã‚“ã§ã—ょã†ã‹ã€‚
(ã“ã®ã¸ã‚“㯠(æŸå¸«åŒ ã«ã¯å±ã‚‰ã‚Œãã†ã ã‘ã©) ã„ã¾ã ã«ã‚ˆãã‚ã‹ã£ã¦ãªã„)
> エンコーディングã¾ã‚ã‚Šã«é–¢ã—ã¦ã¯ã€ãªã‹ãªã‹é€²ã¾ãªã„ã‘ã© UTF-8
> 計画ãŒã‚ã‚Šã¾ã™ãŒã€è¨€èªž/用å—ç³»ã”ã¨ã«å€‹åˆ¥ã®ã‚¿ã‚¤ãƒ—セットã®ãƒ«ãƒ¼ãƒ«ãŒ
> å¿…è¦ (ã¤ã¾ã‚Šè¨€èªžã”ã¨ã®å€‹åˆ¥ã®å‡¦ç†ãŒå¿…è¦) ã¨ã„ã†ã“ã¨ã¯ã‚¨ãƒ³ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã‚’
> ãªã«ã«ã™ã‚‹ã‹ã€ã¨ã„ã†ã“ã¨ã¨ã¯ç‹¬ç«‹ã—ãŸå•é¡Œã§ã™ã®ã§ã€ã“ã®ã¸ã‚“ã¯
> 日本語パッãƒã‹ã‚‰ã‚¨ãƒƒã‚»ãƒ³ã‚¹ã‚’æ±²ã¿å–ã£ã¦ã»ã—ã„ã¨ã“ã‚ã§ã™ã€‚
言語ã«é–¢ã™ã‚‹å‡¦ç†ã¯ç’°å¢ƒå¤‰æ•°ã‚’見るよã†ã«ã™ã‚‹ã€ã¨ã„ã†è©±ãŒã€ç§ã®å‡ºã—ãŸ
è¦æœ›ã«å¯¾ã™ã‚‹è¿”事ã«æ›¸ã‹ã‚Œã¦ã¾ã—ãŸã。
> I had seen some mails about future plan of groff on this list. How
> do they go now? Any progress?
No progress yet, sorry. I have still a lot of bug fixes to apply to
the 1.17 series which takes almost all my time.
> If groff can't handle an encoding for a language, then users who
> need the manpages in that language can't have the working online
> manuals in the system, and it is critical defect for beginners.
If you have followed the discussion about the pre- and postprocessors
to convert anything to and from Unicode, you already know the solution
we've found and which will be eventually implemented.
> Currently, we (Japanese Debian developers) have discussion on the
> way to handle this problem, and two approache is considered.
>
> A) add the new groff command line option for encoding
> A-1) unify terminal device type from ascii/ascii8/latin1/
> nippon/utf8 into tty (maybe), and add the new option
> to switch various encodings.
>
> A-2) simply add the switch for euc-jp encoding (--eucmode)
> The patch for this has been already provided.
>
> B) add the new roff command such as ".x-encoding EUC-JP"
> for input encoding switch. With this approache, users
> do not need to specify the appropriate option for various
> encodings, since groff can handle them automatically
> according to the document (input file) itself.
>
> [...]
>
> But anyway some method to specify the encoding is required for
> pre-processor, isn't it? And if so, then which way is prefered,
> A or B above, or something else?
Both methods. First, groff will look into the environment, checking
the locale. Then there will be two command line options to select the
input and output encoding, overriding the environment. Finally, there
will be an Emacs-like syntax comment (`-*- coding: ... -*-') at the
beginning of the file itself to override the input encoding.
ã“ã®éƒ¨åˆ†ã€‚環境変数㧠locale ã‚’ãƒã‚§ãƒƒã‚¯ã—ã¦ã€æ¬¡ã«ã‚³ãƒžãƒ³ãƒ‰ãƒ©ã‚¤ãƒ³
オプションã§å…¥åŠ›ãŠã‚ˆã³å‡ºåŠ›ã®ã‚¨ãƒ³ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã‚’ãƒã‚§ãƒƒã‚¯ (環境
変数ã«ã‚ˆã‚‹æŒ‡å®šã‚’ override) 最終的ã«æ–‡æ›¸å†’é ã® Emacs 風ãªã‚³ãƒ¡ãƒ³ãƒˆã§
入力エンコーディングを override ã™ã‚‹ã€ã¨ã€‚
鵜飼ã•ã‚“ãŒãŠã£ã—ゃã£ã¦ã„ãŸå‡¦ç†çµŒè·¯ãŒè¤‡æ•°ã‚ã‚‹ã¨ã„ã†å•é¡Œã¯ã€
「将æ¥è¨ˆç”»ã€ã§ã¯ preprocessor を最åˆã«ã‹ã¾ã›ã‚‹ã¨ã„ã†æž 組ã§
解決ã™ã‚‹äºˆå®šãªã®ã‹ãª ?
よãã‚ã‹ã£ã¦ã¾ã›ã‚“ãŒã€ç¾çŠ¶ã® groff ã«éƒ¨åˆ†çš„ã« preprocessor ã‚’
入れã¦ã—ã¾ã†ã¨ã„ã†ã“ã¨ã¯ã§ããªã„ã‚‚ã®ã§ã—ょã†ã‹ ? ãã®å ´åˆ pre
processor ã®å½¹å‰²ã¨ã„ã†ã‹æ„味ã¯æœ¬æ¥ã®ã‚‚ã®ã¨ã¯ã¡ã‚‡ã£ã¨ç•°ãªã£ã¦ãã¦
ã—ã¾ã„ã¾ã™ãŒã€ãれを入れるã“ã¨ã§ç¾çŠ¶ã®ãƒ‡ã‚¶ã‚¤ãƒ³ã§ã‚‚ã‚る程度å„国語ã®
è¦æ±‚ã™ã‚‹å‡¦ç†ã«å¯¾å¿œã§ãるよã†ã«ãªã‚‹ã®ã§ã‚ã‚Œã°ã€push ã—ã¦ã¿ã‚‹ä¾¡å€¤ã¯
ã‚ã‚‹ã‹ã‚‚。
> Request from users: If ascii and latin1 will remain for backward
> compatibility, then please add "nippon" device as well. It is used
> for years, and there are many programs (including XFree86 doctools)
> which use it for support of Japanese documents. If you cut off it,
> then you will cut off many users at once.
I think that it shouldn't be too difficult to integrate it as soon as
Unicode support is here.
Werner
ã¨ã«ã‹ãã€(ã©ã‚Œã ã‘å…ˆã«ãªã‚‹ã‹ã¯ã€æˆ‘々をå«ã‚ãŸé–‹ç™ºã™ã‚‹å´ã®
努力次第ã§ã™ãŒ) å°†æ¥çš„ã«æ—¥æœ¬èªžã‚µãƒãƒ¼ãƒˆã‚‚å«ã‚ã‚‹ã“ã¨ã ã‘ã¯
以å‰ã‹ã‚‰æ˜Žç¢ºã«è¡¨æ˜Žã—ã¦ãã‚Œã¦ã„ã‚‹ã®ã§ã€ãã“ã¯ã‚ã‚ŠãŒãŸã„ã¨
æ€ã£ã¦ã¾ã™ã€‚
> > ãã†ã„ãˆã°ã“ã‚Œã«é–¢é€£ã—㟠groff ã® bug report 㯠Debian BTS ã«
> > 出ã¦ã„ã‚‹ã‚“ã§ã—ょã†ã‹ ? ã¾ã 確èªã—ã¦ãªã„ã®ã§ã™ãŒã€‚
>
> 出ã¦ã„ãªã„よã†ã§ã™ã。
ã‚‚ã—ã‹ã—ãŸã‚‰å¿µã®ãŸã‚ã«å‡ºã—ã¦ãŠãå¿…è¦ã‚ã‚‹ã‹ã‚‚ ? base freeze ã®ã‚«ãƒ©ãƒŸã§ã€‚
--
# (ã‚ãŸã—ã®ãŠã†ã¡ã¯æµœæ¾å¸‚ã€ã€Œå¤œã®ãŠè“åã€ã§æœ‰åã•ã€‚)
<kgh12351@xxxxxxxxxxx> : Taketoshi Sano (ä½é‡Žã€€æ¦ä¿Š)