the webmaster still gets credit for the 'view' For many ads these days, the web publisher gets paid only for clicks.
With Google, the ratio of page views ("impressions" as they call them) to clicks determines the amount paid.
So if you download the ads from my Web site and don't ever click on them, you are actually lowering my revenue very slightly. It's better not to download ads if you aren't going to click on them.
I've worked hard (e.g. on http://www.fromoldbooks.org/ ) to try and have ads that are not too obtrusive, but when you're running an image Web site the bandwidth costs can be fairly high, and very few people will click on donate buttons.
Maybe it just means that some classes of Web site will go away, or will have to reinvent themselves, e.g. as "member-only pay to download images".
In a well-known fairy tale a boy enjoyed the attention he got when he cried out there's a wolf in the village! - but after a while, people stopped listening to him, and when there was really a wolf, no-one believed him, and the wolf stole his shoes and socks and his ipod and ran off with them into the forest.
The problem with people saying such-and-such will mean the certain end of so-and-so is that, like the boy in the story, they weaken our credulity. What is really meant here is that, if the growth of video downloading continues at the same rate, and no other changes happen, the current system will bog down. And maybe that's true.
I remember a huge thread on Usenet lasting months and months, or so it seemed, Imminent death of the network predicted, and that was in the early 1980s.
Yes, video delivery is something to take seriously. The distinction between downloading a movie for later viewing (I would probably want it to be error-free) and watching streaming video (compression is OK, and I'd want the network to drop packets if I got behind, which is part of what IPv6 quality of service is about) might be part of the solution here. Of course, as people get larger desktop screens with higher resolution, the demand even for static images is increasing. 640x480 doesn't cut it for most people today. And most computer users have stereo sound. Or play games in which network latency is significant. Violent games in which you pretend to be a wolf! And videoconferencing, TV-on-demand (as per original article, e.g. joost), and maybe soon 3d holographic pornography is coming.
The music and video industry would do well to spend a fraction of their current legal bills on researching more efficient delivery. Maybe encouraging deployment of IPv6 multicast, for example, so a single stream can go to thousands of users. Or paid subscription p2p networks. Or cascading servers. For that matter, probably we-who-write-the-standards could help by defining cache protocols that can interoperate with advertising, and can reliably send back access logs, maybe anonymized. Video CEOs, I know you read slashdot:-), how about it?
But, shouting "wolves stole my socks" or "the sky is falling" won't help. Although if either of those things does happen, make sure to put the video up on youtube, OK?
I'm not sure that the open source version of Xara is mature. It also hasn't changed (as far as I can tell) since January. The current commercial version is not available on Linux, or doesn't seem to be, on their main Web site.
The Linux version is at http://www.xaraxtreme.org/ (and it's not linked to from xara.com either I think, or not obviously). Last time I tried it, it didn't have much in the way of support for text.
Welcome! There's no point in looking for perfect! There are places where PhotoShop is much better and places where The GIMP is much better, so it all depends what you're doing.
I haven't encountered such a limit, so I'm not sure where it's coming from. Oh, wait - in tool options yes.
First make a normal, sharp selection, then click the right mouse button in the image and choose the Select menu, and then Feather Selection, and you can enter any value. I don't know why there's a limit of 100 in the tool options; you could submit a bug/feature request to allow it to be made larger, perhaps.
I think maybe this is getting off-topic, but GIMP does have Selection->Feather. You may need to use a value that's double the PhotoShop value, I forget, but I use this technique to brighten/darken pictures fairly often.
Luckily GIMP can do rounded rectangles out of the box.
I still wouldn't recommend GIMP for replacing PhotoShop directly in an existing Apple + Adobe + PostScript/EPS/PDF workflow, because of the lack of CMYK support, and the difficulties of working in the RGB colourspace, which doesn't have a clear enough overlap with the CMYK colourspace, and the lack of gamut warnings (visible indication that you've used colours that can't be printed). This stuff needs to happen in the editing interface - to the person who said, isn't it like the sound system compensating for a listening room, no, it's more like the recording engineer noticing when the needles are stuck all the way at 10 (max level) and detail is getting lost. You can't add detail back later.
Inkscape and sk1 are both being used as vector-based software in pre-press (sk1 was designed for that) but overall the Free Software graphic design workflow is not yet very mature. Part of that is that the commercial works has been responsive overall to designer's needs, and part of it is that designers are only very rarely programmers, and programmers only rarely get involved in graphic design enough to understand why OpenOffice + GIMP isn't a total solution.
People have been working on improving the situation - e.g. the organisers and participants at the Libre Graphics Meeting. Scribus is indeed advancing rapidly, with a lot of momentum, although its text handling in some ways still lags behind very early versions of Quark, and as it stands today it's not going to challenge people who have come to rely on the newer features of InDesign. But really, it's early days yet. We're in some ways not quite where the proprietary world was in the late 1980s, and in other ways we're ahead of the proprietary world, but we have to catch up in some of the places where we're behind.
It's no good asking to use software they have no real hope themselves of modifying or enhancing, and saying, use this, and if it doesn't work for you, just add features, and by the way it doesn't do everything that right now you believe you need, because it's as much use as handing a person with no legs who needs to get somewhere a broken bicycle. This is not to say I don't believe in Free Software. I just recognise that we don't yet have a Free solution to everyone's needs yet.
There are two common ways to make animations in GIMP. For animated gif files, like a livejournal or deviantart avatar:D, you can use GIMP's built-in layers, with (replace) on the end of a layer name to make it have a GIF frame disposition of Replace, and then save the image as a GIF file. The other is to use the GAP plugin, which has some tools to make it (supposedly, I have not tried it) possible to do larger or longer animations.
...the celestial object in question is right at the corner where two edges of the universe meet. The edges are of course mirrored to fool astronomers.:-)
The better approach would be for schools to actually do their jobs and provide students with a solid foundation in fact checking and then ENCOURAGE them to consider wikipedia as a potential source.
I'd go further than that: yes, wikipedia is unreliable, of course it is. But it is a known quantity. If you block it, where will the students who used wikipedia for everything get there answers? Maybe from cheat sites, or from uncyclopedia, or from random blogs!
If the teacher finds the wikipedia entries related to the homework incorrect, discuss why in Class and assign students the task of improving the entries as part of their homework. Or at least of drafting new text to be discussed in class.
When the first horseless carriages were introduced, law-makers in some parts of the world required that someone walk in front of the new vehicle carrying a red flag. Part of this was because of a huge financial lobby on the part of the horse-and-cart industry (!) which in the end died out completely because of its RIAA-style stupidity, and part of it was a fear of the new technology. But even where such laws are still on the books they are now seen as representing fears of the small-minded. To be fair, thousands upon thousands of people die every year in horseless-carriage fights, so maybe really those people were right, but either way they are gone and forgotten.
The books I've looked at have been scanned at a resolution that's more or less adequate for OCR, but isn't really adequate for reproducing fine woodcuts, and is hopeless at metal engravings. I've found from my work on fromoldbooks.org that anything less than 1200 dpi generally produces pretty poor results for images, so that, for example, you can't read the signatures of the artist and engraver, still less compare engraving styles. It would be sort of like having a paraphrase of the text instead of the actual words.
It does, of course, vary a lot depending on the style of image. Bold illustrations for children's books, for example, do better at, say, 800dpi greyscale or colour. Fine steel engravings with lines at, say, less than a tenth of a degree from horizontal (they were done by hand after all) and that come out only a couple of pixels wide even at 1200dpi just turn into gray mush with weird banding artefacts until you go to a higher resolution (I use 2400dpi). There's a widely-cited study indicating that an "ultra-high" scan resolution of 400dpi is more than sufficient, based on an extremely small sample of images.
The damage that's done by poor quality digitization is that it makes it harder to justify doing a better job in the future.
For what it's worth, Mandriva has for years (OK, from when they were Mandrake) used RPM-format packages, with package management called "urpmi", which you could think of (if you wanted to) as a slightly improved improved apt-get. You can also use apt-get if you like. Or rpmdrake or Smart. All of which, including urpmi, will download packages automatically, including all dependencies.
On the other hand, they are quickly going to need more Mandriva distribution mirrors in the countries where these new computers are sold, and Mandriva is going to need to work on keeping them reliable.
Although we (W3C) are in fact working on more efficient binary encodings (www.w3.org/XML/EXI) this misses the point a little.
The good thing about XML is that it isn't good for anything, but is mediocre for everything:-)
The main original use case were not "INI files" or other configuration stuff, but computer documentation, and transcriptions of texts. Mixed content, such as paragraphs of running text in which certain items are marked, or tagged, in some way, was the primary goal. We really didn't predict things like Web services!
XML is here, though. Almost every XML expert (myself included, and no irony here) would like to see XML be slightly different in some way, but we all also understand that the importance that every XML tool can have a stab at doing something useful with just about any XML document. And yes, there are people who like using emacs/vi/textedit/eclipse/wordpad/whatever in addition to tools like oxygen or Stylus Studio.
There's a difference between saying, "IE supports every aspect of every standard perfectly" (nothing does, although some programs come a lot closer than others, of course) and saying, "avoid single-browser extensions when possible and use only the portable subset of what is standard". I agree it's not easy though.
First,you only need one disenfranchised user to sue you. For example, if you are operating a Web site in the US (or in many cases the EU or Canada) anti-discrimination laws mean you'd better make your site accessible. And that means accessible to someone using a text-based browser such as Lynx, as well as a text reader. See the American Disabilities Act and the "508" laws.
Second, yes, you can make a Web site more cheaply that's aimed at, say, IE 6. Or IE 7. or maybe you could choose Mosaic 1.5, or Netscape 0.96, as some other sites did. And in a few years you might have to redo everything when that particular browser is no longer available.
Third, you could optimize your site for a particular screen size. For example, 640x480 pixels or even 800x600 are popular choices. Of course, you can't actually buy a desktop PC with a 640x480 pixel screen very easily today. Mine is 1680x1050, but sizes vary widely, mostly because of the emerging popularity of watching DVDs on a computer. But, right now a surprising number of people in some parts of the world (Europe and Japan mostly I think) seem to browse the Web on a mobile phone, and those often have 320x240 pixel screens.
The point of the World Wide Web is that it's for everyone, everywhere, regardless of language, culture, ability, special needs or even computing platform. Do the right thing. Make your site work on as many platforms as you can, by sticking to standards, avoiding platform-specific tricks, and testing.
[disclaimer: I work for the World Wide Web Consortium, although in this area my opinions expressed here also match those of my empolyer!]
The economics of software outside the west are very different to what most people are used to
Actually it's not clear to me that most people live in the West. Nor is it clear to me that one can characterise the "rest of the world" so simply. There are whole Linux distributions aimed at (and developed in) India and China. And for that matter there are places in the West where pirated software is common. There have even been slashdot stories about it as I recall, e.g. in parts Europe.
First, the biggest improvement you are likely to see in the Gimp is if you go to Colour->Layers (in older versions of the Gimp it's Layers->Colours->Levels) and click Auto. For pictures that should contain some black and some white this will usually make a noticeable improvement.
Second, yes, Canon (for example) includes (Windows only, proprietary, secret, closed-source) software to compensate: you shoot a 25% grey surface. You can also use this inside the camera itself: there it will use the data for white balance correction.
In practice, though, it's fairly hard to do this yourself. One difficulty is that the amount and position of colour aberrationswill probably vary depending on the lens you use, or, with a fixed lens, the amount of zoom and the aperture size. I know I found that when my Casio developed some dark spots.
There are some programs that are used with hugin, the panorama stitching UI, that help with some lens corrections; it might be you could ask those people. However, a lot of the variation you are seeing is likely to be digital noise. Try taking 3 shots usinga tripod and timer or remote, and comparing them.
I agree with you that needing more than 200dpi is fairly rare, and if I have needed it more often it is possibly because I tend to work with older books, or books in poor condition.
It's not only for footnotes, but also, say, to distinguish an ae ligature (æ in utf8) from an oe ligature (oe in utf-8 if it survives slashdot), or from the unligatured letters, or to distinguish a zero (0) and a letter "O", and so on. If one has the original book to hand, that's less of an issue.
I agree that the Google bulk scanning is not good quality. In the past, Project Gutenberg produced some very low quality e-texts too. Some of them have been improved, and newer ones are to a much higher standard. It doesn't seem that long since I suggested the use of SGML to Michael Hart, and pointed out that they would then be able to capture italics and other textual variations -- but it's about 15 years ago I think, and since then HTML has become popular:-)
600dpi is really bad for an engraving, but OK for a screened photograph if you don't mine losing some detail. It's not good for archival purposes, e.g. for studying which engraver worked on a particular image.
You're right, though, that Google has spurred competition, and I agree that it's a good thing!
Most of these people focus on English-language books printed in the 19th and early 20th centuries, because (1) it's usually easy to determine copyright status, and (2) if you go earlier you get the tall "s" ( in utf-8) which no OCR program today seems able to handle, so the scanning cost is increased.
Scanning with a flat-bed scanner basically wrecks the binding. So the books probably need to be rebound afterwards, or can be discarded.
There are photography setups (e.g. Phase One has one) but the resolution is too low, even with a 40 megapixel medium-format camera (yes, they are used for this). A little high-school mathematics (e.g. Nyquist) and the back of an envelope, combined with some measurements, will show that if you scan engravings at under 1200dpi, you will lose a lot of detail, and indeed, compare for example the Alice in Wonderland pictures on my own site with the Project Gutenberg ones. You can read the engraver's signature on most of the ones I have. Yes, the bandwidth needed to host higher resolution images is greater (which is why I have ads, sorry). But it's worth it.
Some of these books will never be scanned again. Even for OCR, 400dpi grayscale seems a minimum for footnotes and other small text even in English.
I'd also like to see more interfaced like the Project Gutenberg Distributed Proofreaders' site where people can submit corrections. Maybe use a WIKI for the transcription??
:-) yes, you could say I've heard of FrameMaker, and of Author/Editor and of Adept (later Epic) and of DataLogics Pager and of Interleaf Publisher and of a great many other SGML tools. I was certainly among those who felt that the complexity of the SGML standard was a hindrance to adoption, and also that SoftQuad Panorama was a good demonstration (at the time) of where we wanted to go.
But I certainly don't mind being "lectured" -- we learn a lot by listening!
I should admit that our mandate was to put SGML on the Web, not to make an entirely new syntax; we really didn't expect people to be using what became called XML for anything other than predominantly textual documents. There are, in fact, problems with anonymous end tags for metadata: these are not in general problems for computer programming so much since you can test the code in a way that's often not possible with metadata interchange. Unfortunately, no, I can't give you references for studies that were done (and there were not many such studies that I can recall, although the number was certainly non-zero; the US DoD CALS initiative might have made some public, though, for a starting point if you want to search) in this precise area. As for what we were optimizing, it was pretty clear at the time, but the original central use cases of XML are not really so central these days, although of course they're still there. As I mentioned, much of that history is locked away in private mail archives right now.
At any rate, whether it could be better (it could certainly be improved) or whether it could be worse (that's easy to imagine too), it is what it is:-), changing it, as we discovered with XML 1.1, is next to impossible, and the single most important thing about XML is not what it looks like at all - it's that it's the same everywhere, it's that XML is widely deployed, it's that all general-purpose XML tools work on all XML, so that every new tool, evern new document, multiplies (by some factor only slightly above 1.00 usually) the value of all other XML documents and tools. The network effect.
I'm afraid the only useability studies of SGML tools that I saw were not released to the public. At the time I worked for a vendor of SGML-based software (e.g. including an editor, a viewer, a development environment) and it was a matter of great concern to us.
It's possible we could open up the archives of the XML Working Group, but it would mean getting the permission of several hundred people. I'll ask some people at the upcoming XML conference in Boston and try and get a feeling for how hard that would be.
I agree with you that the involvement of Sun, Microsoft, Netscape and others was very helpful. There are, however, other file formats that were around in the past and had similar backing but which failed. Remember ODA? There were also some attempts early on to move the Web to a dialect of RTF, which was also supported by big companies.
> The error message does not help people all that much
One case where it helps most is when an incorrect start tag was applied; with the empty end tag this could not be detected, and it turned out to be more comman than one might expect. You're right that the error messages often aren't good, but did you ever try debugging a large SGML document with OMITTAG and SHORTREF in use? The error message was almost always "characters found after end of document" because the required strategy by SGML (in one of the most common error situations) was to close elements until you got a match, so the parser typically closed elements all the way up the tree to the document element, and then gave up.
We were bound, at the time, to strict SGML compatibility; perhaps if we had known XML would succeed we could have made more changes, but then we would have strayed further from the well-trodden path of implementation experience.
As to comments for attributes, I agree with you; we lost them, though because we needed a language simple enough it could be processed e.g. with Perl. We didn't dare dream that Perl would support XML natively!
I agree with you that structured tools should generally be used. The redundancy and simplicity help computer-generated XML, and help to detect, say, missing portions of documents. If xml-rpc is scary, s-expr rpc is even scarier!:-)
A lot of people ask about using a different syntax, such as @name{....} as Scribe (and later LaTeX) did. Note that @element{xxx} is in fact a possible syntax that can be defined using SGML. But we were after something different.
When we designed XML, we had over a decade of solid experience with interoperability in the world of SGML, and we also knew about the kinds of problems that different sorts of users had with different sorts of syntax.
The primary users of SGML-based documentation systems were not programmers. They were people who were often not likely to know about a bracket-matching option in an editor or about code indenting, for example. But they were still legitimate users.
You can't easily test the markup in a declarative system: if in an HTML document I used H3 instead of P in a document it might not look right, but it would still parse OK. If I muddle up Author and Title in a bibliography, same thing.
So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with </>, allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.
It's true that today XML is used in lots of situations we didn't predict. We were amazed that by the time we got XML published as a Recommendation there were over 200 users. So no, we didn't predict the future percfectly. But the popularity of XML shows we can't have done all that badly, really;-)
I experimentally put a couple of pages of sheet music on fromoldbooks.org yesterday. I'm not sure how useful they are, but I'm contemplating adding a lot more out-of-copyright sheet music.
I'd be willing to host good quality scans from other people, too, but it has to be demonstrably out of copyright -- I'm not interested in "legal loopholes" here. I'd suggest using 1200dpi greyscale and then adjusting "curves" to make a clear, sharp image. Both the music and the typeset score must be out of copyright, as well as the lyrics. In the US and Canada this is generally easy to determine, but for music produced in other countries it can be arbitrarily difficult; anything printed before 1820 or so is pretty safe though.
This doesn't really help the original poster very much unless I happen to have some specific piece of music, of course!
Slashdot Mirror
the webmaster still gets credit for the 'view'
For many ads these days, the web publisher gets paid only for clicks.
With Google, the ratio of page views ("impressions" as they call them) to clicks determines the amount paid.
So if you download the ads from my Web site and don't ever click on them, you are actually lowering my revenue very slightly. It's better not to download ads if you aren't going to click on them.
I've worked hard (e.g. on http://www.fromoldbooks.org/ ) to try and have ads that are not too obtrusive, but when you're running an image Web site the bandwidth costs can be fairly high, and very few people will click on donate buttons.
Maybe it just means that some classes of Web site will go away, or will have to reinvent themselves, e.g. as "member-only pay to download images".
Liam
In a well-known fairy tale a boy enjoyed the attention he got when he cried out there's a wolf in the village! - but after a while, people stopped listening to him, and when there was really a wolf, no-one believed him, and the wolf stole his shoes and socks and his ipod and ran off with them into the forest.
:-), how about it?
The problem with people saying such-and-such will mean the certain end of so-and-so is that, like the boy in the story, they weaken our credulity. What is really meant here is that, if the growth of video downloading continues at the same rate, and no other changes happen, the current system will bog down. And maybe that's true.
I remember a huge thread on Usenet lasting months and months, or so it seemed, Imminent death of the network predicted, and that was in the early 1980s.
Yes, video delivery is something to take seriously. The distinction between downloading a movie for later viewing (I would probably want it to be error-free) and watching streaming video (compression is OK, and I'd want the network to drop packets if I got behind, which is part of what IPv6 quality of service is about) might be part of the solution here. Of course, as people get larger desktop screens with higher resolution, the demand even for static images is increasing. 640x480 doesn't cut it for most people today. And most computer users have stereo sound. Or play games in which network latency is significant. Violent games in which you pretend to be a wolf! And videoconferencing, TV-on-demand (as per original article, e.g. joost), and maybe soon 3d holographic pornography is coming.
The music and video industry would do well to spend a fraction of their current legal bills on researching more efficient delivery. Maybe encouraging deployment of IPv6 multicast, for example, so a single stream can go to thousands of users. Or paid subscription p2p networks. Or cascading servers. For that matter, probably we-who-write-the-standards could help by defining cache protocols that can interoperate with advertising, and can reliably send back access logs, maybe anonymized. Video CEOs, I know you read slashdot
But, shouting "wolves stole my socks" or "the sky is falling" won't help. Although if either of those things does happen, make sure to put the video up on youtube, OK?
I'm not sure that the open source version of Xara is mature. It also hasn't changed (as far as I can tell) since January. The current commercial version is not available on Linux, or doesn't seem to be, on their main Web site.
The Linux version is at http://www.xaraxtreme.org/ (and it's not linked to from xara.com either I think, or not obviously). Last time I tried it, it didn't have much in the way of support for text.
Welcome! There's no point in looking for perfect! There are places where PhotoShop is much better and places where The GIMP is much better, so it all depends what you're doing.
Liam
I haven't encountered such a limit, so I'm not sure where it's coming from. Oh, wait - in tool options yes.
First make a normal, sharp selection, then click the right mouse button in the image and choose the Select menu, and then Feather Selection, and you can enter any value. I don't know why there's a limit of 100 in the tool options; you could submit a bug/feature request to allow it to be made larger, perhaps.
Best,
Liam
I think maybe this is getting off-topic, but GIMP does have Selection->Feather. You may need to use a value that's double the PhotoShop value, I forget, but I use this technique to brighten/darken pictures fairly often.
Liam
Luckily GIMP can do rounded rectangles out of the box.
I still wouldn't recommend GIMP for replacing PhotoShop directly in an existing Apple + Adobe + PostScript/EPS/PDF workflow, because of the lack of CMYK support, and the difficulties of working in the RGB colourspace, which doesn't have a clear enough overlap with the CMYK colourspace, and the lack of gamut warnings (visible indication that you've used colours that can't be printed). This stuff needs to happen in the editing interface - to the person who said, isn't it like the sound system compensating for a listening room, no, it's more like the recording engineer noticing when the needles are stuck all the way at 10 (max level) and detail is getting lost. You can't add detail back later.
Inkscape and sk1 are both being used as vector-based software in pre-press (sk1 was designed for that) but overall the Free Software graphic design workflow is not yet very mature. Part of that is that the commercial works has been responsive overall to designer's needs, and part of it is that designers are only very rarely programmers, and programmers only rarely get involved in graphic design enough to understand why OpenOffice + GIMP isn't a total solution.
People have been working on improving the situation - e.g. the organisers and participants at the Libre Graphics Meeting. Scribus is indeed advancing rapidly, with a lot of momentum, although its text handling in some ways still lags behind very early versions of Quark, and as it stands today it's not going to challenge people who have come to rely on the newer features of InDesign. But really, it's early days yet. We're in some ways not quite where the proprietary world was in the late 1980s, and in other ways we're ahead of the proprietary world, but we have to catch up in some of the places where we're behind.
It's no good asking to use software they have no real hope themselves of modifying or enhancing, and saying, use this, and if it doesn't work for you, just add features, and by the way it doesn't do everything that right now you believe you need, because it's as much use as handing a person with no legs who needs to get somewhere a broken bicycle. This is not to say I don't believe in Free Software. I just recognise that we don't yet have a Free solution to everyone's needs yet.
There are two common ways to make animations in GIMP. For animated gif files, like a livejournal or deviantart avatar :D, you can use GIMP's built-in layers, with (replace) on the end of a layer name to make it have a GIF frame disposition of Replace, and then save the image as a GIF file. The other is to use the GAP plugin, which has some tools to make it (supposedly, I have not tried it) possible to do larger or longer animations.
Liam
...the celestial object in question is right at the corner where two edges of the universe meet. The edges are of course mirrored to fool astronomers. :-)
The better approach would be for schools to actually do their jobs and provide students with a solid foundation in fact checking and then ENCOURAGE them to consider wikipedia as a potential source.
I'd go further than that: yes, wikipedia is unreliable, of course it is. But it is a known quantity. If you block it, where will the students who used wikipedia for everything get there answers? Maybe from cheat sites, or from uncyclopedia, or from random blogs!
If the teacher finds the wikipedia entries related to the homework incorrect, discuss why in Class and assign students the task of improving the entries as part of their homework. Or at least of drafting new text to be discussed in class.
When the first horseless carriages were introduced, law-makers in some parts of the world required that someone walk in front of the new vehicle carrying a red flag. Part of this was because of a huge financial lobby on the part of the horse-and-cart industry (!) which in the end died out completely because of its RIAA-style stupidity, and part of it was a fear of the new technology. But even where such laws are still on the books they are now seen as representing fears of the small-minded. To be fair, thousands upon thousands of people die every year in horseless-carriage fights, so maybe really those people were right, but either way they are gone and forgotten.
The future is shaped by those who are not afraid.
The books I've looked at have been scanned at a resolution that's more or less adequate for OCR, but isn't really adequate for reproducing fine woodcuts, and is hopeless at metal engravings. I've found from my work on fromoldbooks.org that anything less than 1200 dpi generally produces pretty poor results for images, so that, for example, you can't read the signatures of the artist and engraver, still less compare engraving styles. It would be sort of like having a paraphrase of the text instead of the actual words.
It does, of course, vary a lot depending on the style of image. Bold illustrations for children's books, for example, do better at, say, 800dpi greyscale or colour. Fine steel engravings with lines at, say, less than a tenth of a degree from horizontal (they were done by hand after all) and that come out only a couple of pixels wide even at 1200dpi just turn into gray mush with weird banding artefacts until you go to a higher resolution (I use 2400dpi). There's a widely-cited study indicating that an "ultra-high" scan resolution of 400dpi is more than sufficient, based on an extremely small sample of images.
The damage that's done by poor quality digitization is that it makes it harder to justify doing a better job in the future.
For what it's worth, Mandriva has for years (OK, from when they were Mandrake) used RPM-format packages, with package management called "urpmi", which you could think of (if you wanted to) as a slightly improved improved apt-get. You can also use apt-get if you like. Or rpmdrake or Smart. All of which, including urpmi, will download packages automatically, including all dependencies.
On the other hand, they are quickly going to need more Mandriva distribution mirrors in the countries where these new computers are sold, and Mandriva is going to need to work on keeping them reliable.
Although we (W3C) are in fact working on more efficient binary encodings (www.w3.org/XML/EXI) this misses the point a little.
:-)
The good thing about XML is that it isn't good for anything, but is mediocre for everything
The main original use case were not "INI files" or other configuration stuff, but computer documentation, and transcriptions of texts. Mixed content, such as paragraphs of running text in which certain items are marked, or tagged, in some way, was the primary goal. We really didn't predict things like Web services!
XML is here, though. Almost every XML expert (myself included, and no irony here) would like to see XML be slightly different in some way, but we all also understand that the importance that every XML tool can have a stab at doing something useful with just about any XML document. And yes, there are people who like using emacs/vi/textedit/eclipse/wordpad/whatever in addition to tools like oxygen or Stylus Studio.
Liam
There's a difference between saying, "IE supports every aspect of every standard perfectly" (nothing does, although some programs come a lot closer than others, of course) and saying, "avoid single-browser extensions when possible and use only the portable subset of what is standard". I agree it's not easy though.
Liam
First,you only need one disenfranchised user to sue you. For example, if you are operating a Web site in the US (or in many cases the EU or Canada) anti-discrimination laws mean you'd better make your site accessible. And that means accessible to someone using a text-based browser such as Lynx, as well as a text reader. See the American Disabilities Act and the "508" laws.
Second, yes, you can make a Web site more cheaply that's aimed at, say, IE 6. Or IE 7. or maybe you could choose Mosaic 1.5, or Netscape 0.96, as some other sites did. And in a few years you might have to redo everything when that particular browser is no longer available.
Third, you could optimize your site for a particular screen size. For example, 640x480 pixels or even 800x600 are popular choices. Of course, you can't actually buy a desktop PC with a 640x480 pixel screen very easily today. Mine is 1680x1050, but sizes vary widely, mostly because of the emerging popularity of watching DVDs on a computer. But, right now a surprising number of people in some parts of the world (Europe and Japan mostly I think) seem to browse the Web on a mobile phone, and those often have 320x240 pixel screens.
The point of the World Wide Web is that it's for everyone, everywhere, regardless of language, culture, ability, special needs or even computing platform. Do the right thing. Make your site work on as many platforms as you can, by sticking to standards, avoiding platform-specific tricks, and testing.
[disclaimer: I work for the World Wide Web Consortium, although in this area my opinions expressed here also match those of my empolyer!]
The economics of software outside the west are very different to what most people are used to
Actually it's not clear to me that most people live in the West. Nor is it clear to me that one can characterise the "rest of the world" so simply. There are whole Linux distributions aimed at (and developed in) India and China. And for that matter there are places in the West where pirated software is common. There have even been slashdot stories about it as I recall, e.g. in parts Europe.
First, the biggest improvement you are likely to see in the Gimp is if you go to Colour->Layers (in older versions of the Gimp it's Layers->Colours->Levels) and click Auto. For pictures that should contain some black and some white this will usually make a noticeable improvement.
Second, yes, Canon (for example) includes (Windows only, proprietary, secret, closed-source) software to compensate: you shoot a 25% grey surface. You can also use this inside the camera itself: there it will use the data for white balance correction.
In practice, though, it's fairly hard to do this yourself. One difficulty is that the amount and position of colour aberrationswill probably vary depending on the lens you use, or, with a fixed lens, the amount of zoom and the aperture size. I know I found that when my Casio developed some dark spots.
There are some programs that are used with hugin, the panorama stitching UI, that help with some lens corrections; it might be you could ask those people. However, a lot of the variation you are seeing is likely to be digital noise. Try taking 3 shots usinga tripod and timer or remote, and comparing them.
I agree with you that needing more than 200dpi is fairly rare, and if I have needed it more often it is possibly because I tend to work with older books, or books in poor condition.
:-)
It's not only for footnotes, but also, say, to distinguish an ae ligature (æ in utf8) from an oe ligature (oe in utf-8 if it survives slashdot), or from the unligatured letters, or to distinguish a zero (0) and a letter "O", and so on. If one has the original book to hand, that's less of an issue.
I agree that the Google bulk scanning is not good quality. In the past, Project Gutenberg produced some very low quality e-texts too. Some of them have been improved, and newer ones are to a much higher standard. It doesn't seem that long since I suggested the use of SGML to Michael Hart, and pointed out that they would then be able to capture italics and other textual variations -- but it's about 15 years ago I think, and since then HTML has become popular
600dpi is really bad for an engraving, but OK for a screened photograph if you don't mine losing some detail. It's not good for archival purposes, e.g. for studying which engraver worked on a particular image.
You're right, though, that Google has spurred competition, and I agree that it's a good thing!
Best,
Liam
Most of these people focus on English-language books printed in the 19th and early 20th centuries, because (1) it's usually easy to determine copyright status, and (2) if you go earlier you get the tall "s" ( in utf-8) which no OCR program today seems able to handle, so the scanning cost is increased.
Scanning with a flat-bed scanner basically wrecks the binding. So the books probably need to be rebound afterwards, or can be discarded.
There are photography setups (e.g. Phase One has one) but the resolution is too low, even with a 40 megapixel medium-format camera (yes, they are used for this). A little high-school mathematics (e.g. Nyquist) and the back of an envelope, combined with some measurements, will show that if you scan engravings at under 1200dpi, you will lose a lot of detail, and indeed, compare for example the Alice in Wonderland pictures on my own site with the Project Gutenberg ones. You can read the engraver's signature on most of the ones I have. Yes, the bandwidth needed to host higher resolution images is greater (which is why I have ads, sorry). But it's worth it.
Some of these books will never be scanned again. Even for OCR, 400dpi grayscale seems a minimum for footnotes and other small text even in English.
I'd also like to see more interfaced like the Project Gutenberg Distributed Proofreaders' site where people can submit corrections. Maybe use a WIKI for the transcription??
Liam
:-) yes, you could say I've heard of FrameMaker, and of Author/Editor and of Adept (later Epic) and of DataLogics Pager and of Interleaf Publisher and of a great many other SGML tools. I was certainly among those who felt that the complexity of the SGML standard was a hindrance to adoption, and also that SoftQuad Panorama was a good demonstration (at the time) of where we wanted to go.
But I certainly don't mind being "lectured" -- we learn a lot by listening!
Best,
Liam
I should admit that our mandate was to put SGML on the Web, not to make an entirely new syntax; we really didn't expect people to be using what became called XML for anything other than predominantly textual documents. There are, in fact, problems with anonymous end tags for metadata: these are not in general problems for computer programming so much since you can test the code in a way that's often not possible with metadata interchange. Unfortunately, no, I can't give you references for studies that were done (and there were not many such studies that I can recall, although the number was certainly non-zero; the US DoD CALS initiative might have made some public, though, for a starting point if you want to search) in this precise area. As for what we were optimizing, it was pretty clear at the time, but the original central use cases of XML are not really so central these days, although of course they're still there. As I mentioned, much of that history is locked away in private mail archives right now.
:-), changing it, as we discovered with XML 1.1, is next to impossible, and the single most important thing about XML is not what it looks like at all - it's that it's the same everywhere, it's that XML is widely deployed, it's that all general-purpose XML tools work on all XML, so that every new tool, evern new document, multiplies (by some factor only slightly above 1.00 usually) the value of all other XML documents and tools. The network effect.
At any rate, whether it could be better (it could certainly be improved) or whether it could be worse (that's easy to imagine too), it is what it is
Liam
Thank you for your kind words :-)
We weren't really aiming at HTML users.
I'm afraid the only useability studies of SGML tools that I saw were not released to the public. At the time I worked for a vendor of SGML-based software (e.g. including an editor, a viewer, a development environment) and it was a matter of great concern to us.
It's possible we could open up the archives of the XML Working Group, but it would mean getting the permission of several hundred people. I'll ask some people at the upcoming XML conference in Boston and try and get a feeling for how hard that would be.
I agree with you that the involvement of Sun, Microsoft, Netscape and others was very helpful. There are, however, other file formats that were around in the past and had similar backing but which failed. Remember ODA? There were also some attempts early on to move the Web to a dialect of RTF, which was also supported by big companies.
Best,
Liam
> The error message does not help people all that much
:-)
One case where it helps most is when an incorrect start tag was applied; with the empty end tag this could not be detected, and it turned out to be more comman than one might expect. You're right that the error messages often aren't good, but did you ever try debugging a large SGML document with OMITTAG and SHORTREF in use? The error message was almost always "characters found after end of document" because the required strategy by SGML (in one of the most common error situations) was to close elements until you got a match, so the parser typically closed elements all the way up the tree to the document element, and then gave up.
We were bound, at the time, to strict SGML compatibility; perhaps if we had known XML would succeed we could have made more changes, but then we would have strayed further from the well-trodden path of implementation experience.
As to comments for attributes, I agree with you; we lost them, though because we needed a language simple enough it could be processed e.g. with Perl. We didn't dare dream that Perl would support XML natively!
I agree with you that structured tools should generally be used. The redundancy and simplicity help computer-generated XML, and help to detect, say, missing portions of documents. If xml-rpc is scary, s-expr rpc is even scarier!
Liam
A lot of people ask about using a different syntax, such as @name{....} as Scribe (and later LaTeX) did. Note that @element{xxx} is in fact a possible syntax that can be defined using SGML. But we were after something different.
;-)
When we designed XML, we had over a decade of solid experience with interoperability in the world of SGML, and we also knew about the kinds of problems that different sorts of users had with different sorts of syntax.
The primary users of SGML-based documentation systems were not programmers. They were people who were often not likely to know about a bracket-matching option in an editor or about code indenting, for example. But they were still legitimate users.
You can't easily test the markup in a declarative system: if in an HTML document I used H3 instead of P in a document it might not look right, but it would still parse OK. If I muddle up Author and Title in a bibliography, same thing.
So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with </>, allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.
It's true that today XML is used in lots of situations we didn't predict. We were amazed that by the time we got XML published as a Recommendation there were over 200 users. So no, we didn't predict the future percfectly. But the popularity of XML shows we can't have done all that badly, really
Liam
(Liam Quin, currently W3C XML Activity Lead)
I experimentally put a couple of pages of sheet music on fromoldbooks.org yesterday. I'm not sure how useful they are, but I'm contemplating adding a lot more out-of-copyright sheet music.
I'd be willing to host good quality scans from other people, too, but it has to be demonstrably out of copyright -- I'm not interested in "legal loopholes" here. I'd suggest using 1200dpi greyscale and then adjusting "curves" to make a clear, sharp image. Both the music and the typeset score must be out of copyright, as well as the lyrics. In the US and Canada this is generally easy to determine, but for music produced in other countries it can be arbitrarily difficult; anything printed before 1820 or so is pretty safe though.
This doesn't really help the original poster very much unless I happen to have some specific piece of music, of course!