Bug#464865: whizzytex: Missing examples in package
Package: whizzytex Version: 1.3.1-1 Severity: minor The upstream package of whizzytex includes quite a few examples not included in the Debian package, including templates for using whizzytex with beamer. Could your package them ? Thanks, -- Boris -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21.3-susp2 (PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages whizzytex depends on: ii advi 1.6.0-13 an active DVI previewer and presen ii emacs-snapshot-gtk [emacse 1:20070302-1 The GNU Emacs editor (with GTK+ 2. ii emacs21 [emacsen] 21.4a+1-5.3 The GNU Emacs editor ii gv 1:3.6.3dfsg-6 PostScript and PDF viewer for X ii texlive-latex-base 2007-13 TeX Live: Basic LaTeX packages ii xemacs21-nomule [emacsen] 21.4.20-3 highly customizable text editor -- whizzytex recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345757: darcs not record not showing the number of patch fragments
On Tue, Jan 03, 2006 at 08:55:38AM -0500, David Roundy wrote: If you press ? for help, you'll see that pressing 'c' will show you (count) the number of changes. Right, sorry :-/ I did not check for new options in the last version. On the other hand, I had looked in the Changelog in case something related was mentionned, but the one installed on my machine is really out of date (darcs 1.0.2). This is a result of an optimization to allow record to efficiently handle massive repositories, in which computing all the changes at once may require more memory than is available. Ok. Unfortunately, we don't have logic to figure out whether your repository is large or not, so we always delay computation of the entire patch until it's necesary. Of course. Have you considered adding a new preference (which defaults to don't display) for this ? -- Boris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345757: darcs not record not showing the number of patch fragments
Package: darcs
Version: 1.0.4-2
Severity: normal
Since the current version in unstable (the problem does not manifest itself
with the testing version), darcs record does no longer how many fragment a
patch is made of, e.g.
$ darcs record
hunk ./abcd.tex 1
-\documentclass[orivec]{llncs}
+ \documentclass[orivec]{llncs}
Shall I record this patch? (1/?) [ynWsfqadjkc], or ? for help:
^
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc1
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages darcs depends on:
ii libc6 2.3.5-9GNU C Library: Shared libraries an
ii libcomerr21.38+1.39-WIP-2005.12.10-2 common error description library
ii libcurl3 7.15.1-1 Multi-protocol file transfer libra
ii libgmp3c2 4.1.4-11 Multiprecision arithmetic library
ii libidn11 0.5.18-1 GNU libidn library, implementation
ii libkrb53 1.4.3-5MIT Kerberos runtime libraries
ii libncurses5 5.5-1 Shared libraries for terminal hand
ii libreadline5 5.1-5 GNU readline and history libraries
ii libssl0.9.8 0.9.8a-5 SSL shared libraries
ii zlib1g1:1.2.3-9 compression library - runtime
Versions of packages darcs recommends:
ii exim4 4.60-1 metapackage to ease exim MTA (v4)
ii exim4-daemon-light [mail-tran 4.60-1 lightweight exim MTA (v4) daemon
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339924: advi: same problem
On Wed, Nov 23, 2005 at 09:06:02AM +0100, San Vu-Ngoc wrote: Warning: Error: /invalidfileaccess in --file-- Warning: Operand stack: Warning:(/usr/share/texmf/dvips/base/special.pro) (r) [snip] So it this a bug of advi of gs ??? This bug is clearly an incompatibility between the -dSAFER option and the texc.pro file. At the very least, it should be forwarded to the gs maintainers, and to advi's upstream. In the meantime, here is a less radical patch (compared to removing the -dSAFER option altogether), which should work. -- Boris Index: gs.ml === RCS file: /net/yquem/devel/caml/repository/bazar-ocaml/advi/gs.ml,v retrieving revision 1.43 diff -u -r1.43 gs.ml --- gs.ml 7 Dec 2004 20:48:03 - 1.43 +++ gs.ml 5 Dec 2005 15:03:09 - @@ -137,7 +137,7 @@ (if !antialias then x11alpha_device else x11_device); [| -q; - -dSAFER; + -dDELAYSAFER; -; |]] in @@ -430,6 +430,7 @@ gs # line advi_pro; gs # line TeXDict begin @landscape end; gs # line /SI save def gsave; + gs # line .setsafe; process - Some gs; gs | Some gs -
Bug#314476: Default value for option multiple should be true
On Fri, Jun 17, 2005 at 09:01:11AM +0900, Junichi Uekawa wrote: Whizzytex in Debian ships with value MULTIPLE set to false. The version of advi in Debian (1.6) is perfectly capable of handling MULTIPLE=true (and is much more useful in that mode). That's a bit of a subjective comment without justification. You're right, sorry. I am interested in 1. How useful is it In advi, you can hit w to switch between document view and sliced view. I find it very useful (since otherwise I think it must be done withing emacs). What's more, the default mode (slice by section) is a bit puzzling for people who would like to see the real layout. Moreover, it is documented, and the user can be surprised that it doesn't work (which was my case). 2. Would it break existing behavior? This advice actually comes straigth from upstream (I'm his phd student). If you browse the source, you will notice that this value will be set to false for any viewer which is not advi (barring any bug). So the change should have no effect, except for advi. -- Boris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314476: Default value for option multiple should be true
Package: whizzytex Version: 1.2.2-2 Severity: normal Whizzytex in Debian ships with value MULTIPLE set to false. The version of advi in Debian (1.6) is perfectly capable of handling MULTIPLE=true (and is much more useful in that mode). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages whizzytex depends on: ii advi 1.6.0-6an active DVI previewer and presen ii emacs21 [emacsen] 21.4a-1The GNU Emacs editor ii gv1:3.6.1-11 PostScript and PDF viewer for X ii tetex-bin [xdvi] 2.0.2-30 The teTeX binary files -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297074: Temporary file created by poedit sould be of the same encoding as the file being edited
On Mon, Feb 28, 2005 at 01:25:43AM +0100, Marcin Owsiany wrote: Ah, so the issue is not that poedit performs some inappropriate recoding, but that $EDITOR decides to interpret a file containing just US-ASCII file as iso-8859-15, and not as UTF-8. But then after you input some non-us-ascii characters (which emacs encodes as iso-8859-15), poedit merges a UTF-8 and an iso-8859-15 file. Exactly, sorry for having be so unclear. Since automagic detection of encoding (based just on the data) seems a very risky business, in order to perform a conversion, two things would be needed: - a specification of the target encoding (could be easily retrieved from the original po file Content-Type: header) - a specification of the source encoding, i.e. what encoding $EDITOR chose to save your input in. I can't see how that could be done for any editor in general. I submitted the initial bug report because I (apparently erroneously) thought that there was a way to specify, at the level of the filesystem, what the encoding of a known file is. If there is none (as you seem to imply), my point is indeed moot. However, I can see a third possibility, namely to have poedit prepend a Content-Type header, which would hopefully force $EDITOR into using correct (i.e. matching the initial po file) encoding for the following input. That would indeed work. By the way, doesn't something like: LC_CTYPE=fr_FR.UTF-8 poedit blah.po provide a workaround? I guess that should force into using UTF-8 as the tempfile encoding.. That's more or less what I finally did. Unfortunately at that time my ISO-8859 lines had already been appended... -- Boris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297074: Temporary file created by poedit sould be of the same encoding as the file being edited
On Sun, Feb 27, 2005 at 11:26:06PM +0100, Marcin Owsiany wrote: As far as I know, potool knows nothing about encodings, so it should be completly transparent to them, and just pass text from the po file in whatever encoding it is, unchanged, to the temp file, and back. But I may be wrong. Yes, but I find the current behavior unsatisfactory because it is the responsibility of the user to set the correct encoding for the temporary file. Otherwise it is appended as is, in an incorrect way; in my case emacs saw the temporary file as an iso-8859-15 file (which was technically correct), and then poedit merged it as is with the original utf8 po file. So there are two ways to correct this in my opinion : - the temporary file is created with the correct encoding - the temporary file is converted after it has been saved, before being merged. Of course if poedit does not currently use encodings, this will be a bit of work. But this bug is a wish after all :-) Could you provide an example file which could demonstrate this behavior? I think just about anything would work ; besides it is highly locales and emacs/whatever dependent unfortunately... -- Boris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297074: Temporary file created by poedit sould be of the same encoding as the file being edited
Package: potool Version: 0.5-2 Severity: wishlist When using poedit (typically by calling poedit file.po), an editor is invoked on a temporary file with the remaining strings to be translated. It would be great if this file was in the same encoding as file.po. On my box I edit english strings (which can be encoded in my default locale, iso8859-15), and I translate them into french, which should be in unicode in this case. Even if file.po is in unicode, the temporary file is iso8859. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages potool depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib2.0-02.6.2-1 The GLib library of C routines -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
