Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01726; 26 Dec 96 22:59 PST To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera oct 95 Date: Thu, 26 Dec 1996 22:59:00 -0800 From: Jay Nietling ------- Forwarded Messages Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa26222; 1 Oct 95 11:14 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id TAA16428; Sun, 1 Oct 1995 19:35:50 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0szSmk-0003kLC; Sun, 1 Oct 95 19:06 MET Message-Id: From: Erik Corry Subject: Re: Chimera I18N patch (Alpha version) To: shige-y@is.aist-nara.ac.jp Date: Sun, 1 Oct 1995 19:06:45 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9509220646.AA18088@bls7.aist-nara.ac.jp> from "=?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?=" at Sep 22, 95 03:46:57 pm Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 556 How do the internationalisation changes for Chimera actually work? It looks to me as though there are some special character sequences that are recognised as non-European characters. Is there a general way to specify the character set in HTML, or is this slightly messy solution the normal way of doing things? I am trying to make a mail reader module for Chimera, and I am wondering what I should do with the character set indication in Mime messages. Perhaps you could point me to a URL that explains these things. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 2 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05030; 1 Oct 95 19:40 PDT Received: from little-charlie.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05022; 1 Oct 95 19:37 PDT To: chimera-announce@little-charlie.ISRI.UNLV.EDU Subject: chimera 2.0 alpha 80 Date: Sun, 01 Oct 1995 19:37:06 -0700 From: John Kilburg I just made a new one available: https://www.isri.unlv.edu/~john/chimera/src/cfh80-2.0.tar.gz It can handle JPEG (there is a bug that has been fixed but this one works for the most part) you'll need to look at Common.tmpl, src/Imakefile, image/Imakefile to see what needs to be done (it gets easier in the next release). The next release is getting an extensive rearrangement...I recommend that you wait before you hack. Hopefully after that cool patches can be incorporated (i.e. I8LN (?) patch). -john ------- Message 3 Received: from uxc.cso.uiuc.edu by JIMI.CS.UNLV.EDU id aa05476; 2 Oct 95 14:30 PDT Received: from civilgate.ce.uiuc.edu (node-2f4ba.ce.uiuc.edu) by uxc.cso.uiuc.edu with SMTP id AA06013 (5.67b8/IDA-1.5 for ); Mon, 2 Oct 1995 16:29:35 -0500 Received: by civilgate.ce.uiuc.edu ( 5.52 (84)/9.7) id AA03065; Mon, 2 Oct 95 16:20:23 CDT Date: Mon, 2 Oct 95 16:20:23 CDT From: "Leonard A. Lopez - Faculty" Message-Id: <9510022120.AA03065@civilgate.ce.uiuc.edu> To: bug-chimera@cs.unlv.edu I have been using Chimera 1.65 on an Apollo. I also have a copy of Michael Kellen's Perl script, postto.pl, for posting to the news groups. The script has a February 1995 date. I modified the script to put my name and organization on the header etc... However, the "guts" remain unchanged. When I post to our test news group at the Univ. of Illinois, the message always gets through intact. However, in most instances, when I post to other groups the message either gets totally eliminated, or partially eliminated. The only constant is the appearance of the symbols 3F. Thus, I might get: just a 3F a message followed by 3F a 3F followed by the remainder of the message. What does it mean? Does anybody else have the problem, and does anybody know how to fix it? Any help would be greatly appreciated. Len Lopez l-lopez@uiuc.edu ------- Message 4 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa02800; 3 Oct 95 4:27 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id MAA06510 for cs.unlv.edu!bug-chimera; Tue, 3 Oct 1995 12:45:44 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t05L3-0003kDC; Tue, 3 Oct 95 12:16 MET Message-Id: From: Erik Corry Subject: New image code and Jpeg To: bug-chimera@cs.unlv.edu Date: Tue, 3 Oct 1995 12:16:44 +0100 (MET) Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2645 A few notes on the release 80 and the new Jpeg code: You can find version 6 of the jpeg libraries at ftp://ftp.uu.net/graphics The jpeg-6 directory should be a subdir of the cfh80-2.0/image directory. You can make this a link if you prefer. You need to compile the library (libjpeg.a) with decompression support. Having compression support in it too doesn't hurt. This library is super-portable, so it should be fairly simple to compile. It is probably important not to compile Chimera with a K&R compiler and the Jpeg lib with an ANSI compiler, but to make sure the compiler (settings) match. With this you should get support for the new progressive Jpegs being displayed progressively. If you would rather just test without Jpeg for the time being, you can comment out the 'Use_Jpeg' in Common.tmpl. In this release Gif, Jpeg, Pnm and Xbm files should display inline. This should work on 1, 2, 4, 8, 12/15/16, 24 and 32 bit X displays, both grayscale and color. So please test it on as many different screens as possible. If you can, please also test on cross-endian connections ie. Chimera is compiled on a little-endian machine, but displaying on a big-endian X- terminal, or vice-versa. Transparent colors should work. In the default setting Chimera now grabs rather a lot of colors when displaying Gifs on 8-bit pseudocolor screens. This makes Gifs look good. There are basically three modes (selected with environment variables at the moment): 1) Be nice to GIFs (the current default) 2) Be nice to JPEGs (currently activated with CHIMERA_AGGRESSIVE_COLORS) 3) Be nice to other programs (currently activated with CHIMERA_MAX_SPECIAL_COLORS=0) People who do not have 8-bit pseudocolor screens need not worry about this stuff. If anybody has a 12-bit screen I would really like you to mail me the output of 'xdpyinfo'. I'm not entirely convinced that these things really exist. What still doesn't work is scaling images and background images. Background images don't really work without the ability to set the text color, but there's no way to do that in HTML-2 or HTML-3. The clean solution is to one day support style sheets. PNG files are not yet supported. XPM probably never will be (shout now if you think you really need XPM!). By the way, on an unrelated note, Chimera does not support the Netscape- hack
, but it does support

. Netscape also supports

, so there's no reason why all those 'enhanced for Netscape' pages shouldn't be written in real HTML. If you see people using

, please bug them politely to change to

. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 5 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa10685; 3 Oct 95 9:33 PDT Received: from noc.msc.edu by JIMI.CS.UNLV.EDU id aa10418; 3 Oct 95 9:23 PDT Received: from kv.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA21107; Tue, 3 Oct 95 11:23:13 -0500 Message-Id: <9510031623.AA21107@noc.msc.edu> To: John Kilburg Cc: chimera-announce@little-charlie.isri.unlv.edu Subject: Re: chimera 2.0 alpha 80 Date: Tue, 03 Oct 1995 11:23:12 -0500 From: Steve Oyanagi An interesting side bug - chimera 2.0 alpha 80 doesn't work on mono displays. It core dumps trying to display gifs to a mono display. [sm 5.4] (517) % test-chimera https://www.msc.edu Segmentation Fault - core dumped [sm 5.4] (519) % test-chimera d GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.8, Copyright 1993 Free Software Foundation, Inc... Core was generated by `src/chimera https://www.msc.edu'. Program terminated with signal 11, Segmentation fault. #0 0x0 in ?? () (gdb) where #0 0x0 in ?? () #1 0x2d070 in gs_decode_data (gs=0x92848) at gif.c:601 #2 0x2d274 in gifAddData (pointer=0x92848, data=0x9c4e8 "GIF89a\234\001\222", len=512, data_ended=false) at gif.c:678 #3 0x2a7cc in ImageAddData (is=0x91fd0, data=0x9c4e8, len=512) at image.c:1004 #4 0x1ef54 in HandleInlineDocument (d=0x827e8, closure=0x8e59c, status=0) at inline.c:345 #5 0x498d8 in http_data (s=5, t=0x9c4e8, tlen=512, eof=0, closure=0x8bfd0 "") at http.c:433 #6 0x1b4e0 in ReadStreamHandler (cldata=0x8ea98, netfd=0x8b4ac, xid=0xdffff984) at io.c:442 #7 0xdf6e0374 in scrollbarWidgetClass () #8 0xdf6e06b4 in scrollbarWidgetClass () #9 0xdf6d7b24 in scrollbarWidgetClass () #10 0x1555c in main (argc=2, argv=0xdffffbf4) at main.c:166 (gdb) Chimera 2.0 alpha 80 does display gifs on color displays here. I haven't tried the previous few betas, so I can't tell you at what point things stopped working. - Steve ------- Message 6 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa18091; 3 Oct 95 13:05 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id OAA13232; Tue, 3 Oct 1995 14:01:41 -0600 Date: Tue, 3 Oct 1995 14:01:33 -0600 (MDT) From: Michael Kellen To: Chimera Hacker List Subject: It Don't Work In-Reply-To: <199508042332.RAA07309@xph029.physics.montana.edu> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1520026096-1463681342-812750493=:13211" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --1520026096-1463681342-812750493=:13211 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry john, but cfh80-2.0 is a complete loss. Images are not rendered. LINKS are not active (no underline, no color, no functionality) which kinda defeats the whole purpose of a browser. And the source view invokes aXe, which is not installed on my platform (yes, I know, I can set it to something else, but it is bad to assume an editor that isn't bundled with X11). Oh yeah, and test-chimera lists the resource files as "crap" rather than their correct filenames. Forms don't work either. I'm sticking with 72 ... Michael This is with: gcc version 2.6.3 XFree86-3.1.2 Linux 1.2.13 (ELF/POSIX) jpeg-6 - --1520026096-1463681342-812750493=:13211 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=err Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Makefile Errors eGJtLmM6MTk6IHdhcm5pbmc6IGBsY19yZXZlcnNlX2J5dGUnIGRlZmluZWQg YnV0IG5vdCB1c2VkDQppbWFnZS5jOiBJbiBmdW5jdGlvbiBgbGZfc2V0X3Vw X2V4cGFuc2lvbic6DQppbWFnZS5jOjMyMjogd2FybmluZzogYXNzaWdubWVu dCBmcm9tIGluY29tcGF0aWJsZSBwb2ludGVyIHR5cGUNCmltYWdlLmM6MzI0 OiB3YXJuaW5nOiBhc3NpZ25tZW50IGZyb20gaW5jb21wYXRpYmxlIHBvaW50 ZXIgdHlwZQ0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC91c3IvaW5jbHVkZS9q cGVnbGliLmg6MjQsDQogICAgICAgICAgICAgICAgIGZyb20ganBlZ3AuaDox OSwNCiAgICAgICAgICAgICAgICAgZnJvbSBqcGVnLmM6MjQ6DQovdXNyL2lu Y2x1ZGUvamNvbmZpZy5oOjEyOiB3YXJuaW5nOiBgSEFWRV9TVERMSUJfSCcg cmVkZWZpbmVkDQoqSW5pdGlhbGl6YXRpb24qOjE6IHdhcm5pbmc6IHRoaXMg aXMgdGhlIGxvY2F0aW9uIG9mIHRoZSBwcmV2aW91cyBkZWZpbml0aW9uDQpX V1cuYzoyNjY6IHdhcm5pbmc6IGBXV1dEZXN0cm95JyBkZWZpbmVkIGJ1dCBu b3QgdXNlZA0KaW5saW5lLmM6IEluIGZ1bmN0aW9uIGBQcm9jZXNzSW5saW5l RG9jdW1lbnQnOg0KaW5saW5lLmM6MzA1OiB3YXJuaW5nOiBwYXNzaW5nIGFy ZyAzIG9mIGBJbWFnZUluaXQnIGZyb20gaW5jb21wYXRpYmxlIHBvaW50ZXIg dHlwZQ0KZG9jLmM6IEluIGZ1bmN0aW9uIGBEaXNwbGF5RmlsZUV4dGVybmFs JzoNCmRvYy5jOjc3OiB3YXJuaW5nOiBpbXBsaWNpdCBkZWNsYXJhdGlvbiBv ZiBmdW5jdGlvbiBgdW5saW5rJw0KZG9jLmM6ODM6IHdhcm5pbmc6IGltcGxp Y2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGBmb3JrJw0KbWFpbi5jOjcx Mjogd2FybmluZzogYHh0V2FybmluZ0hhbmRsZXInIGRlZmluZWQgYnV0IG5v dCB1c2VkDQo= - --1520026096-1463681342-812750493=:13211-- ------- Message 7 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa18730; 3 Oct 95 13:25 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id OAA13499; Tue, 3 Oct 1995 14:20:55 -0600 Date: Tue, 3 Oct 1995 14:20:40 -0600 (MDT) From: Michael Kellen To: "Leonard A. Lopez - Faculty" cc: bug-chimera@cs.unlv.edu Subject: [chimera] *to.pl and 3F In-Reply-To: <9510022120.AA03065@civilgate.ce.uiuc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Oct 1995, Leonard A. Lopez - Faculty wrote: > What does it mean? Does anybody else have the problem, and > does anybody know how to fix it? (1) The March release has a slightly better parser. I haven't really worked on it in a while. I just haven't had time. (2) chimera, forms and X do not all work and play well together. Specifically, the cut-and-paste into a textarea *SEEMS* to input into the field, but the output of show.pl indicates that it is not actually put into the form. (???) 3F is of course '?' hex. Michael ------- Message 8 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa20133; 3 Oct 95 13:56 PDT To: Michael Kellen cc: Chimera Hacker List Subject: Re: It Don't Work In-reply-to: Your message of "Tue, 03 Oct 1995 14:01:33 MDT." Date: Tue, 03 Oct 1995 13:56:17 -0700 From: John Kilburg Well, it's alpha software after all :) although I'm kind of surprised because it has worked very well for me. -john >Sorry john, but cfh80-2.0 is a complete loss. > >Images are not rendered. LINKS are not active (no underline, no color, no >functionality) which kinda defeats the whole purpose of a browser. And >the source view invokes aXe, which is not installed on my platform (yes, I >know, I can set it to something else, but it is bad to assume an editor >that isn't bundled with X11). Oh yeah, and test-chimera lists the >resource files as "crap" rather than their correct filenames. Forms don't >work either. I'm sticking with 72 ... ------- Message 9 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa20591; 3 Oct 95 14:13 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id WAA03483 for cs.unlv.edu!bug-chimera; Tue, 3 Oct 1995 22:30:05 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0E7X-0003kJC; Tue, 3 Oct 95 21:39 MET Message-Id: From: Erik Corry Subject: Re: chimera 2.0 alpha 80 To: bug-chimera@cs.unlv.edu Date: Tue, 3 Oct 1995 21:39:22 +0100 (MET) In-Reply-To: <9510031623.AA21107@noc.msc.edu> from "Steve Oyanagi" at Oct 3, 95 11:23:12 am Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5055 Steve Oyanagi wrote: > An interesting side bug - chimera 2.0 alpha 80 doesn't work on mono > displays. It core dumps trying to display gifs to a mono display. OK, I admit it, 1-bit support was seriously broken. Here's a patch that makes it work. Also corrects some endianism problems for 1, 2 and 4-bit screens and a bug that caused the last few lines of a jpeg not to be displayed (this part is the same as I already sent you, John, so patch will complain about already applied patches. Sorry). diff -u --recursive --exclude-from exclusions cfh80-2.0/image/dispdither.c cfh80-2.0-erik//image/dispdither.c - --- cfh80-2.0/image/dispdither.c Tue Sep 19 08:09:44 1995 +++ cfh80-2.0-erik//image/dispdither.c Tue Oct 3 21:03:36 1995 @@ -24,6 +24,7 @@ #include "imagep.h" #include "colorcube.h" #include "dispdither.h" +#include "endian.h" /* * The dither routines all end up in a tight loop that has no: @@ -501,7 +502,7 @@ t |= table->pixel_values[2][b] << 5; b = input[3]; t |= table->pixel_values[3][b] << 4; - - b = input[4] << 6; + b = input[4]; t |= table->pixel_values[0][b] << 3; b = input[5]; t |= table->pixel_values[1][b] << 2; diff -u --recursive --exclude-from exclusions cfh80-2.0/image/image.c cfh80-2.0-erik//image/image.c - --- cfh80-2.0/image/image.c Wed Sep 20 09:32:06 1995 +++ cfh80-2.0-erik//image/image.c Tue Oct 3 21:09:41 1995 @@ -52,6 +52,8 @@ ddt_dither_fn dither_function; /* Function to dither/convert with */ bool dithering; bool data_ended; + void *last_data; + int last_len; XImage *xi; /* X image */ @@ -464,6 +466,9 @@ for (i = 0; i < 4; i++) ips->gray_tables[i].eight_8_dither = ccf_create_gray_dither_table(i, 4, 4, ips->grayscale); + /* In case we end up with a 1-bit image */ + is->fg = ips->grayscale->u.grayscale.pixel_values[1]; + is->bg = ips->grayscale->u.grayscale.pixel_values[0]; if (image_type == IRGB || image_type == IGRAY) { /* @@ -713,7 +718,7 @@ if (image->pixlen == 1) depth = 1; else depth = ips->depth; - - if(depth == 1) + if(image->depth == 1) { lf_set_up_bitmap(is); if(is->expansion_buf) @@ -767,7 +772,7 @@ { XAddPixel(is->xi, ips->bgcolor.pixel); } - - if(depth != 1 || is->expansion_buf) + if(image->depth != 1 || is->expansion_buf) { lf_set_up_dither(is); } @@ -811,11 +816,18 @@ { expanded_input = input; } - - is->dither_function(is->dither_table[line & 3], - - expanded_input, - - output, - - is->xi->bits_per_pixel, - - image->width); + if(is->dither_function) + { + is->dither_function(is->dither_table[line & 3], + expanded_input, + output, + is->xi->bits_per_pixel, + image->width); + } + else + { + printf("Warning:no dither function defined for image\n"); + } } } @@ -998,6 +1010,8 @@ if(debug_add_data_procs == -1) debug_add_data_procs = !!getenv("CHIMERA_DEBUG_ADD_DATA_PROCS"); + isp->last_data = data; + isp->last_len = len; if (isp->if_vector.addDataProc && isp->if_vector.image_format_closure) { if(!debug_add_data_procs) @@ -1034,6 +1048,7 @@ { struct ccs_image_state *isp = (struct ccs_image_state *)is; isp->data_ended = true; + ImageAddData(is, isp->last_data, isp->last_len); return; } Only in cfh80-2.0-erik//image: jpeg-6 diff -u --recursive --exclude-from exclusions cfh80-2.0/image/xcolorcube.c cfh80-2.0-erik//image/xcolorcube.c - --- cfh80-2.0/image/xcolorcube.c Tue Sep 19 08:18:37 1995 +++ cfh80-2.0-erik//image/xcolorcube.c Tue Oct 3 21:20:29 1995 @@ -515,13 +515,25 @@ status = XAllocColor(display, colormap, &try); if(status) { - - *special_return = try.pixel; - - specials[special_count].pixel = try.pixel; - - specials[special_count].brightnesses[0] = try.red >> 8; - - specials[special_count].brightnesses[1] = try.green >> 8; - - specials[special_count].brightnesses[2] = try.blue >> 8; - - if(really_allocated_return) *really_allocated_return = true; - - return true; + if(!xccf_color_compare( + intensities[0] >> 8, intensities[1] >> 8, + intensities[2] >> 8, try.red >> 8, try.green >> 8, + try.blue >> 8)) + { + /* The server gave us a color but it was a really bad match */ + XFreeColors(display, colormap, &try.pixel, 1, 0); + } + else + { + /* The server gave us a color that worked. */ + *special_return = try.pixel; + specials[special_count].pixel = try.pixel; + specials[special_count].brightnesses[0] = try.red >> 8; + specials[special_count].brightnesses[1] = try.green >> 8; + specials[special_count].brightnesses[2] = try.blue >> 8; + if(really_allocated_return) *really_allocated_return = true; + return true; + } } } return false; - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 10 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa20924; 3 Oct 95 14:23 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id WAA03484; Tue, 3 Oct 1995 22:30:06 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0EVp-0003kOC; Tue, 3 Oct 95 22:04 MET Message-Id: From: Erik Corry Subject: Re: It Don't Work To: Michael Kellen Date: Tue, 3 Oct 1995 22:04:28 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: from "Michael Kellen" at Oct 3, 95 02:01:33 pm Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 688 > > Images are not rendered. What sort of an X display do you have? Could you send me the output of xdpyinfo? Do no images display at all, or what? > [..] > the source view invokes aXe, which is not installed on my platform (yes, I > [..] > work either. I'm sticking with 72 ... The aXe stuff hasn't changed since 72, has it? > [..] > gcc version 2.6.3 Isn't this supposed to be a buggy compiler on Linux? I don't think optimisation works properly. > XFree86-3.1.2 > Linux 1.2.13 (ELF/POSIX) > jpeg-6 > Content-Description: Makefile Errors These errors are all harmless, though it is clearly desirable to eliminate them anyway. > [errors] - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 11 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa22532; 3 Oct 95 14:46 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id PAA14076; Tue, 3 Oct 1995 15:42:30 -0600 Date: Tue, 3 Oct 1995 15:42:23 -0600 (MDT) From: Michael Kellen To: Erik Corry cc: Chimera Hacker List Subject: More Linux Failure info In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1520026096-1671421686-812756543=:14027" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --1520026096-1671421686-812756543=:14027 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 Oct 1995, Erik Corry wrote: > What sort of an X display do you have? Could you send me the output > of xdpyinfo? Do no images display at all, or what? No images were displayed whatsoever. Neither with nor without using the jpeg-6 libarary support. It all worked fine under the code in 72 (the last ALPHA I had access to). > The aXe stuff hasn't changed since 72, has it? The source viewer was "xedit" by default in 72. > Isn't this supposed to be a buggy compiler on Linux? I don't think > optimisation works properly. It works just fine on everything I've tried. Besides, I also tried compiling with all optimisations off to no better effect. And that's no excuse for silently not working. >> Content-Description: Makefile Errors > These errors are all harmless, though it is clearly desirable to eliminate > them anyway. Yeah, I know. I just thought I'd include 'em for just that reason. Also, here's the httpd access log for a page with several inlines: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xph029.physics.montana.edu - - [03/Oct/1995:15:38:02 -0600] "GET /~michael/ HTTP/1.0" 200 1073 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ And that's it. So the parser is never requesting the image. Seems to be a collection of parser problems under Linux. Michael - --1520026096-1671421686-812756543=:14027 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="xdpyinfo.out" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Output of xdpyinfo bmFtZSBvZiBkaXNwbGF5OiAgICB4cGgwMjkucGh5c2ljcy5tb250YW5hLmVk dTowLjANCnZlcnNpb24gbnVtYmVyOiAgICAxMS4wDQp2ZW5kb3Igc3RyaW5n OiAgICBUaGUgWEZyZWU4NiBQcm9qZWN0LCBJbmMNCnZlbmRvciByZWxlYXNl IG51bWJlcjogICAgMzEyMA0KbWF4aW11bSByZXF1ZXN0IHNpemU6ICA0MTk0 MzAwIGJ5dGVzDQptb3Rpb24gYnVmZmVyIHNpemU6ICAwDQpiaXRtYXAgdW5p dCwgYml0IG9yZGVyLCBwYWRkaW5nOiAgICAzMiwgTFNCRmlyc3QsIDMyDQpp bWFnZSBieXRlIG9yZGVyOiAgICBMU0JGaXJzdA0KbnVtYmVyIG9mIHN1cHBv cnRlZCBwaXhtYXAgZm9ybWF0czogICAgMg0Kc3VwcG9ydGVkIHBpeG1hcCBm b3JtYXRzOg0KICAgIGRlcHRoIDEsIGJpdHNfcGVyX3BpeGVsIDEsIHNjYW5s aW5lX3BhZCAzMg0KICAgIGRlcHRoIDgsIGJpdHNfcGVyX3BpeGVsIDgsIHNj YW5saW5lX3BhZCAzMg0Ka2V5Y29kZSByYW5nZTogICAgbWluaW11bSA4LCBt YXhpbXVtIDE1Nw0KZm9jdXM6ICB3aW5kb3cgMHgzMDAwMDBkLCByZXZlcnQg dG8gUGFyZW50DQpudW1iZXIgb2YgZXh0ZW5zaW9uczogICAgMTANCiAgICBC SUctUkVRVUVTVFMNCiAgICBNSVQtU0NSRUVOLVNBVkVSDQogICAgTUlULVNI TQ0KICAgIE1JVC1TVU5EUlktTk9OU1RBTkRBUkQNCiAgICBNdWx0aS1CdWZm ZXJpbmcNCiAgICBTSEFQRQ0KICAgIFNZTkMNCiAgICBYQy1NSVNDDQogICAg WEZyZWU4Ni1WaWRNb2RlRXh0ZW5zaW9uDQogICAgWFRFU1QNCmRlZmF1bHQg c2NyZWVuIG51bWJlcjogICAgMA0KbnVtYmVyIG9mIHNjcmVlbnM6ICAgIDEN Cg0Kc2NyZWVuICMwOg0KICBkaW1lbnNpb25zOiAgICAxMDI0eDEwMjQgcGl4 ZWxzICgzNDd4MzQ3IG1pbGxpbWV0ZXJzKQ0KICByZXNvbHV0aW9uOiAgICA3 NXg3NSBkb3RzIHBlciBpbmNoDQogIGRlcHRocyAoMik6ICAgIDEsIDgNCiAg cm9vdCB3aW5kb3cgaWQ6ICAgIDB4MmENCiAgZGVwdGggb2Ygcm9vdCB3aW5k b3c6ICAgIDggcGxhbmVzDQogIG51bWJlciBvZiBjb2xvcm1hcHM6ICAgIG1p bmltdW0gMSwgbWF4aW11bSAxDQogIGRlZmF1bHQgY29sb3JtYXA6ICAgIDB4 MjENCiAgZGVmYXVsdCBudW1iZXIgb2YgY29sb3JtYXAgY2VsbHM6ICAgIDI1 Ng0KICBwcmVhbGxvY2F0ZWQgcGl4ZWxzOiAgICBibGFjayAwLCB3aGl0ZSAx DQogIG9wdGlvbnM6ICAgIGJhY2tpbmctc3RvcmUgWUVTLCBzYXZlLXVuZGVy cyBZRVMNCiAgbGFyZ2VzdCBjdXJzb3I6ICAgIDEwMjR4MTAyNA0KICBjdXJy ZW50IGlucHV0IGV2ZW50IG1hc2s6ICAgIDB4NTAwMDNkDQogICAgS2V5UHJl c3NNYXNrICAgICAgICAgICAgIEJ1dHRvblByZXNzTWFzayAgICAgICAgICBC dXR0b25SZWxlYXNlTWFzayAgICAgICAgDQogICAgRW50ZXJXaW5kb3dNYXNr ICAgICAgICAgIExlYXZlV2luZG93TWFzayAgICAgICAgICBTdWJzdHJ1Y3R1 cmVSZWRpcmVjdE1hc2sgDQogICAgUHJvcGVydHlDaGFuZ2VNYXNrICAgICAg IA0KICBudW1iZXIgb2YgdmlzdWFsczogICAgNg0KICBkZWZhdWx0IHZpc3Vh bCBpZDogIDB4MjINCiAgdmlzdWFsOg0KICAgIHZpc3VhbCBpZDogICAgMHgy Mg0KICAgIGNsYXNzOiAgICBQc2V1ZG9Db2xvcg0KICAgIGRlcHRoOiAgICA4 IHBsYW5lcw0KICAgIGF2YWlsYWJsZSBjb2xvcm1hcCBlbnRyaWVzOiAgICAy NTYNCiAgICByZWQsIGdyZWVuLCBibHVlIG1hc2tzOiAgICAweDAsIDB4MCwg MHgwDQogICAgc2lnbmlmaWNhbnQgYml0cyBpbiBjb2xvciBzcGVjaWZpY2F0 aW9uOiAgICA2IGJpdHMNCiAgdmlzdWFsOg0KICAgIHZpc3VhbCBpZDogICAg MHgyMw0KICAgIGNsYXNzOiAgICBEaXJlY3RDb2xvcg0KICAgIGRlcHRoOiAg ICA4IHBsYW5lcw0KICAgIGF2YWlsYWJsZSBjb2xvcm1hcCBlbnRyaWVzOiAg ICA4IHBlciBzdWJmaWVsZA0KICAgIHJlZCwgZ3JlZW4sIGJsdWUgbWFza3M6 ICAgIDB4NywgMHgzOCwgMHhjMA0KICAgIHNpZ25pZmljYW50IGJpdHMgaW4g Y29sb3Igc3BlY2lmaWNhdGlvbjogICAgNiBiaXRzDQogIHZpc3VhbDoNCiAg ICB2aXN1YWwgaWQ6ICAgIDB4MjQNCiAgICBjbGFzczogICAgR3JheVNjYWxl DQogICAgZGVwdGg6ICAgIDggcGxhbmVzDQogICAgYXZhaWxhYmxlIGNvbG9y bWFwIGVudHJpZXM6ICAgIDI1Ng0KICAgIHJlZCwgZ3JlZW4sIGJsdWUgbWFz a3M6ICAgIDB4MCwgMHgwLCAweDANCiAgICBzaWduaWZpY2FudCBiaXRzIGlu IGNvbG9yIHNwZWNpZmljYXRpb246ICAgIDYgYml0cw0KICB2aXN1YWw6DQog ICAgdmlzdWFsIGlkOiAgICAweDI1DQogICAgY2xhc3M6ICAgIFN0YXRpY0Nv bG9yDQogICAgZGVwdGg6ICAgIDggcGxhbmVzDQogICAgYXZhaWxhYmxlIGNv bG9ybWFwIGVudHJpZXM6ICAgIDI1Ng0KICAgIHJlZCwgZ3JlZW4sIGJsdWUg bWFza3M6ICAgIDB4NywgMHgzOCwgMHhjMA0KICAgIHNpZ25pZmljYW50IGJp dHMgaW4gY29sb3Igc3BlY2lmaWNhdGlvbjogICAgNiBiaXRzDQogIHZpc3Vh bDoNCiAgICB2aXN1YWwgaWQ6ICAgIDB4MjYNCiAgICBjbGFzczogICAgVHJ1 ZUNvbG9yDQogICAgZGVwdGg6ICAgIDggcGxhbmVzDQogICAgYXZhaWxhYmxl IGNvbG9ybWFwIGVudHJpZXM6ICAgIDggcGVyIHN1YmZpZWxkDQogICAgcmVk LCBncmVlbiwgYmx1ZSBtYXNrczogICAgMHg3LCAweDM4LCAweGMwDQogICAg c2lnbmlmaWNhbnQgYml0cyBpbiBjb2xvciBzcGVjaWZpY2F0aW9uOiAgICA2 IGJpdHMNCiAgdmlzdWFsOg0KICAgIHZpc3VhbCBpZDogICAgMHgyNw0KICAg IGNsYXNzOiAgICBTdGF0aWNHcmF5DQogICAgZGVwdGg6ICAgIDggcGxhbmVz DQogICAgYXZhaWxhYmxlIGNvbG9ybWFwIGVudHJpZXM6ICAgIDI1Ng0KICAg IHJlZCwgZ3JlZW4sIGJsdWUgbWFza3M6ICAgIDB4MCwgMHgwLCAweDANCiAg ICBzaWduaWZpY2FudCBiaXRzIGluIGNvbG9yIHNwZWNpZmljYXRpb246ICAg IDYgYml0cw0K - --1520026096-1671421686-812756543=:14027-- ------- Message 12 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa00755; 3 Oct 95 19:14 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id SAA14639; Tue, 3 Oct 1995 18:48:50 -0600 Date: Tue, 3 Oct 1995 18:48:50 -0600 From: Michael Kellen Message-Id: <199510040048.SAA14639@xph029.physics.montana.edu> Subject: [ANNOUNCE] mailto.pl version 2.0 To: Chimera Hacker List Reply-To: Michael Kellen I have done a major revision of mailto.pl. The current version should handle cut-and-paste and punctuation properly. It still does not properly enforce the size of TEXTAREAS, nor will it word-wrap. Those are FORMS support problems. The official site is ftp://xph029.physics.montana.edu/pub/source/mailto.pl https://xph029.physics.montana.edu/chimera/mailto.pl If anyone can read this ... it works. The update of postto.pl should follow in a couple of days. I have work to do. - -- Why yes, I *am* a rocket scientist. ------- Message 13 Received: from isy.liu.se by JIMI.CS.UNLV.EDU id aa14104; 4 Oct 95 1:38 PDT Received: from dagobert.isy.liu.se by isy.liu.se (5.65b/isy.minimaster-V1.0b2) id AA17752; Wed, 4 Oct 95 09:38:20 +0100 Received: from dtr-gw.isy.liu.se (lancelot) by dagobert.isy.liu.se (4.0/SMI-4.0) id AA15449; Wed, 4 Oct 95 09:38:15 +0100 Received: from ladon.YP.krikelin by dtr-gw.isy.liu.se (4.1/SMI-4.1) id AA12722; Wed, 4 Oct 95 09:38:10 +0100 Received: by ladon.YP.krikelin (4.1/SMI-4.1) id AA14010; Wed, 4 Oct 95 09:38:08 +0100 Date: Wed, 4 Oct 1995 09:38:07 +0100 (MET) From: Jean-Jacques Moulis X-Sender: jj@ladon To: John Kilburg Cc: Chimera Hacker List Subject: Re: It Don't Work In-Reply-To: <9510032201.AA14332@isy.liu.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 Oct 1995, John Kilburg wrote: > Well, it's alpha software after all :) although I'm kind of surprised > because it has worked very well for me. > > -john > > >Sorry john, but cfh80-2.0 is a complete loss. > > > >Images are not rendered. LINKS are not active (no underline, no color, no > >functionality) which kinda defeats the whole purpose of a browser. And > >the source view invokes aXe, which is not installed on my platform (yes, I > >know, I can set it to something else, but it is bad to assume an editor > >that isn't bundled with X11). Oh yeah, and test-chimera lists the > >resource files as "crap" rather than their correct filenames. Forms don't > >work either. I'm sticking with 72 ... cfh80-2.0 works at least as well as cfh72-2.0, If it's a kind of consolation. However clicking on links still don't work with some windows managers ie. olwm. Inline Jpegs are not rendered even with Use_JPEG turned on. SunOS 4.1.3 gcc version 2.6.3 X11R5 - ------------------------------------------------------------------------------- Jean-Jacques Moulis Phone: +46-13281684 Dept of Electrical Engineering Fax: +46-13281339 S-581 83 Linkoeping University, Sweden Internet: jj@isy.liu.se - ------------------------------------------------------------------------------- ------- Message 14 Received: from srv01s4.cas.org by JIMI.CS.UNLV.EDU id aa16089; 4 Oct 95 3:56 PDT Date: Wed, 4 Oct 1995 06:56:31 -0400 From: "Larry W. Virden, x2487" Message-Id: <9510040656.AA23091@cas.org> Subject: Re: chimera 2.0 alpha 80 In-Reply-To: of Tue, 3 Oct 1995 21:39:22 +0100 (MET) To: bug-chimera@cs.unlv.edu I came in late to the picture, so I was surprised to hear that chimera doesn't work with olwm (and in fact olvwm as well). Anyone know a) what the problem is and b) how to fix it? Changing window managers is not an option here. This is the only time I have encountered an X program which would not operate under ol*wm. - -- Larry W. Virden INET: lvirden@cas.org is here! Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. ------- Message 15 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa17234; 4 Oct 95 4:54 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id NAA10801; Wed, 4 Oct 1995 13:12:20 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0SHC-0003kCC; Wed, 4 Oct 95 12:46 MET Message-Id: From: Erik Corry Subject: Re: It Don't Work To: Jean-Jacques Moulis Date: Wed, 4 Oct 1995 12:46:18 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: from "Jean-Jacques Moulis" at Oct 4, 95 09:38:07 am Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 > Inline Jpegs are not rendered even with Use_JPEG turned on. :-( Do they fail silently or does Chimera crash, or do they display as a black square or is there an error message on the terminal? What sort of X display do you use (xdpyinfo)? Is space reserved for the image in the layout? Did you already apply my posted patch? The command is patch -p1 < mail_message from the cfh80-2.0 directory (I think). If you don't have patch (by Larry Wall) I could send you the altered files. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 16 Received: from isy.liu.se by JIMI.CS.UNLV.EDU id aa17895; 4 Oct 95 5:25 PDT Received: from dagobert.isy.liu.se by isy.liu.se (5.65b/isy.minimaster-V1.0b2) id AA20784; Wed, 4 Oct 95 13:25:46 +0100 Received: from dtr-gw.isy.liu.se (lancelot) by dagobert.isy.liu.se (4.0/SMI-4.0) id AA16417; Wed, 4 Oct 95 13:25:47 +0100 Received: from ladon.YP.krikelin by dtr-gw.isy.liu.se (4.1/SMI-4.1) id AA12858; Wed, 4 Oct 95 13:25:42 +0100 Received: by ladon.YP.krikelin (4.1/SMI-4.1) id AA14425; Wed, 4 Oct 95 13:25:34 +0100 Date: Wed, 4 Oct 1995 13:25:33 +0100 (MET) From: Jean-Jacques Moulis X-Sender: jj@ladon To: Erik Corry Cc: bug-chimera@cs.unlv.edu Subject: Re: It Don't Work In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Oct 1995, Erik Corry wrote: > > Inline Jpegs are not rendered even with Use_JPEG turned on. > > :-( > > Do they fail silently or does Chimera crash, or do they display as a > black square or is there an error message on the terminal? What > sort of X display do you use (xdpyinfo)? Is space reserved for the image > in the layout? It fail silently doesn't crash and no messages > Did you already apply my posted patch? The command is > > patch -p1 < mail_message > No I didn't , I never saw it or was too fast in deleting it. > from the cfh80-2.0 directory (I think). If you don't have patch (by > Larry Wall) I could send you the altered files. > > -- Please do. ------- Message 17 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa18195; 4 Oct 95 5:44 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id OAA13081 for cs.unlv.edu!bug-chimera; Wed, 4 Oct 1995 14:01:06 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0T7C-0003kIC; Wed, 4 Oct 95 13:40 MET Message-Id: From: Erik Corry Subject: Re: chimera 2.0 alpha 80 To: bug-chimera@cs.unlv.edu Date: Wed, 4 Oct 1995 13:40:00 +0100 (MET) In-Reply-To: <9510040656.AA23091@cas.org> from "Larry W. Virden, x2487" at Oct 4, 95 06:56:31 am Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 994 > > I came in late to the picture, so I was surprised to hear that chimera > doesn't work with olwm (and in fact olvwm as well). Anyone know a) what > the problem is and b) how to fix it? Changing window managers is not an > option here. This is the only time I have encountered an X program which > would not operate under ol*wm. But it's not the only program with this problem. In the open-look FAQ I find the related problem: > Subject: Trouble Shooting: It Won't Let Me Type > @ When I try to type into some programs, I just get beeps or nothing happens > It is a good idea to include at least: > OpenWindows.FocusLenience: true > *Input: TRUE > in your .Xdefaults file, as these allow non-ICCCM-compliant programs to > receive input even if they forget to ask for it. > See the next item for editing .Xdefaults This also works for links in Chimera (and may provide a clue for John for solving the problem). - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 18 Received: from srv01s4.cas.org by JIMI.CS.UNLV.EDU id aa21496; 4 Oct 95 8:06 PDT Date: Wed, 4 Oct 1995 11:06:10 -0400 From: "Larry W. Virden, x2487" Message-Id: <9510041106.AA26844@cas.org> Subject: Re: chimera 2.0 alpha 80 In-Reply-To: of Wed, 4 Oct 1995 13:40:00 +0100 (MET) To: bug-chimera@cs.unlv.edu I added the two resources to my environment, logged off and back on. Chimera still does not recognize clicks on hypertext links. Note that the buttons like help, etc. work just fine, as does inline gifs. This is on Solaris 2.4, using Sun's unbundled c compiler. - -- Larry W. Virden INET: lvirden@cas.org is here! Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. ------- Message 19 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa28163; 4 Oct 95 11:21 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id MAA16371; Wed, 4 Oct 1995 12:17:39 -0600 Date: Wed, 4 Oct 1995 12:17:33 -0600 (MDT) From: Michael Kellen To: Chimera Hacker List Subject: It isn't the compiler Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just upgraded to gcc 2.7.0 ... links still don't work, images are still not requested. It's the code, not the compiler. Sorry, Michael ------- Message 20 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa02037; 4 Oct 95 13:10 PDT Received: from kroete2.freinet.de (root@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id VAA05725 for cs.unlv.edu!bug-chimera; Wed, 4 Oct 1995 21:25:04 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0Vwq-0003kOC; Wed, 4 Oct 95 16:41 MET Message-Id: From: Erik Corry Subject: text/plain To: bug-chimera@cs.unlv.edu Date: Wed, 4 Oct 1995 16:41:29 +0100 (MET) Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 176 Things don't seem to be working right when Chimera displays a file that has content-type text/plain if lines in the file start with a '>'. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 21 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa02041; 4 Oct 95 13:10 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id VAA05733 for cs.unlv.edu!bug-chimera; Wed, 4 Oct 1995 21:25:16 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0XYG-0003kRC; Wed, 4 Oct 95 18:24 MET Message-Id: From: Erik Corry Subject: Local Gifs being overwritten. To: bug-chimera@cs.unlv.edu Date: Wed, 4 Oct 1995 18:24:16 +0100 (MET) Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 250 A really mean bug in alpha 80 overwrites Gifs that were recently loaded with 'file:' URLs when you change your bookmarks. So make sure you do not view any local images you are fond of without taking a copy first. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 22 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa02060; 4 Oct 95 13:11 PDT Received: from kroete2.freinet.de (root@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id VAA05734; Wed, 4 Oct 1995 21:25:18 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0ZvT-0003kJC; Wed, 4 Oct 95 20:56 MET Message-Id: From: Erik Corry Subject: Re: chimera 2.0 alpha 80 To: "Larry W. Virden x2487" Date: Wed, 4 Oct 1995 20:56:22 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9510041106.AA26844@cas.org> from "Larry W. Virden, x2487" at Oct 4, 95 11:06:10 am Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1458 > > I added the two resources to my environment, logged off and back on. Chimera > still does not recognize clicks on hypertext links. Note that the buttons > like help, etc. work just fine, as does inline gifs. Sorry, my test was wrong. If you start Chimera under another window manager, and then to switch to olwm it works. This confused me. So I'm going to withdraw that explanation and present another that is at least as convincing. If you don't ask to get button press events then olwm decides you aren't interested in button release events either. All mouse button events are intercepted and used to move the window. This is probably very useful for xclock etc. The patch is: - --- cfh80-2.0-erik/www/WWW.c Sun Oct 1 04:35:07 1995 +++ cfh80-2.0-erik2/www/WWW.c Wed Oct 4 20:47:49 1995 @@ -500,6 +500,11 @@ /* END SCROLL HANDLING CODE */ +void +DummyHandler() +{ +} + /* * WWWInitialize */ @@ -610,6 +615,8 @@ ExposeHandler, (XtPointer)new); XtAddEventHandler(new->www.child, ButtonReleaseMask, True, ButtonReleaseHandler, (XtPointer)new); + XtAddEventHandler(new->www.child, ButtonPressMask, True, + DummyHandler, (XtPointer)new); if (request->www.anchorReport) { By the way, John, you pass True as the 3rd parameter above, but the manual thinks you 'almost always want to pass False for this parameter'. Are you sure? - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 23 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa02074; 4 Oct 95 13:11 PDT Received: from kroete2.freinet.de (root@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id VAA05726; Wed, 4 Oct 1995 21:25:07 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0XVh-0003kRC; Wed, 4 Oct 95 18:21 MET Message-Id: From: Erik Corry Subject: Re: chimera 2.0 alpha 80 To: Steve Oyanagi Date: Wed, 4 Oct 1995 18:21:36 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9510041445.AA06142@noc.msc.edu> from "Steve Oyanagi" at Oct 4, 95 09:45:21 am Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1794 > FYI - your patch works fine here. A minor nit, however. It looks like > black and white are reversed - things that display white in other > browsers (Mosaic, Netscape) appear black in chimera 2.0-80, and vice > versa. I'm running with the jpeg support, if that makes a difference. > - Steve Oh damn, another thinko! It worked for me, but only through luck. Try this for size (people without 1-bit screens don't need this patch): (In the cfh80-2.0 directory you apply it with patch -p1 < mail_message) diff -u --recursive --exclude-from exclusions cfh80-2.0-erik/image/image.c cfh80-2.0-erik2/image/image.c - --- cfh80-2.0-erik/image/image.c Wed Oct 4 18:14:38 1995 +++ cfh80-2.0-erik2/image/image.c Wed Oct 4 18:12:32 1995 @@ -466,9 +466,22 @@ for (i = 0; i < 4; i++) ips->gray_tables[i].eight_8_dither = ccf_create_gray_dither_table(i, 4, 4, ips->grayscale); - - /* In case we end up with a 1-bit image */ - - is->fg = ips->grayscale->u.grayscale.pixel_values[1]; - - is->bg = ips->grayscale->u.grayscale.pixel_values[0]; + if(ips->depth == 1) + { + /* 1-bit images need special handling because they are not + displayed using the colormap in an XPutImage. Instead the + Graphics context foreground and background colors are used */ + if(ips->grayscale->u.grayscale.pixel_values[1]) + { + is->fg = ips->grayscale->u.grayscale.pixel_values[1]; + is->bg = ips->grayscale->u.grayscale.pixel_values[0]; + } + else + { + is->fg = ips->grayscale->u.grayscale.pixel_values[0]; + is->bg = ips->grayscale->u.grayscale.pixel_values[1]; + } + } if (image_type == IRGB || image_type == IGRAY) { /* - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 24 Received: from boutell.com by JIMI.CS.UNLV.EDU id aa05067; 4 Oct 95 14:38 PDT Received: by boutell.com id AA09303 (5.67b/IDA-1.5 for bug-chimera@cs.unlv.edu); Wed, 4 Oct 1995 14:43:21 GMT Date: Wed, 4 Oct 1995 14:43:21 GMT From: Thomas Boutell Message-Id: <199510041443.AA09303@boutell.com> To: bug-chimera@cs.unlv.edu Subject: 2.0 alpha 80 and JPEGs under Linux Another Linux data point: I don't see JPEGs either. They get downloaded, but they don't appear, and as far as I can tell no space is being reserved for them in the image. Yes, I definitely built in JPEG support. - -T ------- Message 25 Received: from boutell.com by JIMI.CS.UNLV.EDU id aa05556; 4 Oct 95 14:44 PDT Received: by boutell.com id AA09334 (5.67b/IDA-1.5 for bug-chimera@cs.unlv.edu); Wed, 4 Oct 1995 14:49:14 GMT Date: Wed, 4 Oct 1995 14:49:14 GMT From: Thomas Boutell Message-Id: <199510041449.AA09334@boutell.com> To: bug-chimera@cs.unlv.edu Subject: 2.0 alpha 80: password never gets focus Under Linux and X11R5: I tried a page that is protected by HTTP/1.0 authorization. I was presented with an authorization dialog. The name and password labels were clipped a bit, but that's not the real problem. The real problem is that the password field never gets the focus; I click on it, keep the mouse in it, start typing and the name field always gets the keystrokes anyway. Thanks for the continued good work on Chimera. When this version is solid it will please a lot of folks with limited firepower. - -T ------- Message 26 Received: from gw2.att.com by JIMI.CS.UNLV.EDU id aa07125; 4 Oct 95 15:35 PDT Received: from scratchy.cvu.att.com. by ig2.att.att.com id AA23738; Wed, 4 Oct 95 16:52:04 EDT Received: from atpsol.cvu.att.com by scratchy.cvu.att.com with SMTP (1.37.109.14/15.6) id AA191069862; Wed, 4 Oct 1995 16:51:03 -0400 Posted-Date: Wed, 4 Oct 1995 16:51:03 -0400 Received-Date: Wed, 4 Oct 1995 16:51:03 -0400 Received: by atpsol.cvu.att.com (5.x/SMI-SVR4) id AA13987; Wed, 4 Oct 1995 16:51:00 -0400 Date: Wed, 4 Oct 1995 16:50:59 -0400 (EDT) From: "Jeffry R. Abramson" To: Michael Kellen Cc: Chimera Hacker List Subject: Re: It isn't the compiler In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Oct 1995, Michael Kellen wrote: > > I just upgraded to gcc 2.7.0 ... links still don't work, images are still > not requested. It's the code, not the compiler. > > > Sorry, > > Michael > I've got the same problem on Solaris 2.4 using gcc 2.6.3. Links don't work regardless of whether I'm running olwm, olvwm or mwm. I can type in URL's directly and retrieve them, however. jeffry r. abramson https://poohbear.cvu.att.com/~jra/ at&t bell laboratories email: jeffry.abramson@att.com room 2k-054 480 red hill road phone: (908) 615-5340 middletown, nj 07748 facsimile: (908) 615-2672 ------- Message 27 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa10676; 4 Oct 95 17:16 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id BAA17214 for cs.unlv.edu!bug-chimera; Thu, 5 Oct 1995 01:30:36 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0dbD-0003kOC; Thu, 5 Oct 95 00:51 MET Message-Id: From: Erik Corry Subject: It Do Work Now! To: bug-chimera@cs.unlv.edu Date: Thu, 5 Oct 1995 00:51:41 +0100 (MET) In-Reply-To: from "Jean-Jacques Moulis" at Oct 4, 95 01:25:33 pm Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 849 > On Wed, 4 Oct 1995, Erik Corry wrote: > > > > Inline Jpegs are not rendered even with Use_JPEG turned on. > > > > :-( > > > > Do they fail silently or does Chimera crash, or do they display as a > > black square or is there an error message on the terminal? What > > sort of X display do you use (xdpyinfo)? Is space reserved for the image > > in the layout? > > It fail silently doesn't crash and no messages There was a jpeg bug in alpha-80 which I corrected in the first alpha-80 patch I sent to the list (the one that also contains the first 1-bit fixes). This bug caused Chimera to forget to display the last ca. 2k of the jpeg. This means that small jpegs smaller than 2k will fail to display entirely. You guys need to look at larger images or to apply my patch (or to wait for the next release). - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 28 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa14106; 4 Oct 95 19:24 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id UAA18833; Wed, 4 Oct 1995 20:20:08 -0600 Date: Wed, 4 Oct 1995 20:19:58 -0600 (MDT) From: Michael Kellen To: Chimera Hacker List cc: Erik Corry , John Kilburg Subject: Link Parse Problem SOLVED Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII After wasting a day on this, I found the problem and have fixed it (at least for Linux, and probably others) The problem (at least on linux) with links not being highlit, images not being grabbed, etc etc is because isspace(char) is always returning 0. Thus the tag parser cannot match the tags to the database, because "a href" != "a". This error is introduced (under linux) by "image/endian.h" (in general it is a *BAD* idea to name a program header file the same thing as a system file and REALLY bad not to at least check the existing def'n before changing it!!!) Erik's header file undefines system constants (namely BIG_ENDIAN and LITTLE_ENDIAN) that are needed elsewhere, and interferes with files that require /usr/include/endian.h The following following patch makes the image code MUCH more portable. It compares to BYTE_ORDER instead of *_ENDIAN. {Check to make sure that your patch program DELETES "images/endian.h" and places "image_endian.h" in the images directory.} Michael ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff -cNp oldimage/dispdither.c image/dispdither.c *** oldimage/dispdither.c Sun Oct 1 22:25:32 1995 - --- image/dispdither.c Wed Oct 4 18:54:36 1995 *************** lf_color_dither_line_24_4_no_mapping( *** 47,53 **** { unsigned char t; xx = xx & 3; ! # ifdef LITTLE_ENDIAN t = table->pixel_values[0][xx+1][input[3]]; t += table->pixel_values[1][xx+1][input[4]]; t = (t + table->pixel_values[2][xx+1][input[5]]) << 4; - --- 47,53 ---- { unsigned char t; xx = xx & 3; ! # if (BYTE_ORDER == LITTLE_ENDIAN) t = table->pixel_values[0][xx+1][input[3]]; t += table->pixel_values[1][xx+1][input[4]]; t = (t + table->pixel_values[2][xx+1][input[5]]) << 4; *************** lf_color_dither_line_24_4_mapping( *** 79,85 **** { unsigned char t, tt; xx = xx & 3; ! # ifdef LITTLE_ENDIAN t = table->pixel_values[0][xx][input[0]]; t += table->pixel_values[1][xx][input[1]]; t += table->pixel_values[2][xx][input[2]]; - --- 79,85 ---- { unsigned char t, tt; xx = xx & 3; ! # if (BYTE_ORDER == LITTLE_ENDIAN) t = table->pixel_values[0][xx][input[0]]; t += table->pixel_values[1][xx][input[1]]; t += table->pixel_values[2][xx][input[2]]; *************** lf_gray_dither_24_1( *** 241,247 **** { unsigned int t; unsigned int b; ! # ifdef LITTLE_ENDIAN b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[0][b]; - --- 241,247 ---- { unsigned int t; unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[0][b]; *************** lf_gray_dither_24_2( *** 309,315 **** { unsigned int t; unsigned int b; ! # ifdef LITTLE_ENDIAN b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[0][b]; - --- 309,315 ---- { unsigned int t; unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[0][b]; *************** lf_gray_dither_24_4( *** 355,361 **** unsigned int t; unsigned int b; xx &= 3; ! # ifdef LITTLE_ENDIAN b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[xx][b]; - --- 355,361 ---- unsigned int t; unsigned int b; xx &= 3; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]; b >>= 8; t = table->pixel_values[xx][b]; *************** lf_dither_8_1( *** 475,481 **** { unsigned int t; unsigned int b; ! # ifdef LITTLE_ENDIAN b = input[0]; t = table->pixel_values[0][b]; b = input[1]; - --- 475,481 ---- { unsigned int t; unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = input[0]; t = table->pixel_values[0][b]; b = input[1]; *************** lf_dither_8_2( *** 527,533 **** { unsigned int t; unsigned int b; ! # ifdef LITTLE_ENDIAN b = input[0]; t = table->pixel_values[0][b]; b = input[1]; - --- 527,533 ---- { unsigned int t; unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = input[0]; t = table->pixel_values[0][b]; b = input[1]; *************** lf_dither_8_4( *** 565,571 **** unsigned int t; unsigned int b; xx &= 3; ! # ifdef LITTLE_ENDIAN b = input[0]; t = table->pixel_values[xx][b]; b = input[1]; - --- 565,571 ---- unsigned int t; unsigned int b; xx &= 3; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = input[0]; t = table->pixel_values[xx][b]; b = input[1]; *************** lf_convert_8_4( *** 682,688 **** for(x = pixel_count >> 1; x; x--) { unsigned int b; ! # ifdef LITTLE_ENDIAN b = table->pixel_values[input[0]]; b |= table->pixel_values[input[1]] << 4; # else - --- 682,688 ---- for(x = pixel_count >> 1; x; x--) { unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = table->pixel_values[input[0]]; b |= table->pixel_values[input[1]] << 4; # else *************** lf_convert_8_24( *** 737,743 **** for(x = pixel_count; x; x--) { unsigned int t = table->pixel_values[input[0]]; ! # ifdef LITTLE_ENDIAN output[0] = t & 255; output[1] = (t >> 8) & 255; output[2] = (t >> 16) & 255; - --- 737,743 ---- for(x = pixel_count; x; x--) { unsigned int t = table->pixel_values[input[0]]; ! # if (BYTE_ORDER == LITTLE_ENDIAN) output[0] = t & 255; output[1] = (t >> 8) & 255; output[2] = (t >> 16) & 255; *************** lf_convert_24_24( *** 862,868 **** unsigned int t = table->pixel_values[0][input[0]]; t += table->pixel_values[1][input[1]]; t += table->pixel_values[2][input[2]]; ! # ifdef LITTLE_ENDIAN output[0] = t & 255; output[1] = (t >> 8) & 255; output[2] = (t >> 16) & 255; - --- 862,868 ---- unsigned int t = table->pixel_values[0][input[0]]; t += table->pixel_values[1][input[1]]; t += table->pixel_values[2][input[2]]; ! # if (BYTE_ORDER == LITTLE_ENDIAN) output[0] = t & 255; output[1] = (t >> 8) & 255; output[2] = (t >> 16) & 255; *************** lf_gray_convert_24_4( *** 923,929 **** for(x = pixel_count >> 1; x; x--) { unsigned int b; ! # ifdef LITTLE_ENDIAN b = table->pixel_values[(RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]) >> 8]; - --- 923,929 ---- for(x = pixel_count >> 1; x; x--) { unsigned int b; ! # if (BYTE_ORDER == LITTLE_ENDIAN) b = table->pixel_values[(RedIntensity[input[0]] + GreenIntensity[input[1]] + BlueIntensity[input[2]]) >> 8]; diff -cNp oldimage/endian.h image/endian.h *** oldimage/endian.h Tue Sep 19 00:05:04 1995 - --- image/endian.h Wed Dec 31 17:00:00 1969 *************** *** 1,82 **** - - /* - - * endian.h - - */ - - - - #ifndef __ENDIAN_H__ - - #define __ENDIAN_H__ 1 - - - - /* - - * Endianism determination by Erik Corry. Please email changes/additions!!! - - */ - - - - #if !defined(__MIPSEL__) && (defined(MIPSEL) || defined(__MIPSEL) || defined(__MIPSEL__) || defined(__mipsel) || defined(__mipsel__)) - - #define __MIPSEL__ 1 - - #endif - - - - #if !defined(__MIPSEB__) && (defined(MIPSEB) || defined(__MIPSEB) || defined(__MIPSEB__) || defined(__mipseb) || defined(__mipseb__)) - - #define __MIPSEB__ 1 - - #endif - - - - #if !defined(__SPARC__) && (defined(SPARC) || defined(__SPARC) || defined(__SPARC__) || defined(__sparc) || defined(__sparc__)) - - #define __SPARC__ 1 - - #endif - - - - #if !defined(__alpha__) && (defined(ALPHA) || defined(__ALPHA) || defined(__ALPHA__) || defined(__alpha)) - - #define __alpha__ 1 - - #endif - - - - #if !defined(__680x0__) && (defined(__680x0) || defined(__680x0__)) - - #define __680x0__ 1 - - #endif - - - - #if !defined(__AIX__) && (defined(AIX) || defined(_AIX) || defined(__AIX) || defined(__AIX__)) - - #define __AIX__ 1 - - #endif - - - - #if !defined(__RS6000__) && (defined(__AIX__) || defined(RS6000) || defined(_RS6000) || defined(__RS6000) || defined(__RS6000__)) - - #define __RS6000__ 1 - - #endif - - - - #if !defined(__HPUX__) && (defined(HPUX) || defined(_HPUX) || defined(__HPUX) || defined(__HPUX__)) - - #define __HPUX__ 1 - - #endif - - #if !defined(__HPUX__) && (defined(hpux) || defined(_hpux) || defined(__hpux) || defined(__hpux__)) - - #define __HPUX__ 1 - - #endif - - - - #if !defined(__VAX__) && (defined(VAX) || defined (__VAX)) - - #define __VAX__ 1 - - #endif - - - - #if defined(__i386__) || defined(__VAX__) || defined(__MIPSEL__) || defined(__alpha__) - - #undef BIG_ENDIAN - - #define LITTLE_ENDIAN - - #endif - - - - #if defined(__RS6000__) || defined(__SPARC__) || defined(__680x0__) || defined(__HPUX__) || defined(__MIPSEB__) - - #undef LITTLE_ENDIAN - - #define BIG_ENDIAN - - #endif - - - - #if !defined(LITTLE_ENDIAN) && !defined(BIG_ENDIAN) - - /* - - * If you hit this and you don't know what symbols your system defines, - - * look in the compiler manual. Try to find a symbol that identifies the - - * processor, rather than the OS or compiler. If you have gcc on a Unix - - * system, the following will tell you what symbols it defines: - - * - - * ln -s /dev/null null.c - - * gcc -ansi -dM -E null.c - - * - - * If you have a system that does not have a clear integer endianism you - - * are going to have severe portability problems. - - * - - */ - - Error: Unknown endianism of architecture - - #endif - - - - #ifdef __alpha__ - - #define SIXTYFOUR_BIT - - #endif - - - - #endif /* __ENDIAN_H__ */ - --- 0 ---- diff -cNp oldimage/gif.c image/gif.c *** oldimage/gif.c Sun Oct 1 22:22:43 1995 - --- image/gif.c Wed Oct 4 18:55:11 1995 *************** *** 31,37 **** #include "common.h" #include "imagep.h" ! #include "endian.h" #include "image_format.h" #include "gifp.h" - --- 31,37 ---- #include "common.h" #include "imagep.h" ! #include "image_endian.h" #include "image_format.h" #include "gifp.h" *************** gifState *gs; *** 562,568 **** if ((rval = gs_get_pixel(gs, &pixel)) != GS_SUCCESS) return(rval); if(image->pixlen == 1) { ! # ifdef LITTLE_ENDIAN pixel <<= (image->x & 7); # else pixel <<= 7 - (image->x & 7); - --- 562,568 ---- if ((rval = gs_get_pixel(gs, &pixel)) != GS_SUCCESS) return(rval); if(image->pixlen == 1) { ! # if (BYTE_ORDER == LITTLE_ENDIAN) pixel <<= (image->x & 7); # else pixel <<= 7 - (image->x & 7); diff -cNp oldimage/image.c image/image.c *** oldimage/image.c Sun Oct 1 22:22:01 1995 - --- image/image.c Wed Oct 4 18:57:11 1995 *************** *** 14,20 **** #include "dispdither.h" #include "xcolorcube.h" #include "image.h" ! #include "endian.h" #include "imagep.h" #include "image_format.h" - --- 14,20 ---- #include "dispdither.h" #include "xcolorcube.h" #include "image.h" ! #include "image_endian.h" #include "imagep.h" #include "image_format.h" *************** lf_expand_bitmap_to_true( *** 213,219 **** for(i = (width + CHAR_BITS - 1) / CHAR_BITS; i; i--) { byte t = *source_buffer++; ! # ifdef LITTLE_ENDIAN expansion_buffer[0] = red[t & 1]; expansion_buffer[1] = green[t & 1]; expansion_buffer[2] = blue[t & 1]; - --- 213,219 ---- for(i = (width + CHAR_BITS - 1) / CHAR_BITS; i; i--) { byte t = *source_buffer++; ! # if (BYTE_ORDER == LITTLE_ENDIAN) expansion_buffer[0] = red[t & 1]; expansion_buffer[1] = green[t & 1]; expansion_buffer[2] = blue[t & 1]; *************** lf_expand_bitmap_to_gray( *** 291,297 **** for(i = (width + CHAR_BITS - 1) / CHAR_BITS; i; i--) { byte t = *source_buffer++; ! # ifdef LITTLE_ENDIAN expansion_buffer[0] = gray[t & 1]; expansion_buffer[1] = gray[t >> 1 & 1]; expansion_buffer[2] = gray[t >> 2 & 1]; - --- 291,297 ---- for(i = (width + CHAR_BITS - 1) / CHAR_BITS; i; i--) { byte t = *source_buffer++; ! # if (BYTE_ORDER == LITTLE_ENDIAN) expansion_buffer[0] = gray[t & 1]; expansion_buffer[1] = gray[t >> 1 & 1]; expansion_buffer[2] = gray[t >> 2 & 1]; *************** ImageToXImage(void *pointer, int fline, *** 757,763 **** image->height * is->xi->bytes_per_line); ! #ifdef LITTLE_ENDIAN is->xi->byte_order = is->xi->bitmap_bit_order = LSBFirst; #else is->xi->byte_order = is->xi->bitmap_bit_order = MSBFirst; - --- 757,763 ---- image->height * is->xi->bytes_per_line); ! #if (BYTE_ORDER == LITTLE_ENDIAN) is->xi->byte_order = is->xi->bitmap_bit_order = LSBFirst; #else is->xi->byte_order = is->xi->bitmap_bit_order = MSBFirst; diff -cNp oldimage/image_endian.h image/image_endian.h *** oldimage/image_endian.h Wed Dec 31 17:00:00 1969 - --- image/image_endian.h Wed Oct 4 19:16:53 1995 *************** *** 0 **** - --- 1,91 ---- + /* + * image_endian.h + */ + + #ifndef __ENDIAN_H__ + #define __ENDIAN_H__ 1 + + #ifndef BYTE_ORDER + + #ifndef LITTLE_ENDIAN + #define LITTLE_ENDIAN 1234 + #endif + #ifndef BIG_ENDIAN + #define BIG_ENDIAN 4321 + #endif + + /* + * Endianism determination by Erik Corry. Please email changes/additions!!! + */ + + #if !defined(__MIPSEL__) && (defined(MIPSEL) || defined(__MIPSEL) || defined(__MIPSEL__) || defined(__mipsel) || defined(__mipsel__)) + #define __MIPSEL__ 1 + #endif + + #if !defined(__MIPSEB__) && (defined(MIPSEB) || defined(__MIPSEB) || defined(__MIPSEB__) || defined(__mipseb) || defined(__mipseb__)) + #define __MIPSEB__ 1 + #endif + + #if !defined(__SPARC__) && (defined(SPARC) || defined(__SPARC) || defined(__SPARC__) || defined(__sparc) || defined(__sparc__)) + #define __SPARC__ 1 + #endif + + #if !defined(__alpha__) && (defined(ALPHA) || defined(__ALPHA) || defined(__ALPHA__) || defined(__alpha)) + #define __alpha__ 1 + #endif + + #if !defined(__680x0__) && (defined(__680x0) || defined(__680x0__)) + #define __680x0__ 1 + #endif + + #if !defined(__AIX__) && (defined(AIX) || defined(_AIX) || defined(__AIX) || defined(__AIX__)) + #define __AIX__ 1 + #endif + + #if !defined(__RS6000__) && (defined(__AIX__) || defined(RS6000) || defined(_RS6000) || defined(__RS6000) || defined(__RS6000__)) + #define __RS6000__ 1 + #endif + + #if !defined(__HPUX__) && (defined(HPUX) || defined(_HPUX) || defined(__HPUX) || defined(__HPUX__)) + #define __HPUX__ 1 + #endif + #if !defined(__HPUX__) && (defined(hpux) || defined(_hpux) || defined(__hpux) || defined(__hpux__)) + #define __HPUX__ 1 + #endif + + #if !defined(__VAX__) && (defined(VAX) || defined (__VAX)) + #define __VAX__ 1 + #endif + + #if defined(__i386__) || defined(__VAX__) || defined(__MIPSEL__) || defined(__alpha__) + #define BYTE_ORDER LITTLE_ENDIAN + #endif + + #if defined(__RS6000__) || defined(__SPARC__) || defined(__680x0__) || defined(__HPUX__) || defined(__MIPSEB__) + #define BYTE_ORDER BIG_ENDIAN + #endif + + #ifndef BYTE_ORDER + /* + * If you hit this and you don't know what symbols your system defines, + * look in the compiler manual. Try to find a symbol that identifies the + * processor, rather than the OS or compiler. If you have gcc on a Unix + * system, the following will tell you what symbols it defines: + * + * ln -s /dev/null null.c + * gcc -ansi -dM -E null.c + * + * If you have a system that does not have a clear integer endianism you + * are going to have severe portability problems. + * + */ + Error: Unknown endianism of architecture + #endif + + #ifdef __alpha__ + #define SIXTYFOUR_BIT + #endif + + #endif /* BYTE_ORDER */ + + #endif /* __ENDIAN_H__ */ diff -cNp oldimage/pnm.c image/pnm.c *** oldimage/pnm.c Sun Oct 1 22:24:32 1995 - --- image/pnm.c Wed Oct 4 18:56:36 1995 *************** *** 13,19 **** #include #include "common.h" ! #include "endian.h" #include "imagep.h" #include "pnmp.h" - --- 13,19 ---- #include #include "common.h" ! #include "image_endian.h" #include "imagep.h" #include "pnmp.h" *************** lf_read_height( *** 223,229 **** pnm->imagepos = pnm->image->data; if(pnm->pnm_class == 1) pnm->state = PNM_READ_ASC_BIT; else pnm->state = PNM_READ_PRE_RAW_NEWLINE; ! # ifdef LITTLE_ENDIAN if(pnm->pnm_class == 1) pnm->input_table = 0; /* ascii bytes will be assembled l-e */ else - --- 223,229 ---- pnm->imagepos = pnm->image->data; if(pnm->pnm_class == 1) pnm->state = PNM_READ_ASC_BIT; else pnm->state = PNM_READ_PRE_RAW_NEWLINE; ! # if (BYTE_ORDER == LITTLE_ENDIAN) if(pnm->pnm_class == 1) pnm->input_table = 0; /* ascii bytes will be assembled l-e */ else *************** lf_read_asc_bit( *** 427,433 **** if(data[pnm->pos] == '1') { ! # ifdef LITTLE_ENDIAN *pnm->imagepos |= 1 << (pnm->xpos % CHAR_BITS); # else *pnm->imagepos |= 1 << (7 - (pnm->xpos % CHAR_BITS)); - --- 427,433 ---- if(data[pnm->pos] == '1') { ! # if (BYTE_ORDER == LITTLE_ENDIAN) *pnm->imagepos |= 1 << (pnm->xpos % CHAR_BITS); # else *pnm->imagepos |= 1 << (7 - (pnm->xpos % CHAR_BITS)); diff -cNp oldimage/xbm.c image/xbm.c *** oldimage/xbm.c Sun Oct 1 22:25:17 1995 - --- image/xbm.c Wed Oct 4 18:55:41 1995 *************** *** 12,18 **** #include #include "common.h" ! #include "endian.h" #include "imagep.h" #include "xbmp.h" - --- 12,18 ---- #include #include "common.h" ! #include "image_endian.h" #include "imagep.h" #include "xbmp.h" *************** lf_read_image( *** 276,282 **** { xbm->state = XBM_FINISHED; return XBM_SUCCESS; } if(lf_read_int(xbm, data, len, &t)) return XBM_ERROR; t &= 255; ! # ifdef BIG_ENDIAN t = lc_reverse_byte[t]; # endif *xbm->imagepos++ = t; - --- 276,282 ---- { xbm->state = XBM_FINISHED; return XBM_SUCCESS; } if(lf_read_int(xbm, data, len, &t)) return XBM_ERROR; t &= 255; ! # if (BYTE_ORDER == BIG_ENDIAN) t = lc_reverse_byte[t]; # endif *xbm->imagepos++ = t; ------- Message 29 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa24065; 5 Oct 95 0:10 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id IAA28834 for cs.unlv.edu!bug-chimera; Thu, 5 Oct 1995 08:27:39 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t0jxW-0003kGC; Thu, 5 Oct 95 07:39 MET Message-Id: From: Erik Corry Subject: Re: Link Parse Problem SOLVED To: bug-chimera@cs.unlv.edu Date: Thu, 5 Oct 1995 07:39:10 +0100 (MET) In-Reply-To: from "Michael Kellen" at Oct 4, 95 08:19:58 pm Reply-To: Erik Corry X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 476 > > After wasting a day on this, I found the problem and have fixed it (at > least for Linux, and probably others) Thanks for the patches, Michael. If anyone finds themself needing Michael's _and_ my patches at the same time, they should change #include "endian.h" to #include "image_endian.h" in the file image/dispdither.c. (Michael had not yet applied my patch when he made his, so they don't fit together without this change). - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 30 Received: from gw2.att.com by JIMI.CS.UNLV.EDU id aa03815; 5 Oct 95 6:15 PDT Received: from scratchy.cvu.att.com. by ig2.att.att.com id AA09857; Thu, 5 Oct 95 09:16:11 EDT Received: from atpsol.cvu.att.com by scratchy.cvu.att.com with SMTP (1.37.109.14/15.6) id AA164418908; Thu, 5 Oct 1995 09:15:09 -0400 Posted-Date: Thu, 5 Oct 1995 09:15:09 -0400 Received-Date: Thu, 5 Oct 1995 09:15:09 -0400 Received: by atpsol.cvu.att.com (5.x/SMI-SVR4) id AA20944; Thu, 5 Oct 1995 09:15:05 -0400 Date: Thu, 5 Oct 1995 09:15:04 -0400 (EDT) From: "Jeffry R. Abramson" To: Erik Corry Cc: bug-chimera@cs.unlv.edu Subject: Re: It isn't the compiler In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Oct 1995, Erik Corry wrote: > jeffrey: > > On Wed, 4 Oct 1995, Michael Kellen wrote: > > > > > I just upgraded to gcc 2.7.0 ... links still don't work, images are still > > > not requested. It's the code, not the compiler. > > > > I've got the same problem on Solaris 2.4 using gcc 2.6.3. Links > > don't work regardless of whether I'm running olwm, olvwm or mwm. I can > > type in URL's directly and retrieve them, however. > > Are the links not there at all, or can you just not click on them? > Have you tried my olwm patch yet? > The links are there and as you move the pointer from one link to another, the URL's show up. Clicking on the links has no effect. I just added your olwm patch (the one that adds a dummy handler for the button press event) and that one seemed to do the trick. Now, I will try to build a version consolidating the other patches as well to verify loading of jpeg images large and small, etc. thanks, jeff jeffry r. abramson https://poohbear.cvu.att.com/~jra/ at&t bell laboratories email: jeffry.abramson@att.com room 2k-054 480 red hill road phone: (908) 615-5340 middletown, nj 07748 facsimile: (908) 615-2672 ------- Message 31 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa23440; 5 Oct 95 14:10 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id PAA20453; Thu, 5 Oct 1995 15:06:41 -0600 Date: Thu, 5 Oct 1995 15:06:34 -0600 (MDT) From: Michael Kellen To: Chimera Hacker List Subject: [cfh80-2.0] Evaluation Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1520026096-460673711-812927194=:20420" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --1520026096-460673711-812927194=:20420 Content-Type: TEXT/PLAIN; charset=US-ASCII Now that I have it actually running, here's what I've found. Bear in mind that it is easier to spot defects, so there are more -'s than +'s. (+) Still MUCH faster than anything else (+) stripped dynamic executable still under 300k (-) still needs SOME indicator that downloads are in progress (-) links of type "#name" are interpreted as "". links of type "URL#name" go to "URL". Does not matter if URL is in a page or typed in. is ignored also. (+) The problem with side-by-side doubling of images is gone (-) FORMs layout (specifically text input dimensions) incorrect (-) returned http index entries longer than 20 chars are not displayed (-) key bindings still not implemented (-) middle-mouse to download does not work ... file is downloaded, but the popup does not appear (-) File and Search popups still nonexistant (-) No protocol extension support(mailto, finger, etc) (-) No convert file support (eg, on-the-fly gunzipping, inline postscript, etc etc) (-) telnet URLs return "badurl" (-) gopher URLs fail silently or segfault (see attachment) (+) http URLs work fine as long as no NAMEs are involved (+) file URLs work fine (and use the file stat stuff :-) (+) ftp URLs work (although dir/size reports are still needed) as long as you don't want to download anything. Non-anonymous part of ftp is silently discarded. (?) Did not try the inline JPEG code, as I, too threw the patch ... what good was it before I got the parser working? Michael Platform: 486DX 25MHz (8 MB RAM + swap) Linux 1.2.13 (ELF/POSIX) gcc 2.7.0 libc 5.0.9 - --1520026096-460673711-812927194=:20420 Content-Type: TEXT/PLAIN; name=gopher Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: gopher URL gdb output QXR0ZW1wdGVkIFVSTDogZ29waGVyOi8vdGVycmEub3Njcy5tb250YW5hLmVk dQ0KDQpSZXN1bHQ6IG5vdGhpbmcgcmV0cmlldmVkDQoNCkNsaWNrIG9uIFVS TDogaW5wdXQgYm94IGFuZCBoaXQgPEVudGVyPjoNCg0KXkBeRV5IXkBeRV5I L3RlcnJhLm9zY3MubW9udGFuYS5lZC8gZGlzcGxheWVkIGluIFVSTCBib3gN Cg0KDQpQcm9ncmFtIHJlY2VpdmVkIHNpZ25hbCBTSUdTRUdWLCBTZWdtZW50 YXRpb24gZmF1bHQuDQoweDgwMDY4MDEgaW4gQWRkUmVuZGVyUGFydCAocnc9 MHg2ZjJlNjE3MiwgcnA9MHg4MDU4YzNjLCB3aWR0aD0wLCBoZWlnaHQ9MCkN CiAgICBhdCBsYXlvdXQuYzozODANCihnZGIpIGluZm8gZnJhbWUNClN0YWNr IGxldmVsIDAsIGZyYW1lIGF0IDB4YmZmZmRkNjg6DQogZWlwID0gMHg4MDA2 ODAxIGluIEFkZFJlbmRlclBhcnQgKGxheW91dC5jOjM4MCk7IHNhdmVkIGVp cCAweDgwMGM3ZWINCiBjYWxsZWQgYnkgZnJhbWUgYXQgMHhiZmZmZGQ4OA0K IHNvdXJjZSBsYW5ndWFnZSBjLg0KIEFyZ2xpc3QgYXQgMHhiZmZmZGQ2OCwg YXJnczogcnc9MHg2ZjJlNjE3MiwgcnA9MHg4MDU4YzNjLCB3aWR0aD0wLCBo ZWlnaHQ9MA0KIExvY2FscyBhdCAweGJmZmZkZDY4LCBQcmV2aW91cyBmcmFt ZSdzIHNwIGlzIDB4MA0KIFNhdmVkIHJlZ2lzdGVyczoNCiAgZWJ4IGF0IDB4 YmZmZmRkNTQsIGVicCBhdCAweGJmZmZkZDY4LCBlaXAgYXQgMHhiZmZmZGQ2 Yw0KKGdkYikgaW5mbyBsb2NhbHMNCnJsID0gKFJlbmRlckxpbmUgKikgMHgw DQoNCg0KKGdkYikgYnQNCiMwICAweDgwMDY4MDEgaW4gQWRkUmVuZGVyUGFy dCAocnc9MHg2ZjJlNjE3MiwgcnA9MHg4MDU4YzNjLCB3aWR0aD0wLCBoZWln aHQ9MCkNCiAgICBhdCBsYXlvdXQuYzozODANCiMxICAweDgwMGM3ZWIgaW4g Q3JlYXRlVGV4dFN0YXRlIChydz0weDZmMmU2MTcyLCBwPTB4ODA1OGMwYywg DQogICAgcz0weDgwNThjMzQgIv///yIsIHNsZW49NywgZm9udD0weDApIGF0 IHRleHQuYzoxMjYNCiMyICAweDgwMGNlNjkgaW4gRmlsbFRleHQgKHJ3PTB4 NmYyZTYxNzIsIHA9MHg4MDU4YzBjKSBhdCB0ZXh0LmM6MzQyDQojMyAgMHg4 MDA3NmVkIGluIFdXV0xheW91dCAocnc9MHg2ZjJlNjE3MiwgcD0weDgwNThj MGMpIGF0IGxheW91dC5jOjcxOA0KIzQgIDB4ODAwZjJkNCBpbiBoc19jcmVh dGVfcGFydCAoaHM9MHg4MDU4MDBjLCB0YWdpZD0tMywgDQogICAgb3RleHQ9 MHg4MDU4YzBkICL///8iLCBvbGVuPTIxLCB0ZXh0PTB4ODA1OGMwZCAi//// IiwgbGVuPTIxLCB0YT0weDAsIA0KICAgIGVuZD0wKSBhdCBodG1sLmM6NDU5 DQojNSAgMHg4MDBmMzY3IGluIGhzX2NyZWF0ZV90ZXh0IChocz0weDgwNTgw MGMsIHRleHQ9MHg4MDU4YzBkICL///8iLCBsZW49MjEpDQogICAgYXQgaHRt bC5jOjQ4NQ0KIzYgIDB4ODAwZjcxZSBpbiBNTEFkZERhdGEgKGhzPTB4ODA1 ODAwYywgZGF0YT0weDgwNThjMDAgIlwyMzQiLCBsZW49Nzc4MTM3MTg1KQ0K ICAgIGF0IGh0bWwuYzo2MzQNCiM3ICAweDgwMGQ4YzAgaW4gSGFuZGxlRG9j dW1lbnQgKGQ9MHg4MDU3NGQwLCBjbG9zdXJlPTB4ODA1YmM4MCwgc3RhdHVz PTYpDQogICAgYXQgZG9jLmM6Mjk4DQojOCAgMHg4MDMxMjZkIGluIGdvcGhl cl9tYWtlX2RvY3VtZW50IChnaT0weDgwNTEwYzApIGF0IGdvcGhlci5jOjEw Ng0KIzkgIDB4ODAzMTNiMSBpbiBnb3BoZXJfbWVudSAocz03LCBsaW5lPTB4 ODA1YTgxMCAiLlxyXG4iLCBjbG9zdXJlPTB4ODA1MTBjMCkNCiAgICBhdCBn b3BoZXIuYzoxOTANCiMxMCAweDgwMDg4MTQgaW4gUmVhZExpbmVIYW5kbGVy IChjbGRhdGE9MHg4MDVhODAwLCBuZXRmZD0weDgwNTEwMzQsIA0KICAgIHhp ZD0weGJmZmZmMzAwKSBhdCBpby5jOjMzMA0KIzExIDB4NTAwZjY5MDcgaW4g YXBwciAoKQ0KIzEyIDB4NTAwZjZiYmIgaW4gYXBwciAoKQ0KIzEzIDB4NTAw ZWRmODMgaW4gYXBwciAoKQ0KIzE0IDB4ODAwM2I4YyBpbiBtYWluIChhcmdj PTIsIGFyZ3Y9MHhiZmZmZjQyNCkgYXQgbWFpbi5jOjE2Ng0KIzE1IDB4ODAw Mzg5NSBpbiBfc3RhcnQgKCkNCiMxNiAweDggaW4gPz8gKCkNCiMxNyAweDUw MWVmY2M4IGluIGFwcHIgKCkNCiMxOCAweDc4MDAwMDAwIGluIGFwcHIgKCkN Cg0KDQooZ2RiKSBsaXN0DQozNzUgICAgICAgICB9DQozNzYgICAgICAgfQ0K Mzc3ICAgICAgIGlmIChybC0+cnBoZWFkID09IE5VTEwgJiYgSXNTcGFjZShy cCkpIHJldHVybigwKTsNCjM3OA0KMzc5ICAgICAgIHJwLT54ID0gcmwtPngg KyBybC0+d2lkdGg7DQozODAgICAgICAgcmwtPndpZHRoICs9IHJwLT53aWR0 aDsNCjM4MSAgICAgICBpZiAocnAtPmhlaWdodCA+IHJsLT5tYXh5KSBybC0+ bWF4eSA9IHJwLT5oZWlnaHQ7DQozODINCjM4MyAgICAgICBpZiAocmwtPnJw dGFpbCAhPSBOVUxMKSBybC0+cnB0YWlsLT5sbmV4dCA9IHJwOw0KMzg0ICAg ICAgIGVsc2UgcmwtPnJwaGVhZCA9IHJwOw0KDQo= - --1520026096-460673711-812927194=:20420-- ------- Message 32 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25741; 5 Oct 95 14:30 PDT To: Michael Kellen cc: Chimera Hacker List Subject: Re: [cfh80-2.0] Evaluation In-reply-to: Your message of "Thu, 05 Oct 1995 15:06:34 MDT." Date: Thu, 05 Oct 1995 14:30:06 -0700 From: John Kilburg >(-) No protocol extension support(mailto, finger, etc) Try one of export protocolname_local="/path/some_program" or setenv protocolname_local "/path/some_program" Lines end with CRLF instead of just LF. (-) No documentation. -john ------- Message 33 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa15352; 6 Oct 95 16:23 PDT Received: from (michael@localhost [127.0.0.1]) by xph029.physics.montana.edu (8.6.12/8.6.9) with SMTP id RAA23448 for bug-chimera@cs.unlv.edu; Fri, 6 Oct 1995 17:19:27 -0600 Date: Fri, 6 Oct 1995 17:19:27 -0600 From: Michael Kellen Message-Id: <199510062319.RAA23448@xph029.physics.montana.edu> Subject: [ANNOUNCE] postto.pl & mailto.pl v2.1 To: Chimera Hacker List Reply-To: Michael Kellen Okay, a few bugfixes and one update that comes in from trying to get these routines working with the ALPHA release. * Vestigal debugging code removed * External client support is back * Better error reporting * Internal NNTP/SMTP handling * PGP/Signature Boxes actually work ALPHA compatibility still not there yet. ftp://xph029.physics.montana.edu/pub/source https://xph029.physics.montana.edu/chimera - -- It's wrong to wish on space hardware. ------- Message 34 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa16950; 6 Oct 95 17:02 PDT Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id RAA23629; Fri, 6 Oct 1995 17:58:30 -0600 Date: Fri, 6 Oct 1995 17:58:23 -0600 (MDT) From: Michael Kellen To: Chimera Hacker List Subject: [ANNOUNCE (yet again)] postto.pl & mailto.pl ver 2.2 !! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Only one change, they now will work with the ALPHA client _local proxy method. I had to redo the URL parser. Since the announcements on this list take longer than this upgrade did (thank you, thank you), no one should have gotten 2.1 ... you can check the code header or just view the source in the input forms. Michael - -- "... she saw Dr. Pangloss behind the bushes giving a lesson in experimental physics to ... a pretty little brunette who seemed eminently teachable." -- Voltaire, _Candide_ ------- Message 35 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa12510; 7 Oct 95 13:44 PDT Received: from bls7.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id FAA29561; Sun, 8 Oct 1995 05:44:31 +0900 Return-Path: Received: from localhost by bls7.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA06675; Sun, 8 Oct 95 05:44:30 GMT+0900 Message-Id: <9510072044.AA06675@bls7.aist-nara.ac.jp> To: bug-chimera@cs.unlv.edu Subject: [ANNOUNCE] I18N patch for cfh80-2.0 Reply-To: shige-y@is.aist-nara.ac.jp X-Mailer: Mew beta version 0.98+ on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 08 Oct 1995 05:44:29 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= I create new I18N patch for cfh80-2.0. * viewing a page written by english(ASCII), japanese(JIS/SJIS/EUC), hangle and chinese. * adding internal source viewer. * independent of Erik's and Michael's image patches. (may be ...) Please access, https://shika.aist-nara.ac.jp/products/chimera/chimera-i18n.html #I hope a next chimera will become a first I18N WWW browser. - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan ------- Message 36 Received: from bock.freinet.de by JIMI.CS.UNLV.EDU id aa21762; 9 Oct 95 18:46 PDT Received: from kroete2.freinet.de (kroete2@localhost) by bock.freinet.de (8.6.12/8.6.12) with UUCP id CAA27375 for cs.unlv.edu!bug-chimera; Tue, 10 Oct 1995 02:55:02 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0t2IsG-0003kUC; Mon, 9 Oct 95 15:08 MET Message-Id: From: Erik Corry Subject: Minor Gif problem To: bug-chimera@cs.unlv.edu Date: Mon, 9 Oct 1995 15:08:11 +0100 (MET) Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS x == image->width) { image->y += interlace_rate[image->pass]; - - if (image->y >= image->height) - - { - - image->pass++; - - if (image->pass == 4) return(GS_DONE); - - image->y = interlace_start[image->pass]; - - } image->x = 0; } + if (image->y >= image->height) + { + image->pass++; + if (image->pass == 4) return(GS_DONE); + image->y = interlace_start[image->pass]; + } } else { if (image->x == image->width) { image->y++; - - if (image->y == image->height) return(GS_DONE); image->x = 0; } + if (image->y >= image->height) return(GS_DONE); } xpix = image->y * image->bytes_per_line + - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 37 Received: from hydra.ae.utexas.edu by JIMI.CS.UNLV.EDU id aa16468; 11 Oct 95 19:13 PDT Received: by hydra.ae.utexas.edu; id AA21372; Wed, 11 Oct 1995 21:13:16 -0500 Date: Wed, 11 Oct 1995 21:13:15 -0500 (CDT) From: Rob McMullen To: bug-chimera@cs.unlv.edu Subject: TextField widget patch for cfh80-2.0 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've written a free single line text entry widget called TextField that is very similar to the Motif XmTextField, but was intended to be a drop-in replacement for the Athena Text widget (in single line mode). Most of the Motif cool stuff is included, like scrolling, pending delete, etc., but it is free (GNU Library license, a less restrictive GPL). A patch for cfh80-2.0 is at https://www.ae.utexas.edu/~rwmcm/cfh80.patch The source for the TextField widget is available at https://www.ae.utexas.edu/~rwmcm/TextField.html (I've mailed this stuff to John, but did't want to clutter up the list with 60K of patches & source.) Rob - -- Rob McMullen https://www.ae.utexas.edu/~rwmcm Freeware Author: Programs and documentation available through my home page Xt Widgets: SciPlot (x/y & polar plotting) ListTree (file manager style tree) TextField (single line text widget with many XmTextField features) Also on my home page: Quotation Archive, Volleyball Jump Training Archive ------- End of Forwarded Messages