19 May
2005
19 May
'05
5:12 p.m.
On a separate post I mentioned cross support/cross linking. It was my
clumsy way of saying indexing. I would be nice if people pitched in and
just did it. I may make a list of all of the chips listed in the
individual
PDF's that Al has posted for the westerndigital datasheets. If Al then
posts this index with the PDF's (or creates an index folder) so the
googlebot can scan it then a google search would point you where to get it.
Simple with the task easily shared amoung many people.
--
That would be a wonderful thing. I have a HUGE backlog of scanned
databook material, and just finished picking up almost 40 book boxes
of 70's -> 90's data books from a third large collection.
The first was from the databook collection of Haltek Electronics (RIP),
the second from a private collection that was given to us with the
promise that it would be scanned, and now this addional one.
(I've found a few interesting things in the last lot already.. A copy
of the Fairchild '69 data book, a book by Gnostic Concepts on early
70's memory technology, and two of the classic error correcting codes
books)
There is no way I'm going to have time to OCR or index this. A simple
text file per PDF with part number and page number would be wonderful.
This is also the sort of data that Google seems to index REALLY well.
Watching the hits on bitsavers, almost everyone finds the archive by
stumbling upon the 'whatsnew.txt' or 'Index.txt' files.
I'd be interested in suggestions for what books should be higher on the
post-processing queue too. I probably have 50 databooks scanned but not
PDFed right now. I've been concentrating mostly on getting the classic
early stuff done first (2nd Edition TI TTL Data Book, etc.)
19 May
19 May
5:32 p.m.
From: "Al Kossow" <aek at bitsavers.org>
Sent: Thursday, May 19, 2005 4:12 PM
On a separate post I mentioned cross support/cross
linking. It was my
clumsy way of saying indexing. It would be nice if people pitched in and
just did it. I may make a list of all of the chips listed in the
individual
PDF's that Al has posted for the westerndigital datasheets. If Al then
posts this index with the PDF's (or creates an index folder) so the
googlebot can scan it then a google search would point you where to get
it.
Simple with the task easily shared amoung many people.
--
That would be a wonderful thing. I have a HUGE backlog of scanned databook
material, and just finished picking up almost 40 book boxes
of 70's -> 90's data books from a third large collection.
The first was from the databook collection of Haltek Electronics (RIP),
the second from a private collection that was given to us with the promise
that it would be scanned, and now this addional one.
(I've found a few interesting things in the last lot already.. A copy
of the Fairchild '69 data book, a book by Gnostic Concepts on early
70's memory technology, and two of the classic error correcting codes
books)
There is no way I'm going to have time to OCR or index this. A simple
text file per PDF with part number and page number would be wonderful.
This is also the sort of data that Google seems to index REALLY well.
Watching the hits on bitsavers, almost everyone finds the archive by
stumbling upon the 'whatsnew.txt' or 'Index.txt' files.
I'd be interested in suggestions for what books should be higher on the
post-processing queue too. I probably have 50 databooks scanned but not
PDFed right now. I've been concentrating mostly on getting the classic
early stuff done first (2nd Edition TI TTL Data Book, etc.)
One extra caveat would be when listing page numbers both the printed page
numbers and the PDF's declared page numbers should be included.
As I said when someone downloads a copy to look for something when there is
no index, just do it and send it back to Al. By sharing the load no one has
to "do it all right now by yourself".
I highly recommend a file that could be concatenated into a "master index"
so it should have a PDF filename plus page numbers. Each index should be
named the same as the PDF with a different extension and the field widths
should be standardized.
Al can decide if it should be text only, html, excel, etc. If there is a
vote I vote text only either comma delimited (with quotes when needed) or
fixed width fields that would be easier to read.
Randy
www.s100-manuals.com
5:46 p.m.
On Thu, 2005-05-19 16:32:46 -0500, Randy McLaughlin <cctalk at randy482.com> wrote:
One extra caveat would be when listing page numbers
both the printed page
numbers and the PDF's declared page numbers should be included.
Some time ago, I worked on some TeX skeleton (generated with script's
aid) to produce a PDF file with nice bookmarks and all the like.
However, I came to the conclusion that this isn't a real solution.
I'm still thinking about how paper-based documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...)
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
6:20 p.m.
On Thu, 2005-05-19 at 23:46 +0200, Jan-Benedict Glaw wrote:
On Thu, 2005-05-19 16:32:46 -0500, Randy McLaughlin
<cctalk at randy482.com> wrote:
Doesn't this sort of imply that PDF is the wrong choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-)
It might be good for text-based documents (offering text searching and
the like), but is it necessarily the right thing for collections of page
scans?
cheers
J.
One extra caveat would be when listing page
numbers both the printed page
numbers and the PDF's declared page numbers should be included.
Some time ago, I worked on some TeX skeleton (generated with script's
aid) to produce a PDF file with nice bookmarks and all the like.
However, I came to the conclusion that this isn't a real solution.
I'm still thinking about how paper-based documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...)
6:48 p.m.
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
Sent: Thursday, May 19, 2005 5:20 PM
On Thu, 2005-05-19 at 23:46 +0200, Jan-Benedict Glaw
wrote:
PDF is terrible way to package the documents. It's just better than any
other practical method ;-)
So many talk about ASCII being the only "right way", as Al can attest to
time and accuracy makes image oriented PDF's the way to go.
Finding errors in OCR'ed files is extremely time consuming.
Randy
www.s100-manuals.com
On Thu, 2005-05-19 16:32:46 -0500, Randy
McLaughlin <cctalk at randy482.com>
wrote:
Doesn't this sort of imply that PDF is the wrong choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-)
It might be good for text-based documents (offering text searching and
the like), but is it necessarily the right thing for collections of page
scans?
cheers
J. One extra caveat would be when listing page
numbers both the printed
page
numbers and the PDF's declared page numbers should be included.
Some time ago, I worked on some TeX skeleton (generated with script's
aid) to produce a PDF file with nice bookmarks and all the like.
However, I came to the conclusion that this isn't a real solution.
I'm still thinking about how paper-based documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...) 
8:02 p.m.
PDF is terrible way to package the documents.
It's just better than
any other practical method ;-)
So many talk about ASCII being the only "right
way", as Al can attest
to time and accuracy makes image oriented PDF's the way to go.
Finding errors in OCR'ed files is extremely time
consuming.
Those (OCRed plain text and PDF files) are not the only options.
As I remarked a minute ago, I'd far rather have a tar (or a zip, or a
directory on an FTP server) containing TIFF files than a PDF containing
the same TIFF files.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7:45 p.m.
> [...] But first, I'd need to understand PDF
(whose specification
> actually is about 8cm thick...)
1236 pages, according to GhostScript run on the PDF for the 1.6 spec.
Doesn't this sort of imply that PDF is the wrong
choice of format for
jobs like these?
Yes, if it needed further implying.
(plus I'm pissed at Adobe because their current
readr for Linux eats
close on 100MB of disk space just to let me read a PDF file :-)
So don't use Adobe's reader. Ghostscript generally does a pretty good
job in my experience.
It might be good for text-based documents (offering
text searching
and the like),
...though still not as good as a plain text file...
but is it necessarily the right thing for collections
of page scans?
"The" right hing? I dunno, but I do know I'd sure rather have a
directory containing TIFF files than a PDF containing the same TIFF
files. Or a tar of them, or almost anything else non-proprietary - the
less information I have to understand to figure out how to pull it
apart, the better, on which score PDF (as pointed out above) fails
rather dismally. (It may be an open format in that the doc is
unrestricted - though I'm not sure of even that much - but for an open
format, its doc is not easy to find. Google finds
http://www.adobe.com/products/acrobat/adobepdf.html, which is full of
puffery and notably short on links to fetch the spec itself from; I
eventually managed to scare it up - and it's a PDF. "Here! If you can
figure this file out, it will tell you how to figure it out!" As if
that weren't enough, Adobe prohibits saving a copy of it(!!); the
second page includes [ten-finger copy] "No part of this publication
(whether in hardcopy or electronic form) may be reproduced, stored in a
retrieval system, or transmitted, in any form, or by any means,
electronic, mechanical, photocopying, recording, or otherwise, without
the prior written permission of Adobe Systems Incorporated.".)
Writing one's own tar unpacker is a contemplatable exercise - a fairly
easy one, even, for a reasonably experienced programmer. Writing a PDF
groveler...is not.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
20 May
20 May
12:07 a.m.
On Thu, 2005-05-19 at 22:20 +0000, Jules Richardson wrote:
Doesn't this sort of imply that PDF is the wrong
choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-)
Well, don't use Adobe's reader, then! GPDF, GV, XPDF, and Evince are
just the ones off the top of me head. Evince is the latest one out - and
looks very nice. http://www.gnome.org/projects/evince
--
Tore S Bekkedal <toresbe at ifi.uio.no>
3:31 a.m.
On Thu, 2005-05-19 22:20:53 +0000, Jules Richardson <julesrichardsonuk at
yahoo.co.uk> wrote:
On Thu, 2005-05-19 at 23:46 +0200, Jan-Benedict Glaw
wrote:
There are alternatives, like:
- A tarball containing all the TIFF (or whatever) images as well
as some (generated) HTML page (containing some kind of slide
show) as well as a small description file (use this with some
program (to be written) to generate the HTML file(s)).
This gives the chance that the description file can be done
quite clever, so you'll get eg. a clickable index for the TIFF
files (though, needs to be done manually, but now this work
load can actually be *distributed*)
- PDF isn't all that wrong. As far as I understood it, it's
possible to embed any binary sequence into a PDF file. With a
program (like an extended tumble) you can produce a readable
PDF file that also acts as some kind of tarball (though needs
a self-written generator/extractor).
I actually *really* like the PDF approach, just because it's so easy and
hassle-free to view the file. Also, if done right, you won't loose
access to your actual image files. But in the long term, we need to work
on the tools. (That's why I started to play a bit with the TeX
approach.)
That's my wishlist (to be addressed after the vax-linux port matured:-)
- PDF files with really cool bookmarks, containing the chapter
numbers, headings or page numbers (or any mixture of those).
That means that the backing store might either be a tarball or
a PDF file (used as a tarbarll).
- I'm *really* missing a clickable index. People may invest the
time to hand-type the original book's index and the pages into
some description file. From this, I expect a new index
(clickable) to be generated.
- If graphical contents is OCRed+verified, there shall be a way
to generate the final PDF with the OCRed data (except for
those pages where this hasn't been done--there, the original
image file should show up).
Comments?
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
I'm still thinking about how paper-based
documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...)
Doesn't this sort of imply that PDF is the wrong choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-)
7:36 a.m.
On Fri, 2005-05-20 at 09:31 +0200, Jan-Benedict Glaw wrote:
On Thu, 2005-05-19 22:20:53 +0000, Jules Richardson
<julesrichardsonuk at yahoo.co.uk> wrote:
See my other post; that's my preference and what I tend to do with all
image-based PDF content I download from anywhere anyway...
On Thu, 2005-05-19 at 23:46 +0200, Jan-Benedict
Glaw wrote:
There are alternatives, like:
- A tarball containing all the TIFF (or whatever) images as well
as some (generated) I'm still thinking about how paper-based
documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...)
Doesn't this sort of imply that PDF is the wrong choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-) HTML page (containing some kind of slide
show) as well as a small description file (use this with some
program (to be written) to generate the HTML file(s)).
This gives the chance that the description file can be done
quite clever, so you'll get eg. a clickable index for the TIFF
files (though, needs to be done manually, but now this work
load can actually be *distributed*)
One of the things that I was working on a few years back was layering
multiple delivery mechanisms over one form of content (where the dataset
was sufficiently large that storage in multiple formats wasn't
justified).
Data was kept in the "purest" form on the server side, and a client
could ask for content in whatever format they wanted (in this case raw
images, PDF, HTML etc.) and over whatever interface mechanism they
wanted (HTTP, FTP, WAP, email, network filesystem etc.)
Conversion of imagery tends to be memory-expensive, but not
computationally so (unless you're also scaling / cropping images);
caching can be added in where necessary so save on *some* resources.
The other advantage is that as a database is keeping track of what's in
the system there are potential hooks there for indexing and maintaing
access stats.
I could see some of the big archives around the planet (regardless of
content) going this way in the future; user base is maximised through
offering different formats whilst the "pure" dataset is all that's
backed up and actually kept on disk.
cheers
Jules
8:05 a.m.
On Fri, 2005-05-20 11:36:24 +0000, Jules Richardson <julesrichardsonuk at
yahoo.co.uk> wrote:
Actually, I was working on something like that as well, but with a
different ulterior motive: build something like this as a redundant,
peer-to-peer capable database and many of archiving-old-data problems
just vanish. (Indeed, it would make up a nice P2P system as well.)
On Fri, 2005-05-20 at 09:31 +0200, Jan-Benedict Glaw
wrote:
For the records (and my education), how do you extract these?
On Thu, 2005-05-19 22:20:53 +0000, Jules
Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
See my other post; that's my preference and what I tend to do with all
image-based PDF content I download from anywhere anyway... On Thu, 2005-05-19 at 23:46 +0200, Jan-Benedict
Glaw wrote:
There are alternatives, like:
- A tarball containing all the TIFF (or whatever) images as well
as some (generated) I'm still thinking about how paper-based
documentation can be made up
cleverly enough to gain text as well as images and mixing meta-data into
that. Maybe I'd do some C programming and hack something nice producing
PDF files helding everything? But first, I'd need to understand PDF
(whose specification actually is about 8cm thick...)
Doesn't this sort of imply that PDF is the wrong choice of format for
jobs like these? (plus I'm pissed at Adobe because their current readr
for Linux eats close on 100MB of disk space just to let me read a PDF
file :-) HTML page
(containing some kind of slide
show) as well as a small description file (use this with some
program (to be written) to generate the HTML file(s)).
This gives the chance that the description file can be done
quite clever, so you'll get eg. a clickable index for the TIFF
files (though, needs to be done manually, but now this work
load can actually be *distributed*)
One of the things that I was working on a few years back was layering
multiple delivery mechanisms over one form of content (where the dataset
was sufficiently large that storage in multiple formats wasn't
justified).
Data was kept in the "purest" form on the server side, and a client
could ask for content in whatever format they wanted (in this case raw
images, PDF, HTML etc.) and over whatever interface mechanism they
wanted (HTTP, FTP, WAP, email, network filesystem etc.) I could see some of the big archives around the planet
(regardless of
content) going this way in the future; user base is maximised through
offering different formats whilst the "pure" dataset is all that's
backed up and actually kept on disk.
That's what I dream about in long nights, but not as a centralized
database, but a distributed one. Imagine you shift in a raw-encoded
audio CD (with all the interleaved stuff intact, even containing all the
mischievous, intentional errors. ...and a front-end interlacing WAV
files (which another front-end could use to produce ogg/mp3/wma/you name
it).
Concepts like that can be applied to nearly all media types. Just record
that the underliing (sp?) recording/reading machinery gets and write
filters for that. These filters may get as complex as filesystem
drivers. In fact, this *is* a layered filesystem. Remember the thread(s)
about how to rescue tapes? ...or other HDD images? Apply these general
concepts and things may get easier :)
For now (as we're not (yet) there), prividing space isn't my main
problem. It's about having (time to write) the software.
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
9:37 a.m.
On Fri, 2005-05-20 at 14:05 +0200, Jan-Benedict Glaw wrote:
On Fri, 2005-05-20 11:36:24 +0000, Jules Richardson
<julesrichardsonuk at yahoo.co.uk> wrote:
For the records (and my education), how do you extract these?
I've always used Imagemagick's 'convert' util to do it -
'convert foo.pdf foo.tif' will produce a multi-page TIFF image
corresponding to the input pdf file.
'convert foo.pdf foo%02d.tif' will give you seperate TIFF images for
each page (which is the more useful flavour)
I believe Ghostscript will do it too, and there are at least a couple of
other utils I've stumbled across in the past to do this (names elude me
right now!)
cheers
Jules
- A
tarball containing all the TIFF (or whatever) images as well
as some (generated)
See my other post; that's my preference and what I tend to do with all
image-based PDF content I download from anywhere anyway...
9:50 a.m.
On Fri, 2005-05-20 13:37:54 +0000, Jules Richardson <julesrichardsonuk at
yahoo.co.uk> wrote:
On Fri, 2005-05-20 at 14:05 +0200, Jan-Benedict Glaw
wrote:
Will these extract the _original_ TIFF files (eg. with embedded comments
etc.) or would it only produce images looking like the original ones?
Oh, TIFF, *Tagged* image file format. TIFF could even be used to hole
metadata :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Fri, 2005-05-20 11:36:24 +0000, Jules
Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
For the records (and my education), how do you extract these?
I've always used Imagemagick's 'convert' util to do it -
'convert foo.pdf foo.tif' will produce a multi-page TIFF image
corresponding to the input pdf file.
'convert foo.pdf foo%02d.tif' will give you seperate TIFF images for
each page (which is the more useful flavour) - A
tarball containing all the TIFF (or whatever) images as well
as some (generated)
See my other post; that's my preference and what I tend to do with all
image-based PDF content I download from anywhere anyway...
11:01 a.m.
On Fri, 2005-05-20 at 15:50 +0200, Jan-Benedict Glaw wrote:
On Fri, 2005-05-20 13:37:54 +0000, Jules Richardson
<julesrichardsonuk at yahoo.co.uk> wrote:
Hmm, I'm not actually sure - if I get chance later I'll do some tests...
it certainly won't result in any quality loss, but whether it preserves
comments I don't know. Possibly it depends on the PDF spec too (i.e.
whether the PDF spec explictly mentions non-image fields within image
data embedded in a PDF file and whether the spec says that they must be
preserved when transformations are done)
On Fri, 2005-05-20 at 14:05 +0200, Jan-Benedict
Glaw wrote:
Will these extract the _original_ TIFF files (eg. with embedded comments
etc.) or would it only produce images looking like the original ones? On Fri, 2005-05-20 11:36:24 +0000, Jules
Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
I've always used Imagemagick's 'convert' util to do it -
'convert foo.pdf foo.tif' will produce a multi-page TIFF image
corresponding to the input pdf file.
'convert foo.pdf foo%02d.tif' will give you seperate TIFF images for
each page (which is the more useful flavour) > - A tarball containing all the TIFF (or
whatever) images as well
> as some (generated)
See my other post; that's my preference and what I tend to do with all
image-based PDF content I download from anywhere anyway...
For the records (and my education), how do you extract these? Oh, TIFF, *Tagged* image file format. TIFF could even
be used to hole
metadata :)
It's *could* - problem I've always found is that tools to handle multi-
image TIFF files are pretty thin on the ground; they either don't bother
at all (and assume one image per file) or they try and buffer the whole
lot into memory (for 100 A4 page scans in one file, that's Not A Good
Thing). Only about 20% of tools I've come across over the years actually
try and handle TIFFs properly (as I've said in the past, even
Imagemagick isn't great because it buffers data to 32-bit colourspace in
memory regardless of the actual images' bit depth)
That then means that for TIFF to be a viable archive option, it needs to
be one image per page - which also means duplicating metadata across all
pages (images) too.
In some ways it'd be handy having metadata in each image saying what
document it relates to, but duplicating a copy of the index,
description, search keywords or whatever across every image making up a
scanned document seems a bit excessive.
I think I'd rather keep the image data as seperate TIFF files within a
common directory / archive making up a document, and a single ASCII file
that provides the metadata for that document (TIFF's a pretty darn good
format, but it's let down by some pretty bad tools out there)
Open question to the list - would PNG files be a better option than
TIFF? In terms of what I've said above, there's probably not a lot in it
(and TIFF probably has support on classic hardware where PNG doesn't).
But PNG possibly has the advantage that most (and certainly all modern)
web browsers support it, which possibly has implications for a web-
accessible archive...
cheers
Jules
11:25 a.m.
At 10:01 AM 5/20/2005, Jules Richardson wrote:
Only about 20% of tools I've come across over the
years actually
try and handle TIFFs properly
With tagged formats, the problem in my mind has always been
a lack of mechanism for an app to decide what to do with
unknown tags while processing a file. Do you throw out the
tags or keep them?
- John
11:55 a.m.
On Fri, 2005-05-20 10:25:10 -0500, John Foust <jfoust at threedee.com> wrote:
At 10:01 AM 5/20/2005, Jules Richardson wrote:
Ask the user. There's no sane way to decide wether a tag may be thrown
away or should be thrown away. Just two sample cases:
For astronomical use, you want to keep all tags. They contain
important image information (most important they contain RA and
declination as well as the size of the image).
If you're photoshop'ping your digital stil-camera's pictures,
you'd actually like to throw away the tags. Most prominent,
there are smaller preview images embedded that may or may not be
a "good" preview image after some servere photoshopping...
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Only about 20% of tools I've come across over
the years actually
try and handle TIFFs properly
With tagged formats, the problem in my mind has always been
a lack of mechanism for an app to decide what to do with
unknown tags while processing a file. Do you throw out the
tags or keep them?
11:55 a.m.
On Fri, 2005-05-20 at 10:25 -0500, John Foust wrote:
At 10:01 AM 5/20/2005, Jules Richardson wrote:
Well I suppose you preserve tags even if you don't understand them when
copying etc.
When decoding, you just skip any that you don't understand and in theory
your decoder either finds no image it can understand and breaks, or it
works.
Are there any vendor-unique TIFF tags out there that are indirectly
related to the image decoding process? I don't remember stumbling across
vendor-unique tags that say something like "apply xyz filter after
decoding and before displaying" or anything like that, so a decoder
should either be able to display the correct image or barf, but not
something inbetween. I could be wrong there though...
ISTR that the baseline TIFF tags that any decoder should understand
support quite a lot of useful fields (including metadata-like stuff,
like description, author, timestamp, software package etc.)
I tend to find that decoders are pretty good at handling the various
tags, they just often seem to be spectacularly crap at processing TIFF
files with multiple images in them - often because image tools are often
written with a 1:1 mapping between file and image in mind I suppose.
cheers
Jules
Only about 20% of tools I've come across over
the years actually
try and handle TIFFs properly
With tagged formats, the problem in my mind has always been
a lack of mechanism for an app to decide what to do with
unknown tags while processing a file. Do you throw out the
tags or keep them?
11:27 a.m.
On Fri, 2005-05-20 15:01:39 +0000, Jules Richardson <julesrichardsonuk at
yahoo.co.uk> wrote:
That then means that for TIFF to be a viable archive
option, it needs to
be one image per page - which also means duplicating metadata across all
pages (images) too.
...which I consider to be a good thing, to some extend. Keeping Part N?,
title, year, ... in each and every page just looks like a bug. But OTOH
keeping an image's keywords, printed page number, captions on a per-page
(or per-image, that is) basis is a good thing.
In some ways it'd be handy having metadata in each
image saying what
document it relates to, but duplicating a copy of the index,
description, search keywords or whatever across every image making up a
scanned document seems a bit excessive.
Full ACK. But keeping the index words that apply to this very page
inside the TIFF might make some sense :)
I think I'd rather keep the image data as seperate
TIFF files within a
common directory / archive making up a document, and a single ASCII file
that provides the metadata for that document (TIFF's a pretty darn good
format, but it's let down by some pretty bad tools out there)
A text file would work as well, but I'd place one text file per image
and one for the per-document metadata.
Open question to the list - would PNG files be a
better option than
TIFF? In terms of what I've said above, there's probably not a lot in it
(and TIFF probably has support on classic hardware where PNG doesn't).
But PNG possibly has the advantage that most (and certainly all modern)
web browsers support it, which possibly has implications for a web-
accessible archive...
Wouldn't a web browser also show TIFFs? At least the simple ones?
*check* No. My Firefox would like to display it with the 'display'
program of ImageMagick...
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
12:55 p.m.
It's *could* - problem I've always found is
that tools to handle multi-
image TIFF files are pretty thin on the ground; they either don't bother
at all (and assume one image per file) or they try and buffer the whole
lot into memory (for 100 A4 page scans in one file, that's Not A Good
Thing). Only about 20% of tools I've come across over the years actually
try and handle TIFFs properly (as I've said in the past, even
Imagemagick isn't great because it buffers data to 32-bit colourspace in
memory regardless of the actual images' bit depth)
The spectacular badness of TIFF viewers (at least at the free-as-in-beer
level) is why I prefer PDFs. Despite their problems, the PDF viewers seem
*way* better at rendering (and printing) the pages. (Though I am sure there
are other platforms which have no decent PDF viewer.)
Vince
23 May
23 May
7:26 p.m.
On Thu, 19 May 2005, Randy McLaughlin wrote:
Al can decide if it should be text only, html, excel,
etc. If there is a
vote I vote text only either comma delimited (with quotes when needed) or
fixed width fields that would be easier to read.
This is more of just a general observation applicable to everything:
commas are convenient and intuitive but a much better delimiting character
for anything you do is the vertical line | because it rarely if ever shows
up in text either machine generated or hand-written and will therefore not
cause interference in field data containing commas when parsing.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
7001
days inactive
7005
days old
19 comments
9 participants
participants (9)
-
aek＠bitsavers.org -
cctalk＠randy482.com -
jbglaw＠lug-owl.de -
jfoust＠threedee.com -
julesrichardsonuk＠yahoo.co.uk -
mouse＠Rodents.Montreal.QC.CA -
toresbe＠ifi.uio.no -
vcf＠siconic.com -
vrs＠msn.com