Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01746; 26 Dec 96 22:59 PST To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera nov 95 Date: Thu, 26 Dec 1996 22:59:42 -0800 From: Jay Nietling ------- Forwarded Messages Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa23418; 9 Nov 95 3:18 PST Received: from sonne.darmstadt.gmd.de by JIMI.CS.UNLV.EDU id aa23336; 9 Nov 95 3:06 PST Received: from belzbach.darmstadt.gmd.de (belzbach [141.12.35.111]) by sonne.darmstadt.gmd.de (8.6.11/8.6.9) with ESMTP id MAA09078 for ; Thu, 9 Nov 1995 12:05:51 +0100 From: Adrian Mueller Received: (amueller@localhost) by belzbach.darmstadt.gmd.de (8.6.10/8.6.9) id MAA13920; Thu, 9 Nov 1995 12:05:49 +0100 Date: Thu, 9 Nov 1995 12:05:49 +0100 Message-Id: <199511091105.MAA13920@belzbach.darmstadt.gmd.de> To: chimera-announce@cs.unlv.edu Subject: subscribe Adrian Mueller GMD ( German National Research Center for Information Technology ) Dep. IPSI ( Integrated Publication and Information Systems Institute ) Dolivostr. 15, D-64293 Darmstadt, Phone:+49.6151.869-861, Fax:+49.6151.869-818 Internet: amueller@darmstadt.gmd.de Page intentionally blank !(?) ------- Message 2 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id ab00569; 9 Nov 95 8:53 PST Received: from sonne.darmstadt.gmd.de by JIMI.CS.UNLV.EDU id aa00537; 9 Nov 95 8:49 PST Received: from belzbach.darmstadt.gmd.de (belzbach [141.12.35.111]) by sonne.darmstadt.gmd.de (8.6.11/8.6.9) with ESMTP id RAA20514; Thu, 9 Nov 1995 17:49:22 +0100 From: Adrian Mueller Received: (amueller@localhost) by belzbach.darmstadt.gmd.de (8.6.10/8.6.9) id RAA18737; Thu, 9 Nov 1995 17:49:19 +0100 Date: Thu, 9 Nov 1995 17:49:19 +0100 Message-Id: <199511091649.RAA18737@belzbach.darmstadt.gmd.de> To: czyborra@cs.tu-berlin.de CC: chimera-announce@cs.unlv.edu In-reply-to: (message from Roman Czyborra on Thu, 09 Nov 1995 17:43:50 +0100) Subject: I apologize: Re: subscribe Hello, >>>>> Roman Czyborra writes: Roman> Hi! Roman> chimera-announce@cs.unlv.edu war wohl die falsche Adresse, = Roman> das haben jetzt alle zu lesen bekommen. I apologize: sorry for mailing that noise 8-) Roman> Eintragungsw=FCsche schickt man in der Regel nur an den Roman> Mailinglistenverwalter chimera-announce-request@cs.unlv.edu Thanx for the hint. Hmm, I'd _swear_ the README said something different. I'll check it. Bye Adrian - -- ============================================================================== Adrian Mueller GMD ( German National Research Center for Information Technology ) Dep. IPSI ( Integrated Publication and Information Systems Institute ) Dolivostr. 15, D-64293 Darmstadt, Phone:+49.6151.869-861, Fax:+49.6151.869-818 Internet: amueller@darmstadt.gmd.de Page intentionally blank !(?) ------- Message 3 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa08409; 20 Nov 95 5:31 PST Received: from decpc40.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id WAA12727; Mon, 20 Nov 1995 22:30:34 +0900 Return-Path: Received: from decpc40.aist-nara.ac.jp by decpc40.aist-nara.ac.jp (8.6.12/2.7W-AIST/1.3) id WAA00460; Mon, 20 Nov 1995 22:30:32 +0900 Message-Id: <199511201330.WAA00460@decpc40.aist-nara.ac.jp> To: bug-chimera@cs.unlv.edu Subject: patch for gif.c and gifp.h X-Mailer: Mew version 1.00.4 on Emacs 19.28.451, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Nov_20_22:30:23_1995)--" Date: Mon, 20 Nov 1995 22:30:30 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= - ----Next_Part(Mon_Nov_20_22:30:23_1995)-- Content-Type: Text/Plain; charset=us-ascii I fond a bug in cfh80-2.0. A bug is that a while loop in gs_push_string() sometimes becomes an infinite loop. Please use this patch under "image" directory. cd cfh80-2.0/image patch < "this patch" - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan - ----Next_Part(Mon_Nov_20_22:30:23_1995)-- Content-Type: Text/Plain; charset=us-ascii Index: gif.c =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gif.c,v retrieving revision 1.2 retrieving revision 1.4 diff -u -r1.2 -r1.4 - --- 1.2 1995/11/13 15:12:16 +++ 1.4 1995/11/17 22:16:33 @@ -200,6 +200,26 @@ if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); if (gs->buf[0] & 0x1) gs->transparent = gs->buf[3]; } + else if (*b == 0xfe) + { + for (;;) + { + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); + if (gs->buf_cnt <= 0) break; + if (gs->comments != (char*) NULL) + gs->comments = (char*)realloc_mem((void*) gs->comments, + (strlen(gs->comments) + gs->buf_cnt + 1) * sizeof(char)); + else + { + gs->comments = (char*)alloc_mem((gs->buf_cnt + 1) * sizeof(char)); + if (gs->comments != (char*) NULL) + gs->comments[0] = '\0'; + } + if (gs->comments == (char*) NULL) return(GS_ERR_BAD_STATE); + gs->buf[gs->buf_cnt] = '\0'; + strcat(gs->comments, (char*) gs->buf); + } + } else { if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); @@ -314,13 +334,18 @@ { byte *b; int cnt; + int pos = gs->pos; /* read the data block header */ if (gs_read(gs, &b, 1) != 1) return(GS_NEED_DATA); cnt = (int)(*b); /* read the data block body */ - - if (gs_read(gs, &gs->buf, cnt) != cnt) return(GS_NEED_DATA); + if (gs_read(gs, &gs->buf, cnt) != cnt) + { + gs->pos = pos; + return(GS_NEED_DATA); + } gs->buf_idx = 0; gs->buf_cnt = cnt; @@ -448,6 +473,7 @@ int first; int place; int rval; + int pos = gs->pos; /* decode until there are some pixels on the pixel stack */ while (gs->pstk_idx == 0) @@ -456,7 +482,11 @@ { if (gs->buf_idx == gs->buf_cnt) { - - if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) + { + gs->pos = pos; + return(rval); + } } gs->work_data |= ((long) gs->buf[gs->buf_idx++]) << gs->work_bits; @@ -617,6 +647,8 @@ gifState *gs = (gifState *)pointer; if (gs->image) freeImage(gs->image); + if (gs->comments) + free_mem(gs->comments); gs->image = 0; if (gs != NULL) free_mem(gs); Index: gifp.h =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gifp.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 - --- 1.1.1.1 1995/11/13 14:53:30 +++ 1.2 1995/11/17 17:39:07 @@ -80,6 +80,7 @@ int l_ncolors_pos; /* number of colors processed, local colormap */ Intensity l_cmap[3][256]; /* local colormap */ byte interlace_flag; /* interlace image format flag */ + char* comments; /* comments in a image */ } gifState; /* - ----Next_Part(Mon_Nov_20_22:30:23_1995)---- ------- Message 4 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa27656; 20 Nov 95 14:59 PST Received: from decpc40.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id HAA24918; Tue, 21 Nov 1995 07:59:02 +0900 Return-Path: Received: from decpc40.aist-nara.ac.jp by decpc40.aist-nara.ac.jp (8.6.12/2.7W-AIST/1.3) id HAA13213; Tue, 21 Nov 1995 07:59:02 +0900 Message-Id: <199511202259.HAA13213@decpc40.aist-nara.ac.jp> To: bug-chimera@cs.unlv.edu Subject: Re: patch for gif.c and gifp.h In-Reply-To: Your message of "Mon, 20 Nov 1995 22:30:30 +0900" References: <199511201330.WAA00460@decpc40.aist-nara.ac.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.451, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Nov_21_07:58:58_1995)--" Date: Tue, 21 Nov 1995 07:59:01 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= - ----Next_Part(Tue_Nov_21_07:58:58_1995)-- Content-Type: Text/Plain; charset=us-ascii This is a second patch to fix a bug in gif.c. Please use this after my first patch for "gif.c". - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan - ----Next_Part(Tue_Nov_21_07:58:58_1995)-- Content-Type: Text/Plain; charset=us-ascii Index: gif.c =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gif.c,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 - --- 1.4 1995/11/17 22:16:33 +++ 1.5 1995/11/20 22:37:27 @@ -47,8 +47,6 @@ static int gs_read_image_header _ArgProto((gifState *)); static int gs_read_sig _ArgProto((gifState *)); static int gs_read_data_block _ArgProto((gifState *)); - -static int gs_push_string _ArgProto((gifState *, int)); - -static void gs_add_string _ArgProto((gifState *, int, int)); static int gs_read _ArgProto((gifState *, byte **, int)); static int gs_open_file _ArgProto((gifState *)); static int gs_open_image _ArgProto((gifState *)); @@ -151,15 +149,16 @@ if (gs_read(gs, &b, 1) != 1) return(GS_NEED_DATA); - - gs->root_size = (int)(*b); - - gs->clr_code = 1 << gs->root_size; - - gs->eoi_code = gs->clr_code + 1; - - gs->code_size = gs->root_size + 1; - - gs->code_mask = (1 << gs->code_size) - 1; - - gs->work_bits = 0; - - gs->work_data = 0; - - gs->buf_idx = 0; - - gs->buf_cnt = 0; + gs->root_size = (int)(*b); + gs->clr_code = 1 << gs->root_size; + gs->eoi_code = gs->clr_code + 1; + gs->table_size = gs->clr_code + 2; + gs->code_size = gs->root_size + 1; + gs->code_mask = (1 << gs->code_size) - 1; + gs->work_bits = 0; + gs->work_data = 0; + gs->buf_idx = 0; + gs->buf_cnt = 0; /* initialize string table */ for (i = 0; i < STAB_SIZE; i++) @@ -186,6 +185,7 @@ int separator; byte *b; int rval; + int pos = gs->pos; if (gs_read(gs, &b, 1) != 1) return(GS_NEED_DATA); @@ -193,18 +193,37 @@ if (separator == GIF_EXTENSION) { /* get the extension function byte */ - - if (gs_read(gs, &b, 1) != 1) return(GS_NEED_DATA); + if (gs_read(gs, &b, 1) != 1) + { + gs->pos = pos; + return(GS_NEED_DATA); + } if (*b == 0xf9) { - - if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) + { + gs->pos = pos; + return(rval); + } if (gs->buf[0] & 0x1) gs->transparent = gs->buf[3]; } else if (*b == 0xfe) { + int len = 0; + + if (gs->comments != NULL) + len = strlen(gs->comments); + for (;;) { - - if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) + { + gs->pos = pos; + if (gs->comments != NULL) + gs->comments[len] = '\0'; + return(rval); + } if (gs->buf_cnt <= 0) break; if (gs->comments != (char*) NULL) gs->comments = (char*)realloc_mem((void*) gs->comments, @@ -222,7 +241,11 @@ } else { - - if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) return(rval); + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) + { + gs->pos = pos; + return(rval); + } } return(GS_SUCCESS); @@ -354,64 +377,6 @@ } /* - - * gs_push_string - - * - - * push a string (denoted by a code) onto the pixel stack - - * (returns the code of the first pixel in the string) - - */ - -static int - -gs_push_string(gs, code) - -gifState *gs; - -int code; - -{ - - int rslt; - - - - while (gs->prefix[code] != NULL_CODE) - - { - - if (gs->pstk_idx < PSTK_SIZE) - - { - - gs->pstk[gs->pstk_idx] = gs->extnsn[code]; - - gs->pstk_idx++; - - } - - code = gs->prefix[code]; - - } - - - - if (gs->pstk_idx < PSTK_SIZE) - - { - - gs->pstk[gs->pstk_idx] = gs->extnsn[code]; - - gs->pstk_idx++; - - } - - rslt = gs->extnsn[code]; - - - - return(rslt); - -} - - - -/* - - * gs_add_string - - * - - * add a new string to the string table - - */ - -static void - -gs_add_string(gs, p, e) - -gifState *gs; - -int p; - -int e; - -{ - - gs->prefix[gs->table_size] = p; - - gs->extnsn[gs->table_size] = e; - - - - if ((gs->table_size == gs->code_mask) && (gs->code_size < 12)) - - { - - gs->code_size += 1; - - gs->code_mask = (1 << gs->code_size) - 1; - - } - - - - gs->table_size += 1; - - - - return; - -} - - - -/* * gs_make_image */ static int @@ -471,9 +436,7 @@ { int code; int first; - - int place; int rval; - - int pos = gs->pos; /* decode until there are some pixels on the pixel stack */ while (gs->pstk_idx == 0) @@ -482,62 +445,77 @@ { if (gs->buf_idx == gs->buf_cnt) { + int pos = gs->pos; + if ((rval = gs_read_data_block(gs)) != GS_SUCCESS) { gs->pos = pos; return(rval); } } - - + gs->work_data |= ((long) gs->buf[gs->buf_idx++]) << gs->work_bits; gs->work_bits += 8; } - - + /* get the next code */ code = gs->work_data & gs->code_mask; gs->work_data >>= gs->code_size; gs->work_bits -= gs->code_size; - - + /* interpret the code */ + if (code > gs->table_size || code == gs->eoi_code) + { + /* Format Error */ + return(GS_ERR_EOF); + } + if (code == gs->clr_code) { + /* reset decoder */ gs->code_size = gs->root_size + 1; gs->code_mask = (1 << gs->code_size) - 1; - - gs->prev_code = NULL_CODE; gs->table_size = gs->eoi_code + 1; + gs->prev_code = NULL_CODE; + continue; } - - else if (code == gs->eoi_code) + + if (gs->prev_code == NULL_CODE) { - - return(GS_ERR_EOF); + gs->pstk[gs->pstk_idx++] = gs->extnsn[code]; + gs->prev_code = code; + first = code; + continue; } else { - - if (gs->prev_code == NULL_CODE) + int in_code = code; + + if (code == gs->table_size) { - - gs_push_string(gs, code); - - gs->prev_code = code; + gs->pstk[gs->pstk_idx++] = first; + code = gs->prev_code; } - - else + while (code > gs->clr_code) { - - if (code < gs->table_size) - - { - - first = gs_push_string(gs, code); - - } - - else - - { - - place = gs->pstk_idx; - - if (gs->pstk_idx < PSTK_SIZE) - - { - - gs->pstk[gs->pstk_idx] = NULL_CODE; - - gs->pstk_idx++; - - } - - first = gs_push_string(gs, gs->prev_code); - - gs->pstk[place] = first; - - } - - - - gs_add_string(gs, gs->prev_code, first); - - gs->prev_code = code; + gs->pstk[gs->pstk_idx++] = gs->extnsn[code]; + code = gs->prefix[code]; + } + first = gs->extnsn[code]; + /* Add a new string to the string table. */ + if (gs->table_size >= PSTK_SIZE) + return(GS_ERR_EOF); + gs->pstk[gs->pstk_idx++] = first; + gs->prefix[gs->table_size] = gs->prev_code; + gs->extnsn[gs->table_size] = first; + gs->table_size ++; + if (((gs->table_size & gs->code_mask)) == 0 + && (gs->table_size < PSTK_SIZE)) + { + gs->code_size ++; + gs->code_mask += gs->table_size; } + gs->prev_code = in_code; } } - ----Next_Part(Tue_Nov_21_07:58:58_1995)---- ------- Message 5 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa02465; 20 Nov 95 17:22 PST Received: from decpc40.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id KAA00534; Tue, 21 Nov 1995 10:22:31 +0900 Return-Path: Received: from decpc40.aist-nara.ac.jp by decpc40.aist-nara.ac.jp (8.6.12/2.7W-AIST/1.3) id KAA13435; Tue, 21 Nov 1995 10:22:30 +0900 Message-Id: <199511210122.KAA13435@decpc40.aist-nara.ac.jp> To: bug-chimera@cs.unlv.edu Subject: Re: patch for gif.c and gifp.h In-Reply-To: Your message of "Tue, 21 Nov 1995 07:59:01 +0900" References: <199511202259.HAA13213@decpc40.aist-nara.ac.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.451, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Nov_21_10:22:27_1995)--" Date: Tue, 21 Nov 1995 10:22:29 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= - ----Next_Part(Tue_Nov_21_10:22:27_1995)-- Content-Type: Text/Plain; charset=us-ascii I'm sorry, there is a bug in my second patch. This is a third patch to fix a bug in my second patch. - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan - ----Next_Part(Tue_Nov_21_10:22:27_1995)-- Content-Type: Text/Plain; charset=us-ascii Index: gif.c =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gif.c,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 - --- 1.5 1995/11/20 22:37:27 +++ 1.6 1995/11/21 00:49:56 @@ -159,7 +159,8 @@ gs->work_data = 0; gs->buf_idx = 0; gs->buf_cnt = 0; - - + gs->first = 0; + /* initialize string table */ for (i = 0; i < STAB_SIZE; i++) { @@ -435,7 +436,6 @@ int *pel; { int code; - - int first; int rval; /* decode until there are some pixels on the pixel stack */ @@ -454,7 +454,7 @@ } } - - gs->work_data |= ((long) gs->buf[gs->buf_idx++]) << gs->work_bits; + gs->work_data |= ((unsigned) gs->buf[gs->buf_idx++]) << gs->work_bits; gs->work_bits += 8; } @@ -475,7 +475,7 @@ /* reset decoder */ gs->code_size = gs->root_size + 1; gs->code_mask = (1 << gs->code_size) - 1; - - gs->table_size = gs->eoi_code + 1; + gs->table_size = gs->clr_code + 2; gs->prev_code = NULL_CODE; continue; } @@ -484,7 +484,7 @@ { gs->pstk[gs->pstk_idx++] = gs->extnsn[code]; gs->prev_code = code; - - first = code; + gs->first = code; continue; } else @@ -493,7 +493,7 @@ if (code == gs->table_size) { - - gs->pstk[gs->pstk_idx++] = first; + gs->pstk[gs->pstk_idx++] = gs->first; code = gs->prev_code; } while (code > gs->clr_code) @@ -501,13 +501,13 @@ gs->pstk[gs->pstk_idx++] = gs->extnsn[code]; code = gs->prefix[code]; } - - first = gs->extnsn[code]; + gs->first = gs->extnsn[code]; /* Add a new string to the string table. */ if (gs->table_size >= PSTK_SIZE) return(GS_ERR_EOF); - - gs->pstk[gs->pstk_idx++] = first; + gs->pstk[gs->pstk_idx++] = gs->first; gs->prefix[gs->table_size] = gs->prev_code; - - gs->extnsn[gs->table_size] = first; + gs->extnsn[gs->table_size] = gs->first; gs->table_size ++; if (((gs->table_size & gs->code_mask)) == 0 && (gs->table_size < PSTK_SIZE)) Index: gifp.h =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gifp.h,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 - --- 1.2 1995/11/17 17:39:07 +++ 1.3 1995/11/21 00:50:00 @@ -40,8 +40,9 @@ int code_size; /* current code size */ int code_mask; /* current code mask */ int prev_code; /* previous code */ + int first; /* */ - - int work_data; /* working bit buffer */ + unsigned work_data; /* working bit buffer */ int work_bits; /* working bit count */ byte *buf; /* byte buffer */ - ----Next_Part(Tue_Nov_21_10:22:27_1995)---- ------- Message 6 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa20483; 24 Nov 95 13:16 PST Received: from decpc42.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id GAA00917; Sat, 25 Nov 1995 06:16:20 +0900 Return-Path: Received: from decpc42.aist-nara.ac.jp by decpc42.aist-nara.ac.jp (8.6.12/2.7W-AIST/1.3) id GAA01454; Sat, 25 Nov 1995 06:16:56 +0900 Message-Id: <199511242116.GAA01454@decpc42.aist-nara.ac.jp> To: bug-chimera@cs.unlv.edu Subject: Re: patch for gif.c and gifp.h In-Reply-To: Your message of "Tue, 21 Nov 1995 10:22:29 +0900" References: <199511210122.KAA13435@decpc40.aist-nara.ac.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.451, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Nov_25_06:16:20_1995)--" Date: Sat, 25 Nov 1995 06:16:55 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= - ----Next_Part(Sat_Nov_25_06:16:20_1995)-- Content-Type: Text/Plain; charset=us-ascii I found a bug at decoding interlaced inline gif. I send a 4th patch to fix that bug in "gif.c". - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan - ----Next_Part(Sat_Nov_25_06:16:20_1995)-- Content-Type: Text/Plain; charset=us-ascii Index: gif.c =================================================================== RCS file: /home/is/shige-y/CVS/chimera/cfh80-2.0/image/gif.c,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 - --- 1.6 1995/11/21 00:49:56 +++ 1.7 1995/11/24 20:59:05 @@ -41,9 +41,6 @@ /* rate at which we accelerate vertically */ static int interlace_rate[4] = { 8, 8, 4, 2 }; - -/* how often to copy the line */ - -static int interlace_copy[4] = { 8, 4, 2, 1 }; - - static int gs_read_image_header _ArgProto((gifState *)); static int gs_read_sig _ArgProto((gifState *)); static int gs_read_data_block _ArgProto((gifState *)); @@ -586,28 +583,8 @@ if (image->x == image->width) { - - if (gs->interlace_flag && interlace_copy[image->pass] > 1) - - { - - byte *origline = image->data + image->y * image->bytes_per_line; - - byte *copyline = origline + image->bytes_per_line; - - int i; - - for (i = 1; - - i < interlace_copy[image->pass] && image->y + i < image->height; - - i++, copyline += image->bytes_per_line) - - { - - memcpy(copyline, origline, image->bytes_per_line); - - } - - if (gs->lineProc != NULL) - - (gs->lineProc)(gs->closure, - - image->y, - - MIN(image->y + interlace_copy[image->pass] - 1, - - image->height - 1)); - - } - - else - - { - - if (gs->lineProc != NULL) - - (gs->lineProc)(gs->closure, image->y, image->y); - - } + if (gs->lineProc != NULL) + (gs->lineProc)(gs->closure, image->y, image->y); } return(GS_SUCCESS); - ----Next_Part(Sat_Nov_25_06:16:20_1995)---- ------- Message 7 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa21353; 24 Nov 95 14:18 PST Received: from kroete2.freinet.de (arhppp39.uni-c.dk [130.225.243.201]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id XAA19636 for ; Fri, 24 Nov 1995 23:16:41 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tJ6RV-0003m8C; Fri, 24 Nov 95 23:18 MET Message-Id: From: Erik Corry Subject: Re: patch for gif.c and gifp.h To: bug-chimera@cs.unlv.edu Date: Fri, 24 Nov 1995 23:18:01 +0100 (MET) In-Reply-To: <199511242116.GAA01454@decpc42.aist-nara.ac.jp> from "=?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?=" at Nov 25, 95 06:16:55 am Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS I found a bug at decoding interlaced inline gif. > I send a 4th patch to fix that bug in "gif.c". What your patch seems to do is to go back to the old behaviour of displaying each line of an interlaced GIF as it arrives, leaving the lines that have not yet arrived blank to create a sort of trellis effect. The new behaviour was to copy early lines to the lines that have not arrived. This creates a blocky effect of slowly increasing resolution. This is the behaviour I have seen in 'a certain other browser'. According to the documentation for PNG, most users prefer the blocky effect to the trellis effect. Was there a bug in the blocky effect code, or did you just not like it? Does anyone else have a strong opinion on this. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 8 Received: from mail.clark.net by JIMI.CS.UNLV.EDU id aa08248; 26 Nov 95 15:40 PST Received: from clark.net (clark.net [168.143.0.7]) by mail (SMI-8.6/8.6.5) with ESMTP id SAA07102 for ; Sun, 26 Nov 1995 18:39:53 -0500 From: Dave Cottingham Received: (from dc@localhost) by clark.net (8.7.1/8.7.1) id SAA26986 for bug-chimera@cs.unlv.edu; Sun, 26 Nov 1995 18:40:10 -0500 (EST) Date: Sun, 26 Nov 1995 18:40:10 -0500 (EST) Message-Id: <199511262340.SAA26986@clark.net> To: bug-chimera@cs.unlv.edu Subject: Doc on chimera font resources I had to change some of the fonts for preformatted text (my notebook has a very small screen). The resources that control the fonts are not among those documented in the help page. So after I scrounged the info I needed, I wrote it down. Here it is. Hope someone finds it useful. You might add this to the help page if you feel like it. Dave Cottingham dc@clark.net - ----------

Chimera font resources

Chimera uses the following resources to select the fonts used to display documents. Some of the fonts come in bold and italic versions; <B> or <STRONG> switch to the bold version, and <EM>, <VAR>, <CITE>, or <I> switch to the italic version. 
font		The usual font for HTML documents.  Default:
		-*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1

italicFont	Italic version of the regular font.  This is also the
		default italic version for anything other than "plain"
		or "fixed."  Default:
		-*-helvetica-medium-o-normal-*-*-120-*-*-*-*-iso8859-1

boldFont	Bold version of the regular font.  This is also the
		default bold version for anything other then "plain"
		or "fixed."  Default:
		-*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1

fixedFont	Used to display <CODE>, <SAMP>, <KBD>, and <TT>.
		Default:
		-adobe-courier-medium-r-normal-*-14-*-*-*-*-*-*-*

fixedboldFont	Bold version of the fixed font.  Default:
		-adobe-courier-bold-r-normal-*-14-*-*-*-*-*-*-*

fixeditalicFont	Italic version of the fixed font.  Default:
		-adobe-courier-medium-o-normal-*-14-*-*-*-*-*-*-*

header1Font	Used to display a <H1>.  Default:
		-*-helvetica-bold-r-normal-*-*-240-*-*-*-*-iso8859-1

header2Font	Used to display a <H2>.  Default:
		-*-helvetica-bold-r-normal-*-*-180-*-*-*-*-iso8859-1

header3Font	Used to display a <H3>.  Default:
		-*-helvetica-bold-r-normal-*-*-140-*-*-*-*-iso8859-1

header4Font	Used to display a <H4>.  Default:
		-*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1

header5Font	Used to display a <H5>.  Default:
		-*-helvetica-bold-r-normal-*-*-100-*-*-*-*-iso8859-1

header6Font	Used to display a <H6>.  Default:
		-*-helvetica-bold-r-normal-*-*-80-*-*-*-*-iso8859-1

addressFont	Used to display an <ADDRESS>.  Default:
		-*-helvetica-medium-o-normal-*-*-140-*-*-*-*-iso8859-1

plainFont	Used to display <XMP>, <PLAINTEXT>, and <PRE>.
		Also used for non-HTML files.  Default:
		-adobe-courier-medium-r-normal-*-14-*-*-*-*-*-*-*"

plainboldFont	Bold version of the plain font.  Default:
		-adobe-courier-bold-r-normal-*-14-*-*-*-*-*-*-*

plainitalicFont	Italic version of the plain font.  Default:
		-adobe-courier-medium-o-normal-*-14-*-*-*-*-*-*-*

listingFont	Used to display a <LISTING>.  Default:
		-adobe-courier-medium-r-normal-*-12-*-*-*-*-*-*-*
------- Message 9 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa09154; 26 Nov 95 16:50 PST Received: from decpc42.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id JAA07822; Mon, 27 Nov 1995 09:50:38 +0900 Return-Path: Received: from decpc42.aist-nara.ac.jp by decpc42.aist-nara.ac.jp (8.6.12/2.7W-AIST/1.3) id JAA06220; Mon, 27 Nov 1995 09:51:12 +0900 Message-Id: <199511270051.JAA06220@decpc42.aist-nara.ac.jp> To: ehcorry@inet.uni-c.dk, erik@kroete2.freinet.de Cc: bug-chimera@cs.unlv.edu Subject: Re: patch for gif.c and gifp.h In-Reply-To: Your message of "Fri, 24 Nov 1995 23:18:01 +0100 (MET)" References: X-Mailer: Mew version 1.00.4 on Emacs 19.28.451, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 27 Nov 1995 09:51:11 +0900 From: =?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?= >>>>> "Erik" == Erik Corry writes: Erik> Was there a bug in the blocky effect code, Yes. I found a bug at viewing some interlaced images. For example, I create a test page . In this page, there are same three images, in which a single dot and three lines are painted. Can you look at three lines in this test page? - ------------------------------------------------------------------------------- Shigeru Yamamoto Information Networks, Department of Information Systems Nara Advanced Institute of Science and Technology Nara, Japan ------- Message 10 Received: from aohakobe.ipc.chiba-u.ac.jp by JIMI.CS.UNLV.EDU id aa09881; 26 Nov 95 17:35 PST Received: from aohakobe (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.6.12/3.4Wbeta3 (-: 95041617) with ESMTP id KAA25258; Mon, 27 Nov 1995 10:35:52 +0900 Message-Id: <199511270135.KAA25258@aohakobe.ipc.chiba-u.ac.jp> To: bug-chimera@cs.unlv.edu CC: ehcorry@inet.uni-c.dk, erik@kroete2.freinet.de Subject: Re: patch for gif.c and gifp.h In-reply-to: Your message of "Mon, 27 Nov 1995 09:51:11 +0900." <199511270051.JAA06220@decpc42.aist-nara.ac.jp> Date: Mon, 27 Nov 1995 10:35:52 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) > For example, I create a test page > . ^^^^^ FQDN is "shika.aist-nara.ac.jp." if your resolver can't find "shika", try the following URL (-: BTW, good old chimera-1.65 can display three lines, whereas cfh72-2.0 cannot display those. - -- yozo. I don't yet try the newest version, nor I18N patch... ------- Message 11 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa09897; 26 Nov 95 17:37 PST Received: from kroete2.freinet.de (arhppp1.uni-c.dk [130.225.243.161]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id CAA29046 for ; Mon, 27 Nov 1995 02:35:08 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tJrsF-0003kOC; Mon, 27 Nov 95 01:56 MET Message-Id: From: Erik Corry Subject: Re: Doc on chimera font resources To: bug-chimera@cs.unlv.edu Date: Mon, 27 Nov 1995 01:56:46 +0100 (MET) In-Reply-To: <199511262340.SAA26986@clark.net> from "Dave Cottingham" at Nov 26, 95 06:40:10 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS font The usual font for HTML documents. Default: > -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 I'd like to plead for this to be changed to Times. Any typographical text will tell you that long stretches of text should be in a seriffed font. The headings can stay in Helvetica, though. Defaults matter! - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 12 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa10491; 26 Nov 95 18:11 PST Received: from kroete2.freinet.de (arhppp11.uni-c.dk [130.225.243.171]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id DAA00569 for ; Mon, 27 Nov 1995 03:09:44 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tJt1K-0003kOC; Mon, 27 Nov 95 03:10 MET Message-Id: From: Erik Corry Subject: Re: patch for gif.c and gifp.h To: bug-chimera@cs.unlv.edu Date: Mon, 27 Nov 1995 03:10:13 +0100 (MET) In-Reply-To: <199511270051.JAA06220@decpc42.aist-nara.ac.jp> from "=?ISO-2022-JP?B?GyRCOzNLXBsoQg==?= =?ISO-2022-JP?B?GyRCTFAbKEI=?=" at Nov 27, 95 09:51:11 am Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS > >>>>> "Erik" == Erik Corry writes: > Erik> Was there a bug in the blocky effect code, > > Yes. > I found a bug at viewing some interlaced images. > > For example, I create a test page > . You're right, there was a bug in the handling of interlaced 2-colour GIFs. Here is a patch that solves the problem, but preserves the blocky effect: - --- gif.c.shigeru Wed Sep 20 09:32:05 1995 +++ gif.c Mon Nov 27 03:05:07 1995 @@ -562,10 +562,12 @@ if ((rval = gs_get_pixel(gs, &pixel)) != GS_SUCCESS) return(rval); if(image->pixlen == 1) { + int bitpos = image->x & 7; + if (bitpos == 0) *pixptr = 0; # ifdef LITTLE_ENDIAN - - pixel <<= (image->x & 7); + pixel <<= bitpos; # else - - pixel <<= 7 - (image->x & 7); + pixel <<= 7 - bitpos; # endif *pixptr |= pixel; } - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 13 Received: from enterprise.cistron.nl by JIMI.CS.UNLV.EDU id aa11954; 26 Nov 95 19:36 PST Received: from ava.UUCP by enterprise.cistron.nl (8.7.1) with UUCP id EAA27943; Mon, 27 Nov 1995 04:25:39 +0100 Received: by kozmix.ow.nl (Smail3.1.29.1 #3) id m0tJuBE-00028FC; Mon, 27 Nov 95 04:24 MET Message-Id: From: Sander van Malssen Subject: Re: Doc on chimera font resources To: bug-chimera@cs.unlv.edu Date: Mon, 27 Nov 1995 04:24:31 +0100 (MET) In-Reply-To: from "Erik Corry" at Nov 27, 95 01:56:46 am Reply-To: svm@kozmix.ow.nl Organization: Kozmic Egg Productions, Gouda, Netherlands X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > font The usual font for HTML documents. Default: > > -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 > > I'd like to plead for this to be changed to Times. Any typographical > text will tell you that long stretches of text should be in a seriffed > font. The headings can stay in Helvetica, though. I'm not too sure about that. The only rule I know is that if the running text is serifed, the headers should be sans serif, and vice versa. And yes, for printed text it's usually considered better if the running text is serifed, but on computer screens small serifed fonts often don't end up very readable, so it might be better to use Helvetica for *font and Times for *header[1-6]Font. Personally I use Times for the headers and Lucida for everything else. Cheers, Sander - -- Sander van Malssen svm@kozmix.ow.nl -- svm@kozmix.xs4all.nl -- https://www.cistron.nl/~svm/ ------- Message 14 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14741; 26 Nov 95 22:41 PST Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14684; 26 Nov 95 22:35 PST To: chimera-announce@cephas.ISRI.UNLV.EDU Subject: alpha 88 Date: Sun, 26 Nov 1995 22:35:06 -0800 From: John Kilburg 88?!? Well, I was going to wait until the next snapshot but I thought I would let everyone know about https://www.unlv.edu/~john/chimera/src/cfh88-2.0.tar.gz This one has mostly internal changes...lots of things have been rebroken. FTP and text/plain don't work so don't expect to use it as anything other than a view of what I have been doing. The major change is that chimera is no longer based directly on an HTML viewer and that all supported content-types can be inlined or viewed in the toplevel window. -john ------- Message 15 Received: from haymarket.ed.ac.uk by JIMI.CS.UNLV.EDU id aa21565; 27 Nov 95 4:39 PST Received: from aiai.ed.ac.uk (skye-alter.aiai.ed.ac.uk [192.41.104.6]) by haymarket.ed.ac.uk (8.6.10/8.6.12) with SMTP id MAA07918; Mon, 27 Nov 1995 12:35:08 GMT Received: from subnode.aiai.ed.ac.uk (scarp) by aiai.ed.ac.uk; Mon, 27 Nov 95 12:32:45 GMT Date: Mon, 27 Nov 95 12:32:44 GMT Message-Id: <8578.9511271232@subnode.aiai.ed.ac.uk> From: Tim Bradshaw To: Erik Corry Cc: bug-chimera@cs.unlv.edu Subject: Re: Doc on chimera font resources In-Reply-To: References: <199511262340.SAA26986@clark.net> * Erik Corry wrote: > Thank's a lot for writing this doc, Dave! >> font The usual font for HTML documents. Default: >> -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 > I'd like to plead for this to be changed to Times. Any typographical > text will tell you that long stretches of text should be in a seriffed > font. The headings can stay in Helvetica, though. Any typographical text that deals with display of text on screens shouldn't say this! Serifed fonts with plenty of weight variation are fine on high-resolution devices like paper, but pretty awful on screens. Helvetica is a pretty reasonable compromise, lucida might be another one worth trying (lucida was designed with screens in mind, unlike times!). Chimera's use of fonts is *much* better than netscape/mosaics IMHO. - --tim ------- Message 16 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa00935; 27 Nov 95 10:33 PST Received: from kroete2.freinet.de (arhppp8.uni-c.dk [130.225.243.168]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id TAA08778 for ; Mon, 27 Nov 1995 19:31:44 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tK8EU-0003mAC; Mon, 27 Nov 95 19:24 MET Message-Id: From: Erik Corry Subject: Re: Doc on chimera font resources To: bug-chimera@cs.unlv.edu Date: Mon, 27 Nov 1995 19:24:48 +0100 (MET) In-Reply-To: <8578.9511271232@subnode.aiai.ed.ac.uk> from "Tim Bradshaw" at Nov 27, 95 12:32:44 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS >> font The usual font for HTML documents. Default: > >> -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 > > > I'd like to plead for this to be changed to Times. Any typographical > > text will tell you that long stretches of text should be in a serifed > > font. The headings can stay in Helvetica, though. > > Any typographical text that deals with display of text on screens > shouldn't say this! Serifed fonts with plenty of weight variation are > fine on high-resolution devices like paper, but pretty awful on > screens. Helvetica is a pretty reasonable compromise, lucida might be > another one worth trying (lucida was designed with screens in mind, > unlike times!). Chimera's use of fonts is *much* better than > netscape/mosaics IMHO. But this weight variation is edited out at low resolutions. I use - -*-times-medium-r-normal-*-*-140-*-*-*-*-iso8859-1 for the normal text font, and it looks fine. It's a hand edited bitmap at that size. The equivalent, lucidabright, uses slightly more space and is no more readable. Lucida itself is an unserifed font, I presume you meant Lucida Bright. I just think Chimera with the default fonts looks like some sort Zeitgeist magazine where a Mac operator has gone crazy and set the whole thing in Helvetica. I guess this just proves that everyone has different taste. The best solution would be if it were simpler for ordinary users who don't necessarily understand resource files to set things the way they like it. That's a general X problem (which doesn't mean it's insoluble). - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 17 Received: from cygnus.com by JIMI.CS.UNLV.EDU id aa03757; 27 Nov 95 11:47 PST Received: from tito.cygnus.com (tito.cygnus.com [192.80.44.39]) by cygnus.com (8.6.12/8.6.9) with SMTP id LAA23737; Mon, 27 Nov 1995 11:46:56 -0800 Received: by tito.cygnus.com (4.1/SMI-4.1) id AA20845; Mon, 27 Nov 95 14:46:18 EST Date: Mon, 27 Nov 95 14:46:18 EST Message-Id: <9511271946.AA20845@tito.cygnus.com> To: ehcorry@inet.uni-c.dk Cc: bug-chimera@cs.unlv.edu In-Reply-To: (message from Erik Corry on Mon, 27 Nov 1995 19:24:48 +0100 (MET)) Subject: Re: Doc on chimera font resources From: eichin@cygnus.com > best solution would be if it were simpler for ordinary users > who don't necessarily understand resource files to set things the > way they like it. That's a general X problem (which doesn't mean I haven't used Mosaic in a long time (yay) but recall that it had a menu of font styles with enough variation to let inexperienced users figure out what they liked. Then if they *really* want a more specific setting, they get to frob with resources and xfontsel and the like... (of course, I like the spartan helvetica look, though I agree it is less readable overall, I'm often using a laptop where size is everthing and unfortunately sans-serif fonts stay readable to smaller sizes better than the serif'ed ones, at least in X, and to my eyes...) ------- Message 18 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05908; 27 Nov 95 12:45 PST To: bug-chimera@cs.unlv.edu cc: eichin@cygnus.com Subject: Re: Doc on chimera font resources In-reply-to: Your message of "Mon, 27 Nov 1995 14:46:18 EST." <9511271946.AA20845@tito.cygnus.com> Date: Mon, 27 Nov 1995 12:45:01 -0800 From: John Kilburg >> best solution would be if it were simpler for ordinary users >> who don't necessarily understand resource files to set things the >> way they like it. That's a general X problem (which doesn't mean > >I haven't used Mosaic in a long time (yay) but recall that it had a >menu of font styles with enough variation to let inexperienced users >figure out what they liked. Then if they *really* want a more specific >setting, they get to frob with resources and xfontsel and the like... >(of course, I like the spartan helvetica look, though I agree it is >less readable overall, I'm often using a laptop where size is >everthing and unfortunately sans-serif fonts stay readable to smaller >sizes better than the serif'ed ones, at least in X, and to my eyes...) Alpha 88 and above handles fonts differently. The HTML code tries to muck with the font description string so that font attributes can be combined. For example, try: Some text The font handling code will probably be revised as I attempt to figure out what I should be doing. Also, the current font is hardcoded to be "times" (for now) because it seemed to have the best selection of styles and sizes. The Xew text (?) widget already deals with this so I'll probably look there for ideas. If anyone has strong feelings about how this should be handled, let me know. -john ------- Message 19 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa19538; 28 Nov 95 14:30 PST Received: from kroete2.freinet.de (arhppp29.uni-c.dk [130.225.243.189]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id XAA02227 for ; Tue, 28 Nov 1995 23:27:59 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tKYBw-0003mlC; Tue, 28 Nov 95 23:07 MET Message-Id: From: Erik Corry Subject: Internationalisation patches To: bug-chimera@cs.unlv.edu Date: Tue, 28 Nov 1995 23:07:54 +0100 (MET) Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS , &, ;, newline, space). Also, all the characters that are special in URLs are unchanged, and no parts of wide characters look like ASCII characters. 3) Texts in ISO 8859-x fonts which consist mostly of ASCII characters don't get much bigger. 4) Strings can be null-terminated in the same way as normal 8-bit C strings. 5) We become part of the Unicode effort, and can take advantage of OS and library support as it becomes available. For example Linux is standardising on Unicode/UTF-8 for filenames and other system strings. Java and Windows NT are Unicode based. 6) The parts of the program that need to be changed are restricted to input and output routines. The internals can stay unchanged. This minimises the risk of John and I (who can't read any wide character sets) accidentally breaking things. I think it would be possible to write an output routine for X that didn't use the locale support. 7) Input and output formats are independent. So if we have an input mail message that uses the non-standard Russian Cyrillic encoding, but only standard ISO Cyrillic fonts on the display, it is clear what conversions need to be done where. Or if you want to browse different Chinese newsgroups with Chimera that have different character encodings (I understand there are at least two, other than Unicode-based encodings). HTML at the moment only officially supports ISO 8859-1 (Western European 8-bit ASCII superset). The patches from Shigeru Yamamoto are based on non-standard (for HTML) escape-codes for switching fonts. That's not intended as a critcism, because there was no choice, but that is never going to become standard HTML because it seems to be incompatible with SGML (I think). There is a proposal for HTML to become based on Unicode, which looks like it has better chances of being accepted. In the mean time the HTML-reading code can convert to Unicode, so no features presently in Shigeru Yamamoto's patches are lost. I haven't thought much about right-to-left character sets yet, but they are clearly non-trivial. And I don't think anyone on the list is interested (correct me if I'm wrong). Please let me know what you think and whether the implementation of such ideas is too much work, or premature. I am anxious that Chimera should get this right. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 20 Received: from fsb1.aist-nara.ac.jp by JIMI.CS.UNLV.EDU id aa04528; 28 Nov 95 22:53 PST Received: from bls3.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id PAA02972; Wed, 29 Nov 1995 15:52:15 +0900 Return-Path: Received: from localhost by bls3.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA03928; Wed, 29 Nov 95 15:51:54 GMT+0900 Message-Id: <9511290651.AA03928@bls3.aist-nara.ac.jp> To: ehcorry@inet.uni-c.dk Cc: bug-chimera@cs.unlv.edu Subject: Re: Internationalisation patches In-Reply-To: Your message of "Tue, 28 Nov 1995 23:07:54 +0100 (MET)" References: X-Mailer: Mew version 1.00.4 on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 29 Nov 1995 15:51:52 +0900 From: Kenichi Chinen Mr. Corry. Please don't say Unicode. I don't know what is best. but I know Unicode is bad. Unicode was joined many charactors without (charactor and langauage) backgrounds. It support only few charactors in the world. How many people express one's name via Unicode ? I cannot answer this question, but I believe it is less than a quarter of the population of the world. Unicode is very short term complacency solution for several peoples. We must designe other way more smart. Unicode is new one of terrible codes. It will makes us confuse... For example. In japan, there are many codes. Almost all the people use 3 codes(JIS/EUC/SJIS). If they use Unicode. It use as 4th code, it cannot replace others. We are very sensitive to codes... Thanks. - --- k-chinen@is.aist-nara.ac.jp ------- Message 21 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05096; 29 Nov 95 2:04 PST Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05012; 29 Nov 95 2:00 PST To: chimera-announce@cephas.ISRI.UNLV.EDU Subject: alpha 90 Date: Wed, 29 Nov 1995 02:00:10 -0800 From: John Kilburg Just put out a new one https://www.unlv.edu/~john/chimera/src/cfh90-2.0.tar.gz This one shouldn't crash as much 88 (yeah right) and is the first halfway decent release of a multi-window chimera. There are some extremely patient folks out there that have been waiting for this one :) The windows share cache information, should operate at the same time, and have their own document threads. BTW, thanks for the patches and comments. I really appreciate them but don't always acknowledge them. Thanks. -john ------- Message 22 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa21137; 29 Nov 95 12:50 PST Received: from kroete2.freinet.de (arhppp7.uni-c.dk [130.225.243.167]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id VAA25232 for ; Wed, 29 Nov 1995 21:47:57 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tKrhB-0003kTC; Wed, 29 Nov 95 19:57 MET Message-Id: From: Erik Corry Subject: Re: Internationalisation patches To: bug-chimera@cs.unlv.edu Date: Wed, 29 Nov 1995 19:57:27 +0100 (MET) Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS > * Erik Corry wrote: > > > HTML at the moment only officially supports ISO 8859-1 (Western > > European 8-bit ASCII superset). The patches from Shigeru > > Yamamoto are based on non-standard (for HTML) escape-codes > > for switching fonts. That's not intended as a critcism, > > because there was no choice, but that is never going to become > > standard HTML because it seems to be incompatible with SGML (I > > think). There is a proposal for HTML to become based on Unicode, > > which looks like it has better chances of being accepted. In > > the mean time the HTML-reading code can convert to Unicode, > > so no features presently in Shigeru Yamamoto's patches are lost. What I wrote there was a little inaccurate. In fact HTML already supports different character sets. The character set can be specified in the HTTP protocol with the MIME-header 'Content-Type: text/html; charset=xxx' ISO8859-1 has a special status, as it is the default character set. What Shigeru Yamamoto's changes do is to assume that the standard character set is JISx0201.1976. This is necessary, because most web servers don't provide the correct header. Another possibility is to use an HTML META tag near the top of the document. This allows you to add headers that the HTTP server should have sent for that document (does Chimera evaluate these at the moment?). Conceptually this solution is a little messy, because it means the charset is switched halfway through the file, but if you stick to US-ASCII up to that point it should be OK. It is still necessary for Chimera to guess at the character set, however, because most pages are not correctly labelled. This also applies when Chimera reads using protocols like file and ftp that do not have headers. What the proposed Unicode changes do is to declare Unicode to be the SGML character set for the HTML DTD. This means that in addition to the normal characters in the character set you have chosen, you can specify 16-bit Unicode characters with the &#xxxx; notation. The old numeric character set specification &#xx; still refers to ISO 8859-1 (Latin 1) because the first 256 characters of Unicode are the same as Latin 1. This means you can't use &#xx; or &#xxxx; (where xx and xxxx are hexadecimal numbers) to indicate characters in your chosen document character set (unless that happens to be Unicode or Latin 1). [ Incidentally, HTML can only support character sets that are a superset of US-ASCII, or have an ASCII-superset mode. Otherwise there would be no way of specifying HTML markup. I don't think this is a real problem, since nobody cares about EBCDIC any more, and the Scandinavian 7-bit character sets do not alter HTML-relevant characters. (And nobody should care about them any more, either...) ] > Can you tell me what the escape codes are? (I lost the patches). I've still got them, but they are 5000 lines long and I can't find the exact escape sequences in them. Perhaps this is at present handled by the X locale code(?). They start with the ASCII code 27 (ESC), so in practice there should be no conflict with any ASCII-based 8-bit character sets. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 23 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa21152; 29 Nov 95 12:50 PST Received: from kroete2.freinet.de (arhppp7.uni-c.dk [130.225.243.167]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id VAA25258 for ; Wed, 29 Nov 1995 21:48:12 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tKsyG-0003mAC; Wed, 29 Nov 95 21:19 MET Message-Id: From: Erik Corry Subject: Re: Internationalisation patches To: bug-chimera@cs.unlv.edu Date: Wed, 29 Nov 1995 21:19:10 +0100 (MET) In-Reply-To: <9511290651.AA03928@bls3.aist-nara.ac.jp> from "Kenichi Chinen" at Nov 29, 95 03:51:52 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS Mr. Corry. > > > Please don't say Unicode. > I don't know what is best. but I know Unicode is bad. > > Unicode was joined many charactors without (charactor and langauage) > backgrounds. It support only few charactors in the world. > How many people express one's name via Unicode ? > I cannot answer this question, but I believe it is less than a quarter > of the population of the world. Apparently there is a lot of opposition to Unicode in Japan. I think this is a pity. You say that Unicode does not support many characters, yet Unicode has over 21,000 Han characters, whereas JIS only has 12,156. I get this information from https://www.stonehand.com/unicode/faq/cjk.html > Unicode is very short term complacency solution for several peoples. > We must designe other way more smart. I don't think it's really an option for Chimera to design a new system. There's no reason that Chimera can't interact with other standards, but the question is, what should Chimera use internally? I think Unicode/UTF-8 would be a good choice. > Unicode is new one of terrible codes. It will makes us confuse... > For example. In japan, there are many codes. Almost all the people use > 3 codes(JIS/EUC/SJIS). If they use Unicode. It use as 4th code, it > cannot replace others. But Chimera can't possibly work with all three codes, plus the ISO-8859 codes. So if we don't choose Unicode, we have to give up on supporting all these codes simultaneously. We will have to forever have several versions of Chimera. What about Big-5? Is that a separate code, or part of one of the above? > We are very sensitive to codes... I noticed. I think part of the problem is the 'Han unification'. The Unicode standard uses the same character codes for Chinese, Japanese, Korean and Vietnamese characters that are descended from the Chinese Han characters. Many Japanese resent this, because they feel the Chinese Hanzi characters are not the same as the Japanese Kanji characters. Though they have the same meaning, they are often pronounced completely differently. This is of course because they are in completely different languages. The view of the Unicode standard is that they are the same characters, but that they are displayed with a different font, and that there are other localisation differences. That is, the difference is more like the difference between italic and roman letters, or roman and handwritten letters in Western alphabets. Not everyone agrees with that analysis, but it has its advantages. For one thing it keeps the number of Han characters under the magic 65536 boundary, so you don't have to use a 4-byte character set. For Chimera and HTML, there are many possibilities for using the correct Japanese and Chinese fonts at the right times. 1) There could be an option to always use Japanese Kanji. I have seen some Japanese claim they prefer this, because it makes it easier for them to read Chinese texts. 2) Chimera can use the 'lang' attribute which is built into every element in HTML. 3) The information I have also refers to the possibility of automatically determining the correct language by analysing the text. For example, since Japanese texts will very probably contain non-Han characters (Kana), it should be possible to identify the correct font to use. 4) The part of Chimera that converted JIS-codes to Unicode could also supply any information on the language, that can be obtained from those codes. I can see no reason to lose information here. Between these techniques it would surely be possible to find a solution that worked. If there are specific characters, which you feel you need, which are not in the Unicode standard (yet), then Chimera could put them in the private Unicode space. Linux uses this for VT100 graphics characters and Vulcan characters (!), so you can put anything here and it is guaranteed not to clash with later extensions of Unicode. I want Chimera to have a consistent internal representation for characters, and if we don't base it on Unicode, I don't know what else to base it on. Unicode has the advantage that it is stateless (except for writing direction problems). UTF-8 isn't quite stateless, but it is self-synchronising (ie if you have a pointer into the centre of the string then you can work out what the characters are without parsing the string from the start). - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 24 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22952; 29 Nov 95 13:59 PST Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22876; 29 Nov 95 13:52 PST To: chimera-announce@cephas.ISRI.UNLV.EDU Subject: source location Date: Wed, 29 Nov 1995 13:52:32 -0800 From: John Kilburg You can use www.unlv.edu or www.isri.unlv.edu as the host. www.isri.unlv.edu gives the correct content-type, www.unlv.edu doesn't. -john ------- Message 25 Received: from tom.compulink.co.uk by JIMI.CS.UNLV.EDU id aa23547; 29 Nov 95 14:16 PST Received: (from root@localhost) by tom.compulink.co.uk (8.6.9/8.6.9) id WAA16211 for bug-chimera@cs.unlv.edu; Wed, 29 Nov 1995 22:16:39 GMT Date: Wed, 29 Nov 95 22:16 GMT From: Robert Debath Subject: Re: Internationalisation patches To: bug-chimera@cs.unlv.edu, rdebath@cix.compulink.co.uk Reply-To: rdebath@cix.compulink.co.uk Message-Id: X-Mailer: RYO OLR From: Kenichi Chinen > Please don't say Unicode. > I don't know what is best. but I know Unicode is bad. Unfortunatly Unicode or ISO 10646 is the best as far as I can see. > Unicode was joined many charactors without (charactor and langauage) > backgrounds. It support only few charactors in the world. The whole point of unicode is to join the character sets of the world together, but with the limitation of 16 bits it is not possible to have language specific versions of character (glyphs) that look the same (it's a tight squeeze even with this overloading). So many of the accents in roman character sets are merged and more controversially there are major mergings in the ideographic sets. The 32 bit version of 10646 is addressing this problem and UTF-8 is capable of representing all the glyphs in the 32 bit version. > How many people express one's name via Unicode ? Well I can, but then I can do it with ISO 646 so I don't suppose that counts :-) Nevertheless UTF-8 has the considerable advantage that it probably will not break existing 8 bit software, software that has to be modified extensively to work with the JIS character sets or any of the other previous multi-byte character sets, and will still be useable with the 32 bit ISO-10646 version of UTF-8. The only multi-lingual alternative to unicode at the moment would be ISO-2022; this uses VT220 style escape sequences to switch between existing character sets. If you think 4 is bad you haven't seen this list ... there are about 150 different character sets (IIRC) all of which would need translations into any other, you'd end up re-inventing unicode or supporting only a few directly. > We are very sensitive to codes... I'm not that sensitive, probably because there are so many, I regularly use about 7 of those 150 sets including one generic EBCDIC varient. But none of these can represent any ideographic language; I want a unified coding scheme, UTF-8 gives that without seriously breaking the software I use. But, correct me if I'm wrong, don't the JIS/EUC/EJIS varients have one to one mappings into unicode so that a translation from JIS->unicode->JIS doesn't change anything ? In this case Unicode is just a transport code there's no reason for it ever to be visiable on your computer ... > k-chinen@is.aist-nara.ac.jp - -- Rob. (Robert de Bath ) ------- Message 26 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa27015; 29 Nov 95 15:42 PST Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id QAA02203; Wed, 29 Nov 1995 16:42:35 -0700 Date: Wed, 29 Nov 1995 16:42:28 -0700 (MST) From: Michael Kellen To: Chimera Hacker List Subject: [cfh90-2.0] #@$*%#@ ENDIAN crap again (and review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (+) Still superfast!!! (-) Imagemaps did not work at all. (-) The URL field is not updated to match the displayed page. (+) Window cloning and cache sharing is nice. Seems stable. (-) REALLY needs an indicator that the client is doing something. (-) Forms support still missing. (-) Cancel during a download caused segfault: Starting program: cfh90-2.0/src/chimera Program received signal SIGSEGV, Segmentation fault. 0x80112ef in ImageEndData (closure=0x0, d=0x80654c0) at image.c:1204 image.c:1204: No such file or directory. (gdb) bt #0 0x80112ef in ImageEndData (closure=0x0, d=0x80654c0) at image.c:1204 #1 0x8006a9b in FrameEndData (frame=0x80fc300, d=0x80654c0) at frame.c:218 #2 0x8028d87 in HTTPReadData (ios=0x8066640, eof=true, hi=0x8065520) at http.c:313 #3 0x8028f4f in HTTPReadHeader (ios=0x8066640, eof=true, hi=0x8065520) at http.c:367 #4 0x8005fbb in ReadStreamHandler (cldata=0x8066640, netfd=0x80654f4, xid=0xbffff328) at io.c:156 #5 0x400f6907 in appr () #6 0x400f6bbb in appr () #7 0x400edf83 in appr () #8 0x800374a in main (argc=1, argv=0xbffff448) at main.c:117 #9 0x8003555 in ___crt_dummy__ () #10 0x4000000 in ?? () #11 0x40006838 in appr () {I think that this *might* be related to the below, as image.c depends upon BOTH image/endian.h and /usr/include/endian.h under linux. OTOH, the Cancel button seems less effective for some reason ... does it stop ALL pending downloads or only the current one? Or even that much?} Now for the endian stuff ... As you might guess, I was a bit annoyed by this one. The LITTLE/BIG _ENDIAN stuff is broken still/again in cfh90. This time it not only breaks the parser (no links) but it segfaults the client for any type of network connection. Once again, the sol'n is either: (1) {kludgey} rename image/endian.h and fix the #include's (2) {better} remove the -I../* from the compile lines and use proper #include paths Since (1) affects only the image directory, while (2) requires massive rewrites, here is the patch for (1): {again!} You also must rename image/endian.h as image/image_endian.h diff -c oldimage/gif.c image/gif.c *** oldimage/gif.c Sat Nov 25 21:56:15 1995 - --- image/gif.c Wed Nov 29 15:40:19 1995 *************** *** 29,35 **** #include "common.h" #include "imagep.h" ! #include "endian.h" #include "image_format.h" #include "gifp.h" - --- 29,35 ---- #include "common.h" #include "imagep.h" ! #include "image_endian.h" #include "image_format.h" #include "gifp.h" diff -c oldimage/image.c image/image.c *** oldimage/image.c Tue Nov 28 23:07:32 1995 - --- image/image.c Wed Nov 29 15:40:32 1995 *************** *** 17,23 **** #include "colorcube.h" #include "dispdither.h" #include "xcolorcube.h" ! #include "endian.h" #include "imagep.h" #include "image_format.h" - --- 17,23 ---- #include "colorcube.h" #include "dispdither.h" #include "xcolorcube.h" ! #include "image_endian.h" #include "imagep.h" #include "image_format.h" diff -c oldimage/pnm.c image/pnm.c *** oldimage/pnm.c Sun Oct 1 22:35:36 1995 - --- image/pnm.c Wed Nov 29 15:40:43 1995 *************** *** 11,17 **** #include #include "common.h" ! #include "endian.h" #include "imagep.h" #include "pnmp.h" - --- 11,17 ---- #include #include "common.h" ! #include "image_endian.h" #include "imagep.h" #include "pnmp.h" diff -c oldimage/xbm.c image/xbm.c *** oldimage/xbm.c Sun Oct 1 22:39:36 1995 - --- image/xbm.c Wed Nov 29 15:40:59 1995 *************** *** 11,17 **** #include #include "common.h" ! #include "endian.h" #include "imagep.h" #include "xbmp.h" - --- 11,17 ---- #include #include "common.h" ! #include "image_endian.h" #include "imagep.h" #include "xbmp.h" ------- Message 27 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa00825; 29 Nov 95 17:39 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Wed, 29 Nov 95 20:38:53 -0500 (EST) Message-Id: Date: Wed, 29 Nov 95 20:38:36 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: Re: [cfh90-2.0] #@$*%#@ ENDIAN crap again (and review) Er, pardon my cluelessness, but this whole endian business seems to me to be a bit of premature optimization, if it's byte-endianness we're talking about, anyway. If the source and destination byte orderings are known (and for network data, image formats and X data, they usually are) data can almost always be read, written, and translated without reference to the host byte order. ------- Message 28 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa01148; 29 Nov 95 17:55 PST Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id SAA02589; Wed, 29 Nov 1995 18:55:08 -0700 Date: Wed, 29 Nov 1995 18:55:02 -0700 (MST) From: Michael Kellen To: Chimera Hacker List Subject: [cfh90-2.0] SegFault on Hit Counter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It isn't an endian problem, at least, not that I can see. Please try the following URL: https://riceinfo.rice.edu/~indigo/gsotd/ (The Geek Site of the Day) And see if you too get a seg fault. I am getting the fault at the point where it attempts to display the counter on the page. I can view it with v1.5 or cfh80-2.0. Michael ------- Message 29 Received: from babybop.reptiles.org by JIMI.CS.UNLV.EDU id aa13088; 30 Nov 95 0:41 PST Received: by reptiles.org via send-mail with stdio id for bug-chimera@cs.unlv.edu; Thu, 30 Nov 95 03:42:13 -0500 (EST) (/\##/\ Smail3.1.30.13 #30.4 built 26-sep-) Message-Id: Date: Thu, 30 Nov 95 03:42:13 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu, michael@xph029.physics.montana.edu Subject: Re: [cfh90-2.0] SegFault on Hit Counter This seems to happen because the hit counter is an X bitmap, which chimera for some reason doesn't recognize. The headers are: HTTP/1.0 200 Document follows Date: Thu, 30 Nov 1995 07:09:39 GMT Server: NCSA/1.4.2 Content-type: image/x-xbitmap FrameInitData calls ImageInit, which calls GetImageFormat, which doesn't have "images/x-xbitmap" on its list of comparisons, and returns NULL. FrameInitData handles this all right, but FrameEndData tries to call ImageEndData without checking that the closure argument is non-NULL, and ka-boom. ------- Message 30 Received: from scr.siemens.com by JIMI.CS.UNLV.EDU id aa18263; 30 Nov 95 6:23 PST Received: from beast.sme.siemens.com ([129.73.57.199]) by scr.siemens.com (8.7.1/8.6.6) with SMTP id JAA08066 for ; Thu, 30 Nov 1995 09:23:38 -0500 (EST) Received: from localhost by beast.sme.siemens.com (4.1/SMI-4.1) id AA11214; Thu, 30 Nov 95 09:23:19 EST Message-Id: <9511301423.AA11214@beast.sme.siemens.com> To: bug-chimera@cs.unlv.edu Reply-To: cdr@sme.siemens.com Subject: on page anchor problems with new code Date: Thu, 30 Nov 1995 09:23:18 -0500 From: CD Rasmussen Using cfh90-2.0, I can not junp to an on page anchor. Instead it reloads the same page from the beginning. Has this already been reported? Thanks, Costa - -- Constantine Rasmussen 508-750-7500 x7020 cdr@sme.siemens.com ------- Message 31 Received: from scr.siemens.com by JIMI.CS.UNLV.EDU id aa24177; 30 Nov 95 10:02 PST Received: from cons.mountain ([129.73.58.158]) by scr.siemens.com (8.7.1/8.6.6) with SMTP id NAA17486 for ; Thu, 30 Nov 1995 13:01:52 -0500 (EST) Received: from localhost by cons.mountain (4.1/SMI-4.1) id AA18567; Thu, 30 Nov 95 13:01:24 EST Message-Id: <9511301801.AA18567@cons.mountain> To: bug-chimera@cs.unlv.edu Reply-To: cdr@sme.siemens.com Subject: on page anchor problems with new code Date: Thu, 30 Nov 1995 13:01:24 -0500 From: CD Rasmussen I'm new to the list and need some orientation, where is the current bug list kept? Also, has anyone put in a request to enhance chimera to accept a URL to be downloaded but not displayed? I'd like to do that when someone gives me a URL for a compressed file where the transport method is http. I think this would be preferable to trying to display it. When I ran test-chimera with the new release I noticed it had no "file" button. Has this been taken out of the code? If so, why, just out of curiosity? Thanks, Costa - -- Constantine Rasmussen 508-750-7500 x7020 cdr@sme.siemens.com ------- Message 32 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa25101; 30 Nov 95 10:30 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 30 Nov 95 13:29:26 -0500 From: Jim Rees To: Chimera Lovers Date: Thu, 30 Nov 1995 13:29:25 -0500 Subject: cache bug fix for 1.65 Sender: rees@citi.umich.edu I'm still using 1.65. Is there a later version that's just as stable I should switch to? There's a bug in cache.c that causes the cache to be disabled on machines where off_t is bigger than an int (NetBSD, eg). Here's the fix. This diff is against the original source, so it contains the other patches too. By the way, this bug would have been prevented by the use of ANSI function prototypes. % diff -c cache.c- cache.c *** cache.c- Wed Mar 29 04:55:32 1995 - --- cache.c Thu Nov 30 13:21:45 1995 *************** *** 196,202 **** { FILE *fp; char buffer[BUFSIZ]; ! char path[MAXPATHLEN + 1], domain[BUFSIZ]; int max, ttl, clean; CacheInfo *ci, *ti; DIR *dp; - --- 196,203 ---- { FILE *fp; char buffer[BUFSIZ]; ! char domain[BUFSIZ]; ! char *path; int max, ttl, clean; CacheInfo *ci, *ti; DIR *dp; *************** *** 208,216 **** - --- 209,219 ---- { if (buffer[0] == '#' || buffer[0] == '\n') continue; + path = alloc_mem(sizeof(char) * (MAXPATHLEN +1)); if (sscanf(buffer, "%s %s %d %d %d", path, domain, &max, &ttl, &clean) == 5) { + path = FixFilename(path); if ((dp = opendir(path)) != NULL) { ci = (CacheInfo *)alloc_mem(sizeof(CacheInfo)); *************** *** 364,369 **** - --- 367,375 ---- default_cache.clist = NULL; default_cache.next = NULL; + if (!cache_list) { + cache_list = &default_cache; + } ScanCacheDirectories(); return; *************** *** 477,483 **** FILE *fp; char *u; char *filename; ! int size = 0; CacheInfo *ci; MIMEField *mf; time_t now, expires; - --- 483,489 ---- FILE *fp; char *u; char *filename; ! off_t size = 0; CacheInfo *ci; MIMEField *mf; time_t now, expires; ------- Message 33 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa28798; 30 Nov 95 11:40 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 30 Nov 95 14:39:43 -0500 From: Jim Rees To: Chimera Lovers Date: Thu, 30 Nov 1995 14:39:42 -0500 Subject: Re: on page anchor problems with new code Sender: rees@citi.umich.edu In-Reply-To: CD Rasmussen, Thu, 30 Nov 1995 13:01:24 EST Also, has anyone put in a request to enhance chimera to accept a URL to be downloaded but not displayed? I used to have a command called "urlcat" that took a url as argument, fetched the doc, and wrote it to stdout. Very useful. I built this from chimera's protocol parts. But this was a while ago, and it no longer builds from current chimera sources. ------- Message 34 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11432; 30 Nov 95 17:36 PST To: Jim Rees cc: Chimera Lovers Subject: Re: cache bug fix for 1.65 In-reply-to: Your message of "Thu, 30 Nov 1995 13:29:25 EST." Date: Thu, 30 Nov 1995 17:36:20 -0800 From: John Kilburg >I'm still using 1.65. Is there a later version that's just as stable I >should switch to? Not really. Stick with 1.65 until the 2.0 betas appear if you need reliability. -john ------- End of Forwarded Messages