Bug#305801: closed by Oleksandr Moskalenko <[EMAIL PROTECTED]> (close #305801)
Hi, [EMAIL PROTECTED] (Debian Bug Tracking System) writes: > From: Oleksandr Moskalenko <[EMAIL PROTECTED]> > Subject: close #305801 > To: [EMAIL PROTECTED] > Date: Tue, 27 Feb 2007 14:41:14 -0700 > Reply-To: Oleksandr Moskalenko <[EMAIL PROTECTED]> > User-Agent: Mutt/1.5.13 (2006-08-11) > > Tested, not found in the current version. I believe the bug should be re-opened. I'm now using `gs-gpl' 8.54.dfsg.1-5 (on PPC). While `ps2pdf' does succeed in converting a PS file with textures to PDF, Ghostscript (via `gv') still raises an error when trying to display a page with textures. This occurs, e.g., when trying to display page 168[*] of the file /usr/share/doc/lout/user.ps.gz provided by `lout-doc' (I get "GPL Ghostscript 8.54: Unrecoverable error, exit code 255"). Can you reproduce this? Thanks, Ludovic. [*] I'm using the "real" page number, i.e., the page whose top-left corner reads 168, corresponding to Section 8.2 of the manual. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422108: closed by Daniel Baumann <[EMAIL PROTECTED]> (Bug#422108: fixed in linux-libertine 2.5.9-1)
Hi, [EMAIL PROTECTED] (Debian Bug Tracking System) writes: > This is an automatic notification regarding your Bug report > #422108: linux-libertine: Erroneous Defoma hints for Type 1 fonts, > which was filed against the linux-libertine package. Thanks for applying the patch. Could you answer my initial message in further details, though (wrt. `FontName' not matching the AFM `FontName', e.g., `LinLibertine_Bd' vs. `LinLibertineB')? Or should I file a separate bug report? Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419618: Other crash-on-print example
Hi, FWIW, I have another example PDF file that reproducibly crashed Evince (0.4.0-5) and Xpdf (3.01-9) when clicking on "print", or when directly running `pdftops' from `xpdf-utils' (3.01-9): http://www.cs.cmu.edu/~ntolia/files/pubs/fast03.pdf SHA1: 742aef21430186ebc2f46c222a1064df838ad80c Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419618: Other crash-on-print example
Hi, Hamish Moffatt <[EMAIL PROTECTED]> writes: > pdftops works for me on that file. I am out of date from unstable by a > week or two. I wonder if one of the libraries that Xpdf uses has changed > since the lenny flood gates opened, hence the sudden rush of bugs being > reported. I haven't upgraded either since a few days before Etch was released (by fear of breaking something ;-)). Below is the dependency information generated by `reportbug', in case it helps. I'll see whether 3.02 fixes the problem when it's available. Thanks, Ludovic. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.18-4-powerpc-smp (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xpdf depends on: ii xpdf-common 3.01-9 Portable Document Format (PDF) sui ii xpdf-reader 3.01-9 Portable Document Format (PDF) sui ii xpdf-utils3.01-9 Portable Document Format (PDF) sui xpdf recommends no packages. Versions of packages xpdf-reader depends on: ii gsfonts 1:8.11+urwcyr1.0.7~pre41-1 Fonts for the Ghostscript interpre ii lesstif2 1:0.94.4-2 OSF/Motif 2.1 implementation relea ii libc6 2.5-1 GNU C Library: Shared libraries ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-21 GCC support library ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libpaper1 1.1.21 Library for handling paper charact ii libsm61:1.0.1-3 X11 Session Management library ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libt1-5 5.1.0-2Type 1 font rasterizer library - r ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii xpdf-common 3.01-9 Portable Document Format (PDF) sui ii zlib1g1:1.2.3-13 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435452: emacs22: `set-keyboard-coding-system' fails in non-X11 mode]
Hi, Sven Joachim <[EMAIL PROTECTED]> writes: >>> Invoking `set-keyboard-coding-system' in an "emacs -nw" session fails. >>> For instance, asking it `no-conversion' (which is needed so that dead >>> keys work as expected) fails: >> >>> Unsupported coding system in Encoded-kbd mode: no-conversion >> >> I don't understand why you have to set >> keyboard-coding-system to no-conversion for dead keys. Dead >> keys must be handled by terminal, and Emacs just receives >> the resulting character (encoded in your locale) from the >> terminal. So, setting keyboard-coding-system to what is >> appropriate for your locale should work well, and that >> should be done automatically. Indeed, using "C" as my locale fixes the problem (I used to have "LC_CTYPE=fr_FR"). Strangely enough, Emacs 21.4.1 with "LC_CTYPE=fr_FR" doesn't have the problem (i.e., dead keys are usable). Checking the "Meta Sends Escape" box of the xterm in which I run Emacs 22 also fixes the problem, even with a non-C locale. I guess I'm just displaying my lack of familiarity with how terminals work... >> What other choices were tried? utf-8, latin-X should all >> work. What is your locale? With a "C" locale, utf-8, latin-1, and others are accepted, whereas `no-conversion' yields the above error message. Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435452: emacs22: `set-keyboard-coding-system' fails in non-X11 mode]
Hi,
Kenichi Handa <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ludovic Courtès) writes:
>> Indeed, using "C" as my locale fixes the problem (I used to have
>> "LC_CTYPE=fr_FR").
>
>> Strangely enough, Emacs 21.4.1 with "LC_CTYPE=fr_FR" doesn't have the
>> problem (i.e., dead keys are usable).
>
> Does it mean that you have a problem with Emacs 22 with
> LC_CTYPE=fr_FR?
Yes: dead keys (e.g., Meta) won't work.
> In that locale, "emacs -nw" should
> automatically set keyboard-coding-system to latin-1 and the
> input mode to (t nil 0 7), and thus it should accept latin-1
> characters sent from a terminal correctly. What happens
> when you type some latin-1 character with dead-key method
> under LC_CTYPE=fr_FR?
Typing M-x yields the `ø' ("o slash") character instead of running
`execute-extended-command'.
Typing accented characters with the `latin-1-prefix' input method, for
instance, does work, but I'm not sure how this relates to the fact that
Meta doesn't work.
>> Checking the "Meta Sends Escape" box of the xterm in which I run Emacs
>> 22 also fixes the problem, even with a non-C locale.
>
> It seems that your Emacs' input mode is set not to accept
> 8-bit input. Please tell me what is shown by
> ESC : (current-input-mode) RET
=> (t nil 0 7)
Thanks,
Ludovic.
Bug#435452: emacs22: `set-keyboard-coding-system' fails in non-X11 mode]
Hi,
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Typing M-x yields the `ø' ("o slash") character instead of running
>> `execute-extended-command'.
>
> This is because your terminal sends the exact same byte sequence (in this
> case it's actually a single byte) when you type M-x as when you type ø, so
> Emacs has no way to distinguish the two: it chooses to interpret the byte as
> ø here (which messes up the M-x case) and you could tell it to interpret it
> as M-x (which would mess up the ø case).
I see, thanks for the clarification!
> Indeed, that's the right solution because it tells your Terminal to use
> different byte-sequences for the two different cases.
Understood.
Thanks,
Ludovic.
Bug#425716: tdb-dev: Fails to open "previous" databases
Hi, Pierre Habouzit <[EMAIL PROTECTED]> writes: > The problem is because of the deactivated spinlock code. The following > patch seems to fix the problem, but I'm unable to understand the > consequences properly (e.g. on a system where things using the old tdb > library could still exist, and believe to have locked the tdb ...). Hmm, I wouldn't know either. What do upstream people think? Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
