> 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
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
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
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 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
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
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.
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)
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
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
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
(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,
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
--
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.
.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
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
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]
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
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}
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
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!)
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
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
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
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
25 matches
Mail list logo
