> 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:/
> 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 revis
> 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
> 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".
> 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 (
> 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 subjec
>> 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-punc
>> 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
s
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
> (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.
Wern
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.
> .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 charac
> > 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]
> 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}
\
> 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.
>
> \inaccessible
> l.4 \begin{CJK}{UTF8}{songti}
There have been problems with the leading byte 0x80 in UTF-8 enco
> 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 kin
> 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
> 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 UNS
> 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
> 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 VnTe
25 matches
Mail list logo
