Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01833; 26 Dec 96 23:04 PST To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera jan 96 Date: Thu, 26 Dec 1996 23:04:00 -0800 From: Jay Nietling ------- Forwarded Messages Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa03071; 2 Jan 96 14:58 PST Received: from titanic.cs.tu-berlin.de (czyborra@titanic.cs.tu-berlin.de [130.149.17.141]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id XAA23570; Tue, 2 Jan 1996 23:58:36 +0100 Received: (czyborra@localhost) by titanic.cs.tu-berlin.de (8.6.12/8.6.6) id XAA04682; Tue, 2 Jan 1996 23:58:35 +0100 From: Roman Czyborra To: Julian Stacey Cc: bug-chimera@cs.unlv.edu Subject: Re: include statement for HTML In-Reply-To: <199512311755.SAA12888@vector.jhs.local> by jhs@vector.jhs.local dated 1995-12-31 18:55:59 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 02 Jan 1996 23:58:33 +0100 Message-ID: Hello Julian, > Dumb question if I may please :-) Well, your question ain't dumb but news:comp.infosystems.www.authoring.html might have been a more suitable address since you aren't asking about chimera. > Does HTML have an include statement like C's #include "foobar.html" ? > A response of RTFM @ URL would be fine :-) ftp://ftp.cs.tu-berlin.de/pub/doc/rfc/rfc1866 could tell you that HTML offers no includes. For concurring half-standard implementations in HTTP servers see https://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html and https://spinner.infovav.se/spml/ It could well be that some of those new Java browsers allow some sort of client-side inclusion, too. ------- Message 2 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11520; 3 Jan 96 17:58 PST Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11518; 3 Jan 96 17:57 PST To: chimera-announce@cephas.ISRI.UNLV.EDU Subject: alpha 99 Date: Wed, 03 Jan 1996 17:57:34 -0800 From: John Kilburg You can grab the source from https://www.isri.unlv.edu/~john/chimera/src/ This one is quite a bit more stable than 97 (you'll see who is responsible in the CHANGES file :). I've been able to use it for just about everything (the forms stuff could be better...). Note that this one will create ~/.chimera # chimera config directory ~/.chimera/cache # cache directory ~/.chimera/resources # resources file on startup. Append lib/resources to ~/.chimera/resources. If you want to change the location of the resources file, set the X resource Chimera.dbFiles dbFiles must be a single filename but next time it will handle a colon-delimited list. Chimera uses a separate resources file for all messages (a lot of stuff), and non-X configuration parameters. In future releases, chimera will inform the user of the creation of ~/.chimera. Note that the cache is never flushed until chimera exits. The cache will be smarter in the next release. Also, cache filenames are 32 characters long. There will be a resource that you can set to cut this to 14 in the next release. You can set the location of the JPEG 6 library in Common.tmpl instead of having to deal with src/Imakefile and image/Imakefile. On the SGI, rename libimage and libmisc to libwww_image and libwww_misc as /usr/lib/libimage.a and /usr/lib/libmisc.a exist. I will probably put 'www_' in front of the names of all of the protocol and render libraries in the next release. I tested this one on SGIs, Alphas, and Sparcs. My Linux test machine got rebooted to MS-Windows... Have fun. -john ------- Message 3 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa13422; 3 Jan 96 19:46 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Wed, 03 Jan 96 22:45:30 -0500 From: Jim Rees To: Chimera Lovers Date: Wed, 03 Jan 1996 22:45:28 -0500 Subject: core dumps Sender: rees@citi.umich.edu The latest 2.0 builds and installs no problem on Netbsd. It even runs ok in test mode. But when trying to run it for real, I got a core dump: #0 0x2c079 in FixPath (mp=0x3f248, filename=0x0) at util.c:69 69 if (filename[0] == '~') fname = filename; (gdb) bt #0 0x2c079 in FixPath (mp=0x3f248, filename=0x0) at util.c:69 #1 0x2a0c1 in WWWAddResourceFile (wc=0x4c00c, file=0x0) at context.c:40 #2 0x2460 in main (argc=1, argv=0xf7bfda38) at main.c:115 This is fixed easily enough by adding this resource to Chimera.ad: Chimera.dbFiles: ~/.chimera/resources but of course there should also be a check for a null dbFiles resource somewhere, probably in WWWAddResourceFile. But then I got this dump, which I haven't tracked down yet: #0 0x3177 in CreateHead (r=0x35f18, toplevel=0x3d600) at widget.c:153 #1 0x2747 in MakeHead (toplevel=0x3d600, first=0x3900c "chimera-setup:file:/afs/umich.edu/user/r/e/rees/www/home.html") at main.c:210 #2 0x25b6 in main (argc=1, argv=0xf7bfda38) at main.c:140 ------- Message 4 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa15342; 3 Jan 96 21:51 PST To: Jim Rees cc: Chimera Lovers Subject: Re: core dumps In-reply-to: Your message of "Wed, 03 Jan 1996 22:45:28 EST." Date: Wed, 03 Jan 1996 21:51:36 -0800 From: John Kilburg >But then I got this dump, which I haven't tracked down yet: > >#0 0x3177 in CreateHead (r=0x35f18, toplevel=0x3d600) at widget.c:153 >#1 0x2747 in MakeHead (toplevel=0x3d600, > first=0x3900c "chimera-setup:file:/afs/umich.edu/user/r/e/rees/www/home.ht ml") at main.c:210 >#2 0x25b6 in main (argc=1, argv=0xf7bfda38) at main.c:140 Set the resource Chimera.messageFont to something. This helps with some problems for sites with an old chimera installed: XFILESEARCHPATH="" chimera-2.0 -john ------- Message 5 Received: from homesick.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa00658; 4 Jan 96 8:34 PST Received: from concorde.inria.fr by HOMESICK.CS.UNLV.EDU id aa14324; 4 Jan 96 8:25 PST Received: from fantomas.inria.fr (fantomas.inria.fr [128.93.11.34]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id PAA18444 for ; Thu, 4 Jan 1996 15:49:38 +0100 (MET) Received: (from lasgout@localhost) by fantomas.inria.fr (8.6.10/8.6.6) id PAA22682; Thu, 4 Jan 1996 15:49:36 +0100 Date: Thu, 4 Jan 1996 15:49:36 +0100 Message-Id: <199601041449.PAA22682@fantomas.inria.fr> From: Jean-Marc Lasgouttes To: bug-chimera@unlv.edu In-reply-to: <199601040224.DAA24260@nez-perce.inria.fr> (message from John Kilburg on Wed, 03 Jan 1996 17:57:34 -0800) Subject: Re: alpha 99 Reply-to: Jean-Marc.Lasgouttes@inria.fr >>>>> "John" == John Kilburg writes: John> You can grab the source from John> https://www.isri.unlv.edu/~john/chimera/src/ As usual, I've been unable to retrieve the latest alpha, due to a very bad overseas connection. Could some kind soul in europe make it available? Having a regular mirror or chimera versions would not hurt, in fact. One of the reasons why I am eager to get this version is that 97 actually began to be useful for me and I wait with impatience for the day when I'll be able to delete netscape from my hard disk... Thanks in advance. Jean-Marc. ------- Message 6 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa12551; 4 Jan 96 15:35 PST Received: from kroete2.freinet.de (arhppp16.uni-c.dk [130.225.243.176]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id AAA15063; Fri, 5 Jan 1996 00:32:24 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tXz9Z-0003kJC; Fri, 5 Jan 96 00:33 MET Message-Id: From: Erik Corry Subject: Re: alpha 99 To: Jean-Marc.Lasgouttes@inria.fr Date: Fri, 5 Jan 1996 00:32:59 +0100 (MET) Cc: Chimera Hacker List In-Reply-To: <199601041449.PAA22682@fantomas.inria.fr> from "Jean-Marc Lasgouttes" at Jan 4, 96 03:49:36 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS As usual, I've been unable to retrieve the latest alpha, due to a very > bad overseas connection. Could some kind soul in europe make it > available? https://inet.uni-c.dk/~ehcorry/cfh99-2.0.tar.gz > Having a regular mirror or chimera versions would not hurt, in fact. I don't know how to set this up, unfortunately. I'm back from my Xmas break, but reasonably busy. I'll try to look at the Jpeg problems mentioned by Smarasderagd, though he seems to have found the solution already anyway. John wrote in the Changes file: > Frames are no longer widgets. Hooray. Widgets are evil. See https://inet.uni-c.dk/~ehcorry/widget.htm - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 7 Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa19196; 4 Jan 96 21:09 PST Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa19185; 4 Jan 96 21:06 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Fri, 5 Jan 96 00:05:03 -0500 (EST) Message-Id: Date: Fri, 5 Jan 96 00:04:50 -0500 (EST) From: Smarasderagd To: chimera-announce@cephas.ISRI.UNLV.EDU, john@cephas.ISRI.UNLV.EDU Subject: Re: alpha 99 Alpha 99 moves its application resource defaults from resource_list in src/main.c to src/fallback.c. However, as far as I can tell, if an application defaults file exists, fallback resources are ignored. So, if you're using a Chimera resource file, you'll need to copy at least some of the lines from fallback.c. In particular: Chimera.button1Box: quit, open, home, back, reload, dup, help, cancel I spent a while trying to figure out why there was no button bar when I ran chimera. :;SD:; ------- Message 8 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa01694; 5 Jan 96 5:37 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Fri, 5 Jan 96 08:36:10 -0500 (EST) Message-Id: Date: Fri, 5 Jan 96 08:35:46 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu, john@cephas.ISRI.UNLV.EDU Subject: Re: alpha 99 Fixes for forms-associated crashes I experienced: - --- cfh99-2.0/./www/url.c Sun Dec 31 23:27:31 1995 +++ cfh99/./www/url.c Fri Jan 5 08:22:20 1996 @@ -421,7 +421,7 @@ dp->input_data = MPGet(mp, up->input_data_len); memcpy(dp->input_data, up->input_data, up->input_data_len); dp->input_data_len = up->input_data_len; - - dp->input_data_type = MPStrDup(mp, dp->input_data_type); + dp->input_data_type = MPStrDup(mp, up->input_data_type); } else dp->input_data_len = 0; - --- cfh99-2.0/./html/form.c Wed Jan 3 00:00:34 1996 +++ cfh99/./html/form.c Fri Jan 5 01:02:27 1996 @@ -1035,7 +1035,7 @@ if (fs->otext == NULL) { fs->otext = (char *)alloc_mem(len + 1); - - len = 0; + olen = 0; } else { ------- Message 9 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa09755; 5 Jan 96 11:39 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Fri, 05 Jan 96 14:38:12 -0500 From: Jim Rees To: Chimera Lovers Date: Fri, 05 Jan 1996 14:38:11 -0500 Subject: Re: alpha 99 Sender: rees@citi.umich.edu In-Reply-To: Smarasderagd, Fri, 05 Jan 1996 00:04:50 EST Alpha 99 moves its application resource defaults from resource_list in src/main.c to src/fallback.c. However, as far as I can tell, if an application defaults file exists, fallback resources are ignored. I hate ad files. It's one more thing you have to install in the right place. If you install a new version of X, you have to be careful to move over all the ad files you care about. And if you want to run multiple versions of the same application, the ad files will conflict. I recommend that all necessary resources be moved in to fallback.c, and Chimera.ad be eliminated. ------- Message 10 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa12627; 5 Jan 96 13:31 PST Received: from kroete2.freinet.de (arhppp26.uni-c.dk [130.225.243.186]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id WAA18770 for ; Fri, 5 Jan 1996 22:29:22 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tYJit-0003mwC; Fri, 5 Jan 96 22:30 MET Message-Id: From: Erik Corry Subject: Re: alpha 99 To: Chimera Hacker List Date: Fri, 5 Jan 1996 22:30:50 +0100 (MET) In-Reply-To: <199601052008.VAA11814@inet.uni-c.dk> from "Jim Rees" at Jan 5, 96 02:38:11 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS I hate ad files. It's one more thing you have to install in the right > place. If you install a new version of X, you have to be careful to move > over all the ad files you care about. And if you want to run multiple > versions of the same application, the ad files will conflict. > > I recommend that all necessary resources be moved in to fallback.c, and > Chimera.ad be eliminated. I agree there are very serious problems with X resource files. It's incredibly difficult to work out where a process is reading it's resources from, especially if you deal with several platforms and versions of X. Resource files never report errors, so typos silently fail. There's no differentiation between user-customisable and non- customisable resources, and resource files are unsuited to being edited with a GUI. You get the ridiculous situation of a GUI program being customised using an obscure text file syntax. However, if we eliminate resource files, there has to be a different way for users to customise the program. Using forms to automatically generate a .rc file would seem to be an obvious short-cut for a web browser. This also fits in neatly with my banish-X-to-the-edges-of-the-program hobby horse. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 11 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa15543; 5 Jan 96 15:09 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Fri, 05 Jan 96 18:08:51 -0500 From: Jim Rees To: Chimera Lovers Date: Fri, 05 Jan 1996 18:08:50 -0500 Subject: Re: alpha 99 Sender: rees@citi.umich.edu In-Reply-To: Erik Corry, Fri, 05 Jan 1996 22:30:50 +0100 I wasn't advocating the elimination of X resources, just the ad file. Defaults should be built in to the application. ------- Message 12 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa19811; 5 Jan 96 17:55 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Fri, 5 Jan 96 20:54:10 -0500 (EST) Message-Id: Date: Fri, 5 Jan 96 20:53:59 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: resource files My thoughts on resource files: If a resource is absolutely necessary for the program to work, it should be in the argument list at widget creation time. If it can be freely changed, we still want to put a default somewhere. For better or worse, Chimera is an X program, and if it is to be configurable without undue annoyance we need SOME config file or other. Supplying the defaults in an .ad file is by far the easiest route. In the case of resources like Chimera.dbFiles or .messageFont, the program should be more forgiving. If there is no Chimera.dbFiles resource or it's a bad file name, chimera should try, say, $LIBDIR/resources, and exit with an error message if that doesn't work. The Xt/Xlib resource manager isn't perfect, but it does a lot. Making it do what you want requires some work, but almost certainly less than implementing a replacement. ------- Message 13 Received: from watson.ibm.com by JIMI.CS.UNLV.EDU id aa15942; 6 Jan 96 20:11 PST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4045; Sat, 06 Jan 96 23:10:50 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5301; Sat, 6 Jan 1996 23:10:50 EST Received: from hawpub.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Sat, 06 Jan 96 23:10:49 EST Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA43861; Sat, 6 Jan 1996 23:10:34 -0500 Message-Id: <9601070410.AA43861@hawpub.watson.ibm.com> Subject: Re: alpha 99 To: Jim Rees Date: Sat, 6 Jan 1996 23:10:33 -0500 (EST) From: Uri Blumenthal Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9601052023.AA27543@hawpub.watson.ibm.com> from "Jim Rees" at Jan 5, 96 02:38:11 pm X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 359 Jim Rees writes: > I hate ad files. That's your problem. > I recommend that all necessary resources be moved in to fallback.c, and > Chimera.ad be eliminated. I recommend cooling down and leaving Chimera.ad there, as it is the most convenient way to define fancy fonts and such system-wide. - -- Regards, Uri uri@watson.ibm.com - -=-=-=-=-=-=- ------- Message 14 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa17802; 6 Jan 96 22:14 PST Received: from [141.211.170.99] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Sun, 07 Jan 96 01:13:57 -0500 From: Jim Rees To: Chimera Lovers Date: Sun, 07 Jan 1996 01:13:52 -0500 Subject: Re: alpha 99 Sender: rees@citi.umich.edu In-Reply-To: Uri Blumenthal, Sat, 06 Jan 1996 23:10:33 EST I recommend cooling down and leaving Chimera.ad there, as it is the most convenient way to define fancy fonts and such system-wide. That's up to John, of course. But at the very least, Chimera.ad and fallback.c should define identical resources. Otherwise you get what we have now, with chimera working differently depending on whether the ad file is properly installed or not. The ad file should be used for reference and for local site configuration. Chimera shouldn't require that the ad file be present (or absent) for proper operation. One easy way to do this is to automatically generate fallback.c from the ad file, using sed or similar. ------- Message 15 Received: from enterprise.cistron.nl by JIMI.CS.UNLV.EDU id aa25226; 7 Jan 96 4:25 PST Received: from ava.UUCP (uucp@localhost) by enterprise.cistron.nl (8.7.1) with UUCP id NAA00540 for cs.unlv.edu!bug-chimera; Sun, 7 Jan 1996 13:13:46 +0100 Received: by kozmix.ow.nl (Smail3.1.29.1 #1) id m0tYtyN-00008EC; Sun, 7 Jan 96 13:13 MET Message-Id: From: Sander van Malssen Subject: Re: alpha 99 To: bug-chimera@cs.unlv.edu Date: Sun, 7 Jan 1996 13:13:15 +0100 (MET) In-Reply-To: <199601070627.HAA04843@enterprise.cistron.nl> from "Jim Rees" at Jan 7, 96 01:13:52 am Reply-To: svm@kozmix.ow.nl Organization: Kozmic Egg Productions, Gouda, Netherlands X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > One easy way to do this is to automatically generate fallback.c from the ad > file, using sed or similar. Good idea. It's as simple as this: #!/bin/sh if [ $# != 2 ]; then echo "usage: $0 file.ad file.c" exit 1 fi cat > $2 < /* * I got sick of this being in main.c */ char *fallback_resources[] = { EOF grep '^\*' < $1 | sed 's/^\(.*\)$/ "\1",/g' >> $2 cat >> $2 < Subject: Re: alpha 99 To: Jim Rees Date: Sun, 7 Jan 1996 13:20:51 -0500 (EST) From: Uri Blumenthal Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9601070632.AA40120@hawpub.watson.ibm.com> from "Jim Rees" at Jan 7, 96 01:13:52 am X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 384 Jim Rees writes: > ........But at the very least, Chimera.ad and > fallback.c should define identical resources. No arguments about THIS, of course. John, pretty-pretty-please? (:-) > One easy way to do this is to automatically generate fallback.c from the ad > file, using sed or similar. Yup! Sounds perfect to me. - -- Regards, Uri uri@watson.ibm.com - -=-=-=-=-=-=- ------- Message 17 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa01278; 7 Jan 96 12:05 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Sun, 07 Jan 96 15:04:41 -0500 From: Jim Rees To: Chimera Lovers Date: Sun, 07 Jan 1996 15:04:40 -0500 Subject: fallback.c Sender: rees@citi.umich.edu I combined the resources in Chimera.ad and fallback.c, made a new Chimera.ad, and wrote a script to automatically generate fallback.c. It seems to work. I didn't hack the Imakefile. John - no need to include stdio.h. NULL is always 0 (not (void *) 0 as some claim). Check K&R if you don't believe me. # The rest of this file is a shell script which will extract: # Chimera.ad mkfallback echo x - Chimera.ad cat >Chimera.ad <<'Godfather_Of_Soul' !.allProxy: https://www.somewhere.org:8000/ !.ftpProxy: https://www.somewhere.org:8000/ !.httpProxy: https://www.somewhere.org:8000/ !.gopherProxy: https://www.somewhere.org:8000/ !.waisProxy: https://www.somewhere.org:8000/ !.newsProxy: https://www.somewhere.org:8000/ !.nntpProxy: https://www.somewhere.org:8000/ !.urnProxy: https://www.somewhere.org:8000/ *background: moccasin *showGrip: false *Scrollbar.background: burlywood2 *Command.background: burlywood2 *Toggle.background: burlywood2 *MenuButton.background: burlywood2 *SimpleMenu.background: burlywood2 *SmeBSB.background: burlywood2 *Box.orientation: horizontal *Label.borderWidth: 0 *Form.resizeable: true *Form.borderWidth: 0 *allowHoriz: true *allowVert: true *file.label: File *open.label: Open *bookmark.label: Bookmark *quit.label: Quit *reload.label: Reload *help.label: Help *source.label: Source *home.label: Home *back.label: Back *search.label: Search *cancel.label: Cancel *dup.label: Clone *www.height: 600 *www.width: 620 *Bookmark*title: Bookmarks *Bookmark*Box.hSpace: 10 *Bookmark*markbox.hSpace: 20 *Bookmark*markadd.label: Add *Bookmark*markopen.label: Open *Bookmark*markdel.label: Delete *Bookmark*groupadd.label: Add Group *Bookmark*groupdel.label: Delete Group *Bookmark*Viewport.height: 150 *Bookmark*Viewport.width: 400 *Bookmark*Viewport.borderWidth: 1 *Bookmark*dismiss.label: Dismiss *Bookmark*List.forceColumns: true *Bookmark*List.defaultColumns: 1 *Bookmark*groupform.defaultDistance: 3 *Bookmark*markform.defaultDistance: 3 *Bookmark*srgroupadd.strreqMessage: Enter Group Name *Bookmark*srmarkadd.strreqMessage: Enter Bookmark Name *Bookmark.pickDestroys: False *OutputSel.outputType: 0 *OutputSel.outputDevice: 0 *OutputSel*title: Output Selector *OutputSel*Box.hSpace: 10 *OutputSel*obox.hSpace: 60 *OutputSel*plain.label: Plain Text *OutputSel*pretty.label: Pretty Text *OutputSel*ps.label: Postscript *OutputSel*raw.label: HTML/Raw *OutputSel*printer.label: Printer *OutputSel*email.label: Email *OutputSel*file.label: File *OutputSel*ok.label: OK *OutputSel*clear.label: Clear *OutputSel*dismiss.label: Dismiss *OutputSel*ScrollingText.width: 300 *AuthReq*Box.hspace: 10 *AuthReq*ok.label: OK *AuthReq*clear.label: Clear *AuthReq*dismiss.label: Dismiss *AuthReq*ScrollingText.width: 300 *AuthReq*ulabel.label: Username *AuthReq*plabel.label: Password *AuthReq*title: Authentication *StrReq*Box.hSpace: 10 *StrReq*ok.label: OK *StrReq*clear.label: Clear *StrReq*dismiss.label: Dismiss *StrReq*ScrollingText.width: 300 *filename*title: Enter filename *filename.strreqMessage: Enter filename *openurl.strreqMessage: Enter URL *openurl*title: Enter URL *search.title: Enter search *search.strreqMessage: Enter search *url*title: Enter URL *url.strreqMessage: Enter URL *url.left: ChainLeft *url.right: ChainRight *url.fromHoriz: urllabel *url*sensitive: true *url.width: 500 *url*editType: edit *urllabel.label: URL : *urllabel.left: ChainLeft *urllabel.right: ChainLeft *urldisplay.left: ChainLeft *urldisplay.right: ChainRight *urldisplay.fromHoriz: urllabel *urldisplay*sensitive: true *urldisplay.width: 500 *urldisplay*editType: edit *titlelabel.label: Title : *titlelabel.left: ChainLeft *titlelabel.right: ChainLeft *titledisplay.left: ChainLeft *titledisplay.right: ChainRight *titledisplay.fromHoriz: titlelabel *titledisplay*sensitive: false *titledisplay.width: 500 *titledisplay*displayCaret: False *titledisplay*editType: read *font: -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 *Label.font: -*-lucidatypewriter-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 *Command.font: -*-lucida-bold-r-normal-sans-*-120-*-*-*-*-iso8859-1 *Toggle.font: -*-lucida-bold-r-normal-sans-*-120-*-*-*-*-iso8859-1 *urldisplay.font: -*-lucida-bold-r-normal-sans-*-120-*-*-*-*-iso8859-1 *titledisplay.font: -*-lucida-bold-r-normal-sans-*-120-*-*-*-*-iso8859-1 *h1Font: -*-helvetica-bold-r-normal-*-*-240-*-*-*-*-iso8859-1 *h2Font: -*-helvetica-bold-r-normal-*-*-180-*-*-*-*-iso8859-1 *h3Font: -*-helvetica-bold-r-normal-*-*-140-*-*-*-*-iso8859-1 *h4Font: -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 *h5Font: -*-helvetica-bold-r-normal-*-*-100-*-*-*-*-iso8859-1 *h6Font: -*-helvetica-bold-r-normal-*-*-80-*-*-*-*-iso8859-1 *normalFont: -*-helvetica-medium-r-normal-*-*-120-*-*-*-*-iso8859-1 *boldFont: -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 *emphasizedFont: -*-helvetica-medium-o-normal-*-*-120-*-*-*-*-iso8859-1 *addressFont: -*-helvetica-medium-o-normal-*-*-140-*-*-*-*-iso8859-1 *anchorFont: -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 Chimera.dbFiles: ~/.chimera/resources Chimera.homeURL: file://localhost/ Chimera.helpURL: https://www.unlv.edu/chimera/ Chimera.messageFont: variable Chimera.button1Box: quit, open, home, back, reload, dup, help, cancel Godfather_Of_Soul echo x - mkfallback cat >mkfallback <<'Godfather_Of_Soul' FALLBACK=fallback.c cat >$FALLBACK <<'END' /* Automatically generated; do not edit. */ /* * fallback.c * * Copyright 1993, 1994, 1995 by John Kilburg. * See the file COPYRIGHT for details. */ /* * I got sick of this being in main.c */ char *fallback_resources[] = { END egrep -v '^!|^$' >$FALLBACK cat >>$FALLBACK <<'END' 0 }; END Godfather_Of_Soul ------- Message 18 Received: from alpha.Xerox.COM by JIMI.CS.UNLV.EDU id aa21009; 9 Jan 96 8:31 PST Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <17452(6)>; Tue, 9 Jan 1996 08:30:47 PST Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA25496; Tue, 9 Jan 96 11:30:39 EST Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA05655; Tue, 9 Jan 96 11:30:37 EST Message-Id: <9601091630.AA05655@gnu.mc.xerox.com> To: bug-chimera@cs.unlv.edu Subject: going up the file tree Date: Tue, 9 Jan 1996 08:30:36 PST From: Marty Leisner I just made cfh97-2.0 on Linux Something I noticed... When we select .. to go up the file tree, the .. gets added to the path... i.e. /this/is/a/directory select .. /this/is/a/directory/.. instead of /this/is/a marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom (https://www.lpf.org) Any sufficiently advanced technology is indistinguishable from magic Arthur C. Clarke, The Lost Worlds of 2001 ------- Message 19 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa02602; 9 Jan 96 16:20 PST Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id RAA14028; Tue, 9 Jan 1996 17:15:31 -0700 Date: Tue, 9 Jan 1996 17:15:23 -0700 (MST) From: Michael Kellen To: Chimera Hacker List Subject: [cfh99] Is this just me ??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I get an runaway connection attempt at: https://www.vni.net/~kwelch/penguin.html/blue_ice.shtml whereas earlier versions simply give up and admit defeat. Also, I *REALLY* miss bookmarks. Where did they go? (And why?) I like the frames work and the status messages a LOT. And having the forms and imagemap functionality back is enough to make this alpha a real improvement. The "URL:" label clips the left edge of the display box. And I realize that no one but me uses it, but I wish that the "Title" line was displayed. Michael Kellen - -- That which does not kill us ... maims us. Friedrich Nietzsche (first draft) ------- Message 20 Received: from sonny.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa09713; 9 Jan 96 21:57 PST To: Michael Kellen cc: Chimera Hacker List Subject: Re: [cfh99] Is this just me ??? In-reply-to: Your message of "Tue, 09 Jan 1996 17:15:23 MST." Date: Tue, 09 Jan 1996 21:58:00 -0800 From: John Kilburg >Also, I *REALLY* miss bookmarks. Where did they go? (And why?) The old bookmark code had a really bad bug in it and I really didn't care for that nasty looking window thing. There will probably be a set of bookmark URLs: bookmark-add:URL - Add URL to the bookmark list bookmark-list: - output HTML bookmark list bookmark-delete:URL - delete bookmark etc. or something like that. I haven't completely worked it out yet. One problem is that someone could put the following link in their HTML: Cool stuff! which could catch someone unawares. Even worse is a URL that looks harmless but is redirected to a bookmark-delete URL. -john ------- Message 21 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa20065; 10 Jan 96 5:05 PST Received: from kroete2.freinet.de (arhppp20.uni-c.dk [130.225.243.180]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id OAA03742 for ; Wed, 10 Jan 1996 14:02:50 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0ta08k-0003kJC; Wed, 10 Jan 96 14:00 MET Message-Id: From: Erik Corry Subject: Re: [cfh99] Is this just me ??? To: Chimera Hacker List Date: Wed, 10 Jan 1996 14:00:30 +0100 (MET) In-Reply-To: <199601100626.HAA28528@inet.uni-c.dk> from "John Kilburg" at Jan 9, 96 09:58:00 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS One problem is that someone could put the following link in their > HTML: > > Cool stuff! > > which could catch someone unawares. Even worse is a URL that looks > harmless but is redirected to a bookmark-delete URL. I was considering a 'lib' protocol, something like lib://cool-chimera-builtin-icon.gif which is internally implemented as a file URL with a special lookup path. Perhaps you already did something like this and I just didn't look at it yet. Is it possible to restrict the protocols used by a link, so that the bookmark-delete protocol can only be from data fetched with a trusted protocol like bookmark-list:, lib: or file: Actually I think a single new pseudo-protocol called chimera: would be a cleaner solution. You could have the precise function in the rest of the URL sort of like chimera:/bookmark-delete/... That way you don't have to invent too many new protocol names with the associated risk of clashes. - -- Erik Corry ehcorry@inet.uni-c.dk ------- Message 22 Received: from igw2.merck.com by JIMI.CS.UNLV.EDU id aa20278; 10 Jan 96 5:23 PST Received: from igw2.merck.com Message-Id: <199601101321.IAA02440@igw2> Received: from mailhost.merck.com(54.3.1.99) by ngatekeeper.merck.com via smap (g3.0.1) id sma002435; Wed, 10 Jan 96 08:21:06 -0500 From: Anthony Starks Subject: re: bookmarks To: john@sonny.ISRI.UNLV.EDU Date: Wed, 10 Jan 1996 08:19:36 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 404 I suggest that you simply create a HTML file in a standard place as the bookmark file. When you want to access your bookmarks, just fork a new window showing the bookmark document. The only action that the browser does is add; don't even worry about deletion. If the user wants to more stuff, like create bookmark categories, they can hack the HTML file, perhaps with a special tool. - -- Anthony ------- Message 23 Received: from gateway.sandelman.ocunix.on.ca by JIMI.CS.UNLV.EDU id aa08800; 10 Jan 96 17:34 PST Received: from sandelman.ocunix.on.ca (root@latour.sandelman.ocunix.on.ca [192.139.46.129]) by bud.sandelman.ocunix.on.ca (8.6.12/8.6.12) with SMTP id RAA07148; Wed, 10 Jan 1996 17:40:11 -0800 Received: from localhost by sandelman.ocunix.on.ca with SMTP id AA03103 sender mcr@latour.sandelman.ocunix.on.ca (5.65a/IDA-1.4.2); Wed, 10 Jan 96 20:33:19 -0500 Message-Id: <9601110133.AA03103@sandelman.ocunix.on.ca> To: John Kilburg Cc: bug-chimera@cs.unlv.edu Subject: Re: [cfh99] Is this just me ??? In-Reply-To: Your message of "Tue, 09 Jan 1996 21:58:00 PST." Date: Wed, 10 Jan 1996 20:33:17 -0500 From: Michael Richardson >>>>> "John" == John Kilburg writes: John> The old bookmark code had a really bad bug in it and I John> really didn't care for that nasty looking window thing. Hmm. Well, the worse part of the old code was that it didn't reopen the bookmark file to append new entries. I had a cron job that converted the .chimera_bookmark file to an HTML version, zeroing the chimera bookmark file along the way (actually, I left a reference to the HTML bookmark file...) If I left chimera running, of course, chimera would write the bookmark file again, and I'd get repeats... John> bookmark-add:URL - Add URL to the bookmark list John> bookmark-list: - output HTML bookmark list John> bookmark-delete:URL - delete bookmark etc. John> or something like that. I haven't completely worked it out John> yet. John> One problem is that someone could put the following link in John> their HTML: Yes, well, this *is* a problem. You have associate trust levels with protocol lines... I rather think that the most elegant way is to have an associated "bookmarkd" and accepts HTTP commands, like "LINK" to add things. ------- Message 24 Received: from ttmath.ttu.edu by JIMI.CS.UNLV.EDU id aa11011; 12 Jan 96 13:57 PST Date: Fri, 12 Jan 1996 15:57:49 -0600 (CST) From: Jake Kesinger To: Chimera Hacker List Subject: Configuration questions In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've started work on an autoconf script for chimera, but before I proceed further I would like to know what level (if any) of interest there is for this sort of thing. The reason I'm doing this is because I have yet to see a system with a properly working imake, and I'm sick and tired of running xmkmf by hand in a dozen subdirectories and patching up the resulting Makefile because the system defaults are screwed. (This is a problem I have with a lot of software, but chimera is the only one I compile enough to make me do this). I don't want to be the cause of duplicated effort; is there already someone working on this? Thank you. --Jake _ Jake Kesinger (kesinger@math.ttu.edu) <*> LUBBOCK -> _|*~- https://rowlf.cc.wwu.edu:8080/~n9146070/ \, _} I had a marvellous quote to go here, but it is too \( long to fit in the margin. ------- Message 25 Received: from msa.tte.vtt.fi by JIMI.CS.UNLV.EDU id aa12233; 12 Jan 96 14:37 PST Received: (from msa@localhost) by msa.tte.vtt.fi (8.7/8.7) id AAA05570; Sat, 13 Jan 1996 00:34:35 +0200 (EET) Date: Sat, 13 Jan 1996 00:34:35 +0200 (EET) From: Markku Savela Message-Id: <199601122234.AAA05570@msa.tte.vtt.fi> To: kesinger@math.ttu.edu CC: bug-chimera@cs.unlv.edu In-reply-to: Jake Kesinger's message of Fri, 12 Jan 1996 15:57:49 -0600 (CST) Subject: Configuration questions Reply-to: Markku Savela >The reason I'm doing this is because I have yet to see a system with a >properly working imake, and I'm sick and tired of running xmkmf by >hand I used GNU autoconf in my version 4.0 of Xew widgets to generate the Imakefiles (I treated Imakefile's like config.h files). Imakefiles are passed trhough a preprocessor, so it fits. I think the result was rather successful. Easier than generating Makefile's directly. - -- msa ------- Message 26 Received: from nag.cs.Colorado.EDU by JIMI.CS.UNLV.EDU id aa12259; 12 Jan 96 14:39 PST Received: from nag.cs.colorado.edu (localhost.cs.colorado.edu [127.0.0.1]) by nag.cs.colorado.edu (8.6.10/8.6.10) with ESMTP id PAA19904; Fri, 12 Jan 1996 15:39:33 -0700 Message-Id: <199601122239.PAA19904@nag.cs.colorado.edu> To: Jake Kesinger cc: Chimera Hacker List , popiel@nag.cs.colorado.edu Subject: Re: Configuration questions In-reply-to: Your message of "Fri, 12 Jan 1996 15:57:49 MST." Date: Fri, 12 Jan 1996 15:39:32 -0700 From: "T. Alexander Popiel" In message: Jake Kesinger writes: >I've started work on an autoconf script for chimera I strongly recommend against doing this; there's a good reason X programs use imake. If the imake installation is broken, yell at your sysadmin, not at the programs you try to build. - - Alex ------- Message 27 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa13525; 12 Jan 96 15:10 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Fri, 12 Jan 96 18:09:22 -0500 From: Jim Rees To: Chimera Lovers Date: Fri, 12 Jan 1996 18:09:21 -0500 Subject: Re: Configuration questions Sender: rees@citi.umich.edu In-Reply-To: Jake Kesinger, Fri, 12 Jan 1996 15:57:49 CST I've started work on an autoconf script for chimera, but before I proceed further I would like to know what level (if any) of interest there is for this sort of thing. I don't like autoconf. It's ok if there is nothing better, but for X applications I prefer imake. The problem with autoconf is that it only works well on those systems it knows about. Since autoconf is attached to the application, there is no way it can anticipate every environment it might want to run on. Imake, on the other hand, is installed on, and tied to, the machine it's running on. The only way it can possibly malfunction is if it was improperly installed. I'll agree that imake sometimes malfunctions, but so does autoconf. If you fix imake, you've fixed it for all time. But if you fix autoconf, you have to fix it again every time you install a new application. ------- Message 28 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa21623; 12 Jan 96 22:19 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Sat, 13 Jan 96 01:19:50 -0500 (EST) Message-Id: Date: Sat, 13 Jan 96 01:13:22 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: adding PNG to chimera? Now that a version of libpng with a "push reader" is available, I'm thinking of adding PNG capability to chimera 2.0. Is someone else already doing this? ------- Message 29 Received: from concorde.inria.fr by JIMI.CS.UNLV.EDU id aa28774; 13 Jan 96 5:19 PST Received: from fantomas.inria.fr (fantomas.inria.fr [128.93.11.34]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id OAA02052; Sat, 13 Jan 1996 14:19:06 +0100 (MET) Received: (from lasgout@localhost) by fantomas.inria.fr (8.6.10/8.6.6) id OAA28861; Sat, 13 Jan 1996 14:19:04 +0100 Date: Sat, 13 Jan 1996 14:19:04 +0100 Message-Id: <199601131319.OAA28861@fantomas.inria.fr> From: Jean-Marc Lasgouttes To: rees@umich.edu CC: bug-chimera@cs.unlv.edu In-reply-to: <199601122325.AAA26086@nez-perce.inria.fr> (message from Jim Rees on Fri, 12 Jan 1996 18:09:21 -0500) Subject: Re: Configuration questions Reply-to: Jean-Marc.Lasgouttes@inria.fr >>>>> "Jim" == Jim Rees writes: Jim> I've started work on an autoconf script for chimera, but Jim> before I proceed further I would like to know what level (if Jim> any) of interest there is for this sort of thing. Jim> I don't like autoconf. It's ok if there is nothing better, Jim> but for X applications I prefer imake. I like autoconf. I had a lot of problem with Sun's imake in the past (I know I should complain to Sun and force them to fix it...). What make autoconf easier to use is that the generated Makefile is a human readable one, not 10k of make rules impossible to understand. So if an autoconf generated Makefile does not work, you can try to correct it. With a imake generated Makefile, you are generally out of luck. One particular problem with X's Imakefiles is that it is always difficult to decide where you want the binaries/libraries to go and that you must resort to ugly tricks. Concerning the correct/incorrect installations, autoconf is able to use imake to know where the different libraries and includes are. Of course there is some work to do to make it work on all machines, but it is doable. To repeat an argument that appeared earlier, when you fix an imake installation on one machine, it will still not work on all others. I would suggest to generate real Makefiles with autoconf. That's what we are doing currently for the LyX word processor, and it seems to work well. Jean-Marc. ------- Message 30 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa00912; 13 Jan 96 7:36 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Sat, 13 Jan 96 10:34:58 -0500 From: Jim Rees To: Chimera Lovers Date: Sat, 13 Jan 96 10:34:52 EST Subject: Re: Configuration questions Sender: rees@citi.umich.edu In-Reply-To: Jean-Marc Lasgouttes, Sat, 13 Jan 96 14:19:04 +0100 What make autoconf easier to use is that the generated Makefile is a human readable one, not 10k of make rules impossible to understand. I don't agree. The Emacs Makefile is completely incomprehensible. And if autoconf fails, you have no Makefile to fix. One particular problem with X's Imakefiles is that it is always difficult to decide where you want the binaries/libraries to go and that you must resort to ugly tricks. I've never had that problem. Certainly chimera has no problem putting its binaries/libraries in non-standard places. Concerning the correct/incorrect installations, autoconf is able to use imake to know where the different libraries and includes are. If imake works, why add some other piece that might fail? I would suggest to generate real Makefiles with autoconf. That's what we are doing currently for the LyX word processor, and it seems to work well. If I try to install LyX on a machine it doesn't know about, the installation will fail. If I install chimera on a machine it doesn't know about, it will succeed. The chimera installation will only fail if X is improperly installed. And if that's the case, it's futile trying to run X applications on it. ------- Message 31 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa01541; 13 Jan 96 8:36 PST Received: from kroete2.freinet.de (arhppp34.uni-c.dk [130.225.243.196]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id RAA19942 for ; Sat, 13 Jan 1996 17:34:23 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0tb6tY-0003m8C; Sat, 13 Jan 96 15:25 MET Message-Id: From: Erik Corry Subject: Re: adding PNG to chimera? To: Chimera Hacker List Date: Sat, 13 Jan 1996 15:25:24 +0100 (MET) In-Reply-To: from "Smarasderagd" at Jan 13, 96 01:13:22 am Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS > Now that a version of libpng with a "push reader" is available, > I'm thinking of adding PNG capability to chimera 2.0. Is someone > else already doing this? Go for it! PNG includes zlib, which is a library for decompressing .Z and .gz data streams, so John may like to consider whether it can also be used to decomress data with Encoding: x-gzip and the like. Decompression in the Chimera process itself has benefits in terms of stability and the quality of error messages. When N******e accepts PNG there could well be an explosion in PNG usage, as it's legally unproblematic even in the USA, supports 24-bit and compresses better. And a lot of other browsers already support it (basically all that don't do progressive display). I suspect for the initial release you will not be able to handle some of the more exotic options, like arbitrary bitmaps for transparency and maps of partial transparency. That needs more work on the basic image code, which should probably be done at the same time as background images, and overlays. I'm not sure what you should do about gamma, which has been ignored until now, but which the PNG authors seem to think is very important. - -- Erik Corry ehcorry@inet.uni-c.dk https://inet.uni-c.dk/~ehcorry ------- Message 32 Received: from homesick.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa02359; 13 Jan 96 9:10 PST Received: from concorde.inria.fr by HOMESICK.CS.UNLV.EDU id aa27339; 13 Jan 96 9:01 PST Received: from fantomas.inria.fr (fantomas.inria.fr [128.93.11.34]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA02610; Sat, 13 Jan 1996 17:56:12 +0100 (MET) Received: (from lasgout@localhost) by fantomas.inria.fr (8.6.10/8.6.6) id RAA28984; Sat, 13 Jan 1996 17:56:10 +0100 Date: Sat, 13 Jan 1996 17:56:10 +0100 Message-Id: <199601131656.RAA28984@fantomas.inria.fr> From: Jean-Marc Lasgouttes To: rees@umich.edu CC: bug-chimera@cs.unlv.edu In-reply-to: <199601131601.RAA28562@nez-perce.inria.fr> (message from Jim Rees on Sat, 13 Jan 96 10:34:52 EST) Subject: Re: Configuration questions Reply-to: Jean-Marc.Lasgouttes@inria.fr >>>>> "Jim" == Jim Rees writes: Jim> I don't agree. The Emacs Makefile is completely Jim> incomprehensible. And if autoconf fails, you have no Jim> Makefile to fix. That's maybe a problem with the emacs maintainers... Seriously, a huge package like emacs cannot be simple to build. It is not really a fair example. Jim> I've never had that problem. Certainly chimera has no Jim> problem putting its binaries/libraries in non-standard Jim> places. The problem is that X11 insists in putting binaries in the directory pointed to by BINDIR that is also where it looks for its owm files (I had a lot of problems with this and mkdirhier in X11R4). There is *no* imake macro that allows to install in another place. That's what I call a kludge. I've never found a reasonable way to install all X11 programs in /usr/local/bin. (this does not imply that it is not possible, but that it is not easy...). Jim> If imake works, why add some other piece that might fail? imake has no provision for detecting on the fly whether some particular header file it needs is available or not. Therefore you do not need to define yourself HAVE_FOO after browsing your manual. Can imake check whether linking with the resolv library is needed on my Sun? What imake could do for me is link every X program with - -lresolv. Great. Jim> If I try to install LyX on a machine it doesn't know about, Jim> the installation will fail. If I install chimera on a Jim> machine it doesn't know about, it will succeed. The chimera Jim> installation will only fail if X is improperly installed. And Jim> if that's the case, it's futile trying to run X applications Jim> on it. You can install chimera on any machine on which you can guess the correct parameters if John did not provide them. Therefore a good mid-term solution could be to generate an Imakefile through autoconf. Jean-Marc. ------- Message 33 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa02937; 13 Jan 96 10:00 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Sat, 13 Jan 96 12:59:53 -0500 From: Jim Rees To: Chimera Lovers Date: Sat, 13 Jan 96 12:59:47 EST Subject: Re: adding PNG to chimera? Sender: rees@citi.umich.edu In-Reply-To: Erik Corry, Sat, 13 Jan 96 15:25:24 +0100 I'm not sure what you should do about gamma, which has been ignored until now, but which the PNG authors seem to think is very important. It's my opinion that gamma correction should be applied at the lowest layer possible, preferably in the hardware, and if not there, then in the X server. Unfortunately, with X we're stuck with no gamma correction at all anywhere, so we have to put it in each application. That's clearly not a good thing. ------- Message 34 Received: from cygnus.com by JIMI.CS.UNLV.EDU id aa06373; 13 Jan 96 13:33 PST Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id NAA24293; Sat, 13 Jan 1996 13:33:18 -0800 Received: by tweedledumb.cygnus.com (4.1/4.7) id AA00581; Sat, 13 Jan 96 16:33:16 EST Received: by perdiem.cygnus.com (8.6.12/4.7) id QAA00505; Sat, 13 Jan 1996 16:31:27 -0500 Date: Sat, 13 Jan 1996 16:31:27 -0500 From: "Mark W. Eichin" Message-Id: <199601132131.QAA00505@perdiem.cygnus.com> To: Jean-Marc.Lasgouttes@inria.fr Cc: rees@umich.edu, bug-chimera@cs.unlv.edu In-Reply-To: <199601131656.RAA28984@fantomas.inria.fr> (message from Jean-Marc Lasgouttes on Sat, 13 Jan 1996 17:56:10 +0100) Subject: Re: Configuration questions Having some amount of experience with large packages and imake and autoconf (in particular, Kerberos, which once used imake and now uses autoconf) I'd like to make a few comments. * They solve different problems. Imake handles X-related configuration, and handles it quite well; if a program is solely X-based, and has very little non-X code, Imake will suit it well. You need to use the particular set of features it supplies, but if you do, you're fine. Autoconf handles generic-unix (and in theory, a broader range) configuration, and handles that quite well. It is easy to extend the set of supplied tests, so that you can identify features that your code can use. * They're both somewhat difficult to use correctly. If misused, it is easy to have imake-based programs that need porting to every platform. Likewise, if misused it is possible to have autoconf-based programs need tweaking on every platform. This should not be surprising. * The failures are on different vectors. If you don't have X installed and working, then Imake isn't available. This makes Imake a poor choice for non-X programs (such as kerberos.) Also, there are some vendors (such as Sun) that persistently get their imake installations wrong. This is painful, as the whole point of imake is that one can leverage on the work of those who ported X... this is why, when people get burned by imake, they tend to be *very* shy of it. autoconf can fail too; the failures can be more subtle, such as a test that chooses between two possibilities by testing one and assuming the other if the test fails. This is a matter of education. * Synergy! It is possible to combine the strengths of both. There are already standard autoconf macros (AC_FIND_X) for running xmkmf to extract some of the Imake information. I've seen some applications that need both worlds (kerberized xdm!) where unix part of the configuration is handled by autoconf, which then runs imake to drop in the remaining X-specific details. Something like that could be useful for chimera, I'd certainly like to look at what anyone comes up with. Speaking as a "consumer", it's nice to have --prefix and related "standard" features of configure; at the same time, constraining to the features Imake supports can make the program more portable. _Mark_ Cygnus Support, Eastern USA ------- Message 35 Received: from babybop.reptiles.org by JIMI.CS.UNLV.EDU id aa10760; 13 Jan 96 17:53 PST Received: by reptiles.org via send-mail with stdio id for bug-chimera@cs.unlv.edu; Sat, 13 Jan 96 20:53:09 -0500 (EST) (/\##/\ Smail3.1.30.13 #30.4 built 26-sep-) Message-Id: Date: Sat, 13 Jan 96 20:53:09 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: Re: adding PNG to chimera? Having gamma correction in X would be helpful, but it is still desirable in the application. For instance, if alpha channel processing is to produce good results, the source image(s) should have a gamma of 1. Quantization and dithering should also be gamma-aware. The PNG specification (https://www.w3.org/pub/WWW/TR/WD-png) has a good discussion of gamma correction and the issues surrounding it. ------- Message 36 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa12758; 16 Jan 96 11:11 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Tue, 16 Jan 96 14:11:41 -0500 (EST) Message-Id: Date: Tue, 16 Jan 96 14:11:01 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: imake and chimera and linux, augh Cc: orestz@eskimo.com, png-list@dworkin.wustl.edu This morning I had an experience which gave me cause to reflect on the use of imake, specifically under XFree86's flavour of X11R6 under Linux. I was trying out my implementation of PNG for Chimera and ran into a mysterious problem. In the debugger, the "mode" element of the png_struct structure was wrong, but, oddly, only when I looked at it while in the png code; it was OK when I looked at in the Chimera code. Further investigation revealed that libpng and Chimera disagreed on the size of png_struct, in particular, the size of the "jmpbuf" element, which appeared just before "mode"... When the red mist had cleared from my eyes, I was able to determine that in my installation of XFree86 (3.1.1) the imake rules for Linux supply, among other flags: - -D_POSIX_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE which causes gcc on my machine (2.6.2) to include some extra stuff in the declaration for jmp_buf. I am extremely dubious about the flags above as a standard compilation environment for X, but I don't know what constraints the XFree86 person for Linux has to work under. In any case, those programming with libpng on Linux under X should be aware of this, as it may cause similar problems. ------- Message 37 Received: from xph029.physics.montana.edu by JIMI.CS.UNLV.EDU id aa10190; 17 Jan 96 11:29 PST Received: (from michael@localhost) by xph029.physics.montana.edu (8.6.12/8.6.9) id MAA16193; Wed, 17 Jan 1996 12:27:02 -0700 Date: Wed, 17 Jan 1996 12:26:58 -0700 (MST) From: Michael Kellen To: Chimera Hacker List Subject: [cfh99-2.0] Non-Anonymous FTP Patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For no really good reason, here is a patch to allow non-anonymous ftp connections. In case you've forgotten, the URL spec for those is: ftp://user:pass@site:port/path/file The URL hasher had to be patched so that both anon and non-anon ftp could be performed at the same site within a session. *** proto/ftp.c.orig Sun Dec 31 21:33:21 1995 - --- proto/ftp.c Wed Jan 17 12:01:17 1996 *************** byte *data; *** 375,381 **** char *request; char *uname; ! if ((uname = getenv("EMAIL")) != NULL) { request = MemPoolGet(fi->mp, strlen(uname) + 9); strcpy(request, "PASS -"); - --- 375,392 ---- char *request; char *uname; ! /* To really support non-anonymous ftp, this should check username ! * and if that is non-null but password is null, pop up an auth-request ! * style box to grab the password without it being displayed -- MJK ! */ ! if (fi->up->password != NULL) ! { ! request = MemPoolGet(fi->mp, strlen(fi->up->password) + 8); ! strcpy(request, "PASS "); ! strcat(request, fi->up->password); ! strcat(request, "\r\n"); ! } ! else if ((uname = getenv("EMAIL")) != NULL) { request = MemPoolGet(fi->mp, strlen(uname) + 9); strcpy(request, "PASS -"); *************** FTPUser(fi, data) *** 399,405 **** FTPInfo *fi; byte *data; { ! FTPSimple(fi, "USER anonymous\r\n", FTPPass, false); return; } - --- 410,430 ---- FTPInfo *fi; byte *data; { ! char *request; ! ! if (fi->up->username != NULL) ! { ! request = MemPoolGet(fi->mp, strlen(fi->up->username) + 8); ! strcpy(request, "USER "); ! strcat(request, fi->up->username); ! strcat(request, "\r\n"); ! } ! else ! { ! request = MemPoolStrDup(fi->mp, "USER anonymous\r\n"); ! } ! ! FTPSimple(fi, request, FTPPass, false); return; } *************** int len; *** 506,512 **** trailer = FrameGetResource(fi->frame, "ftp.dirtrailer"); if (trailer == NULL) trailer = ""; ! hostname = fi->up->hostname; filename = fi->up->filename; hlen = strlen(hostname); flen = strlen(filename); - --- 531,551 ---- trailer = FrameGetResource(fi->frame, "ftp.dirtrailer"); if (trailer == NULL) trailer = ""; ! if ( fi->up->username != NULL ) ! { ! hostname = MemPoolGet(fi->mp, strlen(fi->up->username) ! + strlen(fi->up->password) ! + strlen(fi->up->hostname) + 2); ! strcpy(hostname, fi->up->username); ! strcat(hostname, ":"); ! strcat(hostname, fi->up->password); ! strcat(hostname, "@"); ! strcat(hostname, fi->up->hostname); ! } ! else ! { ! hostname = fi->up->hostname; ! } filename = fi->up->filename; hlen = strlen(hostname); flen = strlen(filename); *** www/url.c.orig Sun Dec 31 21:27:31 1995 - --- www/url.c Wed Jan 17 12:06:00 1996 *************** URLParts *up; *** 421,427 **** dp->input_data = MPGet(mp, up->input_data_len); memcpy(dp->input_data, up->input_data, up->input_data_len); dp->input_data_len = up->input_data_len; ! dp->input_data_type = MPStrDup(mp, dp->input_data_type); } else dp->input_data_len = 0; - --- 421,427 ---- dp->input_data = MPGet(mp, up->input_data_len); memcpy(dp->input_data, up->input_data, up->input_data_len); dp->input_data_len = up->input_data_len; ! dp->input_data_type = MPStrDup(mp, up->input_data_type); } else dp->input_data_len = 0; *************** URLParts *up; *** 615,620 **** - --- 615,621 ---- ulen = 10; /* for the port number. trouble! */ if (up->protocol != NULL) ulen += strlen(up->protocol); + if (up->username != NULL) ulen += strlen(up->username); if (up->hostname != NULL) ulen += strlen(up->hostname); if (up->filename != NULL) ulen += strlen(up->filename); /* *************** URLParts *up; *** 625,630 **** - --- 626,632 ---- ustr = (char *)MPGet(mp, sizeof(char) * (ulen + 1)); sprintf (ustr, "%d", up->port); if (up->protocol != NULL) strcat(ustr, up->protocol); + if (up->username != NULL) strcat(ustr, up->username); if (up->hostname != NULL) strcat(ustr, up->hostname); if (up->filename != NULL) strcat(ustr, up->filename); /* ------- Message 38 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa25340; 19 Jan 96 3:27 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Fri, 19 Jan 96 06:27:43 -0500 (EST) Message-Id: Date: Fri, 19 Jan 96 06:27:30 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: PNG support for chimera I now have PNG support working in Chimera 2.0 pretty much completely. Chimera will load and view all of the images in both of the test suites I have. I can send what I have now if anyone wants it, but you'll probably want to wait until the next version of libpng comes out, as I ran across a number of bugs in the current one. ------- Message 39 Received: from ttmath.ttu.edu by JIMI.CS.UNLV.EDU id aa14024; 19 Jan 96 18:10 PST Date: Fri, 19 Jan 1996 20:10:09 -0600 (CST) From: Jake Kesinger To: bug-chimera@cs.unlv.edu Subject: Interesting effect In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I was playing around with 2.0a99 yesterday and noticed an interesting effect. I visited a page with one of those SSI substitutions in the form of an . Anyway, the CGI on the other end was misconfigured (error 500, I think) and chimera displayed the calling page, with a ``mini-window'' complete with scrollbars at the point of the source. Is this a known bug? It seems almost as if it could be a feature, it looked so nifty. I'm putting a page that should do the same thing (I'll be away from a workstation over the weekend, so I can't test it) at https://www.math.ttu.edu/~kesinger/chimera/ssimg.html. Also, an update on my efforts at autoconfing Chimera: it appears to work on Linux and Solaris2.5 (with *minor* modifications to common/util.c proto/file.c and www/io.c in some #ifdefs), and I'm wrestling with getting it to go under NetBSD (problem with X libraries) followed by Ultrix (all the systems I have access to). I should hopefully have something ready for public flaming w/in a week or two. --Jake _ Jake Kesinger (kesinger@math.ttu.edu) <*> LUBBOCK -> _|*~- https://rowlf.cc.wwu.edu:8080/~n9146070/ \, _} ``It's a damn poor mind that can only think of one way \( to spell a word.'' (Andrew Jackson) ------- Message 40 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14857; 19 Jan 96 19:00 PST To: bug-chimera@cs.unlv.edu Subject: Re: Interesting effect In-reply-to: Your message of "Fri, 19 Jan 1996 20:10:09 CST." Date: Fri, 19 Jan 1996 19:00:08 -0800 From: John Kilburg >I was playing around with 2.0a99 yesterday and noticed an interesting >effect. I visited a page with one of those SSI substitutions in the >form of an . Anyway, the CGI on the other end was misconfigured >(error 500, I think) and chimera displayed the calling page, with a >``mini-window'' complete with scrollbars at the point of the >source. Is this a known bug? It seems almost as if it could be a feature, >it looked so nifty. I'm putting a page that should do the same thing >(I'll be away from a workstation over the weekend, so I can't test >it) at https://www.math.ttu.edu/~kesinger/chimera/ssimg.html. This is a known "bug" :) This is the reason the release after 80 took so long and many new bugs appeared. Basically, all content can be embedded and since the error message is "text/html" that content is displayed instead of the image. The HTTP code should do something like FrameReload("chimera:/error/icon.gif") when it receives an HTTP error which would cause an error icon to be displayed instead of the HTML. Try embedding HTML in itself... -john ------- Message 41 Received: from iguana.reptiles.org by JIMI.CS.UNLV.EDU id aa18650; 29 Jan 96 13:01 PST Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Mon, 29 Jan 96 16:01:00 -0500 (EST) Message-Id: Date: Mon, 29 Jan 96 16:00:40 -0500 (EST) From: Smarasderagd To: bug-chimera@cs.unlv.edu Subject: PNG patches/additions for chimera I've gotten my PNG changes into shape, and here they are. You'll need libpng-0.88 and zlib-0.95, both available from ftp://swrinde.nde.swri.edu/pub/png/src. The changes consist of a few patches, and a new file, image/png.c. A few notes: You'll want to watch out for the jmp_buf size problem I ran into earlier. Either make sure your png library agrees with chimera on the size of jmp_buf, or vice versa. For my setup (Linux, gcc 2.6.2 with XFree86 3.1.1) I added -U_BSD_SOURCE -U_GNU_SOURCE to PNG_DEFINES in image/Imakefile. Currently, grayscale PNG images are passed on to the image code as IRGB files, as transparency doesn't work if they're passed as IGRAY. The bit-endian business is a real pain. Every decoder that produces bitmaps has to reverse them if LITTLE_ENDIAN is set. I think we should set the bitmap_bit_order to MSBFirst. It would be nice if there were a function in image.c to retrieve the background colour from the "closure" pointer. This would enable the png code to handle images with a full alpha channel. #! /bin/sh # Strip off top stuff and run this through /bin/sh to produce: # png.patch # image/png.c # Produced by Chris's stupid and simple sh shar. echo 'png.patch' if [ -f png.patch ] then echo png.patch already exists; exit 1 fi sed 's/^X//' >'png.patch' <<'ENDIT' Xdiff -r -b -u cfh99-2.0/Common.tmpl.dist cfh99/Common.tmpl.dist X--- cfh99-2.0/Common.tmpl.dist Mon Jan 1 03:00:23 1996 X+++ cfh99/Common.tmpl.dist Tue Jan 16 08:39:46 1996 X@@ -38,6 +38,16 @@ X */ X X /* X+ * Uncomment if you have the PNG and ZLIB library X+ */ X+/* X+#define Use_PNG X+PNGINCLUDE = -I/usr/local/png/include -I/usr/local/zlib/include X+PNGLIB = -L/usr/local/png/lib -lpng -L/usr/local/zlib/lib -lz X+PNGDEPLIB = /usr/local/png/lib/libpng.a /usr/local/zlib/lib/libz.a X+*/ X+ X+/* X * Adjust as needed X */ X CEXTRA_DEFINES = -DHAVE_MKTIME -DHAVE_STDLIB_H -DHAVE_STRING_H \ Xdiff -r -b -u cfh99-2.0/image/Imakefile cfh99/image/Imakefile X--- cfh99-2.0/image/Imakefile Mon Jan 1 03:00:02 1996 X+++ cfh99/image/Imakefile Tue Jan 16 14:54:07 1996 X@@ -7,14 +7,21 @@ X JPEG_SRCS = jpeg.c X #endif X X+#ifdef Use_PNG X+PNG_INCLUDES = $(PNGINCLUDE) X+PNG_DEFINES = -DHAVE_PNG X+PNG_OBJS = png.o X+PNG_SRCS = png.c X+#endif X+ X OBJS = gif.o xbm.o pnm.o new.o dispdither.o halftone.o \ X- colorcube.o xcolorcube.o image.o $(JPEG_OBJS) X+ colorcube.o xcolorcube.o image.o $(JPEG_OBJS) $(PNG_OBJS) X X SRCS = gif.c xbm.c pnm.c new.c dispdither.c halftone.c \ X- colorcube.c xcolorcube.c image.c $(JPEG_SRCS) X+ colorcube.c xcolorcube.c image.c $(JPEG_SRCS) $(PNG_SRCS) X X-EXTRA_INCLUDES = -I../common -I../www $(JPEG_INCLUDES) X-EXTRA_DEFINES = $(XRELEASE) $(CEXTRA_DEFINES) $(JPEG_DEFINES) X+EXTRA_INCLUDES = -I../common -I../www $(JPEG_INCLUDES) $(PNG_INCLUDES) X+EXTRA_DEFINES = $(XRELEASE) $(CEXTRA_DEFINES) $(JPEG_DEFINES) $(PNG_DEFINES) X X NormalLibraryTarget(image, $(OBJS)) X Xdiff -r -b -u cfh99-2.0/image/image.c cfh99/image/image.c X--- cfh99-2.0/image/image.c Wed Jan 3 04:53:31 1996 X+++ cfh99/image/image.c Tue Jan 16 12:14:22 1996 X@@ -31,6 +31,7 @@ X #define IMAGE_GIF 0 X #define IMAGE_XBM 1 X #define IMAGE_JPEG 2 X+#define IMAGE_PNG 3 X #define IMAGE_PNM 5 X #define IMAGE_UNKNOWN 6 X X@@ -46,6 +47,10 @@ X #ifdef HAVE_JPEG X { "image/jpeg", IMAGE_JPEG }, X #endif X+#ifdef HAVE_PNG X+ { "image/x-png", IMAGE_PNG }, X+ { "image/png", IMAGE_PNG }, X+#endif X { "image/x-xbitmap", IMAGE_XBM }, X { "image/x-portable-anymap", IMAGE_PNM }, X { "image/x-portable-bitmap", IMAGE_PNM }, X@@ -1069,6 +1074,9 @@ X else if (format == IMAGE_XBM) xbmInit(ImageToXImage, is, &is->if_vector); X #ifdef HAVE_JPEG X else if (format == IMAGE_JPEG) jpegInit(ImageToXImage, is, &is->if_vector); X+#endif X+#ifdef HAVE_PNG X+ else if (format == IMAGE_PNG) pngInit(ImageToXImage, is, &is->if_vector); X #endif X X ic->icount++; Xdiff -r -b -u cfh99-2.0/src/Imakefile cfh99/src/Imakefile X--- cfh99-2.0/src/Imakefile Mon Jan 1 02:59:52 1996 X+++ cfh99/src/Imakefile Tue Jan 16 08:40:28 1996 X@@ -1,7 +1,7 @@ X #include <../Common.tmpl> X X-IMAGELIB = -L../image -limage $(JPEGLIB) X-IMAGEDEPLIB = ../image/libimage.a $(JPEGDEPLIB) X+IMAGELIB = -L../image -limage $(JPEGLIB) $(PNGLIB) X+IMAGEDEPLIB = ../image/libimage.a $(JPEGDEPLIB) $(PNGDEPLIB) X HTMLLIB = -L../html -lhtml X HTMLDEPLIB = ../html/libhtml.a X PROTOLIB = -L../proto -lproto ENDIT echo 'image/png.c' if [ -f image/png.c ] then echo image/png.c already exists; exit 1 fi sed 's/^X//' >'image/png.c' <<'ENDIT' X/* XPortable Network Graphics (PNG) image format X*/ X X#include X#include "common.h" X#include "imagep.h" X#include "image_format.h" X#include "image_endian.h" X#include X X#define PM_SCALE(a, b, c) (long)((a) * (c))/(b) X Xenum { X image_success = 0, image_need_data = 1, image_error = -1 X}; X Xtypedef struct { X png_struct *state; X png_info *info; X Image *image; X Intensity cmap[3][256]; X void (*lineProc)(void *, int, int); X void *closure; X int lenSoFar; X int done; X} pngState; X X Xstatic Image * XpngGetImage(void *pointer) X{ X return ((pngState *) pointer)->image; X} X X Xstatic void lc_reverse_byte(byte *row, int n) X{ X int i; X byte c; X X for (i = 0; i < n; ++i) { X c = row[i]; X c = ((c << 4) & 0xf0) | ((c >> 4) & 0x0f); X c = ((c << 2) & 0xcc) | ((c >> 2) & 0x33); X c = ((c << 1) & 0xaa) | ((c >> 1) & 0x55); X row[i] = c; X } X} X X Xstatic void Xlf_info_callback(png_struct *state, png_info *info) X{ X int orig_depth = 0; X pngState *png = (pngState *) png_get_progressive_ptr(state); X X if (info->bit_depth < 8 && (PNG_COLOR_TYPE_RGB == info->color_type || X PNG_COLOR_TYPE_RGB_ALPHA == info->color_type)) X png_set_expand(state); X X /* I wish the frame's background colour was available here */ X if (info->color_type & PNG_COLOR_MASK_ALPHA) { X png_color_16 bg; X int gflag = PNG_BACKGROUND_GAMMA_SCREEN; X double gval = 1.0; X int expand = 0; X X bg.red = bg.green = bg.blue = bg.gray = 0; X if (PNG_COLOR_TYPE_PALETTE == info->color_type) X png_set_expand(state); X X png_set_background(state, &bg, gflag, expand, gval); X } X X if (info->bit_depth < 8 && (info->bit_depth > 1 || X PNG_COLOR_TYPE_GRAY != info->color_type)) { X if (PNG_COLOR_TYPE_GRAY == info->color_type) X orig_depth = info->bit_depth; X png_set_packing(state); X } X X /* tell libpng to strip 16 bit depth files down to 8 bits */ X if (info->bit_depth > 8) X png_set_strip_16(state); X X png_set_interlace_handling(state); X X /* update palette with transformations, update the info structure */ X png_read_update_info(state, info); X X /* allocate the memory to hold the image using the fields of png_info. */ X if (PNG_COLOR_TYPE_GRAY == info->color_type && 1 == info->bit_depth) { X png->image = newBitImage(info->width, info->height); X png_set_invert_mono(state); X } else if (PNG_COLOR_TYPE_PALETTE == info->color_type) { X int i; X X png->image = newRGBImage(info->width, info->height, info->bit_depth); X png->image->rgb.red = png->cmap[0]; X png->image->rgb.green = png->cmap[1]; X png->image->rgb.blue = png->cmap[2]; X for (i = 0; i < info->num_palette; ++i) { X png->image->rgb.red[i] = info->palette[i].red << 8; X png->image->rgb.green[i] = info->palette[i].green << 8; X png->image->rgb.blue[i] = info->palette[i].blue << 8; X } X png->image->rgb.used = info->num_palette; X if (info->valid & PNG_INFO_tRNS) { X int val, i; X X val = 0; X for (i = 0; i < info->num_trans; ++i) { X if (info->trans[i] < info->trans[val]) X val = i; X } X png->image->transparent = val; X } X } else if (PNG_COLOR_TYPE_GRAY == info->color_type) { X int i; X int depth = orig_depth ? orig_depth : info->bit_depth; X int maxval = (1 << depth) - 1; X X png->image = newRGBImage(info->width, info->height, depth); X /* png->image->type = IGRAY; */ X png->image->rgb.red = png->cmap[0]; X png->image->rgb.green = png->cmap[1]; X png->image->rgb.blue = png->cmap[2]; X for (i = 0; i <= maxval; i++) { X png->image->rgb.red[i] = PM_SCALE(i, maxval, 0xffff); X png->image->rgb.green[i] = PM_SCALE(i, maxval, 0xffff); X png->image->rgb.blue[i] = PM_SCALE(i, maxval, 0xffff); X } X png->image->rgb.used = maxval + 1; X X if (info->valid & PNG_INFO_tRNS) X png->image->transparent = info->trans_values.gray; X } else { X png->image = newTrueImage(info->width, info->height); X } X X if (info->valid & PNG_INFO_gAMA && png->image->type != IBITMAP) X png->image->gamma = 1.0 / info->gamma; X X assert((png->image->width * png->image->pixlen + 7) / 8 == info->rowbytes); X} X X Xstatic void Xlf_row_callback(png_struct *state, png_byte *new_row, png_uint_32 row_num, X int pass) X{ X pngState *png; X byte *old_row; X X if (!new_row) X return; X X png = (pngState *) png_get_progressive_ptr(state); X old_row = png->image->data + png->image->bytes_per_line * row_num; X X png_progressive_combine_row(state, old_row, new_row); X if (png->lineProc) { X /* I can't say I'm too fond of this endian business. */ X#ifdef LITTLE_ENDIAN X if (IBITMAP == png->image->type) X lc_reverse_byte(old_row, png->info->rowbytes); X#endif X (png->lineProc)(png->closure, row_num, row_num); X#ifdef LITTLE_ENDIAN X if (IBITMAP == png->image->type) X lc_reverse_byte(old_row,png->info->rowbytes); X#endif X } X} X X Xstatic void Xlf_end_callback(png_struct *state, png_info *info) X{ X pngState *png= (pngState *) png_get_progressive_ptr(state); X png->done = image_success; X} X X Xstatic void XpngDestroy(void *pointer) X{ X pngState *png = (pngState *) pointer; X X if (!png) X return; X X if (setjmp(png->state->jmpbuf)) X return; X X if (png->state) { X png_read_destroy(png->state, png->info, (png_info *) 0); X free_mem(png->state); X png->state = 0; X } X X if (png->info) { X free_mem(png->info); X png->info = 0; X } X X if (png->image) { X freeImage(png->image); X png->image = 0; X } X X free_mem(png); X} X Xstatic int XpngAddData(void *pointer, byte *data, int len, bool data_ended) X{ X pngState *png = (pngState *) pointer; X int i; X X if (setjmp(png->state->jmpbuf)) X return image_error; X X if (len > png->lenSoFar) { X png_process_data(png->state, png->info, data + png->lenSoFar, X len - png->lenSoFar); X png->lenSoFar = len; X } X X if (image_need_data == png->done && data_ended) X return image_error; X X return png->done; X} X X Xvoid XpngInit(void (*lineProc)(void *, int, int), void *closure, struct ifs_vector *ifsv) X{ X pngState *png; X X ifsv->image_format_closure = 0; X png = (pngState *) alloc_mem(sizeof(pngState)); X if (!png) X return; X X memset(png, 0, sizeof(pngState)); X png->lineProc = lineProc; X png->closure = closure; X png->state = (png_struct *) alloc_mem(sizeof(png_struct)); X if (!png->state) X return; X X png->info = (png_info *) alloc_mem(sizeof(png_info)); X if (!png->info) { X free_mem(png->state); X return; X } X X if (setjmp(png->state->jmpbuf)) { X png_read_destroy(png->state, png->info, (png_info *) 0); X free_mem(png->state); X free_mem(png->info); X png->state = 0; X png->info = 0; X return; X } X X png_info_init(png->info); X png_read_init(png->state); X X png_set_progressive_read_fn(png->state, (void *) png, lf_info_callback, X lf_row_callback, lf_end_callback); X png->done = image_need_data; X png->lenSoFar = 0; X X ifsv->initProc = &pngInit; X ifsv->destroyProc = &pngDestroy; X ifsv->addDataProc = &pngAddData; X ifsv->getImageProc = &pngGetImage; X ifsv->image_format_closure = (void *) png; X} ENDIT exit 0 ------- Message 42 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa18819; 29 Jan 96 13:08 PST To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: chimera bookmarks Date: Mon, 29 Jan 1996 13:08:56 -0800 From: John Kilburg I thought I would explain how the bookmark stuff works before I release it in case there are any serious objections. The format is HTML...it uses the same scheme as Netscape. Bookmark Title Everything else is ignored. Currently bookmarks can be added or displayed/selected but removed or changed. -john p.s. I've been running the next release for a week now but I introduced a nasty bug that I haven't had time to fix...hopefully this weekend it will be available. ------- Message 43 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa19057; 29 Jan 96 13:17 PST To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: Re: PNG patches/additions for chimera In-reply-to: Your message of "Mon, 29 Jan 1996 16:00:40 EST." Date: Mon, 29 Jan 1996 13:17:54 -0800 From: John Kilburg >I've gotten my PNG changes into shape, and here they are. You'll need >libpng-0.88 and zlib-0.95, both available from >ftp://swrinde.nde.swri.edu/pub/png/src. The changes consist of a few >patches, and a new file, image/png.c. Thanks, I'll try to incorporate this into the possible release this weekend if I have time. On a related note, I think I am going to push the color cube code into www/ so that it is easy to call from other modules. The main reason for this is that the HTML code is going to start dealing with the bgcolor attribute (this will be ignorable in case you happen to hate the absurd background colors some people use...) and other color goodies. It will also be useful for other renderers. Has anyone worked on this? Is it a bad idea? -john ------- Message 44 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa28839; 29 Jan 96 18:31 PST Received: from kroete2.freinet.de (arhppp42.uni-c.dk [130.225.243.204]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id DAA11353 for ; Tue, 30 Jan 1996 03:28:36 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0th3xa-0003kOC; Tue, 30 Jan 96 01:30 MET Message-Id: From: Erik Corry Subject: bgcolor To: Chimera Hacker List Date: Tue, 30 Jan 1996 01:30:10 +0100 (MET) In-Reply-To: <199601292237.XAA24229@inet.uni-c.dk> from "John Kilburg" at Jan 29, 96 01:17:54 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS On a related note, I think I am going to push the color cube code into > www/ so that it is easy to call from other modules. The main reason > for this is that the HTML code is going to start dealing with the > bgcolor attribute (this will be ignorable in case you happen to > hate the absurd background colors some people use...) > and other color goodies. It will also be useful for other renderers. > Has anyone worked on this? Is it a bad idea? Moving the color handling code is probably a good idea. This marks a departure from your 'No Netscapisms' stance since, last I looked, it wasn't in HTML2 or in draft HTML3. (See my home page for a link to the drafts.) So can we have
now? :-) It's not documented enough, but it seems the simplest implementation is to treat it as

, and also change the default for new paragraphs to align=center in stead of align=left.

is equivalent to

and also switches the default back to align=left. A hell of a lot of pages use it, despite the fact that it is absolutely totally unnecessary. Although I have also been tempted to launch into bgcolor and background images, etc., I wonder whether Netscapisms are the priority right now. Does this mean that HTML2.0 is supported? Are forms working? Does '

Centered paragraph

Non-centered paragraph' now work? Weren't you planning to do a public release when HTML2.0 was supported? Of course, this may be just sour grapes because I haven't the time to do this myself right now. If you think bgcolor is a trivial little thing, I'd like to point out a few pitfalls. If you implement that you have to implement text= vlink= alink= and link=, otherwise you will end up with a lot of illegible (black writing on a black background) pages. And the transparent image handling would need upgrading to cope. That includes caching of images, and displaying the same image twice on two different pages with different background colors simultaneously. None of these problems are insurmountable; the question is, how long do you want to wait before you release 2.0? - -- Erik Corry ehcorry@inet.uni-c.dk https://inet.uni-c.dk/~ehcorry/ ------- Message 45 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa23676; 30 Jan 96 10:57 PST Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 30 Jan 96 13:56:56 -0500 From: Jim Rees To: Chimera Lovers Date: Tue, 30 Jan 1996 13:56:55 -0500 Subject: Re: bgcolor Sender: rees@citi.umich.edu In-Reply-To: Erik Corry, Tue, 30 Jan 1996 01:30:10 +0100 This marks a departure from your 'No Netscapisms' stance since, last I looked, it wasn't in HTML2 or in draft HTML3. (See my home page for a link to the drafts.) If you put in the bgcolor stuff, I'll have to change my "I Hate Netscape Bigots" page. I Hate Netscape Bigots By the way, I was in Las Vegas yesterday, and it seems to me that a browser that comes from there should probably support background images, text colors, font changes, and all that other gaudy stuff. ------- Message 46 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25072; 30 Jan 96 11:47 PST To: Erik Corry cc: Chimera Hacker List Subject: Re: bgcolor In-reply-to: Your message of "Tue, 30 Jan 1996 01:30:10 +0100." Date: Tue, 30 Jan 1996 11:47:01 -0800 From: John Kilburg >Moving the color handling code is probably a good idea. > >This marks a departure from your 'No Netscapisms' stance since, last >I looked, it wasn't in HTML2 or in draft HTML3. (See my home page for >a link to the drafts.) I pulled the "bgcolor" example out of thin air. Well, I am mostly thinking about the future (daydreaming). Style sheets (which are a proposed standard or something) can change the background, text color, etc. so at some point the HTML code will have to be able to grab arbitrary colors. I figured it would be good to move the code now instead of later. The rigid "no netscapisms" stance is probably a bad one. How about "maybe netscapisms" if it is very convienent or the list thinks the feature is very useful? -john ------- Message 47 Received: from boutell.com by JIMI.CS.UNLV.EDU id aa26267; 30 Jan 96 12:30 PST Received: by boutell.com id AA08387 (5.67b/IDA-1.5 for bug-chimera@cs.unlv.edu); Tue, 30 Jan 1996 12:37:04 -0800 From: Thomas Boutell Message-Id: <199601302037.AA08387@boutell.com> Subject: Maybe Netscapeisms To: bug-chimera@cs.unlv.edu Date: Tue, 30 Jan 1996 12:37:03 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 431 If Chimera is going to muck about with Netscapeisms to some degree, I would personally vote for the WIDTH and HEIGHT attributes to the tag, because they have such a salutary effect on the swift and smooth formatting of a page. Since Chimera does progressive rendering now, that might be worth thinking about. BTW, I'm highly impressed with the potential of Chimera 2.0 to become the new grassroots X browser of choice. - -T ------- Message 48 Received: from inet.uni-c.dk by JIMI.CS.UNLV.EDU id aa07800; 30 Jan 96 16:29 PST Received: from kroete2.freinet.de (arhppp6.uni-c.dk [130.225.243.166]) by inet.uni-c.dk (8.6.12/8.6.9) with SMTP id BAA04107 for ; Wed, 31 Jan 1996 01:26:59 +0100 Received: by kroete2.freinet.de (Smail3.1.28.1 #4) id m0thPdW-0003kJC; Wed, 31 Jan 96 00:38 MET Message-Id: From: Erik Corry Subject: Re: Maybe Netscapeisms To: Chimera Hacker List Date: Wed, 31 Jan 1996 00:38:53 +0100 (MET) In-Reply-To: <199601302037.AA08387@boutell.com> from "Thomas Boutell" at Jan 30, 96 12:37:03 pm Reply-To: Erik Corry X-Face: 5am4$s<`Jfx-,*w6$)uX,dDt3Z2w?4ZNGS-i@_w(Fzv%(<[(XtN*t\,OmV_a=lS If Chimera is going to muck about with Netscapeisms > to some degree, I would personally vote for > the WIDTH and HEIGHT attributes to the > tag, because they have such a salutary effect > on the swift and smooth formatting of a page. Since > Chimera does progressive rendering now, that might be > worth thinking about. I think Chimera already does! Certainly the code is in there, even if it is switched off at the moment. What isn't done yet is to actually scale the image if it doesn't match what the width= and height= attributes say. Some people use this, though it's not the primary attraction of width= and height=. It's also not really a Netscapism any more, since it is part of the HTML3 draft(s). There it says that the Browser can choose whether to scale images or not. Of course, not enough people put width= and height= in their pages. I don't know why, because it's a single command, at least on a Unix machine: wwwimagesize *.html You have to install perl and wwwimagesize first, but Perl is a necessity anyway, and wwwimagesize is a 1-file installation. - -- Erik Corry ehcorry@inet.uni-c.dk https://inet.uni-c.dk/~ehcorry/ ------- Message 49 Received: from roma.axis.se by JIMI.CS.UNLV.EDU id aa27938; 31 Jan 96 5:34 PST Received: from nevyn.axis.se (root@nevyn.axis.se [192.168.2.52]) by roma.axis.se (8.7.1/8.7.1) with ESMTP id OAA00487; Wed, 31 Jan 1996 14:33:54 +0100 (MET) Received: from axis.se (jh@localhost [127.0.0.1]) by nevyn.axis.se (8.7.1/8.7.1) with ESMTP id OAA20719; Wed, 31 Jan 1996 14:33:53 +0100 (MET) Message-Id: <199601311333.OAA20719@nevyn.axis.se> X-Mailer: exmh version 1.6.5 12/11/95 To: John Kilburg Cc: Chimera Hacker List Subject: Re: bgcolor In-reply-to: Your message of "Tue, 30 Jan 1996 11:47:01 PST." <199601302003.VAA26947@kobra.efd.lth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <20712.823095226.1@axis.se> Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jan 1996 14:33:47 +0100 From: Joergen Haegg In message <199601302003.VAA26947@kobra.efd.lth.se> you write: >The rigid "no netscapisms" stance is probably a bad one. How about >"maybe netscapisms" if it is very convienent or the list thinks >the feature is very useful? Well, I don't think it's such a bad idea. Chimera is good at showing non-standard features in HTML. :-) And it wouldn't hurt to have some WWW-reader that doesn't follow Netscapes attempt to control HTML, but instead follows the standard. Just my opinion, I suppose this could turn into a flame debate. ;-) ------- Message 50 Received: from haymarket.ed.ac.uk by JIMI.CS.UNLV.EDU id aa28962; 31 Jan 96 6:35 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 OAA26986 for ; Wed, 31 Jan 1996 14:35:01 GMT Received: from subnode.aiai.ed.ac.uk (scarp) by aiai.ed.ac.uk; Wed, 31 Jan 96 14:34:39 GMT Date: Wed, 31 Jan 96 14:34:38 GMT Message-Id: <4492.9601311434@subnode.aiai.ed.ac.uk> From: Tim Bradshaw To: Chimera Hacker List Subject: Re: bgcolor In-Reply-To: <9601302003.aa11448@uk.ac.ed.festival> References: <9601302003.aa11448@uk.ac.ed.festival> * John Kilburg wrote: > The rigid "no netscapisms" stance is probably a bad one. How about > "maybe netscapisms" if it is very convienent or the list thinks > the feature is very useful? Can I vote for `netscapisms if there is an SGML DTD that could support them' and preferably for HTML3isms? For people like me who use an SGML-based editor (psgml for emacs) to write html, the awful random stuff that netscape puts in are really a pain. Not to mention most of them are just spurious prettiness. Now tables... - --tim ------- Message 51 Received: from concorde.inria.fr by JIMI.CS.UNLV.EDU id aa02711; 31 Jan 96 8:57 PST Received: from fantomas.inria.fr (fantomas.inria.fr [128.93.11.34]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA04493 for ; Wed, 31 Jan 1996 17:57:11 +0100 (MET) Received: (from lasgout@localhost) by fantomas.inria.fr (8.6.10/8.6.6) id RAA26886; Wed, 31 Jan 1996 17:57:04 +0100 Date: Wed, 31 Jan 1996 17:57:04 +0100 Message-Id: <199601311657.RAA26886@fantomas.inria.fr> From: Jean-Marc Lasgouttes To: bug-chimera@unlv.edu Subject: Chimera and accents. Reply-to: Jean-Marc.Lasgouttes@inria.fr A note about the latest chimera alpha: some accents fail to be rendered correctly, in particular è, which is *very* useful in french. Others like é work correctly. I had a quick look in html/html.c, but I do not see why it does not work. Jean-Marc. ------- Message 52 Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa12353; 31 Jan 96 13:19 PST Received: from mark.cs.tu-berlin.de (archi@mark.cs.tu-berlin.de [130.149.20.40]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id WAA20915 for ; Wed, 31 Jan 1996 22:19:40 +0100 From: Ralf Herrmann Received: (archi@localhost) by mark.cs.tu-berlin.de (8.6.12/8.6.9) id WAA14314 for bug-chimera@unlv.edu; Wed, 31 Jan 1996 22:19:36 +0100 Message-Id: <199601312119.WAA14314@mark.cs.tu-berlin.de> Subject: Re: Chimera and accents. (fwd) To: bug-chimera@unlv.edu Date: Wed, 31 Jan 1996 22:19:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII archi writes: From archi Wed Jan 31 22:19:07 1996 From: Message-Id: <199601312116.WAA14282@mark.cs.tu-berlin.de> Subject: Re: Chimera and accents. To: Jean-Marc.Lasgouttes@inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Jan 1996 22:16:00 +0100 (MET) Cc: bug-chimera In-Reply-To: <199601311657.RAA26886@fantomas.inria.fr> from "Jean-Marc Lasgouttes" at Jan 31, 96 05:57:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Jean-Marc, > > A note about the latest chimera alpha: some accents fail to be > rendered correctly, in particular è, which is *very* useful in > french. Others like é work correctly. I had a quick look in > html/html.c, but I do not see why it does not work. > I have made the same observations for some german letters, e.g. ö. That does not look very fine :( Greetings, Ralf | Ralf Herrmann | Technische Universitaet Berlin Fachbereich Informatik | | Klopstockstr. 21 | Email : archi@cs.tu-berlin.de | | 14163 Berlin | WWW : https://www.cs.tu-berlin.de/~archi/ | | Tel.: 802 71 54 | IRC : archi on #berlin, #kreuzberg, #erlangen | | Ralf Herrmann | Technische Universitaet Berlin Fachbereich Informatik | | Klopstockstr. 21 | Email : archi@cs.tu-berlin.de | | 14163 Berlin | WWW : https://www.cs.tu-berlin.de/~archi/ | | Tel.: 802 71 54 | IRC : archi on #berlin, #kreuzberg, #erlangen | ------- End of Forwarded Messages