From owner-png-list@dworkin.wustl.edu Thu Feb 1 00:28:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id AAA15025 for ; Thu, 1 Feb 1996 00:28:15 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA19214 for png-list-outgoing; Thu, 1 Feb 1996 00:29:59 -0600 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA19208 for ; Thu, 1 Feb 1996 00:29:55 -0600 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id WAA28485 for ; Wed, 31 Jan 1996 22:27:44 -0800 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jan 1996 22:28:06 -0800 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: PNG draft 0.93 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > - In section 18, credits, should Glenn, Chris and/or Dave be included as > contributing editors? (I've forgotten who wrote the gamma and color > tutorials, but you said you and Glenn had worked on 0.93 together.) I'm > making a distinction between spec "authors" (i.e., those who helped create > the PNG concept) and spec writer/editors (those who actually wrote it all > down and edited it into this draft). I wrote the gamma section; Chris did the colour section. I think that makes us authors of the spec, but we're already listed as such. I think "editor" should be reserved for the people who actually edited the mass of text into something cohesive; I wouldn't call myself an editor. I think the confusion is about the meaning of "author". Is a PNG "author" one of the people who created the ideas embodied in the spec, or one of the people who wrote the document describing it? And do we want to distinguish between those two? Currently, the list of authors describes (within some threshold) the people who contributed the ideas and discussion. The people who wrote the document are probably a subset of the discussion-people, so naming the former group doesn't leave out any one who wrote stuff (unless there's someone I'm overlooking, which is quite possible). We can have separate lists of "people who discussed" and "people who wrote" if we want, but I don't see any burning need for that. Listing "people who contributed" is good enough for me. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 01:53:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id BAA15613 for ; Thu, 1 Feb 1996 01:53:00 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA19881 for png-list-outgoing; Thu, 1 Feb 1996 01:54:46 -0600 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id BAA19876 for ; Thu, 1 Feb 1996 01:54:40 -0600 Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Thu, 1 Feb 96 02:51:33 -0500 (EST) Message-Id: Date: Thu, 1 Feb 96 02:51:29 -0500 (EST) From: smar@reptiles.org (Smarasderagd) To: png-list@dworkin.wustl.edu Subject: Re: MPNG prediction Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'm dubious about trying to handle the same types of movie stuff that MPEG has to worry about. MPEG movies of any length are awfully big already. How much larger would a losslessly encoded movie clip be? Most people aren't going to be able to view them progressively... Now there's an idea. If we use 3D interlacing, the viewer can see an initial, crude, jerky version of the animation that gets smoother as more bits come in. I don't know if VRML uses voxel maps, but it might come in handy for them too. Apologies if this has been suggested already. It doesn't square with the requirement for seekability, but for web and other network uses it might be very useful. :;SD:; ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 03:10:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id DAA16163 for ; Thu, 1 Feb 1996 03:10:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id DAA20537 for png-list-outgoing; Thu, 1 Feb 1996 03:12:35 -0600 Received: from kobra.efd.lth.se (kobra.efd.lth.se [130.235.48.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id DAA20531 for ; Thu, 1 Feb 1996 03:12:29 -0600 Received: from efd.lth.se (d89cb@elg-4 [130.235.49.14]) by kobra.efd.lth.se (8.6.11/8.6.11) with ESMTP id KAA11141 for ; Thu, 1 Feb 1996 10:10:18 +0100 Message-Id: <199602010910.KAA11141@kobra.efd.lth.se> x-mailer: exmh version 1.6 4/21/95 to: PNG List subject: Re: MPNG prediction in-reply-to: Your message of "Wed, 31 Jan 1996 17:02:07 PST." mime-version: 1.0 content-type: application/pgp; format=mime; x-action=signclear; x-originator=83612DC7 content-transfer-encoding: 7bit Date: Thu, 01 Feb 1996 10:10:16 +0100 From: Christian Brunschen Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii In message , Dave Martindale writes: > Mark wrote: > >Another little complication to consider is interlacing. Real digitized vide > o > >has fields, not frames, where there are even and odd fields. It is not > >correct to put two fields together to make a frame, since they are offset in > > >time as well as space. (In 3D, the edge-on appearance of the horizontal lin > es > >is a checkerboard of dots.) So there ought to be a way to specify at least > > >vertical offsets of successive frames, as well as time offsets. > > Don't forget variable frame rate, perhaps within a single MPNG sequence. > > A great deal of stuff available in video form is really transferred from > a 24 FPS original medium (film) to 30 FPS video using a field-replication > pattern called "3/2 pulldown". In this case, you really want the conversion > from video to digital form to figure out the 3/2 pulldown sequence and discar > d > the duplicated fields, and merge the two adjacent fields that came from a > single film frame back into a single digital frame, since the two fields *are > * > coincident in time. This is non-trivial, particularly if any editing was > done in the video domain, but outside the scope of a digital image format. > > However, it *does* mean that support high-quality transfers into the > digital realm, you need to support: Um, you might wish to remember that 30 frames/sec is not ubiquitous in TV either: the PAL and SECAM systems, used widely in, for instance, Europe, have higher resolution per frame, but show 25 frames (50 fields) per second. Why limit it to a certain range of frame rates at all ? > > 1) 24 distinct frames/sec, with all pixels being replaced each frame > (for material originated on film) > > 2) 30 distinct frames/sec (for stuff originated on film at 30 FPS because > it was destined for video) or, 25, for ouside the US > > 3) 60 distinct fields/sec, where each field contains only the even or odd > scanlines, and so you probably only replace half the pixels on the > screen each update (for stuff captured via a proper NTSC video camera) or 50, when outside the US, from PAL video > > 4) a variety of lower frame rates and lower resolutions for non-standard > "video" cameras like a Quickcam, frame grabbing only every other > field from a video source, computer-generated animation, etc. Why have it limited at all ? Make it arbitrary, a floating-point number; then you can store whatever you like, at any temporal resolution you want. The 'store only odd/even lines' stuff can be handled by storing images with every other line completely transparent --- so that, when composited on top of the previous frame only those lines containing new information are updated. Easy, no? Also, it would be nice to be able to store different frame rates -- as in, 'it was recorded at this frame rate, but should be displayed at this frame rate' .... > > And you may want to switch from one mode to the other within a sequence, sinc > e > you can have (for example) material that cuts between film-originated and > video-originated images. > > My head hurts thinking about it. > > Dave > > > > ------------------------------------------------------------ > To find out more about the mailing list server, send mail to > png-list-request@dworkin.wustl.edu > with the word "help" (and nothing else) in the message body. > // Christian Brunschen - -- #include -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBMRCDdb2M1u2DYS3HAQEfsAIAleBrpNq4lfL0cvVrkAjeQA5FLgvf8vSM gxBxXZFgNdc5U0y1VanrS/6QOfbRZri3zEzqJ9fWJZ8GtIJgNJDUKg== =L1j2 -----END PGP SIGNATURE----- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 05:57:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id FAA17528 for ; Thu, 1 Feb 1996 05:57:10 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA21828 for png-list-outgoing; Thu, 1 Feb 1996 05:59:11 -0600 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA21822 for ; Thu, 1 Feb 1996 05:59:07 -0600 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id EAA05141; Thu, 1 Feb 1996 04:56:57 -0700 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199602011156.EAA05141@enel.ucalgary.ca> Subject: Re: MPNG prediction To: png-list@dworkin.wustl.edu Date: Thu, 1 Feb 1996 04:56:55 -0700 (MST) In-Reply-To: from "Smarasderagd" at Feb 1, 96 02:51:29 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List It was written (re MPNG): > If we use 3D interlacing, the viewer can see an initial, crude, jerky > version of the animation that gets smoother as more bits come in. I > don't know if VRML uses voxel maps, but it might come in handy for them > too. We want to keep in mind that this isn't necessarily an animation format, but a general multi-image format. It, like PNG, should be serially writable and decodable. In this regard, I think interlacing ala PNG could be useful. The only reason not to have progressive resolution movies would be that they would be larger than non-progressive versions. This isn't necessarily a reason not to have them though. It would allow the decoder to decode the smaller versions of the frame (ie the initial passes), and then if it was falling behind on the frames, it could skip over the final passes to start on the next frames. With this in mind, I think we should allow for the potential of animation with synchronized audio and/or text or other information (whether for storing digital camera input (once the encoder is fast enough :) or for synthetic image generation), but this should not be the initial goal. We should start with a simple multi-image PNG extension that is designed in such a way to ALLOW these future extensions, but not necessarily define them all at once. I have been thinking that the fields/frame rate question is sort of not important. What I envision, rather than doing things with transparency, is to do it with a new filter type. Just like we defined filter type 0 to work for regular PNG images, we can have filter type 1 to work on sequential images, using differences from previous frames to handle the encoding. The image itself would still be structured like a PNG image, with filter type 0 or 1 on a per-frame basis, and the sub-filter type on a per-scanline basis. If filter type 0 was used, this would be equivalent to a regular PNG image, or an MPEG I frame (ie no temporal dependencies). Filter type 1 would be like a P frame (differencing from the previous frame). For filter type 1 we could have for each scanline: none - no differencing for the pixel sub - difference from the same pixel on the previous frame 3d paeth - minimum difference of the 9 adjacent pixels in previous frame up - difference from pixel above the current pixel in prev. frame down - difference from pixel below the current pixel in prev. frame left - difference from pixel left of the current pixel in prev. frame right - difference from pixel right of the current pixel in prev. frame If we really wanted to use the motion vector idea from MPEG, we could have a whole slew of sub-types that were combinations of up, right, left, down, with multiple offsets in either direction. I'm not sure if this would be profitable on a per-scanline basis, compared to the block MPEG approach. In any case, using the plain 'sub' filter could allow very efficient encoding of fields in a NTSC or other interlaced scheme, since alternate scanlines would be all zeros (ie no change). This would also handle the 3/2 pulldown issue without extra effort. An alternative would be to make this a special case of Adam7 interlacing, but in essence make it only the 7th pass, which gives us every other scanline in the image. As for frame rates, I would think that a chunk describing the time between the current image and the next image, in milliseconds? would be sufficient for movies of presentations or whatever. This time distance would describe all future frame distances until another such block was found. Its absence would indicate that the images should be displayed as fast as possible. We could use the oFFs chunk from PNG to handle the offset of sub-images inside the MNG image frame relative to the MNG origin (top left). Its absence would indicate that the sub-image should be positioned in the same relative position as the previous oFFs, or at the image origin. This would allow clever applications to set up a background, and then overlay sub-images in various places, without having to encode the entire frame. As for semantics of the starndard PNG chunks, depending on their location, they could refer to the entire stream, or to the sub-image, for example: --- MNG stream --- MNG header (\222MNG\r\n\032\n or whatever) MHDR - total width, total height, maximum bit-depth, maximum color-type PLTE - refers to the total stream, if present, until the next PLTE cHRM, gAMA - refer to total stream, until next occurrence tEXt - refers to the total stream (display at beginning/end/whatever) tIME - last modification time of MNG file IHDR - regular PNG IHDR - image width, height, color type, interlace type, etc. tEXt - text for this frame only (eg closed caption) oFFS - offset from previous offset (if any for this frame only) tRNS - for this frame only cHRM - overrides global cHRM gAMA - overrides global gAMA IDAT - not legal outside IHDR-IEND IDAT IEND - regular PNG IEND oFFs - sets offset for all future frames, relative to origin, until next iOFs - image offset/distance between successive PNG frames AHDR - audio stream header - sampling rate, encoding, channels, language, etc. ADAT ADAT AEND IHDR ... IEND ... MEND --- MNG stream --- Of course, not all combinations of things make sense. It could be possible to have a palette based PNG in a truecolor MNG, to save space since it can be upgraded, but the converse isn't possible. It may be desirable to allow the interlacing of Audio and Image chunks (which would be difficult to show here, but would be handled analagous to the push-based libpng reader). There would need to be distinct chunks between the audio, image, and text, etc. chunks so that there is no mistaking which stream the chunk belongs to, so the main encoder can send chunks as they arrive to the respecive decoders. Just some ideas, late at night. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 09:06:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id JAA19424 for ; Thu, 1 Feb 1996 09:06:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA23739 for png-list-outgoing; Thu, 1 Feb 1996 09:08:08 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA23722 for ; Thu, 1 Feb 1996 09:08:01 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.1/8.7.1) id JAA13205 for png-list@dworkin.wustl.edu; Thu, 1 Feb 1996 09:05:49 -0600 (CST) From: Peter da Silva Message-Id: <199602011505.JAA13205@Starbase.NeoSoft.COM> Subject: Re: MPNG prediction To: png-list@dworkin.wustl.edu Date: Thu, 1 Feb 1996 09:05:48 -0600 (CST) In-Reply-To: from "Dave Martindale" at Jan 31, 96 05:02:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > And you may want to switch from one mode to the other within a sequence, since > you can have (for example) material that cuts between film-originated and > video-originated images. What you really want is an event stream that you can attach fields and frames to. That will also handle the sound synchronization as well. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 10:21:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA20499 for ; Thu, 1 Feb 1996 10:21:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA24713 for png-list-outgoing; Thu, 1 Feb 1996 10:23:30 -0600 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA24708 for ; Thu, 1 Feb 1996 10:23:24 -0600 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id IAA07861 for ; Thu, 1 Feb 1996 08:21:07 -0800 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 1996 08:21:31 -0800 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: MPNG prediction Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Christian wrote: >Um, you might wish to remember that 30 frames/sec is not ubiquitous in TV >either: >the PAL and SECAM systems, used widely in, for instance, Europe, have higher >resolution per frame, but show 25 frames (50 fields) per second. > >Why limit it to a certain range of frame rates at all ? Well, I wasn't trying to be comprehensive, just give examples of possible headaches. The film/video conversion problem is much simpler in Europe, since they just speed up or slow down the material by 4% when converting between film and video - there are no extra fields. >The 'store only odd/even lines' stuff can be handled by storing images with >every other line completely transparent --- so that, when composited on top >of the previous frame only those lines containing new information are updated. >Easy, no? Well, yes, if you define the format so that each frame is composited on top of the one before it. But in order to have "I frames", some of the data would have to be duplicated. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 10:56:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA20707 for ; Thu, 1 Feb 1996 10:56:25 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA25314 for png-list-outgoing; Thu, 1 Feb 1996 10:58:19 -0600 Received: from llyene.jpl.nasa.gov (llyene.jpl.nasa.gov [128.149.75.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA25304 for ; Thu, 1 Feb 1996 10:58:12 -0600 Received: from quest.jpl.nasa.gov (quest.jpl.nasa.gov [128.149.75.43]) by llyene.jpl.nasa.gov (8.6.8/8.6.6) with SMTP id IAA17904 for ; Thu, 1 Feb 1996 08:56:26 -0800 Received: by quest.jpl.nasa.gov (NX5.67f2/NX3.0S) id AA06666; Thu, 1 Feb 96 08:55:18 -0800 Message-Id: <9602011655.AA06666@quest.jpl.nasa.gov> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Mark Adler Date: Thu, 1 Feb 96 08:55:16 -0800 To: PNG List Subject: Re: MPNG prediction References: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave wrote: >> In this case, you really want the conversion >> from video to digital form to figure out the 3/2 pulldown sequence and >> discard the duplicated fields, and merge ... Though this isn't a job for the format. >> My head hurts thinking about it. The format should simply allow arbitrary temporal spacing between images, as well as spatial offsets for interlacing. I think that would cover everything. mark ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 1 14:37:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id OAA23263 for ; Thu, 1 Feb 1996 14:37:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA29384 for png-list-outgoing; Thu, 1 Feb 1996 14:39:05 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA29379 for ; Thu, 1 Feb 1996 14:38:58 -0600 Date: Thu, 1 Feb 96 20:32:41 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: Zlib and Deflate documentation Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602012032.aa26884@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > From: "Keith S. Pickens" > Subject: Re: Zlib and Deflate documentation > } > } Do you also want a set for swrinde? I can tar up the entire html page > } together with the docs and upload if you want. > } > It would seem like a good idea to have them on swrinde. > You've got it. zlib-node-1feb.* is a tar file containing the page and docs. Read the *.txt file. After you install it, we should be able to browse starting with . BTW the drafts are now in the hands of the Internet-Draft editor. She only wanted the *00.txt files, not the PostScript or HTML, so the latter will only be available in the png and zlib archives, not the IETF archives, for the time being. If you have nits to pick with the documents, let me know and I'll incorporate your comments in the RFC versions, after the necessary aging period as Internet-Drafts. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 2 11:43:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id LAA02507 for ; Fri, 2 Feb 1996 11:43:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28655 for png-list-outgoing; Fri, 2 Feb 1996 11:43:23 -0600 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA28649 for ; Fri, 2 Feb 1996 11:43:18 -0600 Received: from tbd2.arl.mil by wugate.wustl.edu (8.6.12/8.6.11) with SMTP id LAA07296 for ; Fri, 2 Feb 1996 11:41:01 -0600 Received: by TBD2.ARL.MIL id aa22360; 2 Feb 96 12:38 EST Date: Fri, 2 Feb 96 17:31:25 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: second new alpha-channel image uploaded Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602021731.aa20550@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Sat, 27 Jan 1996 22:22:02 -0600 (CST) > From: Cave Newt > Subject: second new alpha-channel image uploaded > > I'm working on a more complex/less contrived example based on the same > > Escher print and should have it ready by tomorrow. > > It is now done and uploaded to swrinde as AlphaSnakes.png, final resting > place /pub/png-group/images/. This one is also quite big, unfortunately > (669k). > This new image motivated me to fix up some problems with ARL Viewpng for SGI. I've loaded new versions of Viewpng, for SGI machines running IRIX 4.0.5 or IRIX 5.3, on //tcg. It does the LinuxSnakes and AlphaSnakes images properly, and displays images about 10x faster than the previous version. On the indigo2, about 15 seconds to decode and display AlphaSnakes twice (once composited against the background grabbed from the screen and once against a supplied bKGD value), including just a fraction of a second to blast each interlace pass onto the screen. There's a JPEG (quality 25) screen shot of the result in and the new viewpng 960202.beta source and executables are in . Greg, if you redo the image sometime, please add a bKGD chunk. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 2 15:00:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id PAA06356 for ; Fri, 2 Feb 1996 15:00:13 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA01947 for png-list-outgoing; Fri, 2 Feb 1996 15:01:58 -0600 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA01939 for ; Fri, 2 Feb 1996 15:01:53 -0600 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id NAA11708; Fri, 2 Feb 1996 13:59:29 -0700 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199602022059.NAA11708@enel.ucalgary.ca> Subject: Re: second new alpha-channel image uploaded To: png-list@dworkin.wustl.edu Date: Fri, 2 Feb 1996 13:59:28 -0700 (MST) In-Reply-To: <9602021731.aa20550@TBD2.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 2, 96 05:31:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > There's a JPEG (quality 25) screen shot of the result in > > and the new viewpng 960202.beta source and executables are in > . I'm curious as to what the actual background color of the image is? I'm trying to determine if ImageMagick 2.6.3 supports the alpha channel or not. When I load AlphaSnakes.png it appears on a gray background, which matches the window borders and such, but at the same time, Greg could have put it on such a background to match what many WWW browsers use for a background color. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 2 15:57:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id PAA06880 for ; Fri, 2 Feb 1996 15:57:16 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA04392 for png-list-outgoing; Fri, 2 Feb 1996 15:59:20 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA04387 for ; Fri, 2 Feb 1996 15:59:15 -0600 Date: Fri, 2 Feb 96 21:52:30 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: second new alpha-channel image uploaded Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602022152.aa02283@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > From: Andreas Dilger > Subject: Re: second new alpha-channel image uploaded > > I'm curious as to what the actual background color of the image is? black ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 2 20:14:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id UAA08379 for ; Fri, 2 Feb 1996 20:14:00 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA23723 for png-list-outgoing; Fri, 2 Feb 1996 20:16:06 -0600 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA23718 for ; Fri, 2 Feb 1996 20:16:02 -0600 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.6.12/8.6.4) with ESMTP id UAA04077 for ; Fri, 2 Feb 1996 20:08:50 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id UAA27650 for png-list@dworkin.wustl.edu; Fri, 2 Feb 1996 20:13:00 -0600 (CST) Date: Fri, 2 Feb 1996 20:13:00 -0600 (CST) From: Cave Newt Message-Id: <199602030213.UAA27650@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: second new alpha-channel image uploaded Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List [AlphaSnakes.png] glenn> Greg, if you redo the image sometime, please add a bKGD chunk. OK. (Conditional promises are so easy to keep. :-) ) andreas> I'm curious as to what the actual background color of the image is? glenn> black I'll take that as a compliment of my skill at image-editing. The background color if you leave out the alpha channel is... white. So ImageMagick is apparently doing the right thing. (And it would be version 3.6.3, I think, not 2.6.3.) Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Feb 3 07:20:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id HAA13333 for ; Sat, 3 Feb 1996 07:20:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA03605 for png-list-outgoing; Sat, 3 Feb 1996 07:22:31 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA03600 for ; Sat, 3 Feb 1996 07:22:26 -0600 Date: Sat, 3 Feb 96 13:15:12 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: second new alpha-channel image uploaded Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602031315.aa08618@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Fri, 2 Feb 1996 20:13:00 -0600 (CST) > From: Cave Newt > Subject: Re: second new alpha-channel image uploaded > [AlphaSnakes.png] > > glenn> black > > I'll take that as a compliment of my skill at image-editing. The > background color if you leave out the alpha channel is... > > white. I stand corrected. I had done an "od -c" on the decompressed IDATs but failed to notice that you were using the sub filter to make all those zeroes... 0000000 001 377 377 377 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 5 23:04:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id XAA01896 for ; Mon, 5 Feb 1996 23:04:49 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA22309 for png-list-outgoing; Mon, 5 Feb 1996 23:06:30 -0600 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA22304 for ; Mon, 5 Feb 1996 23:06:19 -0600 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.6.12/8.6.4) with ESMTP id WAA17522 for ; Mon, 5 Feb 1996 22:58:52 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id XAA17055 for png-list@dworkin.wustl.edu; Mon, 5 Feb 1996 23:03:17 -0600 (CST) Date: Mon, 5 Feb 1996 23:03:17 -0600 (CST) From: Cave Newt Message-Id: <199602060503.XAA17055@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: hex dumps Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: > I stand corrected. I had done an "od -c" on the decompressed IDATs but > failed to notice that you were using the sub filter to make all those > zeroes... > 0000000 001 377 377 377 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > * This is somewhat off-topic, but if anyone out there is interested in a hex dumper, sort of a cross between od and DOS DEBUG, send me e-mail. I've got source code for a nice one that does something like this: 00000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 .PNG........IHDR 00010 00 00 01 f8 00 00 02 2d 08 06 00 00 01 a2 34 58 .......-......4X 00020 e8 00 00 00 04 67 41 4d 41 00 00 af c8 37 05 8a .....gAMA....7.. (That's actually "hd -o -X" output; there are options to customize hex vs. decimal vs. octal, leading zeros, etc.) I really detest od... Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 6 07:25:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id HAA05268 for ; Tue, 6 Feb 1996 07:25:57 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA26691 for png-list-outgoing; Tue, 6 Feb 1996 07:28:03 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA26686 for ; Tue, 6 Feb 1996 07:27:49 -0600 Received: from afs.mcc.ac.uk (actually cguhpb.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Tue, 6 Feb 1996 13:23:25 +0000 From: lilley Message-Id: <27101.9602061323@afs.mcc.ac.uk> Subject: Re: hex dumps To: png-list@dworkin.wustl.edu Date: Tue, 6 Feb 1996 13:23:19 +0000 (GMT) In-Reply-To: <199602060503.XAA17055@ellis.uchicago.edu> from "Cave Newt" at Feb 5, 96 11:03:17 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > This is somewhat off-topic, but if anyone out there is interested in a > hex dumper [...] > I really detest od... On unix/X I use xv as a hex dumper (with a scroll bar). -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 6 15:05:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id PAA14529 for ; Tue, 6 Feb 1996 15:05:17 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA06558 for png-list-outgoing; Tue, 6 Feb 1996 15:07:38 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA06553 for ; Tue, 6 Feb 1996 15:07:34 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA16796; Tue, 6 Feb 1996 21:04:51 GMT Date: Tue, 6 Feb 1996 21:04:51 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9602062104.AA16796@siesta.cs.wustl.edu> To: png-list@dworkin.wustl.edu Subject: Re: hex dumps Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg said: > This is somewhat off-topic, but if anyone out there is interested in a > hex dumper, sort of a cross between od and DOS DEBUG, send me e-mail. > I've got source code for a nice one that does something like this: > > 00000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 .PNG........IHDR > 00010 00 00 01 f8 00 00 02 2d 08 06 00 00 01 a2 34 58 .......-......4X > 00020 e8 00 00 00 04 67 41 4d 41 00 00 af c8 37 05 8a .....gAMA....7.. Heh, this is one wheel that gets reinvented quite often, I think. See http://www.cs.wustl.edu/~amc/utils/#binhex It has a companion, hexbin, which converts the other way (useful for small-scale binary editing). AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 7 08:43:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id IAA21889 for ; Wed, 7 Feb 1996 08:43:34 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA21499 for png-list-outgoing; Wed, 7 Feb 1996 08:44:00 -0600 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA21494 for ; Wed, 7 Feb 1996 08:43:52 -0600 Received: from 199.3.232.2.phoenix.net (dial119.phoenix.net [199.3.234.154]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id IAA07130 for ; Wed, 7 Feb 1996 08:40:31 -0600 Message-Id: <199602071440.IAA07130@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-list@dworkin.wustl.edu Date: Wed, 7 Feb 1996 08:41:03 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MPNG prediction Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Folks, the desire of the VRML folks for a multiple-image MPNG has come up once again. Here's a message from the VRML list. The following is from Chris Marrin: On Feb 7, 12:26am, Tim Wegner wrote: > It would help the PNG team to know what the VRML requirements are > for a meta-PNG multiple image format. Excellent. I look forward to hearing of progress in this area. The problems a meta-PNG format could solve would include: - Multiple images in a file - Some header information giving size, number of images, normal play rate, etc. - Audio in a chunk (in some popular format) - Support for alpha (hopefully free since PNG supports this) - Possibly some sort of streaming capability. I think this is just a matter of interleaving audio and video and enough info to be able to decode each frame on the fly. Any or all of these would make PNG the premiere image format for VRML! -- chris marrin Silicon http://webspace.sgi.com/moving-worlds (415) 933-5367 Graphics http://reality.sgi.com/employees/cmarrin_engr/ cmarrin@sgi.com Inc. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 7 13:55:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id NAA27038 for ; Wed, 7 Feb 1996 13:55:34 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA27376 for png-list-outgoing; Wed, 7 Feb 1996 13:57:54 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA27367 for ; Wed, 7 Feb 1996 13:57:49 -0600 Date: Wed, 7 Feb 96 19:52:04 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@dworkin.wustl.edu Subject: [lnelson441: speaker invites - Atlanta - 03/18/96] Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602071952.aa17601@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Anyone want to present PNG at this meeting? ----- Forwarded message # 1: From: lnelson441@aol.com (LNelson441) Newsgroups: comp.compression Subject: speaker invites - Atlanta - 03/18/96 Date: 7 Feb 1996 14:16:03 -0500 Organization: America Online, Inc. (1-800-827-6364) Message-ID: <4fatpj$jka@newsbf02.news.aol.com> I am seeking potential speakers to participate in the image compression breakout sessions of ImageTech...co-sponsored by Georgia Tech and to be held next month in downtown Atlanta. Total obligation would be to present on still image or motion video compression for ~30 minutes and allow ~10 minutes for Q&A. We're very flexible on topics: technology, markets, applications, commercialization, implementation, systems integration, novel "non-PEG" approaches, etc. Please reply ASAP to: Lee Nelson, Chairperson tel: 1-703-893-0744 email: lnelson@omnioffices.com ----- End of forwarded messages ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 7 13:59:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id NAA27047 for ; Wed, 7 Feb 1996 13:59:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA27546 for png-list-outgoing; Wed, 7 Feb 1996 14:02:11 -0600 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA27540 for ; Wed, 7 Feb 1996 14:02:07 -0600 Received: from 199.3.232.2.phoenix.net (dial3.phoenix.net [199.3.234.34]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id NAA23722 for ; Wed, 7 Feb 1996 13:58:47 -0600 Message-Id: <199602071958.NAA23722@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-list@dworkin.wustl.edu Date: Wed, 7 Feb 1996 13:59:18 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MPNG prediction Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here's more from the VRML list. Is there any way we could relatively quickly arrive at an MPNG that would be suitable for the VRML folks, without committing any horrible architectural sins we would regret? From: "Gavin Bell" Date sent: Wed, 7 Feb 1996 11:47:25 -0800 To: "Chris Marrin" , twegner@phoenix.net, www-vrml@wired.com Subject: Re: PNG compression On Feb 7, 1:37am, Chris Marrin wrote: > Excellent. I look forward to hearing of progress in this area. The > problems a meta-PNG format could solve would include: - Multiple > images in a file -- all the same size would be fine. > - Some header information giving size, number of images, normal play > rate, etc. Play rate should be a float like 30.0 or 24.4 to give rate at which the frames were recorded. > - Audio in a chunk (in some popular format) I actually don't think that's necessary. Two URL's (one for the images and one for the sound) will work and is simpler. > - Support for alpha (hopefully free since PNG supports this) Yes, that's what is missing today. > - Possibly some sort of streaming capability. I think this is just > a matter of interleaving audio and video and enough info to be able > to decode each frame on the fly. Again, I'd leave out the audio. Good implementations should be able to stream from two sources, assuming there's enough bandwidth (which there won't be). I think just putting the frames in order would be sufficient. -- --Gavin Bell (gavin@sgi.com, (415)933-1024) My home page: http://reality.sgi.com/employees/gavin/ WebSpace Info: http://www.sgi.com/Products/WebFORCE/WebSpace Inventor Info: http://www.sgi.com/Technology/Inventor.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 7 16:54:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id QAA29550 for ; Wed, 7 Feb 1996 16:54:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA01243 for png-list-outgoing; Wed, 7 Feb 1996 16:56:17 -0600 Received: from schubert.cs.colostate.edu (schubert.cs.colostate.edu [129.82.102.118]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA01235 for ; Wed, 7 Feb 1996 16:56:11 -0600 Received: (from kettler@localhost) by schubert.cs.colostate.edu (8.7.1/8.7.1) id PAA07351 for png-list@dworkin.wustl.edu; Wed, 7 Feb 1996 15:53:22 -0700 (MST) From: neal kettler Message-Id: <199602072253.PAA07351@schubert.cs.colostate.edu> Subject: Re: MPNG prediction To: png-list@dworkin.wustl.edu Date: Wed, 7 Feb 1996 15:53:22 -0700 (MST) In-Reply-To: <199602071958.NAA23722@mail.phoenix.net> from "Tim Wegner" at Feb 7, 96 01:59:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > - Some header information giving size, number of images, normal play > > rate, etc. > > Play rate should be a float like 30.0 or 24.4 to give rate at which > the frames were recorded. Better yet, an int holding the number of usec's for each frame. That way a still scene need only take 1 frame. > > - Audio in a chunk (in some popular format) > > I actually don't think that's necessary. Two URL's (one for the > images and one for the sound) will work and is simpler. For VRML this might be better, but this is not sufficient for most other apps. The audio needs to be somehow interleaved with the data. Maybe the audio for each frame should be stored just before that frame. Otherwise it's impossible to keep audio synchronised with video. (It would look like a poorly dubbed kung-fu movie if you're really lucky) -- ========= Neal Kettler < kettler@cs.colostate.edu / nak@etl.noaa.gov > ======== --- And then, suddenly and without warning: NOTHING HAPPENED! --- home page - http://www.vis.colostate.edu/~user1209/ ======< After three days without programmming, life becomes meaningless >====== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 7 17:02:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id RAA29726 for ; Wed, 7 Feb 1996 17:02:31 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01402 for png-list-outgoing; Wed, 7 Feb 1996 17:05:13 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01393 for ; Wed, 7 Feb 1996 17:05:05 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.1/8.7.1) id RAA14109 for png-list@dworkin.wustl.edu; Wed, 7 Feb 1996 17:02:18 -0600 (CST) From: Peter da Silva Message-Id: <199602072302.RAA14109@Starbase.NeoSoft.COM> Subject: Re: MPNG prediction To: png-list@dworkin.wustl.edu Date: Wed, 7 Feb 1996 17:02:18 -0600 (CST) In-Reply-To: <199602072253.PAA07351@schubert.cs.colostate.edu> from "neal kettler" at Feb 7, 96 03:53:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > For VRML this might be better, but this is not sufficient for most > other apps. The audio needs to be somehow interleaved with the data. > Maybe the audio for each frame should be stored just before that frame. > Otherwise it's impossible to keep audio synchronised with video. (It would > look like a poorly dubbed kung-fu movie if you're really lucky) Again, you need to treat it as an event stream. You have a sequence of audio streams and sequences of frames, each tagged with the initial timestamp and the playback rate. That gives you a regular set of synchronization points, and allows you to do a cheesy file for VRML with just one set of timestamps if you really want. It also means that you can take a slice starting at a sync point and you know you're not depending on anything before that. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 8 23:19:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id XAA18486 for ; Thu, 8 Feb 1996 23:19:03 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA23825 for png-list-outgoing; Thu, 8 Feb 1996 23:18:35 -0600 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA23818 for ; Thu, 8 Feb 1996 23:18:25 -0600 Received: from 199.3.232.2.phoenix.net (dial119.phoenix.net [199.3.234.154]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id XAA29759 for ; Thu, 8 Feb 1996 23:14:41 -0600 Message-Id: <199602090514.XAA29759@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-list@dworkin.wustl.edu Date: Thu, 8 Feb 1996 23:15:22 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: PNG MIME type Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Is there an official (or an unofficial) MIME type for PNG? If so, I'd appreciate someone reminding me what it is. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 9 05:42:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id FAA22189 for ; Fri, 9 Feb 1996 05:42:10 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA27384 for png-list-outgoing; Fri, 9 Feb 1996 05:43:27 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA27371 for ; Fri, 9 Feb 1996 05:42:05 -0600 Received: from afs.mcc.ac.uk (actually cguhpb.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Fri, 9 Feb 1996 11:36:03 +0000 From: lilley Message-Id: <12485.9602091135@afs.mcc.ac.uk> Subject: Re: PNG MIME type To: png-list@dworkin.wustl.edu Date: Fri, 9 Feb 1996 11:35:54 +0000 (GMT) In-Reply-To: <199602090514.XAA29759@mail.phoenix.net> from "Tim Wegner" at Feb 8, 96 11:15:22 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Is there an official (or an unofficial) MIME type for PNG? If so, I'd > appreciate someone reminding me what it is. image/x-png (so that is what server should be sending) once registration is complete, it will be image/png (so browsers should accept both). -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 9 05:56:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id FAA22247 for ; Fri, 9 Feb 1996 05:56:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA27472 for png-list-outgoing; Fri, 9 Feb 1996 05:57:37 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA27467 for ; Fri, 9 Feb 1996 05:57:34 -0600 Date: Fri, 9 Feb 96 11:52:58 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG MIME type Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602091152.aa03135@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > From: Tim Wegner > Subject: PNG MIME type > Is there an official (or an unofficial) MIME type for PNG? If so, I'd > appreciate someone reminding me what it is. for now, it is "image/x-png". As a part of the RFC process with PNG 1.0 we will apply to the IANA for "image/png". For now, png images must be delivered by mailers and web servers as "image/x-png", but browsers can already be set up to recognize "image/png" in anticipation of IANA approval, which is probably still months away. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 12 13:48:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id NAA11413 for ; Mon, 12 Feb 1996 13:47:59 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA02133 for png-list-outgoing; Mon, 12 Feb 1996 13:49:05 -0600 Received: from dub-img-2.compuserve.com (dub-img-2.compuserve.com [198.4.9.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA02115 for ; Mon, 12 Feb 1996 13:48:59 -0600 Received: by dub-img-2.compuserve.com (8.6.10/5.950515) id OAA01952; Mon, 12 Feb 1996 14:45:22 -0500 Date: 12 Feb 96 14:43:54 EST From: Owen Mortensen To: ngf , Glenn Randers-Pehrson ARL-WTD-TED-TIB Subject: Re: PNG MIME type Message-ID: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: >For now, png >images must be delivered by mailers and web servers as "image/x-png", >but browsers can already be set up to recognize "image/png" in anticipation >of IANA approval, which is probably still months away. Is there any way we can speed up the IANA approval? I've heard that process is at a standstill. Anyone know anything certain? Thanks, Owen ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 12 15:07:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id PAA12239 for ; Mon, 12 Feb 1996 15:07:01 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA08739 for png-list-outgoing; Mon, 12 Feb 1996 15:09:58 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA08727 for ; Mon, 12 Feb 1996 15:09:52 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id QAA08757 for ; Mon, 12 Feb 1996 16:03:06 -0500 (EST) To: PNG List Subject: Re: PNG MIME type In-reply-to: Your message of 12 Feb 96 14:43:54 EST Date: Mon, 12 Feb 1996 16:03:06 -0500 Message-ID: <8755.824158986@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Owen writes: > Is there any way we can speed up the IANA approval? I've heard that process > is at a standstill. Anyone know anything certain? The last I heard was they had told us to go away until we had a non-draft PNG spec. I assume that once we have a document that says "W3C Tech Report" with no draft verbiage at the top, we can kick-start the process again. Chris, aren't you on the ietf-types mail list? What's your perception of what it will take to get image/png officially registered? BTW, today I read an interesting assertion by a Netscape engineer, who was trying to justify the fact that Netscape 2.0 sends "Accept: image/pjpeg" when there is no such registered media type. Scott Furman quoth on the IJG mail list: : It is true that Netscape 2.0 sends "image/pjpeg" as part of its HTTP Accept : headers, which is not (yet) an IANA-registered type. However, recall that, : unlike MIME, HTTP is not restricted to IANA types. The HTTP 1.0 spec has : this to say on the topic: : : Although HTTP allows the use of non-registered media types, such usage : must not conflict with the IANA registry. Data providers are strongly : encouraged to register their media types with IANA via the : procedures outlined in RFC 1590. The "(yet)" is disingenuous, because AFAIK they have not even *submitted* a registration request for image/pjpeg. (Anyone know how to check that? I would like to oppose it if they have ... but that's off-topic for png-list.) Anyway, if one cared to follow Netscape's lead, this reasoning would be sufficient justification to use image/png while awaiting IANA approval. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 12 16:29:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id QAA13784 for ; Mon, 12 Feb 1996 16:29:52 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA10477 for png-list-outgoing; Mon, 12 Feb 1996 16:32:29 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA10470 for ; Mon, 12 Feb 1996 16:32:24 -0600 Date: Mon, 12 Feb 96 22:27:45 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG MIME type Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602122227.aa20742@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > BTW, today I read an interesting assertion by a Netscape engineer, > who was trying to justify the fact that Netscape 2.0 sends > "Accept: image/pjpeg" when there is no such registered media type. > Scott Furman quoth on the IJG mail list: > > :It is true that Netscape 2.0 sends "image/pjpeg" as part of its HTTP Accept > :headers, which is not (yet) an IANA-registered type. However, recall that, I think that one is allowed to "accept" anything at one's own risk. Including "image/pjpeg" or "image/png". But no one is allowed to "send" IANA-unregistered types. (Sending an accept header is OK; that is an "accepting" activity, not a "sending" activity). > : unlike MIME, HTTP is not restricted to IANA types. The HTTP 1.0 spec > : has this to say on the topic: > : > : Although HTTP allows the use of non-registered media types, such usage > : must not conflict with the IANA registry. Data providers are strongly > : encouraged to register their media types with IANA via the > : procedures outlined in RFC 1590. The only way to guarantee that one's usage does not conflict with the IANA registry is to use the "x-" prefix. I think when it says "HTTP allows the use of non-registered media types", it is referring to the use of media types that have the "x-" prefix. I do not believe it should be construed to mean that it is OK to send out files with media type image/pjpeg or image/png prior to these media types being registered. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 12 17:58:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id RAA14740 for ; Mon, 12 Feb 1996 17:58:37 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA11775 for png-list-outgoing; Mon, 12 Feb 1996 18:01:23 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA11769 for ; Mon, 12 Feb 1996 18:01:16 -0600 Received: from afs.mcc.ac.uk (actually cguhpb.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Mon, 12 Feb 1996 23:57:47 +0000 From: lilley Message-Id: <6237.9602122357@afs.mcc.ac.uk> Subject: Re: PNG MIME type To: png-list@dworkin.wustl.edu Date: Mon, 12 Feb 1996 23:57:44 +0000 (GMT) In-Reply-To: <8755.824158986@sss.pgh.pa.us> from "Tom Lane" at Feb 12, 96 04:03:06 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > The last I heard was they had told us to go away until we had a non-draft > PNG spec. I assume that once we have a document that says "W3C Tech > Report" with no draft verbiage at the top, we can kick-start the process > again. > > Chris, aren't you on the ietf-types mail list? What's your perception > of what it will take to get image/png officially registered? Exactly what you said above. Plus, being very active on ietf-types do defusae any criticisms, plus sending the registration on to the next stage after the two week review period. This does npt happen automatically, although the registration RFC implies that it does. > BTW, today I read an interesting assertion by a Netscape engineer, > who was trying to justify the fact that Netscape 2.0 sends > "Accept: image/pjpeg" when there is no such registered media type. > Scott Furman quoth on the IJG mail list: > > : It is true that Netscape 2.0 sends "image/pjpeg" as part of its HTTP Accept > : headers, which is not (yet) an IANA-registered type. However, recall that, > : unlike MIME, HTTP is not restricted to IANA types. The HTTP 1.0 spec has > : this to say on the topic: Yes, it does say that. > : > : Although HTTP allows the use of non-registered media types, such usage > : must not conflict with the IANA registry. Data providers are strongly > : encouraged to register their media types with IANA via the > : procedures outlined in RFC 1590. They are in error. Non-registered media types have an x- in the subtype. The HTTP 1.0 draft says that it is ok to use x- types (which are intended for small-scale experimental use) as a global distribution mechanism. image/pjpeg does not constitute a non-registered type. > The "(yet)" is disingenuous, because AFAIK they have not even *submitted* > a registration request for image/pjpeg. (Anyone know how to check that? > I would like to oppose it if they have ... but that's off-topic for > png-list.) They have not. I subscribe to that list and furthermore have read all the mail list archives right from when it was started. > Anyway, if one cared to follow Netscape's lead, this reasoning would be > sufficient justification to use image/png while awaiting IANA approval. No, servers (and mail senders) should send image/x-png and browsers (and mail readers) should accept both image/x-png and image/png. -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 13 05:53:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id FAA18971 for ; Tue, 13 Feb 1996 05:53:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA19928 for png-list-outgoing; Tue, 13 Feb 1996 05:55:45 -0600 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA19923 for ; Tue, 13 Feb 1996 05:55:38 -0600 Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id ad09296; 12 Feb 96 19:52 GMT Received: from abwillms.demon.co.uk ([158.152.70.175]) by relay-3.mail.demon.net id aa21058; 12 Feb 96 19:44 GMT Received: from abwillms.demon.co.uk by abwillms.demon.co.uk with SMTP id AA824150501 ; Mon, 12 Feb 96 18:41:41 GMT Comments: Authenticated sender is From: "Alaric B. Williams" To: png-list@dworkin.wustl.edu Date: Mon, 12 Feb 1996 18:41:40 +0000 Subject: Re: MPNG prediction Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <824154278.21058.0@abwillms.demon.co.uk> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On 1 Feb 96 at 4:56, Andreas Dilger wrote: > It may be desirable to allow the interlacing of Audio and Image chunks > (which would be difficult to show here, but would be handled analagous > to the push-based libpng reader). There would need to be distinct chunks > between the audio, image, and text, etc. chunks so that there is no mistaking > which stream the chunk belongs to, so the main encoder can send chunks as > they arrive to the respecive decoders. Why not create a superstandard called 'time-streamed network anything' (TSNA) or similar whose job it is to interleave several streams, not really caring much what they are, with the full range of tEXt and zTXt and everything descriptive, then have MPNG as a subformat of this - one of the streams it could use. And audio can go down a seperate stream. The TSNA output would be to a set of functions which would be called and passed some form of access to the next block of data. So, for example, a TSNA stream containing audio and video would call "audio" and pass it a frame's worth of sound, which it would send to the DMA controller for playing, then call "video" and pass it a MPNG frame, which it would display. It would call them at the right moments. The core could be a function called TSNApoll() or similar which wants to be called repeatedly, for example in a loop - the stream handler functions could well just set up the data block for the main loop to handle if need be. TSNA could interleave multiple sound, video, text, direct neural link thought patterns, etc. Regards, ABW ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 13 07:57:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id HAA20066 for ; Tue, 13 Feb 1996 07:57:01 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA20860 for png-list-outgoing; Tue, 13 Feb 1996 07:59:59 -0600 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA20854 for ; Tue, 13 Feb 1996 07:59:55 -0600 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) id IAA18064 for png-list@dworkin.wustl.edu; Tue, 13 Feb 1996 08:56:33 -0500 Message-Id: <199602131356.IAA18064@qnx.com> Subject: BePNG: First BeBox PNG app uploaded! To: png-list@dworkin.wustl.edu (PNG Mailing List) Date: Tue, 13 Feb 1996 08:56:26 -0500 (EST) From: "Chris Herborth" X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Unfortunately, I didn't write it... :-) The author wanted me to post this to the PNG list, so: ---- 8< ---- Article 4014 of comp.sys.be: From: al@crucible.powertools.com (Al Evans) Newsgroups: comp.sys.be Subject: First app uploaded! Date: 8 Feb 1996 14:19:59 -0600 Organization: Powertools, Austin, Texas I just uploaded BePNG to ftp.be.com. I assume it will be available for downloading when somebody gets the time to move it into the 3dParty directory. BePNG displays PNG images. PNG is an "open" graphics format, developed as a response to CompuServe's deciding that people had to license the right to use the GIF format. PNG is much more versatile than GIF, and is often as efficient as JPEG for compression. Converters are readily available for all popular platforms. Hey, I figured it was only fittin' to give precedence to a new graphic format on a new computer! Anyway, it's available in the form of a compiled application and ._rsc file, and also as a self-extracting Mac archive containing Codewarrior 8 projects and sources for the application and libraries. Sorry I couldn't make it available in tar.gz form, there were just too many files to convert and check. --Al Evans-- -- |||| Al Evans -- al@powertools.com -- proud of Graphic Elements Release 3 |||| ==== A new standard for high-performance interactive Macintosh graphics ==== ==== Available from mac.archive.umich.edu and mirrors in ==== |||| /mac/development/libraries/graphicelements3.0.sit.hqx |||| ---- 8< ---- -- ----------========================================================---------- Chris Herborth, R&D Technical Writer Arcane Dragon chrish@qnx.com QNX Software Systems, Ltd. -==(UDIC)==- ||| JAGUAR http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge / | \ 64-bit ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 13 08:41:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id IAA20869 for ; Tue, 13 Feb 1996 08:41:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA21328 for png-list-outgoing; Tue, 13 Feb 1996 08:44:14 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA21321 for ; Tue, 13 Feb 1996 08:44:11 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.1/8.7.1) id IAA13415 for png-list@dworkin.wustl.edu; Tue, 13 Feb 1996 08:40:53 -0600 (CST) From: Peter da Silva Message-Id: <199602131440.IAA13415@Starbase.NeoSoft.COM> Subject: Re: MPNG prediction To: png-list@dworkin.wustl.edu Date: Tue, 13 Feb 1996 08:40:53 -0600 (CST) In-Reply-To: <824154278.21058.0@abwillms.demon.co.uk> from "Alaric B. Williams" at Feb 12, 96 06:41:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > So, for example, a TSNA stream containing audio and video would call > "audio" and pass it a frame's worth of sound, which it would send to > the DMA controller for playing, then call "video" and pass it a MPNG > frame, which it would display. Because a frame's worth of sound is an inefficient amount of sound to feed to the DMA controller in one chunk. Better would be to have a more generalized event structure, and sync the streams to timed events. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 13 09:54:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id JAA21891 for ; Tue, 13 Feb 1996 09:54:18 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA22222 for png-list-outgoing; Tue, 13 Feb 1996 09:57:21 -0600 Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [198.4.7.4]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA22215 for ; Tue, 13 Feb 1996 09:57:17 -0600 Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id KAA25843; Tue, 13 Feb 1996 10:53:59 -0500 Date: 13 Feb 96 10:50:48 EST From: Owen Mortensen To: ngf , "\"Chris Herborth\"" Subject: Re: BePNG: First BeBox PNG app uploaded! Message-ID: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris quoted: >BePNG displays PNG images. PNG is an "open" graphics format, >developed as a response to CompuServe's deciding that people had to >license the right to use the GIF format. Just to be fair: CompuServe did NOT decide that people had to license the right to use the GIF format. It was forced upon us by Unisys, the owner of the LZW patent. Owen Mortensen CompuServe R&D ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 13 20:42:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id UAA00198 for ; Tue, 13 Feb 1996 20:42:14 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA04327 for png-list-outgoing; Tue, 13 Feb 1996 20:45:08 -0600 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA04317 for ; Tue, 13 Feb 1996 20:45:02 -0600 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) with UUCP id VAA02122 for png-list@dworkin.wustl.edu; Tue, 13 Feb 1996 21:41:38 -0500 Message-Id: <199602140241.VAA02122@qnx.com> Subject: Re: BePNG: First BeBox PNG app uploaded! (fwd) To: png-list@dworkin.wustl.edu (PNG Mailing List) Date: Tue, 13 Feb 1996 21:41:37 -0500 (EST) From: "Chris Herborth" X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List What you wrote: > From: Al Evans > Subject: Re: BePNG: First BeBox PNG app uploaded! (fwd) > Date: Tue, 13 Feb 1996 15:07:33 -0600 (CST) > > [Chris Herborth] > > > I sent your BePNG announcement from comp.sys.be to the PNG-list: > > > > From: Owen Mortensen > > > > > > Just to be fair: CompuServe did NOT decide that people had to license > > > the right to use the GIF format. It was forced upon us by Unisys, the owner > > > of the LZW patent. > > > > > Oops. My mistake. I have posted a retraction/apology on comp.sys.be in > a follow-up to my original announcement. > > I am also uploading a new improved version of BePNG to ftp.be.com. This > one is over ten times faster at displaying PNGs (something about over > 3 million calls to the library version of abs() in the innermost loop of > png_set_dither():-). I don't believe the old one ever got moved to a > publically-accessible location. > --Al Evans-- -- ----------========================================================---------- Chris Herborth, R&D Technical Writer Arcane Dragon chrish@qnx.com QNX Software Systems, Ltd. -==(UDIC)==- ||| JAGUAR http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge / | \ 64-bit ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 14 03:07:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id DAA18964 for ; Wed, 14 Feb 1996 03:07:36 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id DAA10316 for png-list-outgoing; Wed, 14 Feb 1996 03:10:45 -0600 Received: from zabadubop.mcom.com (unknown.netscape.com [205.217.236.254]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id DAA10311 for ; Wed, 14 Feb 1996 03:10:38 -0600 Received: from zabadubop (localhost [127.0.0.1]) by zabadubop.mcom.com (950511.SGI.8.6.12.PATCH526/8.6.9) with SMTP id BAA08817 for ; Wed, 14 Feb 1996 01:05:28 -0800 Message-ID: <3121A5D5.41C6@netscape.com> Date: Wed, 14 Feb 1996 01:05:25 -0800 From: Scott Furman Organization: Netscape Communications Corp. X-Mailer: Mozilla 2.0b6 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: PNG List Subject: Re: PNG MIME type References: <8755.824158986@sss.pgh.pa.us> <6237.9602122357@afs.mcc.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I thought I had sent a response to this thread earlier, but it does not show up in my outgoing message archive. My apologizes if you see two versions of this mail. lilley wrote: > > : It is true that Netscape 2.0 sends "image/pjpeg" as part of its HTTP Accept > > : headers, which is not (yet) an IANA-registered type. However, recall that, > > : unlike MIME, HTTP is not restricted to IANA types. The HTTP 1.0 spec has > > : this to say on the topic: > > Yes, it does say that. > > : > > : Although HTTP allows the use of non-registered media types, such usage > > : must not conflict with the IANA registry. Data providers are strongly > > : encouraged to register their media types with IANA via the > > : procedures outlined in RFC 1590. > > They are in error. Non-registered media types have an x- in the subtype. > The HTTP 1.0 draft says that it is ok to use x- types (which are intended > for small-scale experimental use) as a global distribution mechanism. > > image/pjpeg does not constitute a non-registered type. > >From my reading of the 1.0 spec, the HTTP Working Group does not share your interpretation of their work: HTTP uses Internet Media Types [15] (formerly referred to as MIME Content-Types [6]) in order to provide open and extensible data typing and type negotiation. For mail applications, where there is no type negotiation between sender and receiver, it is reasonable to put strict limits on the set of allowed media types. With HTTP, however, user agents can identify acceptable media types as part of the connection, and thus are allowed more freedom in the use of non-registered types. The following grammar for media types is a superset of that for MIME because it does not restrict itself to the official IANA and x-token types. [...] All media-type's registered by IANA must be preferred over extension tokens. However, HTTP does not limit conforming applications to the use of officially registered media types, nor does it encourage the use of an "x-" prefix for unofficial types outside of explicitly short experimental use between consenting applications. -Scott ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 14 09:06:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id JAA22028 for ; Wed, 14 Feb 1996 09:06:29 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA14059 for png-list-outgoing; Wed, 14 Feb 1996 09:08:44 -0600 Received: from mail.Germany.EU.net (mail.germany.eu.net [192.76.144.65]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA14054 for ; Wed, 14 Feb 1996 09:08:36 -0600 Received: by mail.Germany.EU.net with SMTP (5.59:15/EUnetD-2.5.3.d) via EUnet id QAA11690; Wed, 14 Feb 1996 16:05:08 +0100 Received: from escserver1 (escserver1.esc.de) by mail.esc.de (4.1/GEN-1.2.0.99) via ESC for [192.76.144.65] id AA00239; Wed, 14 Feb 96 16:03:53 +0100 Message-Id: <3121F91D.41C67EA6@esc.de> Date: Wed, 14 Feb 1996 16:00:45 +0100 From: Guido Vollbeding Organization: Electronic Service Center X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: PNG List Subject: Re: BePNG: First BeBox PNG app uploaded! (fwd) References: <199602140241.VAA02122@qnx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris Herborth wrote: > > What you wrote: > > From: Al Evans > > Subject: Re: BePNG: First BeBox PNG app uploaded! (fwd) > > Date: Tue, 13 Feb 1996 15:07:33 -0600 (CST) > > ... > > I am also uploading a new improved version of BePNG to ftp.be.com. This > > one is over ten times faster at displaying PNGs (something about over > > 3 million calls to the library version of abs() in the innermost loop of > > png_set_dither():-). I don't believe the old one ever got moved to a > > publically-accessible location. > > --Al Evans-- I discovered a similar performance lack in the libpng Paeth-Filter reading code (file: pngrutil.c, function: png_read_filter_row). I'll give my solution for this problem in png-implement, where it better should be discussed... Regards, Guido ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 14 15:13:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id PAA26880 for ; Wed, 14 Feb 1996 15:13:14 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA21323 for png-list-outgoing; Wed, 14 Feb 1996 15:15:26 -0600 Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA21317 for ; Wed, 14 Feb 1996 15:15:21 -0600 Received: from alum01.its.rpi.edu (alum01.its.rpi.edu [128.113.1.10]) by mail1.its.rpi.edu (8.6.9/8.6.4) with ESMTP id QAA00146 for ; Wed, 14 Feb 1996 16:11:43 -0500 From: Glenn Randers-Pehrson Received: (randeg@localhost) by alum01.its.rpi.edu (8.6.9/8.6.4) id QAA66966 for png-list@dworkin.wustl.edu; Wed, 14 Feb 1996 16:11:39 -0500 Date: Wed, 14 Feb 1996 16:11:39 -0500 Message-Id: <199602142111.QAA66966@alum01.its.rpi.edu> To: png-list@dworkin.wustl.edu Subject: //tcg.arl.mil Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List //tcg.arl.mil will be off-line for the next several days. I'll post another notice when it has been reassembled. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 15 14:03:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id OAA10864 for ; Thu, 15 Feb 1996 14:03:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA09377 for png-list-outgoing; Thu, 15 Feb 1996 14:04:53 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA09359 for ; Thu, 15 Feb 1996 14:04:46 -0600 Date: Thu, 15 Feb 96 19:57:39 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@dworkin.wustl.edu Subject: zlib internet drafts version 01 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602151957.aa16144@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I've uploaded slightly revised Internet Drafts for zlib, gzip, and deflate. Keith, please remove the contents of the png/documents/zlib directory, move zlib-docs-01.tar.gz into it, gunzip and extract from the tar file. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 20 10:13:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA21046 for ; Tue, 20 Feb 1996 10:13:59 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA25512 for png-list-outgoing; Tue, 20 Feb 1996 10:13:55 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA25482 for ; Tue, 20 Feb 1996 10:12:23 -0600 Received: from afs.mcc.ac.uk (actually cguhpb.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Tue, 20 Feb 1996 16:04:28 +0000 From: lilley Message-Id: <26972.9602201604@afs.mcc.ac.uk> Subject: Re: PNG MIME type To: png-list@dworkin.wustl.edu Date: Tue, 20 Feb 1996 16:04:12 +0000 (GMT) In-Reply-To: <3121A5D5.41C6@netscape.com> from "Scott Furman" at Feb 14, 96 01:05:25 am Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Scott Furman writes: > lilley wrote: [attributions deleted] > > > : It is true that Netscape 2.0 sends "image/pjpeg" as part of its HTTP Accept > > > : headers, which is not (yet) an IANA-registered type. However, recall that, > > > : unlike MIME, HTTP is not restricted to IANA types. The HTTP 1.0 spec has > > > : this to say on the topic: > > > : Although HTTP allows the use of non-registered media types, such usage > > > : must not conflict with the IANA registry. Data providers are strongly > > > : encouraged to register their media types with IANA via the > > > : procedures outlined in RFC 1590. > [this bit was me] > > They are in error. Non-registered media types have an x- in the subtype. > > The HTTP 1.0 draft says that it is ok to use x- types (which are intended > > for small-scale experimental use) as a global distribution mechanism. > > > > image/pjpeg does not constitute a non-registered type. > From my reading of the 1.0 spec, the HTTP Working Group does not share > your interpretation of their work: > > [...] The following grammar for media types is a > superset of that for MIME because it does not restrict itself to the > official IANA and x-token types. >From my re-reading of the 1.0 draft, I now agree that it does not prevent you from using image/pjpeg for progressive JPEG. I note however that NCSA Mosaic uses image/x-pjpeg for jpeg compressed PhotoCD images. If they (or indeed anyone else) were ever to register this type, you would then be in contravention of HTTP 1.0 because: > All media-type's registered by IANA must be preferred over extension > tokens. It strikes me, from this thread and from observing the ietf-types list for over a year, that one valuable thing would be a simple, automatic registry of experimental types (and perhaps of non-experimental, unregistered types). -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 20 11:34:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id LAA22293 for ; Tue, 20 Feb 1996 11:34:53 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28622 for png-list-outgoing; Tue, 20 Feb 1996 11:34:43 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA28553 for ; Tue, 20 Feb 1996 11:32:21 -0600 Received: from afs.mcc.ac.uk (actually cguhpb.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Tue, 20 Feb 1996 17:30:41 +0000 From: lilley Message-Id: <27866.9602201730@afs.mcc.ac.uk> Subject: PNG coverage in March 96 Internet World To: png-list@dworkin.wustl.edu Date: Tue, 20 Feb 1996 17:30:12 +0000 (GMT) Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List March 1996 Internet World (in an article about the 4th International Web Conference) talks about PNG. According to Berners-Lee, a consensus is forming to support a new graphics standard for Web page images that will replace the Compuserve GIF format, which has some limitations and may be subject to copyright restrictions imposed by patent-holder Unisys Corp. The new standard is called the Portable Network Graphics (PNG) specification. Berners-Lee hopes that all browsers will accept PNG. Netscape will begin supporting PNG in January, according to Chris Lilley of the University of Manchester Computer Graphics Unit. Like GIF, PNG images are interlaced, but PNG allows superior compression and loads images more quickly, lilley explained. Unlike GIF, which allows only full-on or full-off transparency for each pixel, PNG allows variable transparency, eliminating the halo effect that has plagued transparent anti-aliased images. Text can be coded into the PNG image files to provide captions, copyright notices, and information on title, author, creation time and software. This text also can give the value of gamma correction in an image and the color characteristics of the display monitor that was used by the image's creator, so that characteristics of the image (color, brightness, contrast, etc) will remain the same even when viewed on computers using different types of operating systems or display monitors. I was misquoted about Netscape, and some of the details are a little off, but they seem to have got the gist of it. -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 21 17:49:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id RAA14579 for ; Wed, 21 Feb 1996 17:49:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA04492 for png-list-outgoing; Wed, 21 Feb 1996 17:48:06 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA04487 for ; Wed, 21 Feb 1996 17:48:01 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id SAA29259 for ; Wed, 21 Feb 1996 18:47:48 -0500 (EST) To: png-list@dworkin.wustl.edu Subject: PNG draft 0.94 is done Date: Wed, 21 Feb 1996 18:47:47 -0500 Message-ID: <29256.824946467@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Changes since last time: * there's now a nice-looking PostScript version, generated via TeX (thanks to Oliver Fromme for the initial work on this) * Extensive copy-editing (thanks to Chris Herborth) * Separate references section in place of in-line citations. As far as I'm concerned, this puppy is ready to submit. The deflate and zlib references will need to change when those documents are assigned RFC numbers, but that's just about the only thing on my to-do list. I'd appreciate one more careful proofing pass from as many of you as can spare the time in the next few days. I found a couple of potentially embarassing typos (the alpha-channel code in sec. 10.8 has had syntax errors since Draft 10, for example) so it would behoove us to take another close look. BTW, the single-page HTML, multi-page HTML, PostScript, and plain text versions are all slightly different. Pick whichever you like to proofread, but I hope you don't all pick the same one. pngextensions has not changed as to content, but I modified formatting slightly so that it could be processed through the same LaTeX and nroff- generating scripts. I've uploaded to swrinde.nde.swri.edu:/pub/incoming/png: png-0.94-html.tar.gz PNG draft 0.94, HTML format (multiple pages) png-0.94-html-single.html.gz PNG draft 0.94, HTML format (one file) png-0.94.ps.gz PNG draft 0.94, PostScript png-0.94.txt.gz PNG draft 0.94, plain text png-0.94-master.tar.gz PNG draft 0.94, master document and scripts pngext-0.94.html.gz PNG extensions 0.94, HTML pngext-0.94.ps.gz PNG extensions 0.94, PostScript pngext-0.94.txt.gz PNG extensions 0.94, plain text I expect Keith will move these to /pub/png-group/documents/ (NOT the public /png directory, please, at least not quite yet). swrinde seems to be having *serious* network troubles today; it took multiple attempts over nearly three hours to upload the above files. As a temporary expedient, I've put the same files in ftp.netcom.com:/pub/tg/tgl/png/, so you can grab 'em from there if you can't get to swrinde. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 21 18:09:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id SAA14776 for ; Wed, 21 Feb 1996 18:08:59 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA04733 for png-list-outgoing; Wed, 21 Feb 1996 18:09:00 -0600 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA04726 for ; Wed, 21 Feb 1996 18:08:56 -0600 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.1/8.7.1) id SAA10173 for png-list@dworkin.wustl.edu; Wed, 21 Feb 1996 18:08:44 -0600 (CST) Message-Id: <199602220008.SAA10173@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Wed, 21 Feb 1996 18:08:44 -0600 In-Reply-To: Tom Lane "PNG draft 0.94 is done" (Feb 21, 6:47pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG List Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } I expect Keith will move these to /pub/png-group/documents/ } (NOT the public /png directory, please, at least not quite yet). Done. } swrinde seems to be having *serious* network troubles today; it took } multiple attempts over nearly three hours to upload the above files. We have identified some performance problems on the link. Work is being done to correct the problem but we don't have an ETR yet. Routing has been forced to the backup line so we will be reachable while this gets fixed. Sorry for any inconvenience. -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 08:26:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id IAA25825 for ; Thu, 22 Feb 1996 08:26:18 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA13078 for png-list-outgoing; Thu, 22 Feb 1996 08:25:41 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA13073 for ; Thu, 22 Feb 1996 08:25:36 -0600 Date: Thu, 22 Feb 96 14:21:29 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602221421.aa24525@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > As far as I'm concerned, this puppy is ready to submit. The deflate > and zlib references will need to change when those documents are > assigned RFC numbers, but that's just about the only thing on my > to-do list. > It happens that today, 22 Feb, is a drop-dead date for submitting Internet-drafts for this IETF review cycle. The zlib references can be changed later. I will go ahead and apply for a file-name (I suspect it will be draft-boutell-png-spec-00.txt) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 09:03:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id JAA26369 for ; Thu, 22 Feb 1996 09:03:36 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA13473 for png-list-outgoing; Thu, 22 Feb 1996 09:03:29 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA13468 for ; Thu, 22 Feb 1996 09:03:26 -0600 Date: Thu, 22 Feb 96 15:00:19 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602221500.aa27153@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Subject: PNG draft 0.94 is done > Date: Wed, 21 Feb 1996 18:47:47 -0500 > Message-ID: <29256.824946467@sss.pgh.pa.us> > From: Tom Lane > Changes since last time: > * there's now a nice-looking PostScript version, generated via TeX > (thanks to Oliver Fromme for the initial work on this) > * Extensive copy-editing (thanks to Chris Herborth) Thanks. I think the gramatical changes (may -> can|must, which ->that) are improvements. > * Separate references section in place of in-line citations. > > As far as I'm concerned, this puppy is ready to submit. Yes, I agree. The only changes needed are: change 0.94 to 1.0 Add the "file: " line at the top. I have applied to the IETF for a filename. Change the "awaiting release as RFC" to "work in progress" in the references to zlib and deflate. Why raise the IETF's hackles by violating the statement that "it is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress"? The moment their status changes, we can revise the PNG internet-draft to point to RFC's. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 11:22:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id LAA28253 for ; Thu, 22 Feb 1996 11:22:47 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA15603 for png-list-outgoing; Thu, 22 Feb 1996 11:22:10 -0600 Received: from boutell.com (boutell.com [204.137.132.17]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA15596 for ; Thu, 22 Feb 1996 11:22:04 -0600 Received: by boutell.com id AA01926 (5.67b/IDA-1.5 for png-list@dworkin.wustl.edu); Thu, 22 Feb 1996 09:30:12 -0800 From: Thomas Boutell Message-Id: <199602221730.AA01926@boutell.com> Subject: Re: PNG draft 0.94 is done To: png-list@dworkin.wustl.edu Date: Thu, 22 Feb 1996 09:30:12 -0800 (PST) In-Reply-To: <9602221421.aa24525@TBD2.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 22, 96 02:21:29 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > > As far as I'm concerned, this puppy is ready to submit. The deflate > > and zlib references will need to change when those documents are > > assigned RFC numbers, but that's just about the only thing on my > > to-do list. > > > > It happens that today, 22 Feb, is a drop-dead date for submitting > Internet-drafts for this IETF review cycle. > > The zlib references can be changed later. > > I will go ahead and apply for a file-name (I suspect it will > be draft-boutell-png-spec-00.txt) > > ../glennrp Go for it. A wise choice to get this into the process before further delays come to bear. -T ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 16:16:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id QAA04416 for ; Thu, 22 Feb 1996 16:16:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA20584 for png-list-outgoing; Thu, 22 Feb 1996 16:16:20 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA20538 for ; Thu, 22 Feb 1996 16:15:43 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Thu, 22 Feb 1996 22:15:07 +0000 From: lilley Message-Id: <12831.9602222215@afs.mcc.ac.uk> Subject: Re: PNG draft 0.94 is done To: png-list@dworkin.wustl.edu Date: Thu, 22 Feb 1996 22:15:19 +0000 (GMT) In-Reply-To: <29256.824946467@sss.pgh.pa.us> from "Tom Lane" at Feb 21, 96 06:47:47 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom Lane writes: > Changes since last time: > * there's now a nice-looking PostScript version, generated via TeX > (thanks to Oliver Fromme for the initial work on this) I am checking the new PostScript version, and the multi-file html version. Section 1: "The main part ... An appendix". There are now a number of appendices. Should these be summarised too? Section 2.8: Portions of this contradict the specification, others simply introduce FUD. To quote from Section 4.2.7: Keywords can contain only printable ISO 8859-1 characters and spaces; that is, only character codes 32-126 and 161-255 decimal are allowed. [...] Both keyword and text are interpreted according to the ISO 8859-1 (Latin-1) character set [ISO-8859]. Newlines in the text string should be represented by a single linefeed character (decimal 10); use of other control characters in the text is discouraged. This is all fine and good. But Section 2.8 contradicts this, encourages bad practice, and raises false expectations: Character codes not defined in Latin-1 may be used, but are unlikely to port across platforms correctly. (For that matter, any characters beyond 7-bit ASCII will not display correctly on all platforms; but Latin-1 represents a set which is widely portable.) "May be used" should at least be "should not be used", otherwise someone can tip a whole lot of control characters into a PNG file and then point to Section 2.8 which says they can do this. They are less likely to point to wording that says they should not do it. "unlikely to port to all platforms correctly" - given that that such codes are defined neither in ASCII nor in Latin-1, how can there be any definition of success? There is no choice of charset in PNG, no charset field for tEXT. If one chooses to dump text from another character set into a tEXT chunk, there is no way to indicate that this has been done. I suggest this should be changed to something like "and if used, the results are undefined". "(For that matter, any characters beyond 7-bit ASCII will not display correctly on all platforms" This simply introduces FUD without contributing anything useful. Pedantically it is true, because there are systems which cannot be made to display the correct glyphs for codes in the range 160-255. Pedantically, this is also true: "For that matter, any characters *in* 7-bit ASCII will not display correctly on all platforms" For example, an EBCIDIC system. In general, the whole sentence is an unsubstantiated statement which is demonstrably misleading. Putting "all" in there ensures that somewhere, yes, there is a platform that cannot be made to display Latin-1. But given the phenomenal success of the Web and HTML, which uses Latin-1; given that there are browsers available on a vast number of platforms, even quite obscure ones, the problem of displaying Latin-1 is greatly exagerated here. I suggest replacing the entire sentence with: "Some systems might not be able to display the correct glyphs for all characters in Latin-1. However, the success of HTML demonstrates that Latin-1 represents a set which is widely portable." Section 3.2, chunk type: "encoders and decoders should treat the codes" - instead of should, insert "must". This is not something that should not be done, it is something that must no be done otherwise the result is not a PNG file. Section 3.3, safe to copy bit. This subsection needs, I think, to start off by saying what it does. The information is in there if you read it through carefully enough, but as currently stated there is scope for misinterpretation. In particular, it would be possible to misinterpret this to mean that unrecognised chunks should not ever be copied; which contradicts Section 7 "we strongly encourage programs [...] to preserve ancillary information" I suggest a second sentence (after "0 (uppercase)[...] ") as follows: "This defines the handling of unrecognised ancillary chunks when the image data has been modified." Section 4.1.1 "At present, only compression type 0 [...] future expansion" and "Two values are currently defined". We do not say how these values might be added to, but the text implies that this is possible. Should this be clarified? Do other values make it: - A valid PNG 1.0 file that is not at all portable - An invalid PNG 1.0 (might be a PNG 2.0, for example) - An invalid PNG file, period. Section 4.2.2 "absence of a cHRM chunk indicates the image's" I think this should be "absence of a cHRM chunk indicates that the image's" Section 4.4 "New public chunks will only be registered [...] do not violate the design philosophy of PNG". Does this need anything added, like "as defined in this specification, in particular the Rationale section" ? Section 6 "defines five basic filtering algorithms" this implies that other values are possible, or may later be possible. Again, does this need clarification? Which of the three categories described earlier would a file fall into if it has some other value for a filter type? Section 7: "PNG requires chunks not to have ordering restrictions [...]" this I think should be "PNG requires ancillary chunks not to have ordering restrictions [...]" It also might be clearer to add two new subheadings. After the first paragraph, insert "7.1 Ancillary chunks". Right before "See also Section 3.3" add a subheading "7.2 Critical chunks". Move the paragraph "Note that critical chunks" to this section, omitting "Note that". Perhaps, renaming Section 7 to "Chunk Ordering Rules for New Chunks" would be helpful. Section 9.2. There is information eleswhere in the spec about the standardised gamma of video cameras which would probably be better placed here. Someone writing a video frame grabber with writes PNG will not find the information readilly. I suggest either moving or duplicating the information in Appendix 13 "How do I know [...]" first sentence so that Section 9.2 reads - "[...] or to make a strong guess based on the hardware on which it runs, then the encoder is strongly encouraged to output the gAMA chunk. For example digitized video has a gamma of 0.45 - camera transfer functions are standardized." In fact, similar information is split between Section 9.2 and Section 13, subsection "How do I know [...]". I now remember that I noticed this when writing the Color appendix and did not put a similar section into the Color appendix for this reason. I meant to point out the split before, but I forgot. The two sections could be combined into 9.2, or 9.2 could end with a "See also". By the way, is it intentional that the subheads in Chapters 13, 14 and 15 are not numbered? Section 9.3: "on an SMPTE monitor" anyone have a reference handy for that? (Dave?) My office is like a building site and all my books etc are in boxes at the moment. Similarly, CCIR 709 calls for a reference or a listing of the correctvalues for the cHRM chunk. I similar vein, is it worthwhile putting SMPTE, CCIR, NTSC and CIE into the glossary? (And what does CCIR stand for, anyhow!). Section 10.5 "Assuming a value of 2.5 is reccomended" but elsewhere in the spec we seem to use 2.2 fairly consistently (and 0.45 which implies 2.2). Should this be changed? "the display_gamma is determined entirely by the CRT" should this not be "and the room lighting"? Generally, it looks as if Section 10.5 was written before the Gamma appendix, and needs perhaps to be brought into line with it particularly wrt room lighting level.. Section 12.7 "CRT hardware typically has a gamma near 2.5. Video systems compensate [...] gamma of 0.45". This misses out a couple of steps of working. We need to either explain it, or change it to 2.2. The terminology also needs to be updated to that in the Gamma appendix. For example "CRT hardware has a CRT_gamma near 2.5, resulting in a display_gamma of 2.2. Video systems compensate [...] camera_gamma of 0.45 [...] already have a file_gamma of 0.45"" Sections 16 and 17: should these say "(This appendix is not part of the formal PNG specification)" Section 18: Moving all references to one section is a good idea, but in the ps version the url seems to have been dropped from COLOR-3 (it remains in the HTML version as a link, but not as text). Could this be added back please. Yes, lots of little detailed comments. I think this shows that the spec is very close to 1.0, when we start talking about adding the word "that" into a sentence. -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 18:06:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id SAA06580 for ; Thu, 22 Feb 1996 18:06:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA22607 for png-list-outgoing; Thu, 22 Feb 1996 18:06:30 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA22601 for ; Thu, 22 Feb 1996 18:06:20 -0600 Date: Fri, 23 Feb 96 0:04:22 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602230004.ab16105@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > From: lilley > Subject: Re: PNG draft 0.94 is done > > Yes, lots of little detailed comments. I think this shows that the spec > is very close to 1.0, when we start talking about adding the word "that" > into a sentence. PNG draft 0.95 is also done, and submitted to the IETF for publication as an INTERNET-DRAFT, . The deadline was 5pm today so your comments will go into draft-*-01.txt. IETF will not accept an update until after the IETF meeting, which is the week of March 4th in Los Angeles. Is any member of this list going? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 18:26:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id SAA06658 for ; Thu, 22 Feb 1996 18:26:33 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA22900 for png-list-outgoing; Thu, 22 Feb 1996 18:26:35 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA22894 for ; Thu, 22 Feb 1996 18:26:29 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id TAA16601 for ; Thu, 22 Feb 1996 19:26:11 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Thu, 22 Feb 1996 22:15:19 +0000 (GMT) <12831.9602222215@afs.mcc.ac.uk> Date: Thu, 22 Feb 1996 19:26:11 -0500 Message-ID: <16599.825035171@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris, Thanks for the detailed comments! A couple of these points need discussion, I think. > Character codes not defined in Latin-1 may be used, but are unlikely > to port across platforms correctly. (For that matter, any > characters beyond 7-bit ASCII will not display correctly on all > platforms; but Latin-1 represents a set which is widely portable.) > [ Chris attacks this with vigor ] As I recall, the wording in 2.8 emerged from our horribly long-drawn-out arguments over whether the spec should prohibit use of non-Latin1 codes. The argument that carried the day was that Windows and/or Mac users could not be stopped from using the full character sets available on their respective machines, and that it was pointless to try. Thus what we are trying to say is that codes within the Latin1 set have defined meanings in PNG; other codes have platform-dependent meanings but are not prohibited. This could probably do with a little rewording to clarify. I really, really don't want to reopen the decision, however ... that was a *long* argument. > [ what about nonstandard compression and filter types ] Obviously, the provision of compression and filter type bytes implies that there may someday be extensions with new values for these fields. The description of IHDR states that decoders must reject files with unrecognized values in these fields, and I think that's sufficient. Whether the unrecognized value is a mistake, a future addition to the standard, or a private extension is not possible to say. (I *have* occasionally thought that we should reserve some filter and compression type codes for private vs. public use, in the same way that there are private vs. public chunk typecodes. Say 128-255 for private extensions. But it's probably not really necessary to do this.) Also, my opinion is that filter type 0 means exactly the five filters defined in section 6. A new filtering scheme would require a different filter type code in IHDR, even if it merely added some filter types to the current set. This is implied by the wording under IHDR but should be stated more clearly in chapter 6. Perhaps instead of "PNG defines five basic filtering algorithms..." it should say "Filter typecode 0 defines five...", or something like that. > The two sections could be combined into 9.2, or 9.2 could end with a > "See also". There is some duplication between the tutorial appendixes and the main body of the spec. That's not necessarily bad, but if Chris and Dave want to try cleaning up those sections it's fine with me. > Generally, it looks as if Section 10.5 was written before the Gamma > appendix, and needs perhaps to be brought into line with it particularly > wrt room lighting level.. Dave? regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 18:53:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id SAA06847 for ; Thu, 22 Feb 1996 18:53:50 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA23148 for png-list-outgoing; Thu, 22 Feb 1996 18:53:54 -0600 Received: from hp89.rbg.informatik.th-darmstadt.de (hp89.rbg.informatik.th-darmstadt.de [130.83.9.41]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA23143 for ; Thu, 22 Feb 1996 18:53:48 -0600 From: alexlehm@rbg.informatik.th-darmstadt.de Message-Id: <199602230053.SAA23143@dworkin.wustl.edu> Received: from hp62.rbg.informatik.th-darmstadt.de by hp89.rbg.informatik.th-darmstadt.de with ESMTP ($Revision: 1.37.109.26 $/15.6) id AA073996804; Fri, 23 Feb 1996 01:53:25 +0100 Received: by hp62.rbg.informatik.th-darmstadt.de (1.37.109.15/15.6) id AA019926804; Fri, 23 Feb 1996 01:53:24 +0100 Subject: charsets (was: Re: PNG draft 0.94 is done) To: png-list@dworkin.wustl.edu Date: Fri, 23 Feb 1996 01:53:23 +0100 (MET) In-Reply-To: <12831.9602222215@afs.mcc.ac.uk> from "lilley" at Feb 22, 96 10:15:19 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hello all, one minor comment about the charsets thing (I haven't read the whole spec yet). > > Tom Lane writes: > > Changes since last time: > > * there's now a nice-looking PostScript version, generated via TeX > > (thanks to Oliver Fromme for the initial work on this) > > I am checking the new PostScript version, and the multi-file html version. > > Section 1: "The main part ... An appendix". There are now a number of > appendices. Should these be summarised too? > > Section 2.8: Portions of this contradict the specification, others simply > introduce FUD. To quote from Section 4.2.7: > > Keywords can contain only printable ISO 8859-1 characters and > spaces; that is, only character codes 32-126 and 161-255 decimal are > allowed. [...] Both keyword and text are interpreted according to > the ISO 8859-1 (Latin-1) character set [ISO-8859]. Newlines in the > text string should be represented by a single linefeed character > (decimal 10); use of other control characters in the text is > discouraged. Does this mean that the non-break space (160) is explicitly forbidden? The wording printable and spaces would IMHO include the NBS, while the ranges do not. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows alexlehm@rbg.informatik.th-darmstadt.de (plain) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 18:55:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id SAA06857 for ; Thu, 22 Feb 1996 18:55:33 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA23178 for png-list-outgoing; Thu, 22 Feb 1996 18:55:47 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA23170 for ; Thu, 22 Feb 1996 18:55:43 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id SAA13312 for png-list@dworkin.wustl.edu; Thu, 22 Feb 1996 18:55:02 -0600 (CST) Date: Thu, 22 Feb 1996 18:55:02 -0600 (CST) From: Cave Newt Message-Id: <199602230055.SAA13312@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom writes: > (I *have* occasionally thought that we should reserve some filter and > compression type codes for private vs. public use, in the same way that > there are private vs. public chunk typecodes. Say 128-255 for private > extensions. But it's probably not really necessary to do this.) I think it's distinctly a *bad* idea to do this. Anyone who wants a private compression type has just created a private image format, and there's no reason for them to call it "PNG" and every reason for them not to. If they like the PNG-style chunks that well, they can change the signature to "DNG" or "ZNG" or whatever and leave everything else the same. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 19:15:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id TAA07033 for ; Thu, 22 Feb 1996 19:15:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA23320 for png-list-outgoing; Thu, 22 Feb 1996 19:14:44 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA23315 for ; Thu, 22 Feb 1996 19:14:40 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id UAA16861 for ; Thu, 22 Feb 1996 20:14:22 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Thu, 22 Feb 1996 18:55:02 -0600 (CST) <199602230055.SAA13312@ellis.uchicago.edu> Date: Thu, 22 Feb 1996 20:14:21 -0500 Message-ID: <16859.825038061@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg sez: > I think it's distinctly a *bad* idea to do this. Anyone who wants a > private compression type has just created a private image format, and > there's no reason for them to call it "PNG" and every reason for them > not to. Not really ... a private compression type is on an exact par with a private critical chunk. We allow the one, so the other is sensible too. In fact, if I wanted to experiment with a nonstandard compression method inside PNG and there were *not* a compression type code in IHDR, I would mark the file as nonstandard by inserting a private critical chunk. But since there is a compression type code, it seems like the right thing to use. Ditto for nonstandard filtering, of course. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 19:38:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id TAA07122 for ; Thu, 22 Feb 1996 19:38:45 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA23580 for png-list-outgoing; Thu, 22 Feb 1996 19:38:58 -0600 Received: from boutell.com (boutell.com [204.137.132.17]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA23574 for ; Thu, 22 Feb 1996 19:38:53 -0600 Received: by boutell.com id AA06269 (5.67b/IDA-1.5 for png-list@dworkin.wustl.edu); Thu, 22 Feb 1996 17:46:51 -0800 From: Thomas Boutell Message-Id: <199602230146.AA06269@boutell.com> Subject: Private Compression Types To: png-list@dworkin.wustl.edu Date: Thu, 22 Feb 1996 17:46:51 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From a political perspective it would be a very bad idea to even breathe the words "private compression types" in the PNG specification, IMHO. As has been pointed out, a private critical chunk would express this successfully, so there is a mechanism. We *do not want* people to pursue private compression types, unless they are already thoroughly set on it for some critical reason of their own. And in that case, they will no doubt prove capable of creating a private critical chunk for this purpose. -T ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 22 21:05:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id VAA07591 for ; Thu, 22 Feb 1996 21:05:52 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA24541 for png-list-outgoing; Thu, 22 Feb 1996 21:05:40 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA24536 for ; Thu, 22 Feb 1996 21:05:37 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id VAA28275; Thu, 22 Feb 1996 21:04:49 -0600 (CST) Date: Thu, 22 Feb 1996 21:04:49 -0600 (CST) From: Cave Newt Message-Id: <199602230304.VAA28275@ellis.uchicago.edu> To: dherr@garfield.geosys.com Subject: Re: PNG Cc: png-list@dworkin.wustl.edu Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > After reading about the PNG format in Dr. Dobbs Journal, I recommended > to my manager that we use it as the standard bitmap format in our next > mapping library. He approved, choosing it over GIF and other formats > because of its lossless image-compression and royalty-free license. Most cool. > The first release will be for 16-bit Windows, with 32-bit Windows, > Solaris, and possibly the Mac following soon after. Solaris? Hmph. Been there, done that...we use Linux at work. (Consider that a plea for reconsideration. :-) ) > I'm currently trying to find some sample code for reading and > displaying a PNG file in Windows (16-bit). I already downloaded the > and compiled the Zlib and LibPNG libraries, but a Windows-specific > sample app with source code would be immensely helpful. If you know > where I might find some, please let me know! You might look through some PC Mags for the last couple of years--I think Prosise or Petzold wrote some graphical apps for Windows, and it should be relatively straightforward to fit libpng into one of those. (Speaking from recent experience, I just added PNG support to an existing X app and didn't have too much trouble with it.) I don't think there are any sample Windows apps around with PNG support and source code, but I'll cc this to png-list and see if anyone else knows. -- Greg Roelofs "Name an animal that's small and fuzzy." "Mold." newt@uchicago.edu or http://quest.jpl.nasa.gov/Info-ZIP/people/greg/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 00:29:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id AAA08503 for ; Fri, 23 Feb 1996 00:29:32 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA27363 for png-list-outgoing; Fri, 23 Feb 1996 00:29:35 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA27357 for ; Fri, 23 Feb 1996 00:29:32 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id AAA21773 for png-list@dworkin.wustl.edu; Fri, 23 Feb 1996 00:28:46 -0600 (CST) Date: Fri, 23 Feb 1996 00:28:46 -0600 (CST) From: Cave Newt Message-Id: <199602230628.AAA21773@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom writes: > Not really ... a private compression type is on an exact par with a > private critical chunk. We allow the one, so the other is sensible > too. That statement is entirely true, and in retrospect I think private critical chunks should have been reconsidered as a mostly bad idea, too. Unknown future critical official chunks, no problem; but not private ones. Why should such a file be considered a PNG image when effectively it's not? What do you gain by calling it PNG? Imagine the chaos if someone starting writing "zipfiles" with arithmetic coding... Egad, users would go completely apeshit. Even today, four years after the fact, you still see messages in comp.compression about "unknown compression type" due to using Zip/PKZIP 2.x zipfiles with UnZip/PKUNZIP 1.x. > In fact, if I wanted to experiment with a nonstandard compression > method inside PNG and there were *not* a compression type code in > IHDR, I would mark the file as nonstandard by inserting a private > critical chunk. But since there is a compression type code, it > seems like the right thing to use. If *I* wanted to do that, I'd modify libpng to use the new compression method *and* a new ID string, and I'd forget about any extraneous critical chunks. What would the rest of the world do with it, anyway? OK, if it's marked "PNG" you can run pngcheck on it to see if the CRCs check out...big deal. Now you've got a useless chunk of data sitting on your disk, but at least you know it's not a corrupted useless chunk of data. (No need for further discussion; this is all completely irrelevant at this point. I just wish I'd thought of it 9 months ago. I'll shut up now...) Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 08:33:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id IAA11991 for ; Fri, 23 Feb 1996 08:33:03 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA04843 for png-list-outgoing; Fri, 23 Feb 1996 08:32:46 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA04836 for ; Fri, 23 Feb 1996 08:32:43 -0600 Date: Fri, 23 Feb 96 14:32:14 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602231432.aa29063@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > From: lilley > Subject: Re: PNG draft 0.94 is done > Date: Thu, 22 Feb 1996 22:15:19 +0000 (GMT) > Tom Lane writes: > > Changes since last time: > > * there's now a nice-looking PostScript version, generated via TeX > > (thanks to Oliver Fromme for the initial work on this) > > I am checking the new PostScript version, and the multi-file html versio > n. > > Section 1: "The main part ... An appendix". There are now a number of > appendices. Should these be summarised too? > How about: As reads in Png-0.95: The main part of this specification simply gives the definition of the file format. An appendix gives the rationale for many design decisions. Although the rationale is not part of the formal specification, reading it can help implementors understand the design. Cross-references in the main text point to relevant parts of the rationale. Change to: The main part of this specification (Sections 2 through 7) simply gives the definition of the file format. The remaining sections include
  • Miscellaneous information on file names and security issues
  • Recommendations for encoders and decoders
  • A glossary
  • An appendix giving the rationale for many design decisions. Although the rationale is not part of the formal specification, reading it can help implementors understand the design. Cross-references in the main text point to relevant parts of the rationale.
  • Tutorials on gamma and color
  • A list of related online resources available on the World Wide Web
In the event of any unintended inconsistencies in this specification, the information provided in Sections 2 through 7 takes precedence. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 08:33:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id IAA12019 for ; Fri, 23 Feb 1996 08:33:58 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA03718 for png-list-outgoing; Fri, 23 Feb 1996 07:33:07 -0600 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA03713 for ; Fri, 23 Feb 1996 07:33:03 -0600 Received: from utserv.mcc.ac.uk by wugate.wustl.edu (8.6.12/8.6.11) with ESMTP id HAA28309 for ; Fri, 23 Feb 1996 07:26:07 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Fri, 23 Feb 1996 13:24:18 +0000 From: lilley Message-Id: <14984.9602231324@afs.mcc.ac.uk> Subject: Re: charsets (was: Re: PNG draft 0.94 is done) To: png-list@dworkin.wustl.edu Date: Fri, 23 Feb 1996 13:24:06 +0000 (GMT) In-Reply-To: <199602230053.SAA23143@dworkin.wustl.edu> from "alexlehm@rbg.informatik.th-darmstadt.de" at Feb 23, 96 01:53:23 am Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Alexander says: >[I quoted]: > > Keywords can contain only printable ISO 8859-1 characters and > > spaces; that is, only character codes 32-126 and 161-255 decimal are > > allowed. [...] Both keyword and text are interpreted according to > > the ISO 8859-1 (Latin-1) character set [ISO-8859]. Newlines in the > > text string should be represented by a single linefeed character > > (decimal 10); use of other control characters in the text is > > discouraged. > > Does this mean that the non-break space (160) is explicitly forbidden? > The wording printable and spaces would IMHO include the NBS, while the > ranges do not. Good catch. No, that is an error. It should say 160-255. NBS is a printing character. -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 09:24:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id JAA12859 for ; Fri, 23 Feb 1996 09:24:13 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA06320 for png-list-outgoing; Fri, 23 Feb 1996 09:24:11 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA06315 for ; Fri, 23 Feb 1996 09:24:06 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id KAA19113 for ; Fri, 23 Feb 1996 10:23:45 -0500 (EST) To: PNG List Subject: Status of different parts of the spec (Re: PNG draft 0.94 is done) In-reply-to: Your message of Fri, 23 Feb 96 14:32:14 GMT <9602231432.aa29063@TBD2.ARL.MIL> Date: Fri, 23 Feb 1996 10:23:45 -0500 Message-ID: <19111.825089025@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Change to: > The main part of this specification (Sections 2 through 7) simply gives > the definition of the file format. > The remaining sections include >
    >
  • Miscellaneous information on file names and security issues >
  • Recommendations for encoders and decoders >
  • A glossary >
  • An appendix giving the rationale for many design > decisions. Although the rationale is not part of the formal > specification, reading it can help implementors understand the design. > Cross-references in the main text point to relevant parts of the > rationale. >
  • Tutorials on gamma and color >
  • A list of related online resources available on the World Wide Web >
In my mind, chapters 8-10 are certainly part of the main spec. The recommendations in 9 & 10 are necessary for best interoperability. Probably the introductory text ought to be revised to something like : The main part of the specification gives the definition of the file format : and recommendations for encoder and decoder behavior. An appendix gives : the rationale for many design decisions. Although the rationale is not : part of the formal specification, reading it can help implementors : understand the design. Cross-references in the main text point to : relevant parts of the rationale. Additional appendixes, also not part : of the formal specification, provide tutorials on gamma and color theory : as well as other supporting material. Also, chapter 17 (revision history) should be labeled as an appendix for consistency. However, the glossary and references are part of the formal spec, because they define terms used in the spec. > In the event of any unintended inconsistencies in this specification, > the information provided in Sections 2 through 7 takes precedence. *Bad* idea. As we've already seen in another thread, the information in section 2 is older and not necessarily as carefully worded as some of the later sections (esp. 8-10). We should leave ourselves the wiggle room to resolve any remaining inconsistencies on a case-by-case basis. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 10:03:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA13371 for ; Fri, 23 Feb 1996 10:03:58 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA07705 for png-list-outgoing; Fri, 23 Feb 1996 10:04:06 -0600 Received: from tbd2.arl.mil (tbd2.arl.mil [128.63.9.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA07699 for ; Fri, 23 Feb 1996 10:04:00 -0600 Date: Fri, 23 Feb 96 15:59:49 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: Status of different parts of the spec (Re: PNG draft 0.94 is done) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602231559.aa03223@TBD2.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List tom wrote: > Probably the introductory text ought to be revised to something like > > : The main part of the specification gives the definition of the file format > : and recommendations for encoder and decoder behavior. An appendix gives > : the rationale for many design decisions. Although the rationale is not > : part of the formal specification, reading it can help implementors > : understand the design. Cross-references in the main text point to > : relevant parts of the rationale. Additional appendixes, also not part > : of the formal specification, provide tutorials on gamma and color theory > : as well as other supporting material. This looks fine. > > Also, chapter 17 (revision history) should be labeled as an appendix OK > [glennrp wrote:] > > In the event of any unintended inconsistencies in this specification, > > the information provided in Sections 2 through 7 takes precedence. > > *Bad* idea. As we've already seen in another thread, the information in > section 2 is older and not necessarily as carefully worded as some of the > later sections (esp. 8-10). We should leave ourselves the wiggle room to > resolve any remaining inconsistencies on a case-by-case basis. I found the idea in a recent guide for internet standards writers (internet draft , work in progress) that says `if multiple descriptions of a protocol mechanism are included, one of them must be specified as "binding" in the case of unintended inconsistencies.' I didn't think that was such a bad idea. But in view of the above, I would reword my suggested text to be In the event of any unintended inconsistencies in this specification, the information provided in the main specification takes precedence over that provided in the appendices. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 10:21:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA13577 for ; Fri, 23 Feb 1996 10:21:21 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA08339 for png-list-outgoing; Fri, 23 Feb 1996 10:21:10 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA08332 for ; Fri, 23 Feb 1996 10:21:03 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id LAA19267 for ; Fri, 23 Feb 1996 11:20:41 -0500 (EST) To: PNG List Subject: Re: Status of different parts of the spec (Re: PNG draft 0.94 is done) In-reply-to: Your message of Fri, 23 Feb 96 15:59:49 GMT <9602231559.aa03223@TBD2.ARL.MIL> Date: Fri, 23 Feb 1996 11:20:41 -0500 Message-ID: <19265.825092441@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > In the event of any unintended inconsistencies in this specification, > the information provided in the main specification takes precedence > over that provided in the appendices. This is already implied by the statement that the appendices are not part of the formal spec. On political grounds, I think we ought not to write anything that could be read as an admission that we think there are mistakes ;-) regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 10:33:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.1/8.7.1) with SMTP id KAA13747 for ; Fri, 23 Feb 1996 10:33:58 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA05978 for png-list-outgoing; Fri, 23 Feb 1996 09:13:51 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA05973 for ; Fri, 23 Feb 1996 09:13:46 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id KAA19088 for ; Fri, 23 Feb 1996 10:13:25 -0500 (EST) To: PNG List Subject: Re: charsets (was: Re: PNG draft 0.94 is done) In-reply-to: Your message of Fri, 23 Feb 1996 13:24:06 +0000 (GMT) <14984.9602231324@afs.mcc.ac.uk> Date: Fri, 23 Feb 1996 10:13:24 -0500 Message-ID: <19086.825088404@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris says: > Alexander says: >>>> Keywords can contain only printable ISO 8859-1 characters and >>>> spaces; that is, only character codes 32-126 and 161-255 decimal are >>>> allowed. >> >> Does this mean that the non-break space (160) is explicitly forbidden? > Good catch. No, that is an error. It should say 160-255. NBS is a printing > character. No, that is correct. We are talking about restrictions on keywords here, not on the body text. The point of the restrictions on keywords is to prevent use of keywords that look alike or almost alike but will compare differently. An NBS looks *exactly* like a space. There is no point in forbidding leading/trailing spaces, and suchlike, if we are going to allow invisible problems like NBS. It wouldn't be a bad idea to state explicitly that NBS is excluded, though. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Feb 23 12:34:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA16123 for ; Fri, 23 Feb 1996 12:34:04 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA10269 for png-list-outgoing; Fri, 23 Feb 1996 11:23:33 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA10261 for ; Fri, 23 Feb 1996 11:23:28 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id MAA19376 for ; Fri, 23 Feb 1996 12:23:06 -0500 (EST) To: PNG List Subject: Private critical extensions (Re: PNG draft 0.94 is done) In-reply-to: Your message of Fri, 23 Feb 1996 00:28:46 -0600 (CST) <199602230628.AAA21773@ellis.uchicago.edu> Date: Fri, 23 Feb 1996 12:23:06 -0500 Message-ID: <19374.825096186@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg writes: > ... in retrospect I think private > critical chunks should have been reconsidered as a mostly bad idea, > too. Unknown future critical official chunks, no problem; but not > private ones. I can't resist making two more remarks in this thread: 1. The spec should, and does, discourage people from inventing private critical chunks. I think that's sufficient, although perhaps it could discourage them more vigorously. Do you want to propose different wording? 2. PNG is in part an experiment in designing an extensible file format. Right now we are thinking of it as a universally compatible format, but in a few years we may be damn glad we put in the capability to handle incompatible extensions cleanly. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Feb 24 18:08:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA28959 for ; Sat, 24 Feb 1996 18:08:41 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA05355 for png-list-outgoing; Sat, 24 Feb 1996 18:08:00 -0600 Received: from image.arl.mil (image.arl.mil [128.63.11.59]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA05347 for ; Sat, 24 Feb 1996 18:07:57 -0600 Date: Sat, 24 Feb 96 19:07:00 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@dworkin.wustl.edu Subject: PNG on TV Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602241907.aa25771@IMAGE.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List CSPAN-2 just played a one-hour segment of a conference on the future of the WWW, that was held at the JFK School of Government on 6 FEb. It was a talk by Tim B-L followed by a Question&Answer session. He worked PNG into the conversation a couple of times, and gave a 30-second synopsis of the GIF controversy and the evolution of PNG, in response to a question about the effect of patents. The program was shown 6-7PM EST today, Saturday. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Feb 25 15:21:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03640 for ; Sun, 25 Feb 1996 15:21:17 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA18641 for png-list-outgoing; Sun, 25 Feb 1996 15:21:17 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA18636 for ; Sun, 25 Feb 1996 15:21:13 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id PAA06322 for png-list@dworkin.wustl.edu; Sun, 25 Feb 1996 15:20:33 -0600 (CST) Date: Sun, 25 Feb 1996 15:20:33 -0600 (CST) From: Cave Newt Message-Id: <199602252120.PAA06322@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom wrote: > 1. The spec should, and does, discourage people from inventing private > critical chunks. I think that's sufficient, although perhaps it > could discourage them more vigorously. Do you want to propose > different wording? If I could find the wording to which you refer, I would. :-) As far as I can tell, there is no discouragement; certainly there is none in the section on private chunks (9.8 in revision 0.94 at W3C), and there should be. (The creation of *public* critical chunks is discouraged in section 4.4, but I consider that a less worrisome possibility anyway.) This paragraph is the closest thing I can find: >>> You should use an ancillary chunk type, not a critical chunk type, for >>> all private chunks that store information that is not absolutely >>> essential to view the image. In other words, the first letter of the >>> chunk type code should also be lowercase. I would extend it thusly: The use of private critical chunks, while not prohibited, is strongly discouraged. A private critical chunk implies a private image format, and there is no need for such a format to call itself ``PNG''; doing so creates unnecessary confusion among users and provides virtually no benefit. (A private critical chunk that is intended to become a public chunk will undergo a name-change if it is approved, i.e., the second letter will become uppercase; the private version will never be under- stood by any standard PNG library or application. Thus, since only specially modified software will be able to read and write the private version, the same software can and should be modified to write files with a non-PNG signature string and a non-PNG filename extension.) You should use an ancillary chunk type, not a critical chunk type, for all private chunks that store information that is not absolutely essential to view the image. In other words, the first letter of the chunk type code should also be lowercase. Perhaps that's worded a little too strongly for the rest of the spec, but it reflects my (strong) feelings on "alien" image formats masquerading as PNG images when, in every practical sense, they are not PNG images at all. > 2. PNG is in part an experiment in designing an extensible file format. > Right now we are thinking of it as a universally compatible format, > but in a few years we may be damn glad we put in the capability to > handle incompatible extensions cleanly. I am *not* opposed to incompatible extensions; there is no other way to dramatically improve IDAT chunks (that is, better compression) without allowing for future incompatibilities. But there's a big difference between that and allowing private critical chunks: the latter, by defi- nition, will never be supported by the official PNG library because they will never be part of the official spec, nor even of the official public extensions. I don't see any possible *public* use for the capability of handling incompatible private extensions. The only benefit is to lazy in-house programmers and to hypothetical saboteurs of PNG's public accep- tance. Am I missing something? Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 05:48:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA07299 for ; Mon, 26 Feb 1996 05:48:03 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA29114 for png-list-outgoing; Mon, 26 Feb 1996 05:47:13 -0600 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA29109 for ; Mon, 26 Feb 1996 05:47:09 -0600 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) with UUCP id GAA12208 for png-list@dworkin.wustl.edu; Mon, 26 Feb 1996 06:46:32 -0500 Message-Id: <199602261146.GAA12208@qnx.com> Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) To: png-list@dworkin.wustl.edu Date: Mon, 26 Feb 1996 06:46:31 -0500 (EST) From: "Chris Herborth" In-Reply-To: <199602252120.PAA06322@ellis.uchicago.edu> from "Cave Newt" at Feb 25, 96 03:20:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg writes: > >>> You should use an ancillary chunk type, not a critical chunk type, for > >>> all private chunks that store information that is not absolutely > >>> essential to view the image. In other words, the first letter of the > >>> chunk type code should also be lowercase. > > I would extend it thusly: > > The use of private critical chunks, while not prohibited, is strongly > discouraged. A private critical chunk implies a private image format, > and there is no need for such a format to call itself ``PNG''; doing > so creates unnecessary confusion among users and provides virtually no > benefit. (A private critical chunk that is intended to become a public > chunk will undergo a name-change if it is approved, i.e., the second > letter will become uppercase; the private version will never be under- > stood by any standard PNG library or application. Thus, since only > specially modified software will be able to read and write the private > version, the same software can and should be modified to write files > with a non-PNG signature string and a non-PNG filename extension.) You > should use an ancillary chunk type, not a critical chunk type, for all > private chunks that store information that is not absolutely essential > to view the image. In other words, the first letter of the chunk type > code should also be lowercase. And I would re-write it thusly :-)... Using critical private chunks is strongly discouraged. A critical private chunk creates a private image format which should not call itself ``PNG''; this creates confusion among users. A critical private chunk could be approved as a new critical public chunk, and the second letter of the chunk name will be upper-cased. The private version of this chunk will never be understood by any standard PNG library or application. Software that understands this chunk should [change that to must? -cjh] write files with a non-PNG signature and a different file extension. Use an ancillary chunk type, not a critical chunk type, for all private chunks storing information that is not absolutely essential for viewing the image. > Perhaps that's worded a little too strongly for the rest of the spec, but > it reflects my (strong) feelings on "alien" image formats masquerading as > PNG images when, in every practical sense, they are not PNG images at all. I think it's fine; we can make it slightly stronger by making that "should" in the second paragraph a "must"... this will prevent weenies from making PNG files that have critical private chunks and pointing to the spec saying "it said _should_, so we can do it anyway!"... > I don't see any possible *public* use for the capability of > handling incompatible private extensions. The only benefit is to lazy > in-house programmers and to hypothetical saboteurs of PNG's public accep- > tance. > > Am I missing something? Nope, that last bit immediately made me think of TIFF. The looseness of the TIFF spec has really made it a hit-or-miss file format... you're never sure if program A's TIFF will load into program B. I find Corel and Microsoft to be good examples, since I've had many, many problems loading TIFFs from CorelDRAW! into MS Word... Chris Herborth ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 08:15:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA08346 for ; Mon, 26 Feb 1996 08:15:48 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA00649 for png-list-outgoing; Mon, 26 Feb 1996 08:16:07 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA00644 for ; Mon, 26 Feb 1996 08:16:03 -0600 Date: Mon, 26 Feb 96 9:14:18 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602260914.aa27893@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I do not agree with this whole train of thought. You are converting PNG from an extensible file format to a nonextensible file format. greg: > Am I missing something? For one, someone working on an experimental critical chunk that might eventually be approved as an extension (or maybe not...) must call it a private critical chunk prior to its approval. > change the file signature if it contains private critical chunks What does this accomplish beyond the chunk-naming conventions? We already require png decoders to reject the stream if it encounters an unknown critical chunk, and sensible decoders will emit an error message like "unknown critical chunk NeWT encountered; file abandoned." According to the spec, page 12, section 3.3, "decoders must indicate to the user that the image contains information they cannot safely interpret". I think such a message would be much more useful to the user than "unknown file format" that they would get if the Greg's suggestion were followed. What we could say is that it is inappropriate to let PNG files containing private critical chunks escape into the wild, i.e. in paragraph 9.8, say "Files containing private critical chunks should not appear in public WWW pages and the like." ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 08:34:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA08506 for ; Mon, 26 Feb 1996 08:34:15 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA00341 for png-list-outgoing; Mon, 26 Feb 1996 07:36:06 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA00336 for ; Mon, 26 Feb 1996 07:35:33 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Mon, 26 Feb 1996 13:33:00 +0000 From: lilley Message-Id: <2269.9602261332@afs.mcc.ac.uk> Subject: Re: charsets (was: Re: PNG draft 0.94 is done) To: png-list@dworkin.wustl.edu Date: Mon, 26 Feb 1996 13:32:51 +0000 (GMT) In-Reply-To: <19086.825088404@sss.pgh.pa.us> from "Tom Lane" at Feb 23, 96 10:13:24 am Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Chris says: > > Alexander says: > >>>> Keywords can contain only printable ISO 8859-1 characters and > >>>> spaces; that is, only character codes 32-126 and 161-255 decimal are > >>>> allowed. > >> > >> Does this mean that the non-break space (160) is explicitly forbidden? > > > Good catch. No, that is an error. It should say 160-255. NBS is a printing > > character. > > No, that is correct. We are talking about restrictions on keywords here, > not on the body text. My mistake, I thought we were talking about body text here. Sorry. > The point of the restrictions on keywords is to > prevent use of keywords that look alike or almost alike but will compare > differently. An NBS looks *exactly* like a space. There is no point in > forbidding leading/trailing spaces, and suchlike, if we are going to allow > invisible problems like NBS. I agree. > It wouldn't be a bad idea to state explicitly that NBS is excluded, > though. Yes, the sentence you provided above explained the reason very clearly. Why not just drop it in? -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 08:37:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA08535 for ; Mon, 26 Feb 1996 08:37:12 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA00899 for png-list-outgoing; Mon, 26 Feb 1996 08:37:22 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA00894 for ; Mon, 26 Feb 1996 08:37:18 -0600 Date: Mon, 26 Feb 96 9:32:38 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602260932.aa00903@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Using critical private chunks is strongly discouraged. A critical > private chunk creates a private image format which should not call > itself ``PNG''; this creates confusion among users. > > A critical private chunk could be approved as a new critical public > chunk, and the second letter of the chunk name will be upper-cased. The > private version of this chunk will never be understood by any standard > PNG library or application. Software that understands this chunk should > [change that to must? -cjh] write files with a non-PNG signature and a > different file extension. > How about: Specifically, change the signature to \211 N N G \r \n \032 \n === and the file extension to ".nng" (Nonportable Network Graphics) and the MIME type to "image/x-nng" to indicate that the file is written according to this specification, but contains private critical chunks, decode-at-your-own-risk. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 09:36:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA08907 for ; Mon, 26 Feb 1996 09:36:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA01592 for png-list-outgoing; Mon, 26 Feb 1996 09:36:48 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA01586 for ; Mon, 26 Feb 1996 09:36:42 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id KAA12445 for ; Mon, 26 Feb 1996 10:36:04 -0500 (EST) To: PNG List Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) In-reply-to: Your message of Mon, 26 Feb 1996 06:46:31 -0500 (EST) <199602261146.GAA12208@qnx.com> Date: Mon, 26 Feb 1996 10:36:03 -0500 Message-ID: <12443.825348963@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List various people write stuff along the lines of: > A critical > private chunk creates a private image format which should not call > itself ``PNG''; this creates confusion among users. > [ proposals to require a different signature if such a chunk is present ] And I say, this is all completely nuts. Changing the file signature for files containing private critical chunks amounts to making the signature serve as a version number. That is a terrible idea for the reasons enumerated in the Rationale. It's not even a good attempt at a version number, because we haven't thought through the implications of random changes to the file signature. For example, while the rationale mentions making PNG files unique in the first two bytes, I recall arguing that PNGs needed to be distinguishable from other common graphics formats in the *first* character; that's (one reason) why 'PNG' isn't the first three bytes. When and if MNG becomes reality, I plan to argue that it needs a different first byte too. But there isn't room to assign a different first byte for every private variant that might come along. We included private critical chunks in the spec for reasons which seemed good at the time and still seem good to me: namely, we designed PNG to be extensible because we could not foresee the future, and especially could not foresee all the uses to which the file format might be put. I think this sudden desire to mandate that Incompatible Things Will Not Be Called PNG is naive. And pointless too: if private critical chunks turn out to be the biggest source of incompatibility among PNG implementations, that's an indication that the design *succeeded*, not that it failed. Good ol' programmer error is far more likely to be our biggest compatibility headache than deliberate misuse of the private-critical-chunk feature. >> I don't see any possible *public* use for the capability of >> handling incompatible private extensions. This is shortsighted. Why did we make the design extensible at all? >> The only benefit is to ... hypothetical saboteurs of PNG's public accep- >> tance. And this verges on sheer paranoia. If a PNG file contains a private critical chunk, it is obvious to all that the file is deliberately intended not to be universally readable. There is no possibility for mutual fingerpointing such as commonly occurs with TIFF, where everyone has chosen a different subset of the spec to implement, and newly defined tags might or might not contain critical information. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 09:37:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA08915 for ; Mon, 26 Feb 1996 09:37:57 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA01622 for png-list-outgoing; Mon, 26 Feb 1996 09:38:18 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA01617 for ; Mon, 26 Feb 1996 09:38:15 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id JAA09808 for png-list@dworkin.wustl.edu; Mon, 26 Feb 1996 09:37:19 -0600 (CST) Date: Mon, 26 Feb 1996 09:37:19 -0600 (CST) From: Cave Newt Message-Id: <199602261537.JAA09808@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > I do not agree with this whole train of thought. You are converting > PNG from an extensible file format to a nonextensible file format. But there's a difference between useful extensions and useless ones. >> Am I missing something? > For one, someone working on an experimental critical chunk that might > eventually be approved as an extension (or maybe not...) must call it > a private critical chunk prior to its approval. Yes, I said that. So? Two trivial changes to their code renders it "safe," by my reckoning. >> change the file signature if it contains private critical chunks > What does this accomplish beyond the chunk-naming conventions? We already > require png decoders to reject the stream if it encounters an unknown > critical chunk It seems to me that you have probably never dealt with an incompatible change to a popular file format before. We went through all of this in 1992-1993 when PKWARE came out with a "new critical chunk" in the ZIP format (in a beta) and we followed up with a public release supporting that "chunk" before they did. You would not believe the amount of Usenet traffic and e-mail that generated (including flames)--and THAT was basic- ally an officially sanctioned extension to the format. Anyway, the short answer to your question is: you avoid annoying people unnecessarily. And believe me, they get plenty pissed when they spend time downloading a largish file and only then discover that they can't decode it and, even worse, that they can't even acquire the tools necessary to decode it. (That was not the case with our Zip/UnZip release, but it was with PKWARE's DOS-only beta.) I haven't checked lately: does pngcheck warn about unknown critical chunks, either private or public? I like your NNG suggestion, and as usual, Chris H's rewrite of my text is better than the original was. I'm not suggesting we outlaw private critical chunks, much as I'd like to, because that would break draft 9. But I would like to discourage their use in "PNG" files as much as possible. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 10:37:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA09502 for ; Mon, 26 Feb 1996 10:37:17 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA02876 for png-list-outgoing; Mon, 26 Feb 1996 10:37:46 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA02871 for ; Mon, 26 Feb 1996 10:37:41 -0600 Date: Mon, 26 Feb 96 11:33:31 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602261133.aa08221@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > And believe me, they get plenty pissed when they spend > time downloading a largish file and only then discover that they can't > decode it and, even worse, that they can't even acquire the tools necess Their browser ought to give up on the download as soon as it discovers a critical unknown chunk. I guess that wouldn't work if said chunk appeared *after* the IDAT, but -- what's supposed to happen then, anyway? A sensible browser would have already displayed the image before it discovers that it can't. ../g ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 11:22:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA10084 for ; Mon, 26 Feb 1996 11:22:27 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA03735 for png-list-outgoing; Mon, 26 Feb 1996 11:22:48 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA03730 for ; Mon, 26 Feb 1996 11:22:42 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id MAA12587 for ; Mon, 26 Feb 1996 12:22:04 -0500 (EST) To: PNG List Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) In-reply-to: Your message of Mon, 26 Feb 1996 09:37:19 -0600 (CST) <199602261537.JAA09808@ellis.uchicago.edu> Date: Mon, 26 Feb 1996 12:22:03 -0500 Message-ID: <12585.825355323@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg writes: > Glenn writes: >> I do not agree with this whole train of thought. You are converting >> PNG from an extensible file format to a nonextensible file format. (Excellent pithy summary, Glenn.) > But there's a difference between useful extensions and useless ones. But can you demonstrate that private critical extensions are "useless"? That's a fairly large claim, and the fact that you can't think of a use for it at the moment is hardly proof that there isn't one. I just thought of a different argument for allowing private critical chunks: if we prohibit or strongly discourage such chunks, developers working with private extensions will have a strong motivation to label those extensions noncritical, *even when they really ought to be critical*. It's not that difficult to fool yourself about the distinction, as we've seen ourselves. (Example: a good argument can be made that tRNS should have been critical, for uniformity with the full-alpha-channel semantics.) If that happens, we've created a compatibility problem far worse than we'd have if those private chunks were correctly labeled as critical. In fact, it'd be exactly analogous to the TIFF mess, where you never know for sure if it's safe to ignore some unknown tag. > It seems to me that you have probably never dealt with an incompatible > change to a popular file format before. I have ;-) > We went through all of this in > 1992-1993 when PKWARE came out with a "new critical chunk" in the ZIP > format (in a beta) and we followed up with a public release supporting > that "chunk" before they did. You would not believe the amount of Usenet > traffic and e-mail that generated (including flames)--and THAT was basic- > ally an officially sanctioned extension to the format. True but irrelevant. An unreadable file is an unreadable file. The issue is how good an error message you can produce, and as Glenn correctly points out, a private critical chunk is more likely to result in a helpful message than a variant signature (which would quite likely result in a totally misleading message about file corruption). The only way to completely prevent problems of this ilk is to forever forbid *any* incompatible extension to PNG, public or private. That cure is far worse than the disease. We have a good, solid, clean design for handling extensions to PNG when and if the need arises. Let's not muck it up at the last minute. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 12:25:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11297 for ; Mon, 26 Feb 1996 12:25:51 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA04945 for png-list-outgoing; Mon, 26 Feb 1996 12:26:17 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA04931 for ; Mon, 26 Feb 1996 12:24:53 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Mon, 26 Feb 1996 17:51:15 +0000 From: lilley Message-Id: <4063.9602261751@afs.mcc.ac.uk> Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) To: png-list@dworkin.wustl.edu Date: Mon, 26 Feb 1996 17:51:02 +0000 (GMT) In-Reply-To: <9602261133.aa08221@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 26, 96 11:33:31 am Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn said: > Their browser ought to give up on the download as soon as it discovers > a critical unknown chunk. I guess that wouldn't work if said chunk > appeared *after* the IDAT, but -- what's supposed to happen then, anyway? A > sensible browser would have already displayed the image before it discovers > that it can't. Now we get into conformance criteria. PNG is a streaming format. What is a valid decoder to do if a critical unknown chnk is found after the file has been displayed/ Blank it out and say "oops sorry, shouldn't have shown you that"? What about partial downloads? -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 12:36:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11342 for ; Mon, 26 Feb 1996 12:36:50 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA03229 for png-list-outgoing; Mon, 26 Feb 1996 11:00:34 -0600 Received: from boutell.com (boutell.com [204.137.132.17]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA03223 for ; Mon, 26 Feb 1996 11:00:27 -0600 Received: by boutell.com id AA14407 (5.67b/IDA-1.5 for png-list@dworkin.wustl.edu); Mon, 26 Feb 1996 09:08:32 -0800 From: Thomas Boutell Message-Id: <199602261708.AA14407@boutell.com> Subject: Leave The File Signature Alone To: png-list@dworkin.wustl.edu Date: Mon, 26 Feb 1996 09:08:31 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List We designed private critical chunks into PNG to give those who have a solid justification we did not anticipate a way to gracefully break older software. I agree that we should discourage the cavalier use of this facility. However, I think this business of changing the eight-byte signature is completely out to lunch. A PNG with private critical chunks is still a legal PNG; this was our original design decision and we should change our recommendations, not our design. -T ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 12:40:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11371 for ; Mon, 26 Feb 1996 12:40:52 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA05151 for png-list-outgoing; Mon, 26 Feb 1996 12:41:20 -0600 Received: from boutell.com (boutell.com [204.137.132.17]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA05142 for ; Mon, 26 Feb 1996 12:41:15 -0600 Received: by boutell.com id AA00923 (5.67b/IDA-1.5 for png-list@dworkin.wustl.edu); Mon, 26 Feb 1996 10:49:03 -0800 From: Thomas Boutell Message-Id: <199602261849.AA00923@boutell.com> Subject: Streaming and Critical Unknown Chunks To: png-list@dworkin.wustl.edu Date: Mon, 26 Feb 1996 10:49: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 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris Lilley said: >Now we get into conformance criteria. PNG is a streaming format. What is >a valid decoder to do if a critical unknown chnk is found after the file >has been displayed/ Blank it out and say "oops sorry, shouldn't have shown >you that"? > >What about partial downloads? Well, here's an interesting question. I think we need two things: 1. A recommendation that, if any private critical chunks are used, one should appear before IDAT as a signal. Suitably worded not to overly encourage the use of critical private chunks in the first place. 2. A notation that a warning of some kind in the viewer is sufficient iff #1 was not heeded. Even Netscape has various consoles and status lines where such information could reasonably appear. -T ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 13:03:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA11731 for ; Mon, 26 Feb 1996 13:03:55 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA05594 for png-list-outgoing; Mon, 26 Feb 1996 13:04:22 -0600 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA05586 for ; Mon, 26 Feb 1996 13:04:17 -0600 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id LAA17807 for ; Mon, 26 Feb 1996 11:03:34 -0800 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 11:04:09 -0800 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The confusion between 2.5 and 2.2 (and 0.45, its approximate reciprocal) is partly because of room lighting effects, and partly because people haven't always been consistent over the years. The developers of NTSC believed that the gamma of a TV receiver was about 2.8, but deliberately made the gamma correction value 1/2.2 so that the image on screen would have a gamma of about 1.27 relative to the original scene, to compensate for the assumed "dim surround" viewing. People then built cameras with a gamma of 1/2.2 or 0.45 - which are not truly reciprocals of each other, but were effectively reciprocals in slide-rule days. Then when we entered the higher-precision calculator and computer era, and then the digital signal processing era, and more precise values needed to be had. So someone standardized on a particular camera transfer function that has an exponent of 0.45 (not 1/2.2), but further modified to give constant slope at the low end. So, ultimately, the transfer function used in NTSC (and HDTV) is not a pure power function, and PNG can't represent it exactly using the gAMA chunk. But somewhere along the line, we decided that using gAMA 0.45 was "close enough" to the video transfer function, and a lot simpler than allowing multiple functions to be used. In the PAL world, the designers decided to do full gamma correction, and the PAL colour encoding spec specifies gamma correction of 1/2.8. This turns out to be too much gamma correction in practice, so it is my understanding that everyone ignores that part of the PAL spec and uses a gamma correction factor that is closer to what NTSC uses. Meanwhile, Poynton says that modern CRT's all have a gamma near 2.5. More accurately, CRT's don't have a constant gamma throughout their operating range anyway. So the real-world numbers really are not all consistent with each other. And I think that we do *not* want to try to include in the spec as much detail as I've written above to explain where all the strange numbers come from. At the same time, we do need to mention some numbers as a guide to current practice (digitized video is 0.45, monitors are best assumed to be 2.5 unless you have better measurements). It's difficult to know how much explanation to include, and how much to leave out. I did just pick up a copy of the 0.94 spec, and will read the sections that Chris mentioned as being inconsistent, with the aim of making them at least consistent with each other. Dave The television colour world has a bunch of similar inconsistencies, by the way. NTSC specified a particular set of chromaticities for its RGB phosphors which turned out to be impractical for production receivers. For a while, TV displays had arbitrarily different phosphor sets. SMPTE developed the SMPTE-C standard for a practical set of monitor phosphors, and most professional (TV studio) picture monitors use this now. Cameras are now aligned so that their output looks correct on these standard monitors, so in effect the NTSC primary chromaticites have changed - but the broadcast spec still specifies the old primaries, and the matrix that converts RGB to YIQ is still one that is appropriate for the old phosphors, not the new ones. But, anyway, the matrix is mathematically correct when its inputs are linear, while NTSC actually feeds gamma-corrected values into it, and this causes other errors. Meanwhile, consumer sets generally adhere to *none* of these standards - they use nonstandard phosphors, the wrong colour temperature, and deliberately misaligned colour decoders to trade off colour accuracy for other attributes (brightness, insensitivity to transmission problems). And the PAL people realized that the NTSC phosphors were unrealizable, so they picked a different set - but kept the colour conversion matrix that NTSC designed! So right from the beginning their matrix was inconsistent with their phosphor set. It seems best to ignore all of the TV colour stuff entirely in the spec. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 13:13:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA11885 for ; Mon, 26 Feb 1996 13:13:48 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA05755 for png-list-outgoing; Mon, 26 Feb 1996 13:14:22 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA05750 for ; Mon, 26 Feb 1996 13:14:18 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA11390 for png-list@dworkin.wustl.edu; Mon, 26 Feb 1996 13:13:20 -0600 (CST) Date: Mon, 26 Feb 1996 13:13:20 -0600 (CST) From: Cave Newt Message-Id: <199602261913.NAA11390@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: Private critical extensions (Re: PNG draft 0.94 is done) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List There seems to be at least a three-person consensus against my proposal (or parts thereof), and I can accept that, as long as it's clear that everyone actually understands what I was proposing. - Thomas thinks I'm talking about a spec _requirement_; not so. All of this is recommendation, and I explicitly said that we cannot prohibit these things. As a matter of fact, I would be happy to drop the recommendation about changing the file signature as long as the filename recommendation stands. That's really the more important issue for casual downloaders anyway. - Glenn assumes that everyone downloads with a graphical browser. I trust that pointing out this assumption obviates the need to explain how silly it is. - Tom spun off on a tangent about version numbers; completely off the subject, especially now. One new filename/signature pair for all private-critical-chunk files has nothing to do with version numbers. (And distinguishing file formats in the first character is only necessary when there are formats with a one- or two-character signature starting with the same letter, and also software that only checks that one letter--i.e., PBM/PGM/PPM. Not a problem for \137 or whatever PNG's first character is.) - Tom claims my inability to see any possible public usefulness in private critical chunks is shortsighted. Fine, I'm willing to concede the point: spin me a hypothetical situation where some private critical chunk in a file with a .png extension, floating around in public places, makes more sense than the same thing in a file with a .nng extension. Remember that any benefits you name must outweigh the drawbacks of having permanently incompatible (in the sense that the official libpng will not support them) PNG files loose. Every scenario I've tried to imagine is either better as a .nng file or else becomes public (e.g., arithmetic or wavelet-based IDATs, vector graphics, etc.). - Tom's argument about discouragement of private critical chunks leading to private non-critical ones instead is disingenuous. Every developer will decide for him- or herself whether it would be better to display the file "incorrectly" (private ancillary) or not at all (private critical). We are under no obligation to second-guess such developers; the alternative is to encourage user confusion as I've outlined before. If tRNS didn't exist and I were thinking of creating it, you can be damn sure I'd make it noncritical. I'd much rather have people be able to see *some* version of my image than not see it at all. If there were some situations where that were not the case, I might invent both types, but I'd rename the files with the critical version. Tom's point about goodness of error messages is a good one; I just checked with various Unix/X tools and found the error messages to be sufficient, although in every case they were sent to the console rather than a pop-up error window. (XV with PNG patch 1.0 just crashes, but I'm assuming the more recent patch/library combo fixes that.) Unfortunately the apps were also all based on libpng, but since most PNG-supporting apps are (as far as I can tell), that's probably not a big problem. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 14:36:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA13233 for ; Mon, 26 Feb 1996 14:36:41 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA07720 for png-list-outgoing; Mon, 26 Feb 1996 14:35:26 -0600 Received: from dub-img-5.compuserve.com (dub-img-5.compuserve.com [198.4.9.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA07715 for ; Mon, 26 Feb 1996 14:35:22 -0600 Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id PAA25959; Mon, 26 Feb 1996 15:34:34 -0500 Date: 26 Feb 96 15:31:16 EST From: Owen Mortensen To: ngf , Tom Lane Subject: Re: Status of different parts of the spec (Re: PNG draft 0.94 is done) Message-ID: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom Lane wrote: >On political grounds, I think we ought not to write >anything that could be read as an admission that we think there are >mistakes ;-) There aren't any mistakes or inconsistencies in the spec? The only other non-trivial work that's had that bold statement made about it (sorry about the grammar) was TeX. I don't recall whether any bugs were actually found, but as I remember, Donald Knuth put a bounty on any that anyone could find. I don't think PNG 0.95 is that far ... yet ;-) Mighty close.... Owen ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Feb 26 14:47:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA13330 for ; Mon, 26 Feb 1996 14:47:04 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA07952 for png-list-outgoing; Mon, 26 Feb 1996 14:46:11 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA07947 for ; Mon, 26 Feb 1996 14:46:05 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id PAA13639; Mon, 26 Feb 1996 15:45:22 -0500 (EST) To: Owen Mortensen cc: ngf Subject: Re: Status of different parts of the spec (Re: PNG draft 0.94 is done) In-reply-to: Your message of 26 Feb 96 15:31:16 EST Date: Mon, 26 Feb 1996 15:45:22 -0500 Message-ID: <13637.825367522@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Owen writes: > Tom Lane wrote: >> On political grounds, I think we ought not to write >> anything that could be read as an admission that we think there are >> mistakes ;-) > There aren't any mistakes or inconsistencies in the spec? I didn't say I think there are no mistakes ;-). I said I thought it would be politically unwise to say *in the spec* that we think there are mistakes. Or more precisely, to say anything that might be construed as meaning that (whether or not we meant it that way). It serves no useful purpose and might provide cannon fodder for the anti-PNG contingent. Stating that the appendices are not part of the formal spec seems quite sufficient to me, and it carries no negative connotations. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 10:01:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA24699 for ; Tue, 27 Feb 1996 10:00:59 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA22141 for png-list-outgoing; Tue, 27 Feb 1996 10:00:14 -0600 Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA22111 for ; Tue, 27 Feb 1996 09:59:41 -0600 Received: from mint.ukc.ac.uk by mercury.ukc.ac.uk with SMTP (PP); Tue, 27 Feb 1996 15:58:28 +0000 Received: from localhost (localhost.ukc.ac.uk) by mint.ukc.ac.uk (4.1/UKC-2.14) id AA12532; Tue, 27 Feb 96 15:58:24 GMT To: PNG List Subject: PNG meta data with Harvest Date: Tue, 27 Feb 1996 15:58:24 +0000 Message-Id: <12531.825436704@mint.ukc.ac.uk> From: Dave Beckett Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have just installed pngmeta with Harvest 1.4pl2 to full-text (or should that be full-image) index the PNG images at my mirror of the PNG ftp sites at http://www.hensa.ac.uk/png/ For example, searching for 'NeXTstation color pnmtopng' returns the correct image, ctzn0g04.png, which is a PNG image from the test suite with compressed text fields. image-format{3}: PNG image-colors{1}: 4 image-width{2}: 32 image-height{2}: 32 image-type{25}: Grayscale, non-interlaced title{8}: PngSuite author{49}: Willem A.J. van Schaik (gwillem@ntuvax.ntu.ac.sg) copyright{43}: Copyright Willem van Schaik, Singapore 1995 description{239}: A compilation of a set of images created to test the various color-types of the PNG format. Included are black&white, color, paletted, with alpha channel, with transparency formats. All bit-depths allowed according to the spec are present. software{48}: Created on a NeXTstation color using "pnmtopng". disclaimer{9}: Freeware. This component (in Harvest terminology) containing pngmeta, zlib and libpng can now be easily added to Harvest. I will package it up soon and submit to the harvest group, who hopefully can put it in the harvest contributed area, if not the distribution itself. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 10:44:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA25937 for ; Tue, 27 Feb 1996 10:44:28 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA22754 for png-list-outgoing; Tue, 27 Feb 1996 10:44:56 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA22725 for ; Tue, 27 Feb 1996 10:44:45 -0600 Date: Tue, 27 Feb 96 11:41:10 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271141.aa02435@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris Lilley wrote: > Section 4.1.1 "At present, only compression type 0 [...] future > expansion" and "Two values are currently defined". We do not say how > these values might be added to, but the text implies that this is > possible. Should this be clarified? Do other values make it: > > - A valid PNG 1.0 file that is not at all portable > - An invalid PNG 1.0 (might be a PNG 2.0, for example) > - An invalid PNG file, period. I think it is a valid PNG 1.0 file that is not at all portable. The spec clearly states, in the IHDR section, that the decoder "must report an error (end of section 10.2 says "should") if it finds an unrecognized compression type. We don't say clearly what "unrecognized" means ([a] not defined in PNG 1.0, or [b] not defined in PNG 1.0 or in a private extension or future public extension) I interpret as [b]. There is a problem here, though. We haven't defended against private extensions that define a compression_type 2, when compression_type 2 might become defined later in PNG 2.0. The public/private chunk naming scheme prevents such clashes with future public chunk names. We could put in a requirement that private or experimental extensions to compression_type and filter_type must use numbers greater than 127, reserving the lower numbers for possible future expansion of the spec. I don't remember whether we discussed that last year or not; we might have decided not to put in such language because it would seem to approve of such extensions. We should strongly recommend that any file with such private extensions also include a tEXt chunk explaining exactly what the extensions mean. Alternatively, we could forbid such extensions. I don't think that's a good idea, but I'm sure others in this group do. As far as decoder handling of such files goes, I think we could say: If a decoder encounters an unknown filter_type it must not attempt to unfilter or display the data, and if it encounters an unknown compression_type byte it must not attempt to decompress the IDATs (or if it encounters an unknown compression_type in a zTXt chunk, then it must not attempt to decompress the zTXt data). A PNG editor that does not need to decompress or defilter the image is allowed to copy the filter_type and compression_type bytes from the IHDR chunk and the compressed/filtered IDATs (or the zTXt chunks), just as it is allowed (even encouraged) to copy unknown ancillary chunks. If a decoder encounters an unknown filter_type byte for an individual scanline, it must treat it as an error and must not attempt to decode the scanline or any subsequent scanlines that depend on its contents. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 11:48:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA26984 for ; Tue, 27 Feb 1996 11:48:27 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA23788 for png-list-outgoing; Tue, 27 Feb 1996 11:48:53 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA23782 for ; Tue, 27 Feb 1996 11:48:47 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA17267; Tue, 27 Feb 1996 17:48:01 GMT Date: Tue, 27 Feb 1996 17:48:01 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9602271748.AA17267@siesta.cs.wustl.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn says: > The spec clearly states, in the IHDR section, that the decoder "must > report an error (end of section 10.2 says "should") if it finds an > unrecognized compression type. It's the end of section 10.1, and it should be made consistent. > We don't say clearly what "unrecognized" means ([a] not defined in PNG > 1.0, or [b] not defined in PNG 1.0 or in a private extension or future > public extension) I interpret as [b]. Hmmm, I thought "unrecognized" was a simple enough English word, but I interpret it as meaning that the software doesn't know what it means. That is neither [a] nor [b] above. It depends on which spec the author of the software was using when he wrote it. > There is a problem here, though. We haven't defended against private > extensions that define a compression_type 2, when compression_type 2 > might become defined later in PNG 2.0. Very good point. > We could put in a requirement that private or experimental extensions > to compression_type and filter_type must use numbers greater than 127, > reserving the lower numbers for possible future expansion of the spec. Good idea. Also for interlace_type bytes and unit specifier bytes. Any others? AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 12:24:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA27412 for ; Tue, 27 Feb 1996 12:24:54 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA24300 for png-list-outgoing; Tue, 27 Feb 1996 12:24:59 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA24295 for ; Tue, 27 Feb 1996 12:24:53 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id NAA15218 for ; Tue, 27 Feb 1996 13:24:08 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Tue, 27 Feb 1996 17:48:01 GMT <9602271748.AA17267@siesta.cs.wustl.edu> Date: Tue, 27 Feb 1996 13:24:08 -0500 Message-ID: <15216.825445448@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn & Adam say: >> We could put in a requirement that private or experimental extensions >> to compression_type and filter_type must use numbers greater than 127, >> reserving the lower numbers for possible future expansion of the spec. > Good idea. Also for interlace_type bytes and unit specifier bytes. I'd be in favor of some such language also. However, if I correctly interpret what Greg was saying a few days ago, he's not. The alternative (other than to continue to say nothing, and hope people will do the Right Thing) is to say that nonstandard values of compression type and other codes are forbidden. I don't believe that that's realistic. I think people *will* want to experiment, maybe not right away, but eventually. We'd be better off to make sure that any experimental codes will not get in the way of future public extensions to the spec. I think what Greg wanted to do was to forbid nonstandard codes and instead tell people who want to perform such experiments to use private critical chunks to label their files. But a critical chunk that means "the compression type code in IHDR is a lie, this file is really compressed with method XYZ" is a horribly ugly wart. I suspect that developers would ignore such a ridiculous requirement and do what's obvious and natural, ie, invent a new compression type code. That's *obviously* what the field is there for. Furthermore, the separate-chunk approach doesn't generalize: for example, you can't readily use it to indicate that some particular zTXt chunk is compressed with an unusual method, especially if others might not be. A further problem with using critical chunks (or even worse, different signatures) is that it totally kills compatibility when that might not be necessary. For example, being unable to decompress a particular zTXt chunk probably wouldn't bother most viewers; they likely aren't even examining zTXt chunks' contents. A critical chunk is a sledgehammer, not a useful tool for indicating nonstandardness in an ancillary chunk. So, I don't believe that the alternatives we have are to forbid or allow private codes in these fields. Our real choices are to control what private codes may be used, or to fail to have any control. How about a compromise: would it make sense to require anyone using private codes in fields of public chunks to register their use with the PNG maintainers? That would allow the maintainers to assign unique codes to private experiments, which would benefit everybody. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 13:06:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA27746 for ; Tue, 27 Feb 1996 13:06:24 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA24995 for png-list-outgoing; Tue, 27 Feb 1996 13:06:53 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA24990 for ; Tue, 27 Feb 1996 13:06:49 -0600 Date: Tue, 27 Feb 96 14:00:59 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271400.aa07530@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Tue, 27 Feb 1996 13:24:08 -0500 > From: Tom Lane > Glenn & Adam say: > >> We could put in a requirement that private or experimental extensions > >> to compression_type and filter_type must use numbers greater than 127 [...] > How about a compromise: would it make sense to require anyone using > private codes in fields of public chunks to register their use with the > PNG maintainers? That would allow the maintainers to assign unique codes > to private experiments, which would benefit everybody. More work for us to keep the list. Some people won't do it. We'll run out of numbers. Would registration be automatic, or would it require a 6+ month e-mail debate like that over pCAL? I think it's sufficient just to reserve the low numbers for the official extensions, and let the experimenters worry about keeping control of their own files so they don't clash with other experimenters using the same number. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 13:16:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA27805 for ; Tue, 27 Feb 1996 13:16:16 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25183 for png-list-outgoing; Tue, 27 Feb 1996 13:16:56 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25178 for ; Tue, 27 Feb 1996 13:16:53 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA19594 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 13:15:33 -0600 (CST) Date: Tue, 27 Feb 1996 13:15:33 -0600 (CST) From: Cave Newt Message-Id: <199602271915.NAA19594@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn, Adam, Tom et al.: >>> We could put in a requirement that private or experimental extensions >>> to compression_type and filter_type must use numbers greater than 127, >>> reserving the lower numbers for possible future expansion of the spec. >> Good idea. Also for interlace_type bytes and unit specifier bytes. > I'd be in favor of some such language also. However, if I correctly > interpret what Greg was saying a few days ago, he's not. I'm not fond of the idea, but I agree that forcing someone to use a private critical chunk is much uglier. I would much prefer the following: - set aside 128 and up for private/experimental use - clarify that the filter_type byte in IHDR refers to filter *sets* - add a recommendation strongly discouraging the idea (and incompatible private extensions in general) - recommend a different file extension (.nng) to avoid confusion whenever incompatible private PNG extensions are used I agree that hoping people will do the Right Thing is a bad idea. Most will, but it only takes one to make a mess. > How about a compromise: would it make sense to require anyone using > private codes in fields of public chunks to register their use with the > PNG maintainers? That would allow the maintainers to assign unique codes > to private experiments, which would benefit everybody. Seems like a good idea, and one that most developers would have a hard time arguing with. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 13:20:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA27841 for ; Tue, 27 Feb 1996 13:20:42 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25261 for png-list-outgoing; Tue, 27 Feb 1996 13:21:14 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25255 for ; Tue, 27 Feb 1996 13:21:11 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA20212 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 13:19:51 -0600 (CST) Date: Tue, 27 Feb 1996 13:19:51 -0600 (CST) From: Cave Newt Message-Id: <199602271919.NAA20212@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: speaking of draft 0.94... Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List ...which is available all over the planet, but *not* in our official documents directory, could Keith or somebody please move a copy into /pub/png/documents? (Or 0.95, if that's the one IETF has.) It seems kind of silly to be worrying about minute details when draft 10 is obviously in far worse shape. (Not that draft 10 is bad, of course, but there's been a lot of nice work on the spec since May 1995.) Thanks, Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 13:28:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA27915 for ; Tue, 27 Feb 1996 13:28:36 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25379 for png-list-outgoing; Tue, 27 Feb 1996 13:29:10 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25374 for ; Tue, 27 Feb 1996 13:29:05 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id OAA15374 for ; Tue, 27 Feb 1996 14:28:20 -0500 (EST) To: PNG List Subject: Re: speaking of draft 0.94... In-reply-to: Your message of Tue, 27 Feb 1996 13:19:51 -0600 (CST) <199602271919.NAA20212@ellis.uchicago.edu> Date: Tue, 27 Feb 1996 14:28:20 -0500 Message-ID: <15372.825449300@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > ...which is available all over the planet, but *not* in our official > documents directory, could Keith or somebody please move a copy into > /pub/png/documents? (Or 0.95, if that's the one IETF has.) I agree, it's time to replace draft 10 in our public archives. 0.94 is almost identical to 0.95, so whichever one Keith has handy is fine. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 13:47:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA28060 for ; Tue, 27 Feb 1996 13:47:24 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25608 for png-list-outgoing; Tue, 27 Feb 1996 13:47:51 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA25600 for ; Tue, 27 Feb 1996 13:47:47 -0600 Date: Tue, 27 Feb 96 14:46:34 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271446.aa09050@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Subject: Re: PNG draft 0.94 is done > Date: Tue, 27 Feb 1996 13:24:08 -0500 > Message-ID: <15216.825445448@sss.pgh.pa.us> > From: Tom Lane > Glenn & Adam say: > >> We could put in a requirement that private or experimental extensions > >> to compression_type and filter_type must use numbers greater than 127 > >> reserving the lower numbers for possible future expansion of the spec. > > > Good idea. Also for interlace_type bytes and unit specifier bytes. > > I'd be in favor of some such language also. However, if I correctly > interpret what Greg was saying a few days ago, he's not. > Here's some specific language for you to take potshots at, and for Chris&Chris to edit (paragraph numbers refer to Png-0.94): Add to Paragraph 8.1: If the file contains private critical chunks or private compression type bytes, filter type bytes, etc., that are not defined in this specification, it's a good idea to use an extension other than ".png". You can use the extension ".nng" (Nonportable Network Graphics) instead, to help avoid confusion when such files are rightfully rejected by decoders that are unaware of your private additions to this specificaton. Add Paragraph 9.9: 9.9 Private extensions If you wish to write PNG files with an experimental or private compression method, filter type, interlace type, color type, unit specifier, etc., use a number greater than 127 for the corresponding type byte. The lower numbers are reserved for possible future extensions of this specification. (See also Paragraph 8.1, File Name Extension) Add to Paragraph 4.4, 3rd subparagraph: See also Paragraph 8.1, File Name Extension ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:01:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28247 for ; Tue, 27 Feb 1996 14:01:17 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25798 for png-list-outgoing; Tue, 27 Feb 1996 14:01:49 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA25793 for ; Tue, 27 Feb 1996 14:01:45 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA20627; Tue, 27 Feb 1996 20:00:57 GMT Date: Tue, 27 Feb 1996 20:00:57 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9602272000.AA20627@siesta.cs.wustl.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn proposes: > 9.9 Private extensions > > If you wish to write PNG files with an experimental or private > compression method, filter type, interlace type, color type, unit > specifier, etc., use a number greater than 127 for the corresponding > type byte. The lower numbers are reserved for possible future > extensions of this specification. (See also Paragraph 8.1, File Name > Extension) Looks good, except that the imprecision of "etc." bothers me slightly. Keeping a fully enumerated list of all these things in one place would be a hassle as extension chunks are registered. Another possibility is to put this information in each place where it's relevant. For example, in section 4.2.5: 0: unit is unknown 1: unit is the meter 2-127: reserved 128-255: for experimental use AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:05:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28303 for ; Tue, 27 Feb 1996 14:05:40 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25860 for png-list-outgoing; Tue, 27 Feb 1996 14:06:20 -0600 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA25855 for ; Tue, 27 Feb 1996 14:06:12 -0600 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) id PAA11074 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 15:05:28 -0500 Message-Id: <199602272005.PAA11074@qnx.com> Subject: Re: PNG draft 0.94 is done To: png-list@dworkin.wustl.edu Date: Tue, 27 Feb 1996 15:05:20 -0500 (EST) From: "Chris Herborth" In-Reply-To: <9602271446.aa09050@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 27, 96 02:46:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Your wish is my command Glen: > Add to Paragraph 8.1: > > If the file contains private critical chunks or private compression > type bytes, filter type bytes, etc., that are not defined in this > specification, it's a good idea to use an extension other than ".png". > You can use the extension ".nng" (Nonportable Network Graphics) instead, > to help avoid confusion when such files are rightfully rejected by decoders > that are unaware of your private additions to this specificaton. Use a different file extension, such as ".nng" (Non-portable network graphics) when creating a file with private critical chunks, compression types, filter types, etc. not defined in this specification. This avoids confusion when these files are (correctly) rejected by decoders that cannot process your private extentions. > Add Paragraph 9.9: > > 9.9 Private extensions > > If you wish to write PNG files with an experimental or private compression > method, filter type, interlace type, color type, unit specifier, etc., > use a number greater than 127 for the corresponding type byte. The lower > numbers are reserved for possible future extensions of this specification. > (See also Paragraph 8.1, File Name Extension) Use a number greater than 127 for the type byte when creating PNG files with experimental or private compression methods, filter types, interlace types, color types, unit specifiers, etc.. Numbers below 128 are reserved for possible future extension of this specification. (See also Paragraph 8.1, File Name Extension) > Add to Paragraph 4.4, 3rd subparagraph: See also Paragraph 8.1, File > Name Extension -- ----------========================================================---------- Chris Herborth, R&D Technical Writer Arcane Dragon chrish@qnx.com QNX Software Systems, Ltd. -==(UDIC)==- ||| JAGUAR http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge / | \ 64-bit ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:06:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28311 for ; Tue, 27 Feb 1996 14:06:31 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25878 for png-list-outgoing; Tue, 27 Feb 1996 14:07:03 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA25873 for ; Tue, 27 Feb 1996 14:07:00 -0600 Date: Tue, 27 Feb 96 15:00:20 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: speaking of draft 0.94... Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271500.aa11321@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Tue, 27 Feb 1996 13:19:51 -0600 (CST) > From: Cave Newt > Subject: speaking of draft 0.94... > ...which is available all over the planet, but *not* in our official > documents directory, could Keith or somebody please move a copy into > /pub/png/documents? (Or 0.95, if that's the one IETF has.) It seems > kind of silly to be worrying about minute details when draft 10 is > obviously in far worse shape. > > (Not that draft 10 is bad, of course, but there's been a lot of nice > work on the spec since May 1995.) > > Thanks, > Greg Keith, I have uploaded a copy of draft-boutell-png-spec-00.txt, which is Png-0.95. Please move it to /pub/png/documents. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:11:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28412 for ; Tue, 27 Feb 1996 14:11:28 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25966 for png-list-outgoing; Tue, 27 Feb 1996 14:12:00 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA25955 for ; Tue, 27 Feb 1996 14:11:53 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id PAA15459 for ; Tue, 27 Feb 1996 15:11:08 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Tue, 27 Feb 96 14:46:34 EST <9602271446.aa09050@THOR.ARL.MIL> Date: Tue, 27 Feb 1996 15:11:07 -0500 Message-ID: <15457.825451867@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > If the file contains private critical chunks or private compression > type bytes, filter type bytes, etc., that are not defined in this > specification, it's a good idea to use an extension other than ".png". I'm unreservedly against this. As Glenn himself said the other day, this amounts to suddenly deciding that PNG is not an extensible format. It's a silly and unenforceable idea. If that was what we intended to do, we should have designed the format as a closed format from day one. Would've saved a lot of work. I would also point out that if there ever is a PNG 2.0 spec containing new compression or whatever, it will create the *exact same* compatibility problems as an incompatible private extension. Do you intend to select a new file name extension for PNG 2.0 as well? > If you wish to write PNG files with an experimental or private compression > method, filter type, interlace type, color type, unit specifier, etc., > use a number greater than 127 for the corresponding type byte. The lower > numbers are reserved for possible future extensions of this specification. This part sounds good. Is it sufficient to make it a new section 9.9, or do we need cross-references elsewhere? (In particular, section 10.1 probably ought to mention the possibility of unknown type bytes.) It might also be good to ensure that we consistently refer to all these fields as "typecode bytes" or something like that. Glossary entry, here we come... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:15:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28458 for ; Tue, 27 Feb 1996 14:15:39 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26174 for png-list-outgoing; Tue, 27 Feb 1996 14:16:19 -0600 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26167 for ; Tue, 27 Feb 1996 14:16:15 -0600 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.4/8.7.1) id OAA07535 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 14:15:25 -0600 (CST) Message-Id: <199602272015.OAA07535@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Tue, 27 Feb 1996 14:15:25 -0600 In-Reply-To: Tom Lane "Re: speaking of draft 0.94..." (Feb 27, 2:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG List Subject: Re: speaking of draft 0.94... Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Feb 27, 2:28pm, Tom Lane wrote: } Subject: Re: speaking of draft 0.94... } > ...which is available all over the planet, but *not* in our official } > documents directory, could Keith or somebody please move a copy into } > /pub/png/documents? (Or 0.95, if that's the one IETF has.) } } I agree, it's time to replace draft 10 in our public archives. } } 0.94 is almost identical to 0.95, so whichever one Keith has handy is } fine. Installed 0.94 in the public archives. I have a 25Aug95 copy of the FAQ. Is this current? -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:27:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28701 for ; Tue, 27 Feb 1996 14:27:15 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26283 for png-list-outgoing; Tue, 27 Feb 1996 14:27:50 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA26278 for ; Tue, 27 Feb 1996 14:27:46 -0600 Date: Tue, 27 Feb 96 15:26:27 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271526.aa11857@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Tue, 27 Feb 1996 13:15:33 -0600 (CST) > From: Cave Newt > > - clarify that the filter_type byte in IHDR refers to filter *sets* I like the idea of not using "filter type" here because we also use "filter type" for the individual scanlines. But I would call the IHDR field "filter method" rather than "filter set". "filter method" 0 does happen to mean "use the set of filters 0-4", but some future value of "filter method" might not mean "use some set of filters". So the only change I would make is, in Paragraph 4.1.1, change "filter type" to "filter method" (except where it says "five basic filter types", which should be left as it is). ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:28:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28718 for ; Tue, 27 Feb 1996 14:28:11 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26302 for png-list-outgoing; Tue, 27 Feb 1996 14:28:42 -0600 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26296 for ; Tue, 27 Feb 1996 14:28:37 -0600 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.4/8.7.1) id OAA07599 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 14:27:52 -0600 (CST) Message-Id: <199602272027.OAA07599@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Tue, 27 Feb 1996 14:27:52 -0600 In-Reply-To: Glenn Randers-Pehrson ARL-WTD-TED-TIB "Re: speaking of draft 0.94..." (Feb 27, 3:00pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG List Subject: Re: speaking of draft 0.94... Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Feb 27, 3:00pm, Glenn Randers-Pehrson ARL-WTD-TED-TIB wrote: } Subject: Re: speaking of draft 0.94... } } In reply to the message } > Date: Tue, 27 Feb 1996 13:19:51 -0600 (CST) } > From: Cave Newt } > Subject: speaking of draft 0.94... } > ...which is available all over the planet, but *not* in our official } > documents directory, could Keith or somebody please move a copy into } > /pub/png/documents? (Or 0.95, if that's the one IETF has.) It seems } > kind of silly to be worrying about minute details when draft 10 is } > obviously in far worse shape. } > } > (Not that draft 10 is bad, of course, but there's been a lot of nice } > work on the spec since May 1995.) } > } > Thanks, } > Greg } } Keith, I have uploaded a copy of draft-boutell-png-spec-00.txt, which } is Png-0.95. Please move it to /pub/png/documents. } I added this to /pub/png/documents but did not remove the 0.94 copies. The 0.94 stuff has html and ps. Does anyone see a problem with this? -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:35:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28878 for ; Tue, 27 Feb 1996 14:35:43 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26461 for png-list-outgoing; Tue, 27 Feb 1996 14:36:24 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26456 for ; Tue, 27 Feb 1996 14:36:18 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id PAA15543 for ; Tue, 27 Feb 1996 15:35:33 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Tue, 27 Feb 96 15:26:27 EST <9602271526.aa11857@THOR.ARL.MIL> Date: Tue, 27 Feb 1996 15:35:33 -0500 Message-ID: <15541.825453333@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > So the only change I would make is, in Paragraph 4.1.1, change "filter type" > to "filter method" (except where it says "five basic filter types", which > should be left as it is). Not a bad idea, though we probably should change "compression type" and "interlace type" to "methods" also, for consistency. (But "color method" wouldn't be right; that stays as it is.) Also, I like Adam's idea: >Another possibility is to put this information in each place where it's >relevant. For example, in section 4.2.5: > 0: unit is unknown > 1: unit is the meter > 2-127: reserved > 128-255: for experimental use although "reserved" is perhaps a little too brief. Maybe "reserved for future public definition"? regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 14:45:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28939 for ; Tue, 27 Feb 1996 14:45:13 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26688 for png-list-outgoing; Tue, 27 Feb 1996 14:45:51 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26681 for ; Tue, 27 Feb 1996 14:45:47 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id OAA03473 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 14:44:26 -0600 (CST) Date: Tue, 27 Feb 1996 14:44:26 -0600 (CST) From: Cave Newt Message-Id: <199602272044.OAA03473@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: recommendations, not requirements Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom writes: > I'm unreservedly against this. As Glenn himself said the other day, > this amounts to suddenly deciding that PNG is not an extensible format. No, it does not. PNG is defined by the signature bytes and, indirectly, by the other internal self-consistency checks. The filename is of use primarily to humans, and changing the filename does not alter the fact that it's a PNG file. (I have already agreed that changing the signature was a bad idea.) > It's a silly and unenforceable idea. It's a *recommendation*. Recommendation != enforceable, which is so nearly a tautology that I don't know why it even came up. Nobody is forbidding anybody from doing any of this stuff, *including* using compression type 2 for private purposes, because that would deliberately break draft 9. > I would also point out that if there ever is a PNG 2.0 spec containing new > compression or whatever, it will create the *exact same* compatibility > problems as an incompatible private extension. Do you intend to select > a new file name extension for PNG 2.0 as well? Dammit, Tom, it is NOT THE SAME. PNG 2.0 will be supported by an official PNG 2.0 library (which may or may not still be maintained by Guy), at which time the files will suddenly be comprehensible to the world (cf. libjpeg v6). It will be the result of months of endless bickering over stupid things like this, plus an occasional brilliant idea, all distilled into some sort of well-defined, well-thought-out specification. Incompatible private extensions, on the other hand, will probably not undergo the same scrutiny and dissection; they will *never* be supported by the official library; and they will therefore *always* be incompatible and unusable to anyone but the person or persons creating them. I don't know how to say that any more plainly. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 15:41:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA29991 for ; Tue, 27 Feb 1996 15:41:10 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA27678 for png-list-outgoing; Tue, 27 Feb 1996 15:41:34 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA27673 for ; Tue, 27 Feb 1996 15:41:28 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id QAA15739 for ; Tue, 27 Feb 1996 16:40:43 -0500 (EST) To: PNG List Subject: Re: recommendations, not requirements In-reply-to: Your message of Tue, 27 Feb 1996 14:44:26 -0600 (CST) <199602272044.OAA03473@ellis.uchicago.edu> Date: Tue, 27 Feb 1996 16:40:43 -0500 Message-ID: <15737.825457243@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg writes: > The filename is of use > primarily to humans, and changing the filename does not alter the fact > that it's a PNG file. (I have already agreed that changing the signature > was a bad idea.) If it is a PNG file, why shouldn't it be called one? >> I would also point out that if there ever is a PNG 2.0 spec containing new >> compression or whatever, it will create the *exact same* compatibility >> problems as an incompatible private extension. Do you intend to select >> a new file name extension for PNG 2.0 as well? > Dammit, Tom, it is NOT THE SAME. PNG 2.0 will be supported by an official > PNG 2.0 library [ ... and private extensions won't ] I remain unconvinced. The above argument seems perilously close to defining PNG as "whatever libpng supports". The folly of that idea need not be elaborated, I hope. > ... (which may or may not still be maintained by Guy), at which > time the files will suddenly be comprehensible to the world (cf. libjpeg v6). You are talking to the wrong guy to make the claim that the existence of libjpeg v6 suddenly makes progressive JPEG universally compatible. In fact, that example supports my point far more than yours. There's a *long* distance from the release of one library that supports a new file-format feature to the achievement of universal support for that feature. Even the developers who use libjpeg don't turn on a dime, and libjpeg is hardly the only implementation. I hope that by the time we start thinking about PNG 2.0, libpng will be far from the only implementation of PNG. (Actually, it's already far from the only implementation.) Any incompatible extension, public or private, will make it impossible to promise universal compatibility of PNG. But the history of every popular graphics format suggests it's better to design for extensibility than not to, and that's why we designed PNG as we did. I don't see the value in trying to prevent private extensions from calling themselves PNG. regards, tom lane organizer, Independent JPEG Group ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 16:37:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA01485 for ; Tue, 27 Feb 1996 16:37:46 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA29264 for png-list-outgoing; Tue, 27 Feb 1996 16:38:10 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA29254 for ; Tue, 27 Feb 1996 16:38:03 -0600 Date: Tue, 27 Feb 96 17:32:14 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271732.aa16087@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam says: > > Another possibility is to put this information in each place where it's > relevant. For example, in section 4.2.5: > > 0: unit is unknown > 1: unit is the meter > 2-127: reserved > 128-255: for experimental use This is certainly accurate and complete, but I'm not really sure we want this stuff pervading the entire spec. Let's wait and see if Chris/Chris come up with a better way of making a generic statement that just appears in the part of the spec relating to new chunks. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 16:47:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA01548 for ; Tue, 27 Feb 1996 16:47:41 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA29446 for png-list-outgoing; Tue, 27 Feb 1996 16:48:08 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA29438 for ; Tue, 27 Feb 1996 16:48:03 -0600 Date: Tue, 27 Feb 96 17:43:27 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602271743.aa16166@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Not a bad idea, though we probably should change "compression type" and > "interlace type" to "methods" also, for consistency. (But "color method" > wouldn't be right; that stays as it is.) > Best to leave "compression type" alone, because zlib internally has a "compression method" that we mention in the Compression section. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 18:36:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA02226 for ; Tue, 27 Feb 1996 18:36:14 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA01320 for png-list-outgoing; Tue, 27 Feb 1996 18:36:34 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA01315 for ; Tue, 27 Feb 1996 18:36:30 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id SAA10858 for png-list@dworkin.wustl.edu; Tue, 27 Feb 1996 18:35:05 -0600 (CST) Date: Tue, 27 Feb 1996 18:35:05 -0600 (CST) From: Cave Newt Message-Id: <199602280035.SAA10858@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: recommendations, not requirements Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom asked: > If it is a PNG file, why shouldn't it be called one? I've explained this already, too: it avoids the problem of casual (read: technically unsophisticated) users coming across a file calling itself .png, saying "hey, this has an interesting filename, and I can decode PNG files," and then spending half an hour downloading it, only to discover that they can't decode it after all. Yes, this can happen with PNG 2.0 as well. The difference is that in that case we can tell them to download version 2.0 of their viewer software, and thereafter they'll be able to view their big picture and all subsequent ones until PNG 3.0 comes along. I seem to recall that we used to decide arguments using the principle of least astonishment. Let me reverse the question, then: how is it less astonishing to users to call eternally incompatible image files ".png"? > I remain unconvinced. The above argument seems perilously close to > defining PNG as "whatever libpng supports". The folly of that idea > need not be elaborated, I hope. No; the point is that there is guaranteed to be at least *one* library that supports it. There is no such guarantee for incompatible private extensions. > You are talking to the wrong guy to make the claim that the existence of > libjpeg v6 suddenly makes progressive JPEG universally compatible. I didn't claim that it happens suddenly; obviously that's far from being true. But progressive JPEG has been in the spec for years; how many implementations can you name that existed before last July? And *that* was a feature officially described in the spec. What does that then say for private extensions to JPEG or to PNG? The points I'm trying to make are simply that (1) it does nobody any harm to recommend that privately extended PNG files have a .nng filename extension; (2) the existence of unsupported PNGs does hurt naive users, something that we can partially avoid with the recommendation; and (3) there is a fundamental difference in the support one can expect for an officially sanctioned incompatibility and a private one. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Feb 27 19:26:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA02507 for ; Tue, 27 Feb 1996 19:26:32 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA01871 for png-list-outgoing; Tue, 27 Feb 1996 19:25:46 -0600 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA01866 for ; Tue, 27 Feb 1996 19:25:40 -0600 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id RAA00868 for ; Tue, 27 Feb 1996 17:24:50 -0800 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 1996 17:25:27 -0800 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: recommendations, not requirements Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >I've explained this already, too: it avoids the problem of casual >(read: technically unsophisticated) users coming across a file calling >itself .png, saying "hey, this has an interesting filename, and I can >decode PNG files," and then spending half an hour downloading it, only >to discover that they can't decode it after all. > >Yes, this can happen with PNG 2.0 as well. The difference is that in >that case we can tell them to download version 2.0 of their viewer >software, and thereafter they'll be able to view their big picture >and all subsequent ones until PNG 3.0 comes along. > >I seem to recall that we used to decide arguments using the principle >of least astonishment. Let me reverse the question, then: how is it >less astonishing to users to call eternally incompatible image files >".png"? To me, this says that libpng should be particularly helpful in explaining this particular case. It should point out that yes, indeed, this is recognized as a PNG file, but that it cannot be displayed because the program that wrote the file in the first place is using some non-portable or non-standard private extension. Perhaps it could even print the 4-byte tag of the unrecognized chunk. Then, if someone does release a bunch of nonportable files onto the net, it should be reasonably clear who created the extension and exactly which files are affected by any particular chunk name. But files that adhere to the basic PNG definition should still be called .png, even if they have additional chunks that make them incompatible. Having an extra suffix for "non-portable portable network graphics" files seems to me even *more* confusing. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 05:36:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA05563 for ; Wed, 28 Feb 1996 05:36:02 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA08179 for png-list-outgoing; Wed, 28 Feb 1996 05:36:13 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA08174 for ; Wed, 28 Feb 1996 05:36:02 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Wed, 28 Feb 1996 11:33:09 +0000 From: lilley Message-Id: <2155.9602281133@afs.mcc.ac.uk> Subject: Re: PNG draft 0.94 is done To: png-list@dworkin.wustl.edu Date: Wed, 28 Feb 1996 11:33:05 +0000 (GMT) In-Reply-To: <9602271732.aa16087@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 27, 96 05:32:14 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > 0: unit is unknown > > 1: unit is the meter > > 2-127: reserved > > 128-255: for experimental use > This is certainly accurate and complete, but I'm not really sure we > want this stuff pervading the entire spec. Let's wait and see if > Chris/Chris come up with a better way of making a generic statement > that just appears in the part of the spec relating to new chunks. I am waiting to see what the consensus is before attempting to express it concisely. So far, there does not appear to be concensus on this issue. -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 06:03:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA05674 for ; Wed, 28 Feb 1996 06:03:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA08365 for png-list-outgoing; Wed, 28 Feb 1996 06:04:02 -0600 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA08360 for ; Wed, 28 Feb 1996 06:03:59 -0600 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) with UUCP id HAA32311 for png-list@dworkin.wustl.edu; Wed, 28 Feb 1996 07:03:11 -0500 Message-Id: <199602281203.HAA32311@qnx.com> Subject: Re: recommendations, not requirements To: png-list@dworkin.wustl.edu Date: Wed, 28 Feb 1996 07:03:10 -0500 (EST) From: "Chris Herborth" In-Reply-To: from "Dave Martindale" at Feb 27, 96 05:25:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List What you wrote: > To me, this says that libpng should be particularly helpful in explaining > this particular case. It should point out that yes, indeed, this is > recognized as a PNG file, but that it cannot be displayed because the > program that wrote the file in the first place is using some non-portable > or non-standard private extension. Perhaps it could even print the > 4-byte tag of the unrecognized chunk. Then, if someone does release > a bunch of nonportable files onto the net, it should be reasonably clear > who created the extension and exactly which files are affected by > any particular chunk name. Definitely. Ideally, the application would pop up a nice, big dialog box explaining the situation, though I suspect most programs will pop up a tiny one saying "Unsupported chunk: BoZO". We should create some PNG files with unsupported private critical chunks for the test suite to see how apps deal with them. > But files that adhere to the basic PNG definition should still be called > .png, even if they have additional chunks that make them incompatible. > Having an extra suffix for "non-portable portable network graphics" files > seems to me even *more* confusing. I agree with this; with an extensible file format, there's almost no such thing as an incompatible _file_ (assuming it follows the spec), just incompatible _viewers_. -- Chris Herborth, R&D Technical Writer Arcane Dragon chrish@qnx.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 07:49:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA06769 for ; Wed, 28 Feb 1996 07:49:28 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA09161 for png-list-outgoing; Wed, 28 Feb 1996 07:50:01 -0600 Received: from image.arl.mil (image.arl.mil [128.63.11.59]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA09152 for ; Wed, 28 Feb 1996 07:49:57 -0600 Date: Wed, 28 Feb 96 8:44:19 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602280844.aa02892@IMAGE.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Tue, 27 Feb 1996 15:05:20 -0500 (EST) > From: Chris Herborth > > Use a number greater than 127 for the type byte when creating PNG files > with experimental or private compression methods, filter types, > interlace types, color types, unit specifiers, etc.. Numbers > below 128 are reserved for possible future extension of this > specification. (See also Paragraph 8.1, File Name > Extension) > OK but doesn't address Adam's concern about "etc" and having to enumerate all the currently defined type codes. How about: Add Paragraph 9.9: This specification only defines the meaning of some of the possible values of some bytes (for example, only compression type 0 and filter types 0 through 4 are defined). Use numbers greater than 127 when inventing additional experimental or private definitions of values for any of these bytes. Numbers below 128 are reserved for possible future extension of this specification. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 08:58:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA07667 for ; Wed, 28 Feb 1996 08:58:33 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA09888 for png-list-outgoing; Wed, 28 Feb 1996 08:58:46 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA09883 for ; Wed, 28 Feb 1996 08:58:41 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id IAA13015 for png-list@dworkin.wustl.edu; Wed, 28 Feb 1996 08:57:50 -0600 (CST) Date: Wed, 28 Feb 1996 08:57:50 -0600 (CST) From: Cave Newt Message-Id: <199602281457.IAA13015@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: recommendations, not requirements Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> But files that adhere to the basic PNG definition should still be called >> .png, even if they have additional chunks that make them incompatible. >> Having an extra suffix for "non-portable portable network graphics" files >> seems to me even *more* confusing. > I agree with this; with an extensible file format, there's almost no > such thing as an incompatible _file_ (assuming it follows the spec), > just incompatible _viewers_. OK, I seem to be the only one who feels otherwise, so I'll not press the point any further. I do still want some private-incompatible-extension discouragement thrown in, however. Currently there is none. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 09:29:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA08410 for ; Wed, 28 Feb 1996 09:29:37 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA10396 for png-list-outgoing; Wed, 28 Feb 1996 09:30:05 -0600 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA10387 for ; Wed, 28 Feb 1996 09:30:00 -0600 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id KAA16750 for ; Wed, 28 Feb 1996 10:29:10 -0500 (EST) To: PNG List Subject: Re: PNG draft 0.94 is done In-reply-to: Your message of Wed, 28 Feb 1996 11:33:05 +0000 (GMT) <2155.9602281133@afs.mcc.ac.uk> Date: Wed, 28 Feb 1996 10:29:10 -0500 Message-ID: <16748.825521350@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris L. writes: >> This is certainly accurate and complete, but I'm not really sure we >> want this stuff pervading the entire spec. Let's wait and see if >> Chris/Chris come up with a better way of making a generic statement >> that just appears in the part of the spec relating to new chunks. > I am waiting to see what the consensus is before attempting to express > it concisely. So far, there does not appear to be concensus on this issue. I haven't seen any objections to the idea of specifying that 0-127 are reserved for public definition and 128-255 are available for private use in all the enumerated-code fields. The argument is about whether PNGs containing such extensions should still be called PNGs... Another thought: perhaps the spec should recommend that unknown values in enumerated-code fields be treated as fatal errors only in critical chunks. For example, you have to go belly up if you see an unknown compression type in IHDR, but if you see one in a zTXt chunk, you could carry on by ignoring that zTXt. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 09:52:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA08711 for ; Wed, 28 Feb 1996 09:52:30 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA10629 for png-list-outgoing; Wed, 28 Feb 1996 09:53:03 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA10624 for ; Wed, 28 Feb 1996 09:52:58 -0600 Date: Wed, 28 Feb 96 10:47:56 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: recommendations, not requirements Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602281047.aa00984@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Since everyone else seems to have yielded on the point, neither do I support the recommendation to use ".nng" file suffixes to indicate PNG files containing nonportable material. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 10:25:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA09058 for ; Wed, 28 Feb 1996 10:25:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA11212 for png-list-outgoing; Wed, 28 Feb 1996 10:23:12 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA11204 for ; Wed, 28 Feb 1996 10:23:08 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA10176; Wed, 28 Feb 1996 16:22:18 GMT Date: Wed, 28 Feb 1996 16:22:18 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9602281622.AA10176@siesta.cs.wustl.edu> To: png-list@dworkin.wustl.edu Subject: Re: PNG draft 0.94 is done Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom says: > Another thought: perhaps the spec should recommend that unknown values > in enumerated-code fields be treated as fatal errors only in critical > chunks. That makes perfect sense. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 10:43:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA09167 for ; Wed, 28 Feb 1996 10:43:15 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA11622 for png-list-outgoing; Wed, 28 Feb 1996 10:43:31 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA11617 for ; Wed, 28 Feb 1996 10:43:26 -0600 Date: Wed, 28 Feb 96 11:40:14 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602281140.aa02663@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message > Date: Wed, 28 Feb 1996 16:22:18 GMT > From: "Adam M. Costello" > Subject: Re: PNG draft 0.94 is done > Tom says: > > > Another thought: perhaps the spec should recommend that unknown values > > in enumerated-code fields be treated as fatal errors only in critical > > chunks. > > That makes perfect sense. > Yes. I think the right place to put it is in section 10.1, second paragraph: ...an unknown chunk type (or a known chunk type with unrecognized contents) is not to be treated as an error unless it is a critical chunk. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Feb 28 10:52:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA09226 for ; Wed, 28 Feb 1996 10:52:55 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA11799 for png-list-outgoing; Wed, 28 Feb 1996 10:53:35 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA11794 for ; Wed, 28 Feb 1996 10:53:30 -0600 Date: Wed, 28 Feb 96 11:45:18 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: Glenn Randers-Pehrson ARL-WTD-TED-TIB cc: PNG List Subject: Re: PNG draft 0.94 is done Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602281145.aa02866@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote > I think the right place to put it is in section 10.1, second paragraph: > > ...an unknown chunk type (or a known chunk type with unrecognized contents) > is not to be treated as an error unless it is a critical chunk. I meant is not to be treated as a fatal error unless it is a critical chunk. > ../glennrp > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 29 16:35:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA06961 for ; Thu, 29 Feb 1996 16:35:14 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA07865 for png-list-outgoing; Thu, 29 Feb 1996 16:34:25 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA07859 for ; Thu, 29 Feb 1996 16:34:22 -0600 Received: by THOR.ARL.MIL id aa12395; 29 Feb 96 17:28 EST Date: Thu, 29 Feb 96 17:26:24 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@dworkin.wustl.edu Subject: A question of style for PS versions Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9602291726.aa12191@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I've uploaded to swrinde zlib-indent.ps.gz and zlib-block.ps.gz (Keith, please move them to png-group/documents) The "block" paragraph style looks more like an RFC and like the HTML, but it takes about 10 percent more paper if you print it out. (10 pages vs 9 for zlib, 83 pages vs 75 for PNG) The "indent" paragraph style uses the default TeX behavior. Which do you like better? tom and I have already discussed this, and we need someone to break the tie :-) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 29 16:54:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA07102 for ; Thu, 29 Feb 1996 16:54:37 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA08033 for png-list-outgoing; Thu, 29 Feb 1996 16:55:15 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA08028 for ; Thu, 29 Feb 1996 16:55:10 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA14833; Thu, 29 Feb 1996 22:54:11 GMT Date: Thu, 29 Feb 1996 22:54:11 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9602292254.AA14833@siesta.cs.wustl.edu> To: png-list@dworkin.wustl.edu Subject: Re: A question of style for PS versions Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn says: > The "block" paragraph style looks more like an RFC and like the HTML, > but it takes about 10 percent more paper if you print it out. > > The "indent" paragraph style uses the default TeX behavior. > > Which do you like better? I find the block style to be much more readable for the zlib doc. That's probably because there are rarely ever three paragraphs in a row without a heading or list or illustration interrupting, and because indentation is also sometimes being used for hierarchy. Nitpick: In the block version, the abstract is still indented, but shouldn't be for consistency. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Feb 29 18:15:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA08000 for ; Thu, 29 Feb 1996 18:15:56 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA10047 for png-list-outgoing; Thu, 29 Feb 1996 18:16:10 -0600 Received: from utserv.mcc.ac.uk (utserv.mcc.ac.uk [130.88.200.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA10042 for ; Thu, 29 Feb 1996 18:15:55 -0600 Received: from afs.mcc.ac.uk (actually cguhpc.cgu.mcc.ac.uk) by utserv.mcc.ac.uk with SMTP (PP); Fri, 1 Mar 1996 00:14:21 +0000 From: lilley Message-Id: <15433.9603010014@afs.mcc.ac.uk> Subject: Re: A question of style for PS versions To: png-list@dworkin.wustl.edu Date: Fri, 1 Mar 1996 00:14:30 +0000 (GMT) In-Reply-To: <9602291726.aa12191@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Feb 29, 96 05:26:24 pm Organisation: Computer Graphics Unit, University of Manchester, UK Phone: +44 0161 275 6045 Fax: +44 0161 275 6040 Operating-System: some HP unix thingy X-Uri: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > The "block" paragraph style looks more like an RFC and like the > HTML, but it takes about 10 percent more paper if you print it out. > (10 pages vs 9 for zlib, 83 pages vs 75 for PNG) > > The "indent" paragraph style uses the default TeX behavior. > > Which do you like better? I like the block style much better, because tab indents on new paragraphs are just a hang-on from manual typewriters. Some of the vertical spacing could however be tightened if required without making it look at all cramped. I wouldn't bother, though. If this is the most important thing we have to discuss then the gzip spec is ready to roll ;-) -- Chris Lilley, Technical Author and JISC representative to W3C +-------------------------------------------------------------------+ | Manchester and North Training & Education Centre ( MAN T&EC ) | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | Timezone: UTC URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | +-------------------------------------------------------------------+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body.