Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #10572 > unrolled thread
| Started by | Robert Roland <fake@ddress.no> |
|---|---|
| First post | 2012-11-24 17:41 +0100 |
| Last post | 2012-11-26 00:08 +0000 |
| Articles | 20 on this page of 153 — 47 participants |
Back to article view | Back to comp.arch.embedded
Getting started with AVR and C Robert Roland <fake@ddress.no> - 2012-11-24 17:41 +0100
Re: Getting started with AVR and C hamilton <hamilton@nothere.com> - 2012-11-24 09:55 -0700
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 10:39 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-11-24 18:03 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-10 13:21 +0100
Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-12-10 18:33 -0800
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-11 12:34 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-24 12:44 -0600
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:12 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-24 11:28 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:42 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-25 07:01 -0800
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 20:14 +0100
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 03:18 +0700
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 04:18 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-24 17:09 -0500
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-24 22:12 +0000
Re: Getting started with AVR and C Dave Nadler <drn@nadler.com> - 2012-11-24 21:01 -0800
statement / expression contexts in C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 12:54 +0700
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 13:37 +0700
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-28 14:49 +0000
Re: Getting started with AVR and C Frank Miles <fpm@u.washington.edu> - 2012-11-28 17:53 +0000
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 18:05 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 12:56 -0600
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 21:45 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 15:55 -0600
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-29 01:35 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 01:47 +0100
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:24 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 01:18 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 20:07 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:23 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:01 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 19:19 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 14:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 11:44 -0800
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 21:23 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:15 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 09:26 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 13:22 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 14:10 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:16 -0800
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-11-30 17:36 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:18 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 10:08 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 00:45 -0800
Re: Getting started with AVR and C Ed Beroset <beroset@mindspring.com> - 2012-12-01 08:00 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 13:22 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-01 17:33 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 17:43 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-02 14:13 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-04 20:34 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-04 18:25 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 07:55 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:11 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-05 07:52 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 11:02 -0500
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 21:28 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:21 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:05 +0200
Re: Getting started with AVR and C Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2012-12-05 23:22 +0200
Re: Getting started with AVR and C Niklas Holsti <niklas.holsti@tidorum.invalid> - 2012-12-06 00:00 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:17 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:10 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-06 07:15 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 21:52 -0800
Re: Getting started with AVR and C Lanarcam <lanarcam1@yahoo.fr> - 2012-12-06 20:59 +0100
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-06 12:38 -0800
Re: Getting started with AVR and C George Neuner <gneuner2@comcast.net> - 2012-12-06 20:39 -0500
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 22:31 -0500
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-12-05 16:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-05 17:04 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 22:01 -0800
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-12-06 14:05 +0000
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-06 10:28 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 16:58 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 07:34 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 10:55 -0500
Re: Getting started with AVR and C Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-06 11:11 -0500
Re: Getting started with AVR and C Rocky <RobertGush@gmail.com> - 2012-12-06 21:38 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-07 03:49 -0800
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 02:58 -0600
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 17:28 +0200
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 11:55 -0600
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:17 +0200
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 12:36 -0800
Re: Getting started with AVR and C Stephen Sprunk <stephen@sprunk.org> - 2012-11-29 16:22 -0600
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:36 -0800
Re: Getting started with AVR and C "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-12-11 10:53 +0100
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-11 14:53 +0000
Unicode Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:25 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 14:30 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 12:24 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 18:02 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 15:45 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-16 22:55 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-16 23:20 -0800
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:27 +0200
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-17 11:17 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:07 +0000
Re: Getting started with AVR and C Nobody <nobody@nowhere.com> - 2012-12-16 03:28 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-16 10:40 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 02:31 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 03:36 +0000
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 03:55 +0000
Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-11-28 23:24 -0800
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:37 +0100
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:31 +0000
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:44 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 13:22 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:32 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:28 -0800
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:20 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:07 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:17 -0500
Re: Getting started with AVR and C pete <pfiland@mindspring.com> - 2012-11-29 18:25 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 22:46 -0500
Re: Getting started with AVR and C lawrence.jones@siemens.com - 2012-11-30 11:47 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:38 -0800
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 15:21 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 22:26 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 17:32 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 19:02 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 18:29 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:39 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-29 00:59 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 07:57 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-29 13:02 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:19 +0000
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-29 12:03 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:39 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 08:04 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:17 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:19 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:44 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 13:15 -0500
Re: Getting started with AVR and C Arlet Ottens <usenet+5@c-scape.nl> - 2012-11-28 19:17 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:30 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:29 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-29 16:36 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:40 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 13:55 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 22:06 +0000
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 14:22 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 21:59 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-30 08:29 +0000
Re: Getting started with AVR and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-25 05:41 -0800
Re: Getting started with AVR and C Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 10:21 +0100
Re: Getting started with AVR and C dbr@kbrx.com - 2012-11-24 21:49 +0000
Re: Getting started with AVR and C MK <mk@nospam.co.uk> - 2012-11-25 12:24 +0000
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-11-26 00:08 +0000
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Rich Webb <bbew.ar@mapson.nozirev.ten> |
|---|---|
| Date | 2012-12-06 11:11 -0500 |
| Message-ID | <img1c8d20567ck1uhfheaaupkfpih34ls1@4ax.com> |
| In reply to | #10706 |
On Thu, 06 Dec 2012 10:55:19 -0500, Walter Banks <walter@bytecraft.com> wrote: > > >Mark Borgerson wrote: > >> In article <0259afc9-9d19-43c8-977f-ebfabe49cec6@ >> 8g2000yqp.googlegroups.com>, dp@tgi-sci.com says... >> > >> > On Dec 6, 1:25 am, Jon Kirwan <j...@infinitefactors.org> wrote: >> > > On Wed, 05 Dec 2012 16:32:15 -0500, Mel Wilson >> > > >> > > <mwil...@the-wire.com> wrote: >> > > >Jon Kirwan wrote: >> > > >> > > >> But I lose the ability to have good storage for millennia. >> > > >> Holes in papertape will easily last a millenia, and more. >> > > >> Maybe I want to communicate with neo-humans 10,000 years from >> > > >> now and say "hi," eh? >> > > >> > > >The holes will probably outlast the tape. "Time Team" is one of my favorite >> > > >shows, and they're continually trying to deduce, since dirt right here is a >> > > >slightly different color from the dirt over there, that Saxons must have >> > > >built something out of wood. >> > > >> > > > Mel. >> > > >> > > Cool, yet another reason for holes rather than ink spots on >> > > paper. >> > > >> > > Jon >> > >> > Hmmm, joining the party a bit late but... >> > >> > Is aluminum foil (I think plain kitchen foil) not longer lived than >> > paper? >> > Punching it at a 10 holes per mm (fairly dense but surely doable using >> > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will >> > store >100 megabytes on an A4 sheet... >> > Hopefully the morlocks will be smart enough to read that though. >> >> Just keep that foil away from any acidic or basic solutions! >> >> If you want real archival storage, go back to the basics. Have >> your solenoids indent some good quality clay. Glaze and fire. >> You could also get colored patterns for optical sensing by >> filling the indentations with colored glaze before firing. >> >> A well-fired ceramic will outlast your paper tape---especially >> if you don't live in a desert area. To make sure it >> gets passed on from generation to generation, fashion your >> codex in the shape of a number of beer coasters! Nothing >> like continued utility to make sure something gets passed >> on to the kids! >> >> If you want to pass on your spoken word, how about an >> Edison phonograph with fired ceramic cylinders instead >> of wax? >> > >For real duration broadcast your data into space. >Observatories are still looking at echoes of the big bang >back 12Billion or so years, much long than any material >will last unchanged. > >Recovery may require the technology of tomorrow. I'm surprised nobody has mentioned it -- although it may be up-thread somewhere in the drifting topics -- but the 10,000-year clock project is a real effort to pass information forward a few millennia. http://longnow.org/clock/ -- Rich Webb Norfolk, VA
[toc] | [prev] | [next] | [standalone]
| From | Rocky <RobertGush@gmail.com> |
|---|---|
| Date | 2012-12-06 21:38 -0800 |
| Message-ID | <89157387-ff3f-47fc-abef-adb10cc2ce0f@googlegroups.com> |
| In reply to | #10700 |
On Thursday, December 6, 2012 3:04:07 AM UTC+2, dp wrote: > On Dec 6, 1:25 am, Jon Kirwan <j...@infinitefactors.org> wrote: > > > On Wed, 05 Dec 2012 16:32:15 -0500, Mel Wilson > > > > > > <mwil...@the-wire.com> wrote: > > > >Jon Kirwan wrote: > > > > > > >> But I lose the ability to have good storage for millennia. > > > >> Holes in papertape will easily last a millenia, and more. > > > >> Maybe I want to communicate with neo-humans 10,000 years from > > > >> now and say "hi," eh? > > > > > > >The holes will probably outlast the tape. "Time Team" is one of my favorite > > > >shows, and they're continually trying to deduce, since dirt right here is a > > > >slightly different color from the dirt over there, that Saxons must have > > > >built something out of wood. > > > > > > > Mel. > > > > > > Cool, yet another reason for holes rather than ink spots on > > > paper. > > > > > > Jon > > > > Hmmm, joining the party a bit late but... > > > > Is aluminum foil (I think plain kitchen foil) not longer lived than > > paper? > > Punching it at a 10 holes per mm (fairly dense but surely doable using > > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will > > store >100 megabytes on an A4 sheet... > Mmmm. 2100 * 2970 is 6237000 bits. Not sure where the 100Mbytes comes from.
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2012-12-07 03:49 -0800 |
| Message-ID | <71a2e216-2865-4152-9183-1dbfc1144499@g14g2000yqp.googlegroups.com> |
| In reply to | #10714 |
On Dec 7, 7:38 am, Rocky <RobertG...@gmail.com> wrote: > On Thursday, December 6, 2012 3:04:07 AM UTC+2, dp wrote: > > On Dec 6, 1:25 am, Jon Kirwan <j...@infinitefactors.org> wrote: > > > > On Wed, 05 Dec 2012 16:32:15 -0500, Mel Wilson > > > > <mwil...@the-wire.com> wrote: > > > > >Jon Kirwan wrote: > > > > >> But I lose the ability to have good storage for millennia. > > > > >> Holes in papertape will easily last a millenia, and more. > > > > >> Maybe I want to communicate with neo-humans 10,000 years from > > > > >> now and say "hi," eh? > > > > >The holes will probably outlast the tape. "Time Team" is one of my favorite > > > > >shows, and they're continually trying to deduce, since dirt right here is a > > > > >slightly different color from the dirt over there, that Saxons must have > > > > >built something out of wood. > > > > > Mel. > > > > Cool, yet another reason for holes rather than ink spots on > > > > paper. > > > > Jon > > > Hmmm, joining the party a bit late but... > > > Is aluminum foil (I think plain kitchen foil) not longer lived than > > > paper? > > > Punching it at a 10 holes per mm (fairly dense but surely doable using > > > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will > > > store >100 megabytes on an A4 sheet... > > Mmmm. 2100 * 2970 is 6237000 bits. Not sure where the 100Mbytes comes from. ROFL, I wish I could answer that. Pressed the * key twice on my calculator? Been asleep? Both? .... :D Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-12-01 02:58 -0600 |
| Message-ID | <tvfjb8hjjqkbv481q3rnt18lmu6b33qdau@4ax.com> |
| In reply to | #10672 |
On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:
>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
><jonk@infinitefactors.org> wrote:
>
>>
>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>So, 8 bit char became standard.
>
>If you think about a mechanical typewriter or line printer, how on
>earth would you fit a large character set into it ?
>
>Being able to print numbers was of course the most needed feature,
>printing a very limited set of (upper case) letters was a bonus and
>some special characters like + or - would also be a bonus.
>
>The English language can be represented with only a few letters, but
>even most Latin based languages needed some extra characters and these
>were taken in ISO 646 from the special character sets, thus square
>brackets were replaced by national variants.
>
>On a line printer you typically had a 64 (upper case only) or 96 (with
>lower case) character drums and you had to order a drum made for your
>non-anglosaxon country.
Line printers were a varied lot. A popular design, at least for
higher end models, used a print train or chain with type slugs moving
around the train. On the popular 1403 printer, for example, the train
had 240 positions, which could, at least theoretically, hold that many
different characters, although that would require a custom train.
The standard 1403 trains ("TN") with the largest variety of characters
had two complete copies of 120 different characters. These were
rather slow trains, and tended to be used only for text-heavy output,
and included, amongst other things, superscript digits, and a variety
of mathematical symbols). More commonly trains with more copies of
fewer characters were used, the idea being that a slug with the
appropriate character had to rotate past every print position on the
line before the printer could advance to the next line.
I actually saw (custom) trains with over 200 different characters,
which included italics and other funky things. These were very slow…
Many trains had a mix of frequencies - "PCS-AN", for example, with
four copies of most characters, two copies of some unusual characters,
and eight copies of common characters such as digits. This would
allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
depending on what characters were on a given line.
The fastest trains had a few as 42 characters ("YN"), but six copies
of 39 of those (and two copies of the other three). Print speeds were
maximized when avoiding those last three characters. The fast trains
could often sustain the full (or nearly the full) 1400LPM of the
printers, while a TN train would usually chug along at about a third
that (~550LPM).
Probably more than anyone wanted to know about line printers, but...
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2012-12-01 17:28 +0200 |
| Message-ID | <m28kb8p1uebs6epfhsq36isbr7sjsrkfhk@4ax.com> |
| In reply to | #10674 |
On Sat, 01 Dec 2012 02:58:58 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:
>On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:
>
>>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
>><jonk@infinitefactors.org> wrote:
>>
>>>
>>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>>So, 8 bit char became standard.
>>
>>If you think about a mechanical typewriter or line printer, how on
>>earth would you fit a large character set into it ?
>>
>>Being able to print numbers was of course the most needed feature,
>>printing a very limited set of (upper case) letters was a bonus and
>>some special characters like + or - would also be a bonus.
>>
>>The English language can be represented with only a few letters, but
>>even most Latin based languages needed some extra characters and these
>>were taken in ISO 646 from the special character sets, thus square
>>brackets were replaced by national variants.
>>
>>On a line printer you typically had a 64 (upper case only) or 96 (with
>>lower case) character drums and you had to order a drum made for your
>>non-anglosaxon country.
>
>
>Line printers were a varied lot. A popular design, at least for
>higher end models, used a print train or chain with type slugs moving
>around the train. On the popular 1403 printer, for example, the train
>had 240 positions, which could, at least theoretically, hold that many
>different characters, although that would require a custom train.
>
>The standard 1403 trains ("TN") with the largest variety of characters
>had two complete copies of 120 different characters. These were
>rather slow trains, and tended to be used only for text-heavy output,
>and included, amongst other things, superscript digits, and a variety
>of mathematical symbols). More commonly trains with more copies of
>fewer characters were used, the idea being that a slug with the
>appropriate character had to rotate past every print position on the
>line before the printer could advance to the next line.
>
>I actually saw (custom) trains with over 200 different characters,
>which included italics and other funky things. These were very slow…
>
>Many trains had a mix of frequencies - "PCS-AN", for example, with
>four copies of most characters, two copies of some unusual characters,
>and eight copies of common characters such as digits. This would
>allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
>depending on what characters were on a given line.
>
>The fastest trains had a few as 42 characters ("YN"), but six copies
>of 39 of those (and two copies of the other three). Print speeds were
>maximized when avoiding those last three characters. The fast trains
>could often sustain the full (or nearly the full) 1400LPM of the
>printers, while a TN train would usually chug along at about a third
>that (~550LPM).
>
>Probably more than anyone wanted to know about line printers, but...
This was interesting reading, since I have only used and maintained
drum printers.
Those chain printers must have been quite expensive with switchable
"fonts". Did the printer controller have an actual CPU with local core
memory or was it hard wired with standard RTL/DTL/TTL logic chips ?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-12-01 11:55 -0600 |
| Message-ID | <qfgkb8h0rvj4q877cjuvejiml5fpmqi065@4ax.com> |
| In reply to | #10676 |
On Sat, 01 Dec 2012 17:28:03 +0200, upsidedown@downunder.com wrote:
>On Sat, 01 Dec 2012 02:58:58 -0600, Robert Wessel
><robertwessel2@yahoo.com> wrote:
>
>>On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:
>>
>>>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
>>><jonk@infinitefactors.org> wrote:
>>>
>>>>
>>>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>>>So, 8 bit char became standard.
>>>
>>>If you think about a mechanical typewriter or line printer, how on
>>>earth would you fit a large character set into it ?
>>>
>>>Being able to print numbers was of course the most needed feature,
>>>printing a very limited set of (upper case) letters was a bonus and
>>>some special characters like + or - would also be a bonus.
>>>
>>>The English language can be represented with only a few letters, but
>>>even most Latin based languages needed some extra characters and these
>>>were taken in ISO 646 from the special character sets, thus square
>>>brackets were replaced by national variants.
>>>
>>>On a line printer you typically had a 64 (upper case only) or 96 (with
>>>lower case) character drums and you had to order a drum made for your
>>>non-anglosaxon country.
>>
>>
>>Line printers were a varied lot. A popular design, at least for
>>higher end models, used a print train or chain with type slugs moving
>>around the train. On the popular 1403 printer, for example, the train
>>had 240 positions, which could, at least theoretically, hold that many
>>different characters, although that would require a custom train.
>>
>>The standard 1403 trains ("TN") with the largest variety of characters
>>had two complete copies of 120 different characters. These were
>>rather slow trains, and tended to be used only for text-heavy output,
>>and included, amongst other things, superscript digits, and a variety
>>of mathematical symbols). More commonly trains with more copies of
>>fewer characters were used, the idea being that a slug with the
>>appropriate character had to rotate past every print position on the
>>line before the printer could advance to the next line.
>>
>>I actually saw (custom) trains with over 200 different characters,
>>which included italics and other funky things. These were very slow…
>>
>>Many trains had a mix of frequencies - "PCS-AN", for example, with
>>four copies of most characters, two copies of some unusual characters,
>>and eight copies of common characters such as digits. This would
>>allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
>>depending on what characters were on a given line.
>>
>>The fastest trains had a few as 42 characters ("YN"), but six copies
>>of 39 of those (and two copies of the other three). Print speeds were
>>maximized when avoiding those last three characters. The fast trains
>>could often sustain the full (or nearly the full) 1400LPM of the
>>printers, while a TN train would usually chug along at about a third
>>that (~550LPM).
>>
>>Probably more than anyone wanted to know about line printers, but...
>
>This was interesting reading, since I have only used and maintained
>drum printers.
>
>Those chain printers must have been quite expensive with switchable
>"fonts". Did the printer controller have an actual CPU with local core
>memory or was it hard wired with standard RTL/DTL/TTL logic chips ?
Something like a 1403 needed a separate control unit (a 2821) to
attach to a S/360 channel. The 2821 was a combination of device
specific hardware* and a microsequenced control unit. They included a
bit of memory necessary for performing their function (a record or two
worth of buffer, and, in the case of printer, a buffer containing the
image of the print train).
Later printers had actual processors in their control units.
The trains were not terribly expensive, several hundred dollars for
the standard ones (although inflation will make that rather more in
today's dollars).
A decent picture:
http://ibmcollectables.com/gallery/album127/IBM_1403_print_train
You can see an installed train at:
http://en.wikipedia.org/wiki/File:IBM_1403_Printer_opened.jpg
The end of the train is sticking out from under the ink ribbon wrapped
around the left side (as viewed) of the gate. The gate is the part in
the right foreground of the picture, swung out from the printer. Just
below and to the right of the corner of the train is the rather
industrial motor that drove the train. The print hammers were behind
the paper, and smacked the paper into the ribbon and slug as the slug
passed the appropriate position.
Changing the train was fairly simple, open the gate, remove the
ribbon, flip up to two handles on the train (as seen on the first
photo), and lift it out - then reverse the process for the new train.
You'd then have to load a new mapping buffer into the control unit,
usually from the spooler on the OS driving the printer (typically that
would be semi-automated - the print job would be written to the spool
specifying the required train, when the spooler printed it, and the
wrong train was installed on the printer, he'd stop and tell the
operator to mount the new train, and when the operator acknowledged
doing that, he'd download the new mapping buffer).
Somewhat oddly, the second photograph shows already printed paper
being fed through the printer.
*2821s could control a number of printers, card readers and punches,
you had to order the right hardware (for example a model one could
support one 1403 printer, and one 2540 reader/punch, a model three
could support three 1403 printers).
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2012-11-29 22:17 +0200 |
| Message-ID | <b4gfb81ihafctck2bu6a3o24trpvo0ug8h@4ax.com> |
| In reply to | #10641 |
On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper <jameskuyper@verizon.net> wrote: >On 11/29/2012 10:23 AM, Grant Edwards wrote: >> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: >> ... Trying to impliment >> any sort of communications protocol with that was fun. Using left/right shifts and AND and OR operations work just fine. Works OK with different CHAR_BIT and different endianness platforms. Do not try to use structs etc. >Thanks for that information. Claims have frequently been made on >comp.lang.c that, while the C standard allows CHAR_BIT != 8, the >existence of such implementations is a myth. I'm glad to have a specific >counter example to cite. IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range. On the Unicode list, I even suggested packing three 21 characters into a single 64 bit data word as UTF-64 :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-29 12:36 -0800 |
| Message-ID | <lnobig9me2.fsf@nuthaus.mib.org> |
| In reply to | #10649 |
upsidedown@downunder.com writes:
> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
> <jameskuyper@verizon.net> wrote:
>
>>On 11/29/2012 10:23 AM, Grant Edwards wrote:
>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
>
>>> ... Trying to impliment
>>> any sort of communications protocol with that was fun.
>
> Using left/right shifts and AND and OR operations work just fine.
> Works OK with different CHAR_BIT and different endianness platforms.
> Do not try to use structs etc.
>
>>Thanks for that information. Claims have frequently been made on
>>comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
>>existence of such implementations is a myth. I'm glad to have a specific
>>counter example to cite.
>
> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>
> On the Unicode list, I even suggested packing three 21 characters into
> a single 64 bit data word as UTF-64 :-)
I like it -- but it breaks as soon as they add U+200000 or higher, and
I'm not aware of any guarantee that they won't.
I've thought of UTF-24, encoding each character in 3 octets; that's
good for up to 16,777,216 distinct code points.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-11-29 16:22 -0600 |
| Message-ID | <k98n6b$cbf$1@dont-email.me> |
| In reply to | #10651 |
On 29-Nov-12 14:36, Keith Thompson wrote: > upsidedown@downunder.com writes: >> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range. >> >> On the Unicode list, I even suggested packing three 21 characters into >> a single 64 bit data word as UTF-64 :-) > > I like it -- but it breaks as soon as they add U+200000 or higher, and > I'm not aware of any guarantee that they won't. I thought they had guaranteed they would never go above U+10FFFF, which would break UTF-16. > I've thought of UTF-24, encoding each character in 3 octets; that's > good for up to 16,777,216 distinct code points. AIUI, there are some DSPs with CHAR_BIT==24 (or was that 12?). S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-29 18:36 -0800 |
| Message-ID | <lnfw3rakaw.fsf@nuthaus.mib.org> |
| In reply to | #10657 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 29-Nov-12 14:36, Keith Thompson wrote:
>> upsidedown@downunder.com writes:
>>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>>>
>>> On the Unicode list, I even suggested packing three 21 characters into
>>> a single 64 bit data word as UTF-64 :-)
>>
>> I like it -- but it breaks as soon as they add U+200000 or higher, and
>> I'm not aware of any guarantee that they won't.
>
> I thought they had guaranteed they would never go above U+10FFFF, which
> would break UTF-16.
You're right. <http://www.unicode.org/faq/utf_bom.html> says:
Both Unicode and ISO 10646 have policies in place that formally
limit future code assignment to the integer range that can be
expressed with current UTF-16 (0 to 1,114,111).
>> I've thought of UTF-24, encoding each character in 3 octets; that's
>> good for up to 16,777,216 distinct code points.
>
> AIUI, there are some DSPs with CHAR_BIT==24 (or was that 12?).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> |
|---|---|
| Date | 2012-12-11 10:53 +0100 |
| Message-ID | <op.wo5cfylwj0diun@thanatos.indes.com> |
| In reply to | #10651 |
Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson <kst-u@mib.org>: > upsidedown@downunder.com writes: >> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper >> <jameskuyper@verizon.net> wrote: >> >>> On 11/29/2012 10:23 AM, Grant Edwards wrote: >>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: >> >>>> ... Trying to impliment >>>> any sort of communications protocol with that was fun. >> >> Using left/right shifts and AND and OR operations work just fine. >> Works OK with different CHAR_BIT and different endianness platforms. >> Do not try to use structs etc. >> >>> Thanks for that information. Claims have frequently been made on >>> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the >>> existence of such implementations is a myth. I'm glad to have a >>> specific counter example to cite. >> >> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range. >> >> On the Unicode list, I even suggested packing three 21 characters into >> a single 64 bit data word as UTF-64 :-) > > I like it -- but it breaks as soon as they add U+200000 or higher Not really. You can use the spare bit to indicate a different packing. > , and I'm not aware of any guarantee that they won't. > > I've thought of UTF-24, encoding each character in 3 octets; that's > good for up to 16,777,216 distinct code points. I hope that, when the galactic discovery is underway that would make this amount of code points necessary, software engineering will have evolved beyond the point of humans worrying about bit widths and encodings. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2012-12-11 14:53 +0000 |
| Message-ID | <877goomyi1.fsf@devereux.me.uk> |
| In reply to | #10755 |
"Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> writes: > Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson <kst-u@mib.org>: >> upsidedown@downunder.com writes: >>> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper >>> <jameskuyper@verizon.net> wrote: >>> >>>> On 11/29/2012 10:23 AM, Grant Edwards wrote: >>>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: >>> >>>>> ... Trying to impliment >>>>> any sort of communications protocol with that was fun. >>> >>> Using left/right shifts and AND and OR operations work just fine. >>> Works OK with different CHAR_BIT and different endianness platforms. >>> Do not try to use structs etc. >>> >>>> Thanks for that information. Claims have frequently been made on >>>> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the >>>> existence of such implementations is a myth. I'm glad to have a >>>> specific counter example to cite. >>> >>> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range. >>> >>> On the Unicode list, I even suggested packing three 21 characters into >>> a single 64 bit data word as UTF-64 :-) >> >> I like it -- but it breaks as soon as they add U+200000 or higher > > Not really. You can use the spare bit to indicate a different packing. > >> , and I'm not aware of any guarantee that they won't. >> >> I've thought of UTF-24, encoding each character in 3 octets; that's >> good for up to 16,777,216 distinct code points. > > I hope that, when the galactic discovery is underway that would make > this amount of code points necessary, software engineering will have > evolved beyond the point of humans worrying about bit widths and > encodings. UTF-8 is the way forward isn't it? -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| Date | 2012-12-14 23:25 +0700 |
| Subject | Unicode |
| Message-ID | <86zk1gob1n.fsf_-_@gray.siamics.net> |
| In reply to | #10757 |
>>>>> John Devereux <john@devereux.me.uk> writes: >>>>> "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> writes: >>>>> Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson: [...] >>> I've thought of UTF-24, encoding each character in 3 octets; that's >>> good for up to 16,777,216 distinct code points. >> I hope that, when the galactic discovery is underway that would make >> this amount of code points necessary, software engineering will have >> evolved beyond the point of humans worrying about bit widths and >> encodings. > UTF-8 is the way forward isn't it? I doubt it is. FWIW, it requires three octets for Cyrillic, while UTF-16 requires only two. Personally, I'd try to use the latter whenever possible (which means: anywhere, unless OS interaction issues are deeply involved in the matter.) -- FSF associate member #7257
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-12-15 14:30 -0500 |
| Message-ID | <kaij54$fl9$1@dont-email.me> |
| In reply to | #10757 |
On 12/11/12 9:53 AM, John Devereux wrote: > > UTF-8 is the way forward isn't it? > As with most compression systems it depends on what the usage pattern of characters is. If the text base is mostly the 7 bit ASCII character set, with some of the other lower valued characters and only a few bigger valued characters, UTF-8 makes sense. If most of the characters are in the larger values (like using a non-Latin based character set) then UTF-16 may make much more sense.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-12-15 12:24 -0800 |
| Message-ID | <ln38z7kqr0.fsf@nuthaus.mib.org> |
| In reply to | #10823 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 12/11/12 9:53 AM, John Devereux wrote:
>> UTF-8 is the way forward isn't it?
>
> As with most compression systems it depends on what the usage pattern of
> characters is. If the text base is mostly the 7 bit ASCII character set,
> with some of the other lower valued characters and only a few bigger
> valued characters, UTF-8 makes sense. If most of the characters are in
> the larger values (like using a non-Latin based character set) then
> UTF-16 may make much more sense.
UTF-8 has a couple of other advantages. It's equivalent to ASCII
as long as all the characters are <= 127, which means you can
(mostly) deal with UTF-8 using old tools that aren't Unicode-aware.
And it has no byte ordering issues, so it doesn't need a BOM (Byte
Order Mark).
As for compression, you can always use another compression tool
if necessary; gzipped UTF-8 should be about as compact as gzipped
UTF-16.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-12-15 18:02 -0500 |
| Message-ID | <kaiviq$1en$1@dont-email.me> |
| In reply to | #10824 |
On 12/15/12 3:24 PM, Keith Thompson wrote: > Richard Damon <news.x.richarddamon@xoxy.net> writes: >> On 12/11/12 9:53 AM, John Devereux wrote: >>> UTF-8 is the way forward isn't it? >> >> As with most compression systems it depends on what the usage pattern of >> characters is. If the text base is mostly the 7 bit ASCII character set, >> with some of the other lower valued characters and only a few bigger >> valued characters, UTF-8 makes sense. If most of the characters are in >> the larger values (like using a non-Latin based character set) then >> UTF-16 may make much more sense. > > UTF-8 has a couple of other advantages. It's equivalent to ASCII > as long as all the characters are <= 127, which means you can > (mostly) deal with UTF-8 using old tools that aren't Unicode-aware. > And it has no byte ordering issues, so it doesn't need a BOM (Byte > Order Mark). > > As for compression, you can always use another compression tool > if necessary; gzipped UTF-8 should be about as compact as gzipped > UTF-16. > UTF-8 and UTF-16 *ARE* compression methods. Uncompressed Unicode would be UTF-32 or UCS-4, using 32 bits per character. For most use, if you don't need code points above U+0FFFF, then you might consider UCS-2 uncompressed format. Then UTF-16 isn't really compression, but a method to mark the very rare character above U+0FFFF. UTF-8 is really just a compression format to try and remove some of the extra space, and will do so to the extent that characters 0-7F are more common than U+0800 and higher, the former saving you a byte, and the latter costing you one. UTF-8 does have the other advantage that you mention, looking like ASCII for those characters allowing many Unicode unaware programs to mostly function with UTF-8 data.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-12-15 15:45 -0800 |
| Message-ID | <lntxrmkhgk.fsf@nuthaus.mib.org> |
| In reply to | #10825 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 12/15/12 3:24 PM, Keith Thompson wrote:
[...]
>> As for compression, you can always use another compression tool
>> if necessary; gzipped UTF-8 should be about as compact as gzipped
>> UTF-16.
>>
>
> UTF-8 and UTF-16 *ARE* compression methods.
[...]
I don't recall saying they aren't.
But they're (relatively) simplistic compression methods that don't
adapt to the content being compressed, which is why applying another
compression tool (I *did* say "another") can be useful.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-12-16 22:55 -0500 |
| Message-ID | <kam54d$r3l$1@dont-email.me> |
| In reply to | #10826 |
On 12/15/12 6:45 PM, Keith Thompson wrote: > Richard Damon <news.x.richarddamon@xoxy.net> writes: >> On 12/15/12 3:24 PM, Keith Thompson wrote: > [...] >>> As for compression, you can always use another compression tool >>> if necessary; gzipped UTF-8 should be about as compact as gzipped >>> UTF-16. >>> >> >> UTF-8 and UTF-16 *ARE* compression methods. > [...] > > I don't recall saying they aren't. > > But they're (relatively) simplistic compression methods that don't > adapt to the content being compressed, which is why applying another > compression tool (I *did* say "another") can be useful. > But they are fundamentally different than other compressions. Multi-byte/symbol encodings are generally designed so that it is possible to process the data in that encoding. It isn't that much harder to process the data then if it was kept fully expanded. Some operations, like computing the length of a string, require doing a pass over the data instead of just taking the difference in the addresses, but nothing becomes particularly hard. On the other hand, it is very unusual for any program to actually process "zipped" data as such, it is almost always uncompressed to be worked on and then re-compressed, and any changes tend to require reprocessing the entire rest of the file (or at least the current compression block).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-12-16 23:20 -0800 |
| Message-ID | <lnwqwhi1pw.fsf@nuthaus.mib.org> |
| In reply to | #10835 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 12/15/12 6:45 PM, Keith Thompson wrote:
>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>> On 12/15/12 3:24 PM, Keith Thompson wrote:
>> [...]
>>>> As for compression, you can always use another compression tool
>>>> if necessary; gzipped UTF-8 should be about as compact as gzipped
>>>> UTF-16.
>>>>
>>>
>>> UTF-8 and UTF-16 *ARE* compression methods.
>> [...]
>>
>> I don't recall saying they aren't.
>>
>> But they're (relatively) simplistic compression methods that don't
>> adapt to the content being compressed, which is why applying another
>> compression tool (I *did* say "another") can be useful.
>
> But they are fundamentally different than other compressions.
> Multi-byte/symbol encodings are generally designed so that it is
> possible to process the data in that encoding. It isn't that much harder
> to process the data then if it was kept fully expanded. Some operations,
> like computing the length of a string, require doing a pass over the
> data instead of just taking the difference in the addresses, but nothing
> becomes particularly hard.
>
> On the other hand, it is very unusual for any program to actually
> process "zipped" data as such, it is almost always uncompressed to be
> worked on and then re-compressed, and any changes tend to require
> reprocessing the entire rest of the file (or at least the current
> compression block).
I'd say that's a difference of degree, not anything fundamental.
Computing the length of a string requires doing a pass over it, whether
it's UTF-8 encoded or gzipped. And it's certainly possible to process
UTF-8 data by internally converting it to UTF-32.
And copying a file doesn't require uncompressing it, regardless of the
format.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2012-12-17 12:27 +0200 |
| Message-ID | <87pq29j7mc.fsf@bazspaz.fatphil.org> |
| In reply to | #10825 |
Richard Damon <news.x.richarddamon@xoxy.net> writes: > On 12/15/12 3:24 PM, Keith Thompson wrote: > > Richard Damon <news.x.richarddamon@xoxy.net> writes: > >> On 12/11/12 9:53 AM, John Devereux wrote: > >>> UTF-8 is the way forward isn't it? > >> > >> As with most compression systems it depends on what the usage pattern of > >> characters is. If the text base is mostly the 7 bit ASCII character set, > >> with some of the other lower valued characters and only a few bigger > >> valued characters, UTF-8 makes sense. If most of the characters are in > >> the larger values (like using a non-Latin based character set) then > >> UTF-16 may make much more sense. > > > > UTF-8 has a couple of other advantages. It's equivalent to ASCII > > as long as all the characters are <= 127, which means you can > > (mostly) deal with UTF-8 using old tools that aren't Unicode-aware. > > And it has no byte ordering issues, so it doesn't need a BOM (Byte > > Order Mark). > > > > As for compression, you can always use another compression tool > > if necessary; gzipped UTF-8 should be about as compact as gzipped > > UTF-16. > > > > UTF-8 and UTF-16 *ARE* compression methods. Hmmm, those who work in compression tend to prefer the term "encodings", for such fixed 1-1 mappings of input to output tokens. UTF-8, and the others you consider to be "compressed", simply have output tokens of different lengths. Phil -- I'm not saying that google groups censors my posts, but there's a strong link between me saying "google groups sucks" in articles, and them disappearing. Oh - I guess I might be saying that google groups censors my posts.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web