July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: scheme - my opinion 26 years, 4 months

Michael Sperber

>>>>> "Holger" == Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: Holger> I wasn't so concerned with the efficiency as with the availabilty on a Holger> large number of platforms. Do you want to port a "foreign" scheme Holger> system to a new machine type ? I certainly won't want to. I don't understand what you're saying. All implementations I mentioned are highly portable. Scheme 48 is currently restricted to 32-bit architectures, but Richard Kelsey is working on fixing that. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [PATCH] Handle transparency and backgrounds properly in PNG files 26 years, 4 months

Didier Verna

jareth(a)camelot.co.jp (P. E. Jareth Hein) writes: > After a forced education into the wonders of specifiers and their care > and feeding in C, I know what you mean :-) > Now the background for display is the same as the background of the default > face. It works, thanks. Now I have a quizz for you (please select what you think is the correct answer): Q: What if I have a background pixmap for the default face ? A: [ ] a background what ?! [ ] huh, dunno. [ ] I don't give a f*cking damn. [ ] Then, remove it. [ ] No problem, here's a new patch :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

[PATCH] Handle transparency and backgrounds properly in PNG files 26 years, 4 months

Jareth Hein

After a forced education into the wonders of specifiers and their care and feeding in C, I think I've got this nailed. This fixes display problems for Steve's beer-swilling penguin that he mailed earlier today. Now the background for display is the same as the background of the default face. 1998-07-29 P. E. Jareth Hein <jareth(a)camelot.co.jp> * glyphs-eimage.c (png_instantiate): Add proper handling for background colors taken from the default face. Also correct a thinko in transparency (not alpha) handling. Index: glyphs-eimage.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/glyphs-eimage.c,v retrieving revision 1.3 diff -u -u -r1.3 glyphs-eimage.c --- glyphs-eimage.c 1998/06/13 04:28:48 1.3 +++ glyphs-eimage.c 1998/07/29 21:05:10 ＠＠ -49,6 +50,7 ＠＠ #include "lstream.h" #include "console.h" #include "device.h" +#include "faces.h" #include "glyphs.h" #include "objects.h" ＠＠ -902,6 +688,42 ＠＠ for (y = 0; y < height; y++) row_pointers[y] = unwind.eimage + (width * 3 * y); + { + /* if the png specifies a background chunk, go ahead and + use it, else use what we can get from the default face. */ + png_color_16 my_background, *image_background; + Lisp_Object bkgd = Qnil; + + my_background.red = 0x7fff; + my_background.green = 0x7fff; + my_background.blue = 0x7fff; + bkgd = FACE_BACKGROUND (Vdefault_face, domain); + if (!COLOR_INSTANCEP (bkgd)) + { + warn_when_safe (Qpng, Qinfo, "Couldn't get background color!"); + } + else + { + struct Lisp_Color_Instance *c; + Lisp_Object rgblist; + + c = XCOLOR_INSTANCE (bkgd); + rgblist = MAYBE_LISP_DEVMETH (XDEVICE (c->device), + color_instance_rgb_components, + (c)); + my_background.red = XINT (XCAR (rgblist)); + my_background.green = XINT (XCAR (XCDR (rgblist))); + my_background.blue = XINT (XCAR (XCDR (XCDR (rgblist)))); + } + + if (png_get_bKGD (png_ptr, info_ptr, &image_background)) + png_set_background (png_ptr, image_background, + PNG_BACKGROUND_GAMMA_FILE, 1, 1.0); + else + png_set_background (png_ptr, &my_background, + PNG_BACKGROUND_GAMMA_SCREEN, 0, 1.0); + } + /* Now that we're using EImage, ask for 8bit RGB triples for any type of image*/ /* convert palatte images to full RGB */ ＠＠ -914,12 +736,6 ＠＠ /* we can't handle alpha values */ if (info_ptr->color_type & PNG_COLOR_MASK_ALPHA) png_set_strip_alpha (png_ptr); - /* rip out any transparancy layers/colors */ - if (png_get_valid (png_ptr, info_ptr, PNG_INFO_tRNS)) - { - png_set_expand (png_ptr); - png_set_strip_alpha (png_ptr); - } /* tell libpng to strip 16 bit depth files down to 8 bits */ if (info_ptr->bit_depth == 16) png_set_strip_16 (png_ptr); ＠＠ -932,25 +748,6 ＠＠ png_set_packing (png_ptr); } -#if 1 /* tests? or permanent? */ - { - /* if the png specifies a background chunk, go ahead and - use it */ - png_color_16 my_background, *image_background; - - /* ### how do I get the background of the current frame? */ - my_background.red = 0x7fff; - my_background.green = 0x7fff; - my_background.blue = 0x7fff; - - if (png_get_bKGD (png_ptr, info_ptr, &image_background)) - png_set_background (png_ptr, image_background, - PNG_BACKGROUND_GAMMA_FILE, 1, 1.0); - else - png_set_background (png_ptr, &my_background, - PNG_BACKGROUND_GAMMA_SCREEN, 0, 1.0); - } -#endif png_read_image (png_ptr, row_pointers); png_read_end (png_ptr, info_ptr); -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

Re: xemacs-21.0-b50: package-get 26 years, 4 months

Adrian Aichner

>>>>> "Michael" == Michael Kifer <kifer(a)cs.sunysb.edu> writes: Hello Michael, this should be Michael> provides (tpu) requires type regular), (regular) provides (tpu) requires nil type regular Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: Problem with PNG 26 years, 4 months

Jareth Hein

Didier Verna <verna(a)inf.enst.fr> writes: > SL Baur <steve(a)xemacs.org> writes: > > > An upgrade to libpng-1.0.2 solves the squished image problem, except > > now the transparent background doesn't appear to get handled optimally. > > It appears white in XEmacs, gray in display and black in xv. > > Same here. > I haven't handled backgrounds properly in XEmacs, and am whomping up a patch for that right now that will take the background of the default face and use that instead of 'almost white'. I don't know about display, but xv (3.10+png) uses 0,0,0 as the background for files that don't spec 'em. I'm concerned about the wierdness on the inside of the penguin, though... Checking... -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

Re: Always initialize DEFVAR_LISP variables (was Re: Core dump in Benadir) 26 years, 4 months

William M. Perry

SL Baur <steve(a)xemacs.org> writes: > Here's a sledgehammer test to detect stuff like this in the future (no > doubt there's room for optimzation, this is slow and pure brute force): > > (mapatoms > (lambda (symbol) > (cond > ((boundp symbol) > (prin1 (symbol-name symbol)) (terpri) > (prin1 (symbol-value symbol)) (terpri)) > ((fboundp symbol) (symbol-function symbol)) > (t nil)))) > > 1998-07-27 SL Baur <steve(a)altair.xemacs.org> > > * keymap.c (vars_of_keymap): Initialize Vkey_translation_map and > Vvertical_divider_map. Isn't this something that could just be done in DEFVAR_LISP? Slap a *c_location = Qnil; at the end of DEFVAR_LISP in symeval.h? Then you would only ever have to worry about explicit initialization if it needed to be something other than Qnil. Similar for DEFVAR_INT, DEFVAR_BOOL, etc. -Bill P.

2 participants
1 comments

Re: scheme - my opinion 26 years, 4 months

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 28 Jul 1998 10:14:05 +0200: SJT> We want an engine that will be usable on all platforms we SJT> support, an efficiency improvement on most of them, and a big SJT> efficiency improvement on as many as possible. Holger> How many of the Scheme implementations mentioned does are Holger> ruled out by this commitment (to which I totally agree) ? MS> None. The efficiency varies greatly among them, but all are MS> vastly faster than Elisp. I wasn't so concerned with the efficiency as with the availabilty on a large number of platforms. Do you want to port a "foreign" scheme system to a new machine type ? I certainly won't want to. Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- "Wie haben andere Linux Benutzer ihr `erstes Mal' mit Linux erlebt??" "Wir haben danach gemeinsam eine Gitanes geraucht und nochmal ueber alles geredet." -- P.Vollmann und Stefanie Teufel in de.comp.os.linux.misc

1 participants
0 comments

Re: Problem with PNG 26 years, 4 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > An upgrade to libpng-1.0.2 solves the squished image problem, except > now the transparent background doesn't appear to get handled optimally. > It appears white in XEmacs, gray in display and black in xv. Same here.

1 participants
0 comments

Re: xemacs-21.0-b50: --with-gif failure on Solaris 2.6 26 years, 4 months

Didier Verna

kifer(a)cs.sunysb.edu (Michael Kifer) writes: > Configure dies with a PANIC msg. The config.log file says: > > /usr/local/sparc-sun-solaris2.5.1/bin/ld: cannot open -lgifreader: No such > file or directory > > Does --with-gif now require gifreader? > Xemacs 20.4 doesn't need it to compile. Due to patent problems, we had to remove all code for writing gif, hence using gifreader only. But anyway, it appears that even using code reading gifs (and thus making LZW decompression) is incompatible with distributing XEmacs, and so the gif support will be totally removed in the next release. We're in the process of porting all images to PNG. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

xemacs-21.0-b50: --with-mule problem 26 years, 4 months

Michael Kifer

If I use configure --with-mule but the mule-base package isn't installed, I get Error: dumped file mule-charset.elc does not exist Error: dumped file mule-coding.elc does not exist Error: dumped file mule-files.elc does not exist Error: dumped file mule-help.elc does not exist at the time xemacs gets dumped. I think configure.in should check in lisp/mule-base exists, if --with-mule is specified on command line. This way the user will be notified right away of the problem. --michael

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta July 1998