Bug#1069705: lilypond man-page has defective link on Debian
> on https://manpages.debian.org/testing/lilypond/abc2ly.1.en.html is a > reference to the abc standard applicable for this software. The related > sentence is > > "abc2ly converts ABC music files (see > http://abcnotation.com/abc2mtex/abc.txt) to LilyPond input." > > The correct link is "http://abcnotation.com/abc2mtex/abc.txt; which > leads the reader to a wiki page and a text file. `abc2ly`'s man page of LilyPond's development version gets created with `help2man` version 1.47.4, which gives ``` abc2ly converts ABC music files (see https://abcnotation.com/standard/abc_v1.6.txt) to LilyPond input. ``` > On Debian the link is "http://abcnotation.com/abc2mtex/abc.txt)". I guess that the Debian people use another version of `help2man` that tries to convert URLs like the above to real hyperlinks, and that this version uses a regular expression that accepts `(` and `)` as part of URLs. While this is technically correct, it might fail for situations like the one under discussion where a human reader can easily deduce that the final, closing parenthesis is actually *not* part of the URL. Anyway, I've fixed this in LilyPond's git repository. https://gitlab.com/lilypond/lilypond/-/merge_requests/2309 Werner
Bug#131137: [ft-devel] manual pages for freetype2-demos
Here is another one, for freetype-config. Committed, thanks! Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#131137: [ft-devel] manual pages for freetype2-demos
Please find attached some minimal draft man pages, mainly based upon the usage output of the various tools. Any kind of feedback/review is appreciated since I hardly know anything about freetype, and whether you are interested in adding man pages upstream at all. I've now committed revised and updated versions of the man pages. Please check. Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#131137: [ft-devel] manual pages for freetype2-demos
Please find attached some minimal draft man pages, mainly based upon the usage output of the various tools. Any kind of feedback/review is appreciated since I hardly know anything about freetype, and whether you are interested in adding man pages upstream at all. Thanks for the man pages, I'll check and eventually add them to the ft2demos bundle. I'm not too happy that distributions like Debian publish all of the FreeType demo programs (for example, `ftgamma' has essentially no real use); maybe this can be improved somehow. Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635382: [tex-live] new release of latex-unicode
I wonder whether it is sensible to always call the package “ucs”, in particular, to rename the directory on CTAN from “unicode” to “ucs”. Is this possible and feasible? What do you think? +1 Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635382: [tex-live] new release of latex-unicode
I have no idea what this change was for. And while I have found references to \OHORN, \ohorn, \UHORN, and \uhorn in The Comprehensive LateX Symbol List, I haven’t found references to \horn. So maybe, it is best if I just revert this change. `\horn' is a virtual accent used in t5enc.def (in the vntex bundle). Werner
Bug#635382: [tex-live] new release of latex-unicode
So is it okay for ucs to map the Unicode horn characters to \horn O, \horn o, \horn U, and \horn u, as it is done currently? I think so, yes. No time to actually check it. Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
The only thing which I consider bad is that there is `(' at the
line end. Can this be improved by adjusting the calls to .cflags?
Hmm, I tried to add `(' to CJKpostpunct class, but it did not help.
リストでは合計実行時間、呼び出し回 数、そのルーチン自身で消費した時間 (
Groff adds a space between (non-punct) Japanese characters instead
of breaking the line. The expected result would be something like:
リストでは合計実行時間、呼び出し回数、そのルーチン自身で消費した時間
(...
or:
リストでは合計実行時間、呼び出し回数、そのルーチン自身で消費した時
間 (...
Perhaps assigning IGNORE_HCODE to whole CJK range is not perfectly
enough to control the line breaking rule.
I should have activated my brain before asking such questions :-)
Here are my observations.
. Attached you can find an improved version of the Japanese
`gprof.1' man page (I'm calling it `gprofx.1' for convenience).
Note the many backslashes at the end of lines to suppress unwanted
spaces caused by newline characters. Alternatively, it might be
useful to have long lines to avoid linebreaks at all. Most
editors provide automatic line breaking anyways.
In groff, there is nothing similar to a `CJK*' environment (as
provided by my CJK package for LaTeX) to handle suppression of
unwanted spaces automatically. It would need more cflags trickery
(with new values) to emulate this behaviour since groff doesn't
know the concept of active characters.
. Formatting the improved man page, you get a lot of warning
messages like
gprofx.1:45: warning [p 1, 2.2i]: cannot adjust line
This gets much better if you ensure that the indented part of the
main page (which is the majority of text) has an even number of
characters so that the double-width CJK characters fit exactly.
Try, for example, this:
groff -Keuc-japan -Tutf8 -rIN=8n \
-ww -man -mja gprofx.1 gprofx.txt
and the number of warnings decreases from 15 to only 4 (output
attached). I strongly suggest to add something like this to the
Japanese locale configuration for man.
. To get really rid of the warnings, and to improve formatting CJK
stuff in general, we need inter-character glue between CJK
characters. Without that, groff produces too short lines (it then
emits the `cannot adjust line' warning). This is a TODO.
An alternative is to add `.ad l' for Japanese manpages.
. To come back to the abovementioned problem of `(' in the original
output of `gprof.1', this isn't solvable at all with the current
set of cflags: The problem is conflicting cflags values: The
character right after the open parenthesis, `ミ', has value 66,
which means
lines can be broken before the character (regardless of the
hcode values of the surrounding characters)
What ever cflags value I set for `(', the value `66' of `ミ'
inserts a breakpoint, causing a line break right before the
character.
I've now implemented three new cflags values, completely
independent of hcode values:
don't break before character but allow break after: 128
don't break after character but allow break before: 256
allow break before and after character: 512
which are handled internally similar to kern pairs so that the new
`inter_char_space_node'[1] sees the cflags values of both the left
and right character to decide whether there should be a zero-width
break inbetween. I've also updated ja.tmac accordingly.
Please test.
Werner
[1] Contrary to its name, inter-character spacing isn't yet
implemented. As soon as it is, value 512 becomes `allow
inter-character breaks and insert stretchable space'; this should
eventually fix all line adjust warnings.
.\ Copyright (c) 1983, 1990 The Regents of the University of California.
.\ All rights reserved.
.\
.\ Redistribution and use in source and binary forms are permitted provided
.\ that: (1) source distributions retain this entire copyright notice and
.\ comment, and (2) distributions including binaries display the following
.\ acknowledgement: ``This product includes software developed by the
.\ University of California, Berkeley and its contributors'' in the
.\ documentation or other materials provided with the distribution and in
.\ all advertising materials mentioning features or use of this software.
.\ Neither the name of the University nor the names of its contributors may
.\ be used to endorse or promote products derived from this software without
.\ specific prior written permission.
.\ THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
.\ WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\
.\ @(#)gprof.1 6.6 (Berkeley) 7/24/90
.\
.\ Japanese Version Copyright (c) 1997-2000 NAKANO Takeo all rights reserved.
.\ Translated Fri Jan 9 1998 by NAKANO Takeo nakano@@apm.seikei.ac.jp
.\ Updated Fri 27
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
Any progress on the docs?
Please find below a patch to the docs. Sorry for the delay.
Thanks! I've revised all patches, updated the documentation,
normalized the import of gnulib's wcwidth, fixed a buglet in the new
`.class' request (each call caused insertion of an empty line), and it
seems that everything works fine!
Attached is a Japanese man page, gprof.1 – this is in EUC-JP
encoding –, which I've taken from the Japanese man page project
(http://sourceforge.jp/projects/linuxjm/), together with its output,
generated with
groff -K euc-japan -Tutf8 -ww -man -mja gprof.1 gprof.jp.txt
(You should use `less' or something similar for display since the
output contains SGR escape sequences.)
The only thing which I consider bad is that there is `(' at the line
end. Can this be improved by adjusting the calls to .cflags?
Werner
.\ Copyright (c) 1983, 1990 The Regents of the University of California.
.\ All rights reserved.
.\
.\ Redistribution and use in source and binary forms are permitted provided
.\ that: (1) source distributions retain this entire copyright notice and
.\ comment, and (2) distributions including binaries display the following
.\ acknowledgement: ``This product includes software developed by the
.\ University of California, Berkeley and its contributors'' in the
.\ documentation or other materials provided with the distribution and in
.\ all advertising materials mentioning features or use of this software.
.\ Neither the name of the University nor the names of its contributors may
.\ be used to endorse or promote products derived from this software without
.\ specific prior written permission.
.\ THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
.\ WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\
.\ @(#)gprof.1 6.6 (Berkeley) 7/24/90
.\
.\ Japanese Version Copyright (c) 1997-2000 NAKANO Takeo all rights reserved.
.\ Translated Fri Jan 9 1998 by NAKANO Takeo nakano@@apm.seikei.ac.jp
.\ Updated Fri 27 Oct 2000 by NAKANO Takeo
.\
.TH GPROF 1 January 29, 1993
.SH 名前
gprof \- コール・グラフ (call graph) のプロファイルを表示する
.SH 書式
.B gprof [ \-abcsz ] [ \-e|\-E
.I name
.B ] [ \-f|\-F
.I name
.B ]
.B [ \-k
.I fromname toname
.B ] [
.I objfile
.B [
.I gmon.out
.B ]
.B ]
.SH 説明
.B gprof
は C, Pascal, Fortran77 プログラムの実行プロファイルを生成する。呼び出
されたルーチンの値は呼び出し元に取り込まれる。プロファイルのためのデー
タはコール・グラフ (call graph: 関数コールの親子関係のグラフ) のプロファ
イルデータファイル (デフォルトでは `gmon.out') から取り
込まれる。このファイルは
.BR cc ( 1 ) 、
.BR pc ( 1 ) 、
.BR f77 ( 1 )
で
.B \-pg
オプションを指定してコンパイルされたプログラムによって作成される。
.B \-pg
オプションでは、リンクされるライブラリもプロファイル用にコンパイルされ
たものになる。
.B gprof
は指定されたオブジェクトファイル (デフォルトは `a.out') からシンボ
ルテーブルを読み、これと `gmon.out' のコール・グラフ・プロファイルとを
関連付ける。
複数のプロファイルデータファイルが指定された場合には、
.B gprof
はそれらのプロファイル情報をすべて合計して表示する。
.PP
.B gprof
はそれぞれのルーチンによって消費された時間を計算する。次にこれらの時間
をコール・グラフの枝に沿って親ルーチンへと伝播させる。プログラムの
サイクル (cycle: 再帰呼び出しの循環) をまとめ、サイクルへのコールを行っ
たルーチンは、サイクルで消費した時間を共有するとみなす。最初のリストは
関数で、消費時間の順にソートされている。
消費時間にはコール・グラフでの子孫の分も含まれる。それぞれの関数エントリ
の下には、その関数のコール・グラフでの (直接の) 子と、そこで消費された
時間がどのように関数に伝播したかが表示される。同様の表示は関数の上にも
表示されており、その関数とそれらの子孫で消費された時間がどのようにコー
ル・グラフの (直接の) 親へ伝播するかが示される。
.PP
サイクルも表示される。サイクル全体としてのエントリ、そのサイクルに属す
るメンバーのリストとそれぞれのメンバーによって消費された時間、その
サイクルの呼び出し回数などが表示される。
.PP
次にフラットプロファイル
.RB ( prof (1)
の結果と似たもの) が与えられる。このリストでは合計実行時間、呼び出し回
数、そのルーチン自身で消費した時間 (ミリ秒単位)、子孫の分も含めて消費
した時間 (ミリ秒単位) が表示される。
.PP
最後に関数名の索引が与えられる。
.SH オプション
以下のオプションが指定できる:
.TP
.B \-a
スタティックに宣言された関数を表示しない。このオプションが指定され
ると、スタティックな関数に関する全ての情報 (実行時間、他の関数の呼び出
し、他の関数から呼び出される関係など) は、ファイル `objfile' 中でこの
スタティックな関数の直前にロードされた関数に属することになる。
.TP
.B \-b
プロファイルのそれぞれのフィールドに関する説明を表示しない。
.TP
.B \-c
プログラムのスタティックなコール・グラフを、オブジェクトファイルのテキ
ストセグメントを調べるという発見的 (heuristic) な手法で作成する。ス
タティック・コールだけの親や子の呼び出し回数は 0 として表示する。
.TP
.BI \-e name
ルーチン
.I name
と、その子孫すべてに関するグラフプロファイルのエントリを表示しない
(子孫に関しては、別の祖先がいれば表示される)。
.B \-e
オプションは複数回指定できる。一つの
.B \-e
オプションについて指定できる
.I name
は一つだけである。
.TP
.BI \-E name
.B \-e
と同様にルーチン
.I name
とその子孫に関するグラフプロファイルのエントリを表示しない。また
.I name
(とその子孫) によって消費された時間も、プログラム実行の総時間 (および
パーセンテージの計算) から除かれる。例えば
.BI \-E mcount
.BI \-E mcleanup
はデフォルトになっている。
.TP
.BI \-f name
ルーチン
.I name
とその子孫に関してのみ、グラフプロファイルのエントリを表示する。
.B \-f
オプションは複数回指定できる。一つの
.B \-f
オプションについて指定できる
.I name
は一つだけである。
.TP
.BI \-F name
.B \-f
と同様に、ルーチン
.I name
とその子孫に関してのみ、グラフプロファイルのエントリを表示する。またこ
れらによって用いられた時間だけを合計の実行時間とパーセンテージの計算に
用いる。
.B \-F
オプションは複数指定できる。一つの
.B \-F
オプションについて指定できる
.I name
は一つだけである。
.B \-F
オプションは
.B \-E
オプションによる設定を上書きする。
.TP
.BI \-k fromname toname
ルーチン
.I fromname
からルーチン
.I toname
までの枝を削除する。これは不要なサイクルの循環を破壊するのに便利である。
.B \-k
は複数指定できる。一つの
.B \-k
オプションに対して指定できるのは一組のルーチン名だけである。
.TP
.B \-s
プロファイルファイル `gmon.sum' を作成し、指定したプロファイルファイル
の情報すべてからのプロファイル情報を総計したものを書き込む。この合計プ
ロファイルファイルは後に gprof を (おそらくは
.B \-s
と共に) 実行する際に与えて、 `objfile' ファイルを複数回実行して得られ
たプロファイルデータを累積するために用いることもできる。
.TP
.B \-v
gprof のバージョン番号を表示して終了する。
.TP
.B \-z
用いられなかった関数 (呼び出し回数と実行時間でわかる) も表示する。これ
を
.B \-c
オプションと共に用いると、呼び出されなかったルーチンを見つけるのに役
に立つ。
.PP
.SH ファイル
a.out
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
Any progress on the docs? Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
the `classes' keyword for font files, ... What is the keyword supposed to work? I didn't notice that since it is currently not used in any font file and seems not to affect the run-time behavior. Perhaps a wreck of the original patch? The `classes' keyword should help reduce the size of non-TTY font description files of CJK fonts: Instead of thousands of lines in the `charset' section for glyphs from the CJK range(s), you just have a single one, something like classes [CJK] u4E00-u9FFF charset ... [CJK] 1000,800,200 3 ? ? However, the two question marks indicate that I don't know how to handle those fields. Perhaps it should be something like [CJK] 1000,800,200 3 %d uni%X to programmatically derive the index value for \N'...' (field 4) and the PS glyph name for grops (field 5), but this isn't implemented yet. So please ignore the `classes' keyword documentation; I'll remove the corresponding code, to be postponed for later. Alternatively, you might add the missing bits right now :-) Besides that, it is an interesting question how to support Japanese fonts for CJK characters. In my CJK package for LaTeX, I've used active characters to activate CJK fonts for CJK characters. For groff, the probably easiest method is to register, say, a Japanese font as `special' using either `.fspecial' or `.special'. Then any glyph not found in the current (latin) font is taken from the fspecial or special list. Note that I can't remember how this has been solved in the old Debian extension for Japanese... I'm now trying to extend current ja.tmac to support Chinese and Korean: http://ueno.fedorapeople.org/groff/make-cjk-tmac/ Very nice! Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
(CCing Daiki Ueno and the groff list, since I have some comments on the patch and this is a convenient hook for them.) I received a patch from him and tested. It worked well, particularly for Japanese and Korean. As far as my tests, it won't break any other languages (tested with C, fr_FR.UTF-8, nl_NL.UTF-8, and ru_RU.UTF-8.) Here is a debdiff against 1.20.1-10. Right now I'm going to integrate and test the patches. However, a very important piece is still missing: documentation! I won't commit the changes otherwise. Please provide a patch for groff.texinfo which fully documents `.class' (probably by adding a new section `Classes' to `Fonts and Symbols'), the `classes' keyword for font files, and a proper extension of the description of the `.cflags' request. Similarly, I need updates to the `NEWS', `groff_diff.man', and `groff.man' files. BTW, this can be rough and sketchy: There's no need to polish the documentation since I'll do this. Note that I don't need ChangeLog entries; I've written them already by myself while reading the code. - nroff: supply -mja to groff if running under Japanese locales. We should be trying to reduce the cases where Japanese is handled uniquely, particularly in code rather than in configuration such as macro files, and this change introduces one. Furthermore, relying on the locale is a problematic approach we should be trying to escape, as it makes it harder to test Japanese pages in English locales or vice-versa. I second that; it's not necessary to do that so I'll omit these changes to nroff. Werner, is there any chance that you might be able to release 1.20.2 in the near future? I'll release 1.21 after integrating your and Daiki-san's patches. Sorry for the large delay. Are there any specific blockers (perhaps I could help), or is it just a lack of time? I certainly understand the latter, but would really like to be able to take advantage of the change above ... The main blocker is missing enthusiasm for groff :( Last year I was extremely busy, and recently I've moved from Germany to Austria, and in my spare time I've mainly concentrated on FreeType. I have to say I agree with Werner in http://lists.gnu.org/archive/html/groff/2010-08/msg0.html when he suggests that this would be better done some other way. Fonts aren't ideal, though, because then we'd have to have separate font files for Japanese. There is perhaps a misunderstanding. I don't object to using wcwidth; this is used for TTY output only, and grotty outputs characters, not glyphs, thus it doesn't harm if the logic for character widths is in the UTF8 part of grotty. Given how groff + grotty works the implementation is OK, and the actual changes to the groff code are less than 10 lines. What I object, as you've correctly noted, is to provide special locale-dependent support files. Perhaps you could add a new charinfo flag and set this in ja.tmac using a character class? I don't know if that design is perfect either, but my feeling is that this kind of problem is why we came up with the idea of character classes in the first place. Yes! It would allow to overwrite the global wcwidth values if necessary. For example, we could provide a new request `.charwidth' which has the same syntax as `.cflags'. Values for `.charwidth' are then only taken into account if a new `charwidth' keyword is present in the DESC file. However, I don't consider that as essential, and I will release 1.21 without this yet-to-be-written stuff. Another minor thing which isn't urgent: I think that the (current) contents of ja.tmac is essentially universal, not restricted to Japanese. For speed considerations it is OK that character classes are not part of standard calls to groff, however, what about moving them to a file `cjk.tmac' which then gets included by ja.tmac, kr.tmac, etc.? Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579890: grotty: infinite loop when processing a man page
In fact, you can reproduce this infinite loop with just the following grotty input: x T utf8 x res 240 24 40 x init p1 Dt The following patch would turn this into a fatal error instead, [...] Thanks a lot! I've applied your patch to the CVS repository. Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545821: groff: [manual] Options -w and -W do not list names of the warnings that can be used
Package: groff Version: 1.20.1-5 Severity: minor Manual page reads: -w name Enable warning name. -W name disable warning name. The documentation does not list what the parameter NAME can be. Please present list of allowed NAMEs. Hmm. The section in `groff(1)' which contains `-w' and `-W' is called `Transparent Options', and it starts with this paragraph: The following options are transparently handed over to the formatter program `troff' that is called by `groff' subsequently. These options are described in more detail in `troff(1)'. There are many other groff options like `-P' or `-K' which refer to other subprograms. It's quite error-prone to duplicate all those options in the groff man page. Werner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#472903: [Groff] Re: Bug#472903: Acknowledgement (scons: badly formatted manpage)
.de does nothing if the macro you're trying to define already exists, This is not correct. .de simply overwrites a previous definition without notice, similar to TeX. One is to simply rename your macro to something else. I'm not sure if there's a recommended way to avoid this problem in future, though, and I recognise that that's a problem; I'm CCing the groff list in case they have any suggestions. In general, the user shouldn't define *any* macro within a man page -- many man2xxx converters understand only the limited set of man macros (and probably a few raw troff commands). The next groff version will contain an-ext.man, which defines a bunch of useful macros currently missing in most man macro packages. All man macros are uppercase. If Joe User really want to define something, I strongly recommend to use mixed-case macro names, for example uppercaselowercase -- only the `Tm' string register is defined in the man package (and its extension). The other is to move your preamble below .TH (so that it comes after the point where an-ext.tmac is sourced), and to remove the existing macros before defining your own. The attached patch does this. Yes. Defining macros before .TH is always problematic since .TH is often defined to switch between `man' and `mdoc' (redefining .TH afterwards). Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196762: [Groff] Groff Version in Debian and [K]ubuntu
I'm happy to (try to) add kinsoku shori handling for Debian[0], [...] Great! Maybe I don't understand the problem with width handling, but it seems like you get this for free with Unicode, which is another reason that I think CVS groff would be better. Well, you have to implement character classes (or rather, groff entity classes). For example, read this email: http://lists.gnu.org/archive/html/groff/2006-01/msg00123.html [0] To make Werner's life easier, I'm happy to disclaim copyright on those changes, using the standard FSF form if necessary, should I produce usable work. Excellent. Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396142: Missing control sequence inserted after install latex-cjk-common
and send me the log file (compressed). Here it comes Danai already answered the issue. Anyway, I'll add some words regarding BOM to the docs. Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396142: Missing control sequence inserted after install latex-cjk-common
a Debian user has reported a regression in latex-cjk.
Hmm, I don't get any problems with the latest release, CJK 4.7.0.
! Missing control sequence inserted.
inserted text
\inaccessible
l.4 \begin{CJK}{UTF8}{songti}
There have been problems with the leading byte 0x80 in UTF-8 encoding
which is meanwhile fixed in 4.7.0. Anyway, the error message you
report won't happen with the input `abcdefg' since it doesn't force a
CJK encoding to be loaded.
Please retry with 4.7.0.
Werner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396142: Missing control sequence inserted after install latex-cjk-common
Yes. If I change \usepackage{CJK} to \usepackage{CJKutf8}, it runs
fine.
Strange, since this shouldn't matter in the example. Please do
\documentclass[a4paper]{book}
\usepackage{CJK}
\begin{document}
\tracingall
\tracingonline0
\begin{CJK}{UTF8}{songti}
abcdefg
\end{CJK}
\end{document}
and send me the log file (compressed).
We'll do that as soon as possible. I noticed that the example
CJKutf8.tex included in 4.6.0 loads CJKutf8.sty, not CJK.sty, and
when I make this change in the document included in this bug
report, it runs fine. Are you sure that CJK.sty was supposed to
work in 4.6.0?
Well, CJKutf8.sty immediately loads CJK.sty... I really can't see a
reason why the above example fails with CJK.sty. Are you sure that
the file doesn't start with the `byte order mark' (BOM, U+FEFF), which
some editors insert even for UTF-8 encoding? This is the byte
sequence 0xEF 0xBB 0xBF. This must always be removed.
Werner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390397: groff -Tascii broken: should not output ANSI escape sequences
from groff-base 1.18.1.1-7 we have:
$ echo '.BR foo bar' |
2/dev/null groff -te -msafer -mtty-char -mm -Tascii |
fgrep f | cat -v
^[[1mfoo^[[22mbar
$
Apparently with groff-base 1.18.1.1-7, -Tascii is outputting ANSI
escape sequences, and this of course breaks all kinds of stuff (e.g.
this no longer works on dumb line printers and other devices that
perfectly well understand ^H, ^I, ^L and printable ASCII characters,
but know nothing of ANSI escape sequences; this similarly breaks
stuff passed to less or col -b, etc., generally resulting in quite a
mess).
This is an old issue. groff 1.18 has been released 4 years ago!
This works fine on oldstable (woody) groff-base 1.17.2-15.woody.1 as
seen here:
$ echo '.BR foo bar' |
2/dev/null groff -te -msafer -mtty-char -mm -Tascii |
fgrep f | cat -v
f^Hfo^Hoo^Hobar
$
If one wants ANSI escape sequences, perhaps there should be a
-Tansi, but please, -Tascii should continue to only generate
printable ASCII characters and well defined common ASCII control
codes (e.g. ^H, ^I, ^L), and should *not* generate ANSI escape
sequences, as the actions of these escape sequences are not defined
in the ASCII character set.
I strongly disagree. To get bold characters with ^H was and is and
will be a hack. How do you come to the conclusion that embolding of a
character string with ^H is in any way standardized in ASCII? ^H is a
backspace, nothing else. AFAIK there is *no* standard which defines
this behaviour, whereas SGR is defined in ISO 6429 (and ECMA-48).
The solution to your problem is the very first item in groff's
`PROBLEMS' files. For your convenience, I'm pasting it below.
Werner
==
* Displaying a man page on a terminal with/without my favourite pager
only gives garbage.
groff by default now uses SGR escape sequences (`ANSI color') to
control the display attributes (bold, underlined, colour) on TTYs.
Some terminals (e.g. `kterm') don't understand SGR, and some pagers
(e.g. older versions of `less' or `less' without the -R option) don't
understand SGR either. There are three solutions to fix this, in order
of preference; please read the grotty man page for more details.
The fourth and probably best option is to update your terminal program
and pager to versions which can handle SGR.
1. Set the GROFF_NO_SGR environment variable.
2. Pass option -c to grotty (this is, add `-P-c' to groff's command
line options).
3. Append the following fragment to the `troffrc' file:
--- start ---
.if n \{\
. nr _C \n(.C
. cp 0
.
. \ The following code sets a top-of-page trap to disable grotty's TTY
. \ mode. Since neither \X nor .output can be used before the first
. \ page has started, we must use a trap. To make it work with troff's
. \ -o option, we wait until the first printed page.
.
. de [EMAIL PROTECTED]
. .
.
. rn wh [EMAIL PROTECTED]
.
. \ The stand-alone version. If no other trap is set, we can safely
. \ insert the truncated vertical space caused by the trap (if any).
. \ Otherwise we assume that the document's main macro package takes
. \ care of that. As soon as the trap has been executed, it is removed.
. de1 [EMAIL PROTECTED]
.if \\n[.P] \{\
. if (\\n[.t] == \\n[.p]) \{\
.rn [EMAIL PROTECTED] wh
.rm [EMAIL PROTECTED]
.wh 0
.sp \\n[.trunc]
.nop \X'tty: sgr 0'
.sp -1
.\}\}
. .
.
. [EMAIL PROTECTED] 0 [EMAIL PROTECTED]
.
. \ The piggyback version to be appended to macros planted with the
. \ modified `wh' request.
. de1 [EMAIL PROTECTED]
.if \\n[.P] \{\
. rn [EMAIL PROTECTED] wh
. ds [EMAIL PROTECTED]
. nop \X'tty: sgr 0'
. sp -1
.\}
. .
.
. \ We redefine the `wh' request so that [EMAIL PROTECTED]' is appended to
. \ the trap macro.
. de1 wh
.am1 \\$2 [EMAIL PROTECTED]
. [EMAIL PROTECTED]
.[EMAIL PROTECTED]
.[EMAIL PROTECTED] \\$1 \\$2
. .
.
. cp \n[_C]
.\}
--- end ---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314385: [ft-devel] Re: FreeType issues
One change that *would* mitigate the problems for other distributors (and Debian) is, since freetype 2.2 will already include a linker script, to add symbol versions to that linker script. [...] According to this excellent document (everybody involved into this discussion should read it!) http://people.redhat.com/drepper/dsohowto.pdf which describes all aspects of writing DLLs, symbol versioning isn't portable. Consequently, this must be hidden with macros. If someone comes up with an elegant macro solution which doesn't uglify the source code and which are easy to use I don't object to add this to the CVS. In case we introduce that we should do it right, this is, support symbol versioning in the source code too. Takers? Comments? Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348636: [Cjk] Bug#348636: tetex-extra: listings package in tetex-3 conflicts with cjk-latex
I'm forwarding this issue to you, because there seems to be an
incompatibility between CJK and listings when GB2312 is used.
Note that this incompatibility is documented behaviour of the
`listings' package! If you don't use Chinese within listings, add
\lstset{extendedchars=false}
at the beginning of your document to make GB2312 work.
Werner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253124: cyrtexinfo format in fmtutil.in
I think that I (or someone else) have set it up like this, because the t2 package (CTAN:macros/latex/contrib/t2) contains this cyrtxinf.ini file. I don't use this format. Werner, Vladimir: any comments from your side about it? No. I see it the first time :-) Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317708: broken e-mail, Re: amd64-specific bug in XPDF based programs?
Apparently [EMAIL PROTECTED] is broken; this is the mail address listed in the freetype-2.1.10 README file. See below for a bug report that bounced. We moved FreeType to `nongnu.org' except the www stuff which is now on `freedesktop.org'. `www.freetype.org' has already been redirected to the new site, but forwarding of mails apparently doesn't work as expected. Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315839: babel support for vietnamese?
a user of our Debian teTeX packages (which are still 2.0.2 in
unstable) asked about the TeX support of vietnamese. It seems there
is one file already [...]
Of course, this file is also in teTeX 3.0 which is currently only in
Debian experimental.
Right now we are preparing a new VnTeX package to be included in the
next TeXLive release. Have a look at vntex.sf.net for beta versions
-- testers welcome!
But why isn't it in the babel directory?
Because it's not part of the Babel package.
And can one call \usepackage[vietnamese]{babel} anyway?
Actually, it is
\usepackage[vietnam]{babel}
Werner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
