Bug#754529: typo in impnattypo
Norbert Preining prein...@logic.at wrote:
it seems that there is a nasty problem with encoding in
impnattypo.xml
in the TeX Catalogue. It is rendered as
Fran§aise ...
weird. the mangled characters were there in the xml file, not merely
being sloppily translated. i've updated the xml file.
which in turn ends up as
FranASSaise ...
truly weird, that.
in the TeX Live database - probably due to some encoding games.
AFAIR the Catalogue is UTF8, so that should be possible to be fixed.
maybe so, but the README file has the same strangulation of c-cedilla.
r
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750057: [tex-live] Serious (?) problem with Babel and language attributes
Norbert Preining prein...@logic.at wrote:
I got a bug report here at Debian, but it is the same in the
current TL2014 status. It seems that something with the
language attributes is up-side-down:
The report states that
\today
prints the wrong month for June in Russian. It should be
июнь (cyrillic i at the first position)
but comes out as
iюнь (latin i followed by cyrillic юнь)
The input file is trivial:
\documentclass[12pt,russian]{article}
\usepackage[T2A]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\begin{document}
\today
\end{document}
(with or without the inputenc, I tried both!)
Reading a bit through russian.ldf I see that the printed version
is related to the ancient variant of Russian.
So I tried
...
\usepackage{babel}
\languageattribute{russian}{ancient}
...
and voila, the June comes out as expected in all cyrillic.
So it seems to me that there is something - a test - turned
around.
I am not sure whether Karl considers this a show-stopper, but
considering how core babel is that would be a good reason for me.
the package has a modern/ancient switch; there was a language reform
after the revolution (iirc).
if the switch is set to ancient, it sets june and july with an old
cyrillic i, but if the switch is set to modern, it uses the soft i
(transcribed, iirc, as yi). the document that's had trouble
presumably has the command
\languageattribute{russian}{ancient}
in it.
robin
Please try to keep the Debian bug report in Cc, if possible.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750057: [tex-live] Serious (?) problem with Babel and language attributes
Manfred Lotz manf...@dante.de wrote:
On Sun, 1 Jun 2014 10:28:34 +0100
Robin Fairbairns robin.fairbai...@cl.cam.ac.uk wrote:
Norbert Preining prein...@logic.at wrote:
I got a bug report here at Debian, but it is the same in the
current TL2014 status. It seems that something with the
language attributes is up-side-down:
The report states that
\today
prints the wrong month for June in Russian. It should be
июнь (cyrillic i at the first position)
but comes out as
iюнь (latin i followed by cyrillic юнь)
actually, it's a cyrillic i-dot
The input file is trivial:
\documentclass[12pt,russian]{article}
\usepackage[T2A]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\begin{document}
\today
\end{document}
(with or without the inputenc, I tried both!)
Reading a bit through russian.ldf I see that the printed version
is related to the ancient variant of Russian.
So I tried
...
\usepackage{babel}
\languageattribute{russian}{ancient}
...
and voila, the June comes out as expected in all cyrillic.
So it seems to me that there is something - a test - turned
around.
I am not sure whether Karl considers this a show-stopper, but
considering how core babel is that would be a good reason for me.
the package has a modern/ancient switch; there was a language
reform after the revolution (iirc).
if the switch is set to ancient, it sets june and july with an old
cyrillic i, but if the switch is set to modern, it uses the soft i
(transcribed, iirc, as yi). the document that's had trouble
presumably has the command
\languageattribute{russian}{ancient}
in it.
If set to ancient then it is іюня, otherwise (the modern variation) it
is июня. As Zdeněk pointed out rightly, the я indicates genitive.
Interesting question is why Norbert got the nominative form июнь.
indeed -- it doesn't appear in the russian ldf/
According to russianb.pdf the default should be modern cyrillic which
is actually not true.
As texmf-dist/tex/generic/babel-russian/russianb.ldf is the same in
both texlive 2013 and 2014 the error doesn't seem to be texlive 2014
specific.
presumably tl2014 is being delivered with this wrong version, but the
version on the archive (dated may 20) doesn't have the genitive.
(i can't guarantee this: my backup links aren't working, so it could be
that the pre-20 may version is also right, and the correction came even
earlier.)
robin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703212: [tex-k] dvips segfault
Norbert Preining prein...@logic.at wrote: at Debian we got a bug report about segfaulting dvips when reading and writing to itself .. (yes I know it is not very intelligent, but still segfaulting is not optimal): [...] [1887007337Segmentation fault This is with current TeX Live 2012 (but the same in old versions and Debian versions). Maybe that can be handled sooner or later, but no hurry I guess. it's obviously a bug in the user, too: does he/she segfault, too? (btw, what's become of your meaning of liff quotes ... some time since i saw one...) robin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647433: [l2h] New release of latex2html?
Roland Stigge sti...@antcom.de wrote: roughly speaking, with abandonware like l2h, we merely go by the licence. gpl implies (to us) that anyone can hack out a bug and re-release. Yes, of course! It would be fine if someone steps up and helps Ross (who is still responsive and is considering including the 2012 changes into his lastex2html) to work on this. yes. true of an awful lot of abandoned packages, unfortunately. someone needs a ring to rule them all, to bind them, and to find them when the lights go out. Unfortunately, there was no notice by anyone when and why a release was done. Just need to maintain what we accept into Debian for the next few years, and trying to prevent a mess caused by random diverging releases by different people. quite. i used to mirror some web site for l2h, and it was just the same then, except one assumed that access to the site \equiv has some clue about what they're doing with l2h. the announcement situation was otherwise the same. maintaining an archive is a case of damned if you do, damned if you don't. in that situation, i generally tend not to (after agonising about it for a while) on the grounds that i don't want to waste any _more_ time. sorry you've been inconvenienced. i hope you understand our situation. Robin Fairbairns For the CTAN team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647433: [l2h] New release of latex2html?
Roland Stigge sti...@antcom.de wrote: at Debian, we found that there is http://mirrors.ctan.org/support/latex2html/latex2html-2012.tgz which wasn't announced as an official new release. See also http://bugs.debian.org/647433 Now I wonder if I should use this as the new official upstream version to be built upon from now on? There are some doubts that I collected in the above Debian bug report. the author of this revision merely said fix warnings in perl 5.14 i don't have any working latex that would work with latex2html, so i can't claim to know whether this is a reasonable. roughly speaking, with abandonware like l2h, we merely go by the licence. gpl implies (to us) that anyone can hack out a bug and re-release. Robin Fairbairns For the CTAN team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674185: [texdoc] texdoc and cweb manual
Robin Fairbairns robin.fairbai...@cl.cam.ac.uk wrote: [...] 3 /home/norbert/tl/2012/texmf-dist/doc/plain/cweb/cwebman.dvi Hum, really? ;-) if i wasn't otherwise engaged (dancing in small circles around the catalogue) i would redo that as a pdf. you can't read dvi out of a browser, is the theory ... and we're an archive. if i change cweb on the archive, it'll make its way to tex live, eventually. sigh. it seems i'm wrong; there is no cwebman.dvi on the archive, so i deduce that cwebman arrives in tl by some other means. i shall let sleeping dogs lie... sorry about the noise. robin the sleepy archivist. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674185: [texdoc] texdoc and cweb manual
Manuel Pégourié-Gonnard m...@elzevir.fr wrote: On 24/05/2012 00:48, Norbert Preining wrote: texdoc cannot find cweb manual: $ texdoc -l cweb 1 /home/norbert/tl/2012/texmf-dist/doc/latex/cweb-latex/cweb-user.pdf = User manual 2 /home/norbert/tl/2012/texmf-dist/doc/latex/cweb-latex/cweb-conf.pdf = Internal interfaces 3 /home/norbert/tl/2012/texmf-dist/doc/plain/cweb/cwebman.dvi Hum, really? ;-) if i wasn't otherwise engaged (dancing in small circles around the catalogue) i would redo that as a pdf. you can't read dvi out of a browser, is the theory ... and we're an archive. if i change cweb on the archive, it'll make its way to tex live, eventually. But we would ike to get cwebman.dvi as an option (maybe first?), too. Is this possible? Of course it is. I just made it the first result. does cwebman apply to cweb-latex? should they be listed together? robin -- 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] Bug#635382: new release of latex-unicode
Wolfgang Jeltsch wolfg...@cs.ioc.ee wrote: By the way, the package is already called “ucs” in TeXLive. However, it is called “unicode” in MiKTeX. And it is called “unicode” on CTAN, and its directory on CTAN is also called “unicode”. i wonder what you consider is naming what, here? if you're assuming the catalogue entry name is the source, you're wrong. the catalogue only really emerged about 10 years after ctan, and its first population was named from the directory that the catalogue entry described. tbh, i don't recall the first appearance of unicode package: if i had been as involved in catalogue work, then, as i am now, i would probably have objected. i'm all in favour of unifying the name. on general principles, i would prefer a shorter name. How can I change the package and directory name on CTAN? Is there a dedicated process for doing so? Should I upload the package under the name “ucs”? Should the “unicode” entry be changed to just contain some README that tells that the package name has changed? Should the “unicode” entry be removed entirely? upload a package called ucs and note that it replaces unicode ;-) if you upload it to cambridge, i'll just install it. if you upload it to dante, there might be more of a delay. but whatever you do, don't worry about the name change -- you've more important work to do... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667805: [tex-live] la.sty and va.sty and non-free fonts
down here we got a complain that the fonts for la.sty and va.sty cannot be found. And indeed it seems that the la font has no license statement at all, thus the font is not included in TL. But we still ship la.sty and va.sty in teh fundus package. I am not sure, but I would say we should at least remove tha va* and la* files from the fundus package, and check for the others, suetterl and startrek etc, whether the fonts are actually available. i have always found the fundus bundle rather disturbing; indeed, i wonder whether tl is allowed to distribute bits of it at all (even if the licence you are NOT allowed to modify this file is considered free) -- it seems to demand that all of fundus be distributed together. (i'm not an expert here, but i wouldn't be surprised to be told to downgrade them.) someone (preferably not me) should contact gerd n about this. fwiw, the sutterlin fonts are clearly pd. the startrek fonts aren't on ctan afaict, and i've not spotted anything about how to find them (it says they have to be a got separately). robin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666791: [tex-live] Bug#666791: g-brief uses marvosym, but both defined \EMail
Mojca Miklavec mojca.miklavec.li...@gmail.com wrote: On Mon, Apr 2, 2012 at 11:10, Norbert Preining wrote: I already wanted to upload the package to CTAN when I realized that back then we had a problem with whether or not we are allowed to distribute original PDF documentation. Martin Vogel replied to me with: ... So my question before uploading a fixed version is: based on his reply, am I allowed to add his original PDF documentation to the package? INAL but I would say yes, of course, it is very clear. But keep in mind, is there also the source code of the pdf? Uncompressed PDF is just a text file, isn't it? maybe; but it still has pointers which mean that editing involves replacing text without changing the text's length. it's not normally considered a sane thing to do. You can also easily use any tool like InDesign to modify it if hand-editing PDF file by hand sounds too complicated ;) who's you? i've never even seen a copy of indesign; arguing from that to saying that you don't need source in tl ... is a non-starter. The document has been created with some ancient version of Star Office (that's probably a predecessor of OpenOffice/LibreOffice, so there is even a slight chance that it could be opened :). That source document is not part of the zip, but even if it was it would probably be almost useless since even if one would be able to open it, it would be a bit difficult to convince Office to use the right version of font and the right glyphs. (It would probably work after some time, but it would be a nontrivial task.) In principle it is trivial to reproduce the document (or even to just copy-paste from PDF to Writer and fix some problems; or maybe replicate the document in TeX), but I see no compelling reason to do so. It is just work (trivial work) that takes time and doesn't bring any benefit apart from being able to say that we have the source now and resulting in a document just a tiny bit different from author's original. Using common-sense, replicating the document is a less friendly gesture towards the author than simply including the original PDF. If anyone feels a need to do whatever changes in the document, (s)he can always do that when the need arises. fine. we can hold the pdf on ctan, but tl won't take anything for which there is no source. The document contains 12 pages of a table with (graphical symbol, character number, latin1 character to type, PostScript name, German description, English description) plus Author's contact information and some tiny examples at the end. it is indeed going to be a joy to reproduce the document in tex. robin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#467183: Long-standing bug in marvosym.sty
Hilmar Preusse hill...@web.de wrote: On 11.10.11 Robin Fairbairns (robin.fairbai...@cl.cam.ac.uk) wrote: tex live gets its marvosym from fonts/marvosym fwiw, i've moved the obsolete version out of the way; it will no longer be available from any proper mirror, at the old address, in a day or so. I re-tested this bug with the version from TL 2011 and with the version from CTAN (which BTW differ). in the sense that they're at different addresses? just now, diff of the .sty and .fd, and md5sum of the .pfb, confirm that they're the same in tl and on ctan under fonts/marvosym. but maybe you're looking at a stale mirror of ctan (not in mirrors.ctan, presumably) and hence at the marvosym copy that's now on the ctan obsolete/ tree... I can still reproduce the issue with both versions. Jan, could you confirm? certainly worked for me, on my tl installation (i've just confirmed, using latex and pdflatex on marvotest in the bug record). which of the versions on ctan, at the time this exchange started, did you use? i've not actually tried direct from ctan -- seems irrelevant given the comparisons i've done. if you persist in disbelieving me, please don't bother to mail again. i've said all i'm going to say. Robin Fairbairns For the CTAN team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#467183: Long-standing bug in marvosym.sty
the package was taken over, earlier this year, and re-done. the test program compiles correctly with tex live 11, under latex or pdflatex. why is it satisfactory to send out bug messages without testing whether the bug has been corrected? Robin Fairbairns For the CTAN team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#467183: Long-standing bug in marvosym.sty
Jan Medlock medl...@turboshower.net wrote: I'm glad to hear it's been fixed and appreciate your quick reply. I do not appreciate what appears to be the tone of your last comment. The version of marvosym.sty in CTAN still has the bug: http://mirrors.ctan.org/fonts/psfonts/marvosym/marvosym.sty I checked it this morning before sending my bug report, which was to CTAN, not to TeX Live. more's the pity. tex live maintains a current copy of things; you chose an outdated copy of marvosym (presumably without reference to the ctan catalogue, which doesn't list it). tex live gets its marvosym from fonts/marvosym fwiw, i've moved the obsolete version out of the way; it will no longer be available from any proper mirror, at the old address, in a day or so. Robin Fairbairns For the CTAN team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571679: [tex-live] Bug#571679: moving ucs back to -recommended
Norbert Preining prein...@logic.at wrote:
On Mi, 10 Mär 2010, Manuel Pégourié-Gonnard wrote:
Well, ucs isn't required for utf8 input, \usepackage[utf8]{inputenc} is
enough.
Well, I myself always use \usepackage[utf8x]{inputenc}, but without
knowing why. Probably I had problems at some point with [utf8] ...
utf8 covers (at most) characters represented in latex-standard font
encodings. anything (like japanese, for example) without such an
encoding, isn't covered.
in your case, i would imagine the problem was just that.
analysis of the code of utf8x leads me to suspect that it's not as
robust as that of utf8; since utf8x is not supported, this could in
principle be a problem.
fwiw, the only european language omitted from utf8, afaik, is greek.
as an (indirect) result, i've never actually used utf8.
robin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571679: [tex-live] Bug#571679: moving ucs back to -recommended
Norbert Preining prein...@logic.at wrote: On Mi, 10 Mär 2010, Philipp Stephani wrote: If you want Greek, Japanese or similar, you probably should not be using pdfTeX at all. Huuu? But? Plain TeX? unicode-based engines good, 8-bit engines (tex, pdftex,...) bad. you can bash 16-bit (or whatever) characters into an 8-bit engine, but the result is hardly robust. people _can_ do it (witness heiko with hyperref) but it's going to be increasingly difficult to make such piecemeal solutions inter-work. or it would, were it not for xetex and up-and-coming luatex, which eliminate the need for the lot. in the words of the advertising twaddle: you _know_ it makes sense. robin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#122635: Unclear documentation of rotating.sty
Hilmar Preusse hill...@web.de wrote: One of our users complained about rotating.sty not working. After some investigation, it turned out that he hadn't realized the necessity of running the DVI file through dvips in order to see the effects. The following patch to rotating.dtx adds a paragraph that makes that requirement clear: i've put a new version on the archive -- it's not your wording, but i trust it'll do the job. note that the doc's now pdf 1.5 (so small, but not readable on my home acr* reader...) robin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518800: [tex-live] lamsarrow.sty non-free?
Martin Schröder mar...@oneiros.de wrote: 2009/3/10, Norbert Preining prein...@logic.at: Suggestions? Contact Spivak through http://www.mathpop.com and ask him to free LamS-TeX. would he? the alternative is to claim that pb-diagram *only* works with the xy fonts. (those fonts have the advantage of being available in type 1 format...) r -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#425085: [tex-live] Bug#425085: texlive-doc-en: catalogue entries with dangling links
Karl Berry [EMAIL PROTECTED] wrote: Doesn't look straightforward to fix - any ideas? We will probably reinstate the Catalogue in TL, and when we do, I guess we should not just copy the files, but set up some kind of conversion process. Ugh. the catalogue as you see it on ctan or sarovar is the result of processing the xml files that make up the repository. since those xml files contain the names of tpm files (for those for which i know the correspondence). for example: entry datestamp='$Date: 2007-06-20 23:40:03 +0100 (Wed, 20 Jun 2007) $' modifier='$Author: robin $' id='footmisc' ... texlive location='footmisc'/ ... /entry [the id is the name of the xml file (and hence the name of the converted html file); the texlive location is the name of the tpm file.] given that info, one could in principle match things up, presumably? but before we even start, we need to know what we want the links to point to. suppose ctan has pdf docs and texlive has .dvi ... or, as in the case of footmisc, ctan has pdf and texlive has no docs at all? Does MiKTeX contain the Catalogue? If so, are the links properly transformed? If so, maybe we could just work from that. it doesn't, that i can see. (there's a file called files.csv.bz2 in the miktex package repository, that tells you every file in miktex and the miktex package it belongs to. i've no script that looks in all the different formats and extracts the data.) If someone wants to take this up, great. as it stands, i don't think it's do-able. we need a definition of what's really required. (this comes as a surprise to me ... until this issue arose, i had assumed it was all trivial.) would a non-ctan html version, as you find on sarovar, help? robin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426790: [tex-live] Bug#426790: Bug#426790: mathpple.map should be listed in updmap.cfg
Frank Küster [EMAIL PROTECTED] wrote: I'd like to, but I don't have much time. And I'm still waiting for input from Walter Schmidt. a lot of people are waiting for input from walter schmidt; i'm beginning to worry that he's seriously ill, or something. i know of a contract he agreed to undertake, but he's disappeared from the sight of the contracting people. there are things i would like to ask him (faq-related), but i'm holding off for signs that he's active again.
