Shop/Parts Manual CD rom Project R&D
JETman
down in front of a G3 330mz and toyed with a few things.
1. Using OmniPage 8.0, we were unable to combine graphics and text in a
usable manner with a single scan. We did get a good quality scan of
all items but as a graphic, not a combo of text 'n graphics.
2. The options, (IMO), at this point are a), Produce the manuals on CD
ROM in graphic form which would be lacking the search capability but
would not require replicating the original with regards to text,
photographs, and line illustrations; or b), proceed with a full featured
CD ROM of each manual.
3. Estimate for CD ROM master production for non-search type product
would be about a couple of weeks working full time. On the other hand,
a full featured CD ROM master would take upwards of a couple of months.
4. Steps required for a no features master include: a), Scan each page
at 300 dpi into Photoshop and save as a tiff; b), Convert the tiff to a
PDF by printing to PDF Writer, (Chooser extension), What was originally
a 6-8 meg tiff file is reduced to less than Meg which would easily
permit a full manual for each CD.
5. Steps required for a full featured CD ROM master include scaning the
full page as a graphic, scanning the ext with OCR, put it all into
PageMaker as this is the only way to maintain good typographical
control, (leading,etc.), and generating the data base required for cross
referencing, etc. Search itself does not require a database.
6. When considering the amount of time required to go through a manual
and scan the photo(s), line illustrations, and text and the effort that
would be required to format it to match the original, it is my humble
opinion that a simple CD would be the best way to go. With a table of
contents, one should be able to navigate to the appropriate page(s).
Bear in mind that he/she could elect to print the page and it would be
of quality close to the original and better than some of the manual
reprints that are floating around.
I think that all this should be run past Steve Miller as he is involved
daily in the artsy stuff. I am more into books, catalogs, and technical
publications.
What say you Steve?
--
Regards,
JT, Austin, Texas - Home of the Annual Spamarama Festival
(the kind in a can!)
Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
Replace the “*” with an “s“ when replying!
NOSP...@hange.com.comnospam
Hmmmmm.....
First Omnipage generally sucks. I've used it since version 5 and it
has many limitations, including not handling the pic/text combo you
mentioned. Additionally, even handling a straight text scan used to
throw everything into stupid frames when exporting to MS Word formats.
I have Omnipage 9 now and it is some what better, but still has
shortcomings.
Xerox TextBridge98 is a superior product, supporting a scan directly
to .PDF format. This is by far the easiest way to do the kind of
scanning you are considering. (Note one shortcoming, this format/save
setting is only available before you scan. A few weeks ago I spent
some time scanning a 60 page document I needed to save in MS .doc
format only to find that a co-worker had slipped into my office and
changed the setting to .PDF format, I had to re scan the entire
thing!).
I am generally not a fan of .PDF format. I love most Adobe products
but the .PDF format is a little too propriety for me. You can also
blow up/crash the .PDF reader by printing one long doc and then open
another. It also hoses up printing due to font swapping, many times
dropping all spaces between words when printing. All that being said,
I still use .PDF often, many times in situations like you are looking
at. I have also used a program from Adobe that was written
specifically for the purpose of migrating hard copy docs into
electronic format, I can't remember it's name. It was pretty good,
better than OmniPage. If you want I'll reload it and do discovery.
Is your project doing the Shop manuals or parts books?
It seems like the biggest issue you may be dealing with is the
"searchability" one. To me, this seems absolutely critical for your
project.
Under your "full feature" methodology what are your thoughts about
indexing and/or searching? How would this be achieved?
What is your (how big) target audience? Mac or PC format? What is your
target machine speed? What software will users need to access this
brute, or will it be self contained?
Is this project being done for profit or will it be donated to SDC or
some chapter? This is an issue because if you might not want others to
simply take all the work you do off the CD and go do something with
it. If you need this kind of copyright protection you will have to
compile the CD into a format that will protect it. (A compiled program
runs many times faster too.)
You must also consider the long-term file compatibility issues. You
don't want to have to be redoing this thing every 2 years as
directions change. The file format of the next 5 years will be .html.
I believe that best way to approach this would be to scan it as plain
text format, then move towards .html. Html (text) format is easily
searchable and can be ported between PC/MAC platforms. It is the
lowest common denominator.
Now, you may be asking, "who the hell is this Don guy, and what makes
his opinion matter?" Well...first IT (Information Technology) is my
career. I'm self taught and I've moved from a simple engineering job
to VP of IT in 5 years in a high technology corporation. I've
designed/architeched many projects similar to your's and driven them
to fruition.
I've crossed paths with some folks in the group, sometimes I may be
perceived as arrogant because I get frustrated by folks who think they
are IT experts because they use a PC/MAC. I have a good stereo, but
I'd default to John P because it is his business. I have and use locks
everyday, but others in the group are locksmiths and have forgotten
more than I'll ever know about locks. Sorry if I've stepped on toes,
but I have considerable experience and expertise with regards to IT.
The computing landscape is littered with failed software projects, I
don't want to see your's become one of them. I am willing to help in
any way, right down to the grunt coding work. I have considerable
resources at my disposal, including literally 1000's of programs and
all kinds of hardware. If the SDC, or any SDC chapters wishes to use
me, I'm available at no charge.
In the past, my ideas on IT and the SDC have been met with scepticism.
Many said that the SDC PC owning membership is too small to support
these kinds of efforts. At first I disagreed, but I now believe they
were right. But this should not dissuade us from moving forward, all
these efforts are worthwhile and will, sooner or later, be done.
I believe that SDC is missing the boat by not having someone appointed
to information technology for the club. Some one who could map out the
future of all the information the club owns. Perhaps not actually
spending big $$$ right now, but decisions are being made each year
that effects the future of the club. (Geez, with all the concern about
bring young folks into the club you'd think that we would be
considering stuff like PC programs/internet stuff).
Let me know what you think...
don
PS On an related subject...
Does anyone know if the SDC Club owns the actual electronic files of
the previous years of the Turning Wheels? I know the TW has been done
on a MAC for quite a few years, does the SDC actually have possession
of the files? Who maintains these files for the long term? Are they
maintained in at least two geographically different locations? I have
a hunch that the club does not have these files, and that they may
have a hard time getting them....but I could be wrong.
Jeff Rice
Don,
Perhaps you should speak with the SDC people at one of their board
meetings. I am not asking you to volunteer for a project ("The" project?),
but your apparent technical knowledge (expressed very clearly) should help
the less informed make better decisions on this subject.
Jeff Rice
John Poulos
From: The Bean Counters
JT
I think the simple CD with index is the way to go. I'd like to see an
easy to use navigational system, the ability to to print pages and
graphics and a built in reader.
Please advise when you get an estimate of the costs involved in the
project.
John Poulos
My Studebaker Page, FAQ & The Studebaker Ring
at:http://members.xoom.com/Poulos/chat.htm
63 R-1 Avanti's(2)
63 R-2 Avanti
64 Avanti R-1 (The Survivor)
57 Golden Hawk
John Poulos
>
> JT,
> Hmmmmm.....
> First Omnipage generally sucks.?
Snip-Snip
>
> It seems like the biggest issue you may be dealing with is the
> "searchability" one. To me, this seems absolutely critical for your
> project.
>
> Under your "full feature" methodology what are your thoughts about
> indexing and/or searching? How would this be achieved?
I'd like at least an easy to use index.
>
> What is your (how big) target audience? Mac or PC format? What is your
> target machine speed?
PC unless a MAC version can be added with out much cost.
What software will users need to access this
> brute, or will it be self contained?
It has to be self contained.
>
> Is this project being done for profit or will it be donated to SDC or
> some chapter?
My intention when coming up with the idea was a Business venture, I was
going to pay and outside company to do the works and market the CD. I
can either pay the members for their work or do a profit spit. I put up
the capital and do the marketing and promotion and pay for the sweat
equity of the production staff.
I think depending on the cost involved a percentage to the National
Museums or to build a "super Studebaker Web site" should be looked
into.
Snip-Snip
> don
JETman
>
> JT,
> Hmmmmm.....
> First Omnipage generally sucks. I've used it since version 5 and it
> has many limitations, including not handling the pic/text combo you
> mentioned. Additionally, even handling a straight text scan used to
> throw everything into stupid frames when exporting to MS Word formats.
> I have Omnipage 9 now and it is some what better, but still has
> shortcomings.
>
> Xerox TextBridge98 is a superior product, supporting a scan directly
> to .PDF format. This is by far the easiest way to do the kind of
> scanning you are considering. (Note one shortcoming, this format/save
> setting is only available before you scan. A few weeks ago I spent
> some time scanning a 60 page document I needed to save in MS .doc
> format only to find that a co-worker had slipped into my office and
> changed the setting to .PDF format, I had to re scan the entire
> thing!).
While I did not have much time to fiddle with OmniPage, I tend to agree
that it is cumbeesome and perhaps has a lack of needed options.
We are working with G3 PowerMacs and can run any type of s/w including
the windoze stuff faster than pee cees themselves but prefer to stay
with the Macs for authoring.
>
> I am generally not a fan of .PDF format. I love most Adobe products
> but the .PDF format is a little too propriety for me. You can also
> blow up/crash the .PDF reader by printing one long doc and then open
> another. It also hoses up printing due to font swapping, many times
> dropping all spaces between words when printing. All that being said,
> I still use .PDF often, many times in situations like you are looking
> at. I have also used a program from Adobe that was written
> specifically for the purpose of migrating hard copy docs into
> electronic format, I can't remember it's name. It was pretty good,
> better than OmniPage. If you want I'll reload it and do discovery.
PDF seems to be the choice as it is pretty well universally accepted.
Even the IRS uses it. It is simple, file sizes are small, and it is
cross platform.
>
> Is your project doing the Shop manuals or parts books?
All of the above. But it is not my project, it is just a growth of a
discussion that began last weekend and in fact I think that John Poulos
is the one who instigated it.
>
> It seems like the biggest issue you may be dealing with is the
> "searchability" one. To me, this seems absolutely critical for your
> project.
>
> Under your "full feature" methodology what are your thoughts about
> indexing and/or searching? How would this be achieved?
>
Full feature is the desired goal, but the methodology is not yet set and
in fact, feasibility has not been established.
> What is your (how big) target audience? Mac or PC format? What is your
> target machine speed? What software will users need to access this
> brute, or will it be self contained?
All platforms via, (I forget the ISO standard), CD and would be totally
self contained for each CD.
>
> Is this project being done for profit or will it be donated to SDC or
> some chapter? This is an issue because if you might not want others to
> simply take all the work you do off the CD and go do something with
> it. If you need this kind of copyright protection you will have to
> compile the CD into a format that will protect it. (A compiled program
> runs many times faster too.)
I dunno on this. Personally, I am profit motivated. However, the
market for electronic Studebaker shop/parts manuals is kinda limited.
>
> You must also consider the long-term file compatibility issues. You
> don't want to have to be redoing this thing every 2 years as
> directions change. The file format of the next 5 years will be .html.
>
The above is subject to discussion as HTML would require entire
re-formatting and is too time consuming. PDF is much simpler and is
equally universal.
> I believe that best way to approach this would be to scan it as plain
> text format, then move towards .html. Html (text) format is easily
> searchable and can be ported between PC/MAC platforms. It is the
> lowest common denominator.
I agree, but time restraints play factors here.
>
> Now, you may be asking, "who the hell is this Don guy, and what makes
> his opinion matter?" Well...first IT (Information Technology) is my
> career. I'm self taught and I've moved from a simple engineering job
> to VP of IT in 5 years in a high technology corporation. I've
> designed/architeched many projects similar to your's and driven them
> to fruition.
>
> I've crossed paths with some folks in the group, sometimes I may be
> perceived as arrogant because I get frustrated by folks who think they
> are IT experts because they use a PC/MAC. I have a good stereo, but
> I'd default to John P because it is his business. I have and use locks
> everyday, but others in the group are locksmiths and have forgotten
> more than I'll ever know about locks. Sorry if I've stepped on toes,
> but I have considerable experience and expertise with regards to IT.
Geeeeeeeeeeeez, my stereo stuff dates to the late 70's and I like it
just fine. My experience is publications, (long), and all the other
stuff, brochures, newsletters, yada, yada, yada.
>
> The computing landscape is littered with failed software projects, I
> don't want to see your's become one of them. I am willing to help in
> any way, right down to the grunt coding work. I have considerable
> resources at my disposal, including literally 1000's of programs and
> all kinds of hardware. If the SDC, or any SDC chapters wishes to use
> me, I'm available at no charge.
>
> In the past, my ideas on IT and the SDC have been met with scepticism.
> Many said that the SDC PC owning membership is too small to support
> these kinds of efforts. At first I disagreed, but I now believe they
> were right. But this should not dissuade us from moving forward, all
> these efforts are worthwhile and will, sooner or later, be done.
>
Yup, resistance to change/technology is rampant in most groups such as
ours. Then again, the participants of this ng consist of less than 1%
of SDC memebership. And, the majority rules whether they are in the
know or not.
> I believe that SDC is missing the boat by not having someone appointed
> to information technology for the club. Some one who could map out the
> future of all the information the club owns. Perhaps not actually
> spending big $$$ right now, but decisions are being made each year
> that effects the future of the club. (Geez, with all the concern about
> bring young folks into the club you'd think that we would be
> considering stuff like PC programs/internet stuff).
Agreed.
>
> Let me know what you think...
>
> don
>
> PS On an related subject...
> Does anyone know if the SDC Club owns the actual electronic files of
> the previous years of the Turning Wheels? I know the TW has been done
> on a MAC for quite a few years, does the SDC actually have possession
> of the files? Who maintains these files for the long term? Are they
> maintained in at least two geographically different locations? I have
> a hunch that the club does not have these files, and that they may
> have a hard time getting them....but I could be wrong.
In my own case, I own the electronic files of my clients unless an
express agreement otherwise has been made.
JETman
More R&D on this is required. There are better answers out there and
right now my time is really limited but perhaps I can spend some more
time on it this week.
I am especially interested in some other scanning program other than
OminPage.
Once that is solved, the rest should be a cake walk.
NOSP...@hange.com.comnospam
If you go with .PDF you may have to check Adobe to see if you can
distribute the format in a compiled program or on a CD. (I've been
struggling with Unisys over a small commercial graphics program. I'd
like to include support for .GIF format and they want $10k just to
open a contract. -- and they only own the .LHZ compression format
contained in all .GIF files.)
Additionally, I know of only one way to do internal word searches in
and across many .PDF docs and its not pretty. It is also difficult to
port .PDF content to any other file format.
I think that if you are going to spend the hours it will take to scan
all this stuff you will want to keep it in as simple a format as
possible. If it is an ASCII format you could take it in almost any
direction in the future. Frankly, if every Stude Shop Manual was
sitting someway in this format, it would be worth quite a bit of $$$
to many folks. It could be made available to folks who wanted to write
software and incorporate the content into their programs. Almost
anyone can write code utilizing ASCII text embedded and encrypted into
an executable, (I would recommend C++). If quicker development or
experienced coders are not available, a RAD (rapid application
development) approach could be taken by using platforms like Visual
Basic or Delphi.
I have scanned a number of pages from a 1950 Stude Shop manual. It
took me an average of 50 seconds per page to do and there are 270
pages in it. That's about 4 hours and if we assume the same size
manuals for each postwar year that's about 80 man hours. (Note that
this figure assumes original manuals at 75 dpi). Of course, this would
represent only the actual scanning effort, time would then be required
to proof and save the results in any format chosen. (I got 99%
accuracy with the originals). Now here's the hard part......which way
to go.
1.) If you go .PDF you could then simply burn the whole thing to a CD
and there you go. I'd buy it because I have special servers set up to
search .PDF, but what would the average user do with a group of docs
with no way to search? Folks could certainly read the manual on-line,
print, and even search within a single document. (BTW, how big would
each .PDF file be? You couldn't make the whole year a single file, it
would be too huge, each section or chapter perhaps).
2.) If you go to plain ASCII format you would have a ton of additional
work to do. I estimate it would take at least 800 man hours to develop
a professional application based on this content to sell. In the end
you would have a slick, fast, searchable, and scalable application
that I think anyone who owned a postwar Stude and PC would want. Heck,
I bet it would be of value to many other auto writers/restorers/shops.
I don't mean to poo-poo .PDF too much. If the effort was made and the
entire thing was in .PDF format it would be possible to port to ASCII
in the future, it's just a hassle and a lot of work. If you do go with
.PDF then look at Adobe Capture. It is made specifically to do what
you are looking for...I've used it and it's ok.
I guess it's a question of if this effort is to get this beast back on
the road for a daily beater or if its worth a total frame-off
restoration ...
don
John Poulos
>
>
> I have scanned a number of pages from a 1950 Stude Shop manual. It
> took me an average of 50 seconds per page to do and there are 270
> pages in it. That's about 4 hours and if we assume the same size
> manuals for each postwar year that's about 80 man hours. (Note that
> this figure assumes original manuals at 75 dpi).
Snip-Snip
I can't see investing 100's of man hours in manual scanning. What
about the 17,000 page/hour scanner mentioned earlier ?
NOSP...@hange.com.comnospam
I didn't get the first posts of this thread, but 17,000 pages per
hour?
I don't think so.....lets see that's 283 pages a minute, or 4.72 pages
per second. Even if the Shop Manual was individual pages (not bound)
you would have to load the whole stack at a time.
Hmmmmm
don
John Poulos
I just saw a post in this thread about a scanner that could do that.
Maybe he'll repost the info.
--
Steve Miller
<jeta*s...@worldnet.att.net> wrote:
> Afta that title, I'm confused but this morning, my partner and I sat
> down in front of a G3 330mz and toyed with a few things.
>
SNIP
>
> I think that all this should be run past Steve Miller as he is involved
> daily in the artsy stuff. I am more into books, catalogs, and technical
> publications.
>
> What say you Steve?
>
> --
> Regards,
>
> JT, Austin, Texas - Home of the Annual Spamarama Festival
> (the kind in a can!)
> Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
>
>
> Replace the “*” with an “s“ when replying!
JT, et al
Iąve tried to digest your postings on the e-manual project this evening. In
capsule, what Iąve taken you to say is:
A. This project would be of maximum usefulness if the text were searchable.
B. OmniPage was a nice try, but canąt capture both image and text in one pass.
C. Acrobat is good for a project like this, but has flaws in printing long
docs. It is also proprietary.
D. HTML is the łlowest common denominator˛: completely searchable,
completely cross-platform.
E. This project would be easiest to complete if the pages were scanned and
left as images only.
Item A, I think, is the overriding concern for this project. With a printed
manual, having an index page is enough to guide you to the information you
need. And after youąve used the manual a few (or few dozen) times, you
begin to know where you are going. This is because you are dealing with a
physical object. You know that page on Flight-O-Matic transmissions is
about three-quarters of the way through Group III, for instance (or
wherever--I havenąt gotten to transmissions, yet. But I know C&K front
fenders are on page 47 of Group V, you betcha!).
Since you wonąt have a book to pick up and thumb, indexing will be
absolutely necessary. The indexing should at its simplest be multi-level,
just like the printed book. First level is the tabbed pages: Group I --
Identification, Specifications, etc. Second level is the indexes for the
group subsets -- Identification: 59 Lark, Standard, Custom, Regal,
whatever... Other groups will probably require a third level. This can be
accomplished just with images, but hyperlinked text would be more elegant.
The second most important concern is the last item Iąve listed above: ease
of project completion. Sure, we can scan the pages, plop the images into
some program, and generate some sort of file that can be paged through. I
not so much concerned this is not an elegant solution (and it isnąt) as
that it would be only minimally usable.
We donąt have the time, energy or resources (unless John has real deep
pockets and one Hell of an altruistic bent!) to completely recreate these
manuals page layout by layout. That would require capturing the text in
OCR, proofing it very carefully, scanning each picture, flowing text and
pictures into page layouts, proofing them again, and then cranking them
into something that is self-running and cross-platform. This applies
equally to a layout program like PageMaker or to HTML, though we can more
nearly count everyone having a browser than PageMaker...
Don, you mention TextBridge. Iąve not used it, but I do have a copy at work
and will give it a whirl. I like OmniPage, but it is not bullet proof by
any means. It will output its text as HTML (but weąd still have to build
pages); Iąm intrigued by your mention of TextBridgeąs PDF output. If that
will handle both text and image in one pass (and retain page layout as
OmniPage can almost do), we may have something!
Iąve tried Adobe Acrobat Capture, which does convert a scan into images and
recognizable text (if you hold you mouth just right, or something). Trouble
with that -- on the Mac side anyway -- is that you cannot scan directly
into the program. But I think this has the most promise of anything Iąve
looked at. I have no problem with the proprietary aspect of Acrobat. PDFs
are being touted as the next big thing in work flow management in the
graphics industry precisely because of its cross-platform nature. In fact,
PDF will be the native format for Adobeąs rumored replacement for
PageMaker.
Again, I have a small sample of the manual done in Acrobat. One page I
couldnąt get Capture to OCR, but there are some hyperlinks to the second
page, which combines searchable text and images -- both generated from the
same scan.
Iąm pretty sure Capture can be automated with scripting, so that should
speed the process, too.
If anyone wants to see the demo file (it comes in at a meg-and-a-half),
e-mail me with information as to what platform youąre using, and Iąll
compress and send you a copy.
Steve
--
Some mornings it just doesn't seem worth the trouble to chew through the
leather straps.
Steve Miller
John --
You may have been painting POR-15 without ventilation again. (g) I don't
know of any scanner --ADF or otherwise -- that could operate at this rate.
A computer could scan text files pretty fast. Perhaps that's what was
meant: searching text?
John Poulos
> >
> > I think that all this should be run past Steve Miller as he is involved
> > daily in the artsy stuff. I am more into books, catalogs, and technical
> > publications.
> >
> > What say you Steve?
> >
> > --
> > Regards,
> JT, et al
>
> I¹ve tried to digest your postings on the e-manual project this evening.
Snip-Snip
Do you think we might be trying to reinvent the wheel ? I could
approach the guy that's already doing CD manuals about doing a join
project or search the Net for a company that does this sort of thing
daily. Your thoughts ?
Steve Miller
> S
> > >
> > > I think that all this should be run past Steve Miller as he is involved
> > > daily in the artsy stuff. I am more into books, catalogs, and technical
> > > publications.
> > >
> > > What say you Steve?
> > >
> > > --
> > > Regards,
>
> > JT, et al
> >
> > I靶e tried to digest your postings on the e-manual project this evening.
> Snip-Snip
>
> Do you think we might be trying to reinvent the wheel ? I could
> approach the guy that's already doing CD manuals about doing a join
> project or search the Net for a company that does this sort of thing
> daily. Your thoughts ?
> --
> John Poulos
> My Studebaker Page, FAQ & The Studebaker Ring
> at:http://members.xoom.com/Poulos/chat.htm
> 63 R-1 Avanti's(2)
> 63 R-2 Avanti
> 64 Avanti R-1 (The Survivor)
> 57 Golden Hawk
We all would like to hear how he's doing it, I'm sure. Like Don says, to do
it up right, you'd build the thing from the groud up, coding your project
and viewer in something like C++, and spending a ton of time and bucks in
the process. I think the PDF is workable (though Don also posed some good
caveats).
Maybe this guy has found another process that makes sense. '
I'd like to be involved in the project. If I can make some bucks, so much
the better -- I know a Hawk that can use some parts! (Can you imagine how
disgusted I was to find the horn ring busted tonight?)
John Poulos
>
> In article <3658DAD9...@erols.com>, John Poulos <ava...@erols.com> wrote:
>
> > S
> > > >
> > > > daily in the artsy stuff. I am more into books, catalogs, and technical
> > > > publications.
> > > >
> > > > What say you Steve?
> > > >
> > > > --
> > > > Regards,
> >
> > >
> > > I¹ve tried to digest your postings on the e-manual project this evening.
> > Snip-Snip
> >
> > Do you think we might be trying to reinvent the wheel ? I could
> > approach the guy that's already doing CD manuals about doing a join
> > project or search the Net for a company that does this sort of thing
> > daily. Your thoughts ?
> > --
> > John Poulos
> > My Studebaker Page, FAQ & The Studebaker Ring
> > at:http://members.xoom.com/Poulos/chat.htm
> > 63 R-1 Avanti's(2)
> > 63 R-2 Avanti
> > 64 Avanti R-1 (The Survivor)
> > 57 Golden Hawk
>
> We all would like to hear how he's doing it, I'm sure. Like Don says, to do
> it up right, you'd build the thing from the groud up, coding your project
> and viewer in something like C++, and spending a ton of time and bucks in
> the process. I think the PDF is workable (though Don also posed some good
> caveats).
>
> Maybe this guy has found another process that makes sense. '
>
> I'd like to be involved in the project. If I can make some bucks, so much
> the better -- I know a Hawk that can use some parts! (Can you imagine how
> disgusted I was to find the horn ring busted tonight?)
>
>
> --
> Some mornings it just doesn't seem worth the trouble to chew through the
> leather straps.
I could buy this book and get a free CD rom on CD rom publication
here http://www.cd-info.com/ It looks like they might be a source for
info.
JETman
>
> John,
> I didn't get the first posts of this thread, but 17,000 pages per
> hour?
> I don't think so.....lets see that's 283 pages a minute, or 4.72 pages
> per second. Even if the Shop Manual was individual pages (not bound)
> you would have to load the whole stack at a time.
>
> Hmmmmm
>
> don
>
> > I can't see investing 100's of man hours in manual scanning. What
> >about the 17,000 page/hour scanner mentioned earlier ?
> >John Poulos
I don't remember that one either.
John Poulos
>
> I just got a catalog Friday in the mail, that had a scanner that ran
> 15 pages a minute, and the output was pdf, AND Adobe Capture came with
> the scanner... price, was I believe about $1,600, and this was the
> BOTTOM of the line scanner, the fast ones ran 27 pages a minute and
> better, can recheck and give make/model numbers if anyone is
> interested..
I just sent a E-mail to these guys, they scan manuals as part of their
business. They are here: http://www.scantekdesign.com/Pages/frcont.html
JETman
>
> S
> > >
> > > I think that all this should be run past Steve Miller as he is involved
> > > daily in the artsy stuff. I am more into books, catalogs, and technical
> > > publications.
> > >
> > > What say you Steve?
> > >
> > > --
> > > Regards,
>
> >
> > I1ve tried to digest your postings on the e-manual project this evening.
> Snip-Snip
>
> Do you think we might be trying to reinvent the wheel ? I could
> approach the guy that's already doing CD manuals about doing a join
> project or search the Net for a company that does this sort of thing
> daily. Your thoughts ?
> --
> John Poulos
>
The problem here is martketability. I don't think that there are
enought potential users out there to make a full featured CD viable.
The numbers just can't justify the effort.
JETman
>
> Steve Miller wrote:
> >
> > In article <3658DAD9...@erols.com>, John Poulos <ava...@erols.com> wrote:
> >
> > > S
> > > > >
> > > > > daily in the artsy stuff. I am more into books, catalogs, and technical
> > > > > publications.
> > > > >
> > > > > What say you Steve?
> > > > >
> > > > > --
> > > > > Regards,
> > >
> > > >
> > > > I1ve tried to digest your postings on the e-manual project this evening.
> > > Snip-Snip
> > >
> > > Do you think we might be trying to reinvent the wheel ? I could
> > > approach the guy that's already doing CD manuals about doing a join
> > > project or search the Net for a company that does this sort of thing
> > > daily. Your thoughts ?
> > > --
> > > John Poulos
> > > at:http://members.xoom.com/Poulos/chat.htm
> > > 63 R-1 Avanti's(2)
> > > 63 R-2 Avanti
> > > 64 Avanti R-1 (The Survivor)
> > > 57 Golden Hawk
> >
> > it up right, you'd build the thing from the groud up, coding your project
> > and viewer in something like C++, and spending a ton of time and bucks in
> > the process. I think the PDF is workable (though Don also posed some good
> > caveats).
> >
> > Maybe this guy has found another process that makes sense. '
> >
> > I'd like to be involved in the project. If I can make some bucks, so much
> > the better -- I know a Hawk that can use some parts! (Can you imagine how
> > disgusted I was to find the horn ring busted tonight?)
> >
> >
> > --
> > Some mornings it just doesn't seem worth the trouble to chew through the
> > leather straps.
>
> here http://www.cd-info.com/ It looks like they might be a source for
> info.
> --
> John Poulos
>
CD ROM is not the big problem. The problem is an efficient assemby of
the ingredients. I think that we really need to sit on this a few weeks
and try to work out the best method.
John Poulos
>
> NOSP...@hange.com.comNOSPAM wrote:
> >
> > John,
> > I didn't get the first posts of this thread, but 17,000 pages per
> > hour?
> > I don't think so.....lets see that's 283 pages a minute, or 4.72 pages
> > per second. Even if the Shop Manual was individual pages (not bound)
> > you would have to load the whole stack at a time.
> >
> > Hmmmmm
> >
> > don
> >
> > > I can't see investing 100's of man hours in manual scanning. What
> > >about the 17,000 page/hour scanner mentioned earlier ?
> > >John Poulos
>
> I don't remember that one either.
>
> Regards,
>
> JT, Austin, Texas - Home of the Annual Spamarama Festival
> (the kind in a can!)
> Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
>
> Replace the “*” with an “s“ when replying!
It might have been an E-mail, but even one for a few thousand can do
1800/hour, maybe that's what he meant.
John Poulos
>
> John Poulos wrote:
> >
> > S
> > > >
> > > > I think that all this should be run past Steve Miller as he is involved
> > > > daily in the artsy stuff. I am more into books, catalogs, and technical
> > > > publications.
> > > >
> > > > What say you Steve?
> > > >
> > > > --
> > > > Regards,
> >
> > >
> > > I1ve tried to digest your postings on the e-manual project this evening.
> > Snip-Snip
> >
> > Do you think we might be trying to reinvent the wheel ? I could
> > approach the guy that's already doing CD manuals about doing a join
> > project or search the Net for a company that does this sort of thing
> > daily. Your thoughts ?
> > --
> > John Poulos
> >
>
> enought potential users out there to make a full featured CD viable.
> The numbers just can't justify the effort.
>
> Regards,
>
> JT, Austin, Texas - Home of the Annual Spamarama Festival
> (the kind in a can!)
> Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
>
> Replace the “*” with an “s“ when replying!
If a guy is doing manuals for Desoto, you'd think we could do
Studebaker. I'm seeing OCR scanning for 30 cents per page bur don't know
how much the indexing would add. If you could get 1000 page manual
scanned and indexed for $500 and paid $400 for 100 CD's you'd end up
with a $9.00 unit cost. At a $30.00 retail you make money after 35 or
so.
I don't think selling a 100 would be a problem and any after that
would be gravy.
John Poulos
>
> John,
> I didn't get the first posts of this thread, but 17,000 pages per
> hour?
> I don't think so.....lets see that's 283 pages a minute, or 4.72 pages
> per second. Even if the Shop Manual was individual pages (not bound)
> you would have to load the whole stack at a time.
>
> Hmmmmm
>
> don
>
> > I can't see investing 100's of man hours in manual scanning. What
> >about the 17,000 page/hour scanner mentioned earlier ?
> >John Poulos
A quick Net search found scanners that do 60/minute but they talk
about batch scanners that are much faster. Even 60/minute would do a
shop manual in way faster than we'd need. Even a $1000 scanner would do
a shop manual in a day at 10 pages/minute. At least I'm learning lots of
stuff.
JETman
>
> --- Shiva --- wrote:
> >
> > I just got a catalog Friday in the mail, that had a scanner that ran
> > 15 pages a minute, and the output was pdf, AND Adobe Capture came with
> > the scanner... price, was I believe about $1,600, and this was the
> > BOTTOM of the line scanner, the fast ones ran 27 pages a minute and
> > better, can recheck and give make/model numbers if anyone is
> > interested..
>
> I just sent a E-mail to these guys, they scan manuals as part of their
> business. They are here: http://www.scantekdesign.com/Pages/frcont.html
> --
> John Poulos
>
Looks like their "quick scan" service might bear looking into.
John Poulos
> Looks like their "quick scan" service might bear looking into.
I'll pick there brains, they can do the quick scan, PDF or OCR. I have
no idea what that means but maybe we can get a manual scanned
in the format you guys want and than "play with it" before burning are
CD's.
> --
> Regards,
>
> JT, Austin, Texas - Home of the Annual Spamarama Festival
> (the kind in a can!)
> Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
>
> Replace the “*” with an “s“ when replying!
Bob Kapteyn
Reply to Don's long post.
We all do value your opinion.
That what is nice about this news group.
There are people from all different walks of live and expertise.
I had an earlier post on the same question of publihing the tech
articles on the S.D.C. web page.
What we really do need to consider as far as scanning in parts books
in how parts books are used.
My idea was to do research on the serial number breaks between
design changes and add a number to the serial number of the vehicles
such as 9G-F2 1890 and ad a number such as - 5 for the fith serial number
or body number break where substantially different parts were used.
Then scan in the Plate (exploded vieuw) and change the plate number
such as 1204-7 to the actual part number for that car between these
breaks. Some items such as fasteners do not carry a plate number and
could be added underneath the partnumber.
Once you know which car with which serial number or body number
you can access the propper plate and get the part number directly.
If you analize the parts books there is a lot of parts for right hand
drive and design changes that are not important.
I do not want to exclude right hand drive vehicles but Studebaker
never published plates for right hand drive. You had lo find the plate
number for the left hand version and find the right hand drive part.
Many Studebakers were modified with later engines or replacement engine
kits but no matter what ,it will be hard for these people in any case.
Many owners do not realise that their engines are later designs and
order parts for the old design,that do not fit.
R.Kapteyn at Joliet Studebaker, rkap...@mcs.com
JETman
>
> Snip-Snip
>
> > Looks like their "quick scan" service might bear looking into.
>
> I'll pick there brains, they can do the quick scan, PDF or OCR. I have
> no idea what that means but maybe we can get a manual scanned
> in the format you guys want and than "play with it" before burning are
> CD's.
> > --
> > Regards,
> >
> > JT, Austin, Texas - Home of the Annual Spamarama Festival
> > (the kind in a can!)
> > Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
> >
> > Replace the “*” with an “s“ when replying!
>
> --
> John Poulos
>
PDF (PortableFileDocument) was developed by Adobe Systems and has become
a universal form for cross platform document use. Almost every major
corporation utilizes this method including the U.S. Guvment. PDF can be
sorta compared to a fax where you are getting is a picture that contains
text which cannot be proccesed.
OCR (OpticalCharacterRecognition) is the ability, (via software), for
scanners to recognize scanned documents for text rather than a graphic.
PDF's can utilize OCR but not necessarilly in the same format that is
apparant in the document.
Yada, yada, yada. . .
JETman
>
> OK,,
> Fujitsu ScanPartner 600C
> scans at 15 ppm at 200 dpi, and output is pdf. $1,549.95
> fastest they listed was 27 ppm
200 dpi will probably yield poor results. In our tests Saturday, the
best results were obtained at 450 dpi for mixed pages, (text, photos,
line art), as you have to overcome the effects of moire on photos.
I have pdf files of the test pages if anyone wants a copy.
>
> Pagemaker can feed directly from a scanner and ver 6 can export as a
> pdf, so I might break a manual out and see..
I just don't see a function for PageMaker unless the long route is taken
to incorporate full search, content, and index functions.
Steve Miller
<jeta*s...@worldnet.att.net> wrote:
> John Poulos wrote:
> >
> > Steve Miller wrote:
> > >
> > > In article <3658DAD9...@erols.com>, John Poulos
<ava...@erols.com> wrote:
> > >
EDITED
>
> CD ROM is not the big problem. The problem is an efficient assemby of
> the ingredients. I think that we really need to sit on this a few weeks
> and try to work out the best method.
>
>
>
> --
> Regards,
>
> JT, Austin, Texas - Home of the Annual Spamarama Festival
> (the kind in a can!)
> Saturday, May 1, 1999 at Auditorium Shores on Town Lake!
>
>
> Replace the “*” with an “s“ when replying!
This makes sense. One thing my daddy always told me was, "The lazy man
works long and hard to find the easy way to do the job." I've always
assumed that meant thinking out the process...
BondoBill1
>line art), as you have to overcome the effects of moire on photos.
My I interject something? At least 3 times a week, we get some "art work" that
needs to be converted to art for a T-shirt. 450 dpi, is the minimum I can use,
to make art for a screen, I perfer 600/900, since I can clean it up by
auto-reduce. When we get photos, you need about 300 to get a sharp image that
can be "blown up" without losing information and definition. To print out a
useful picture, other than a line drawing you need a high resolution print, or
it will look just a bad as one of the early re-printed service manuals you can
buy. One thing I did do on the 56 Hawk during the restoration was to shoot a
stat of the plate I am working on and have a 14x17 taped to car, or on garage
wall. Unless you make the images/drawings sharp and detailed it will serve no
purpose. Most folks will not have a laptop under the car with them.. I think
the ideas you have offered are great, but maybe we could do something more
useful, and that would be to offer on CD a parts substitution data base. That
would be the ultimate. I believe that could be done with OCR, and Excel or
other spread sheet program. These are my thought you got them for free and you
know information is owth what you pay.
Bill
Bondo Billy, proud owner of the Hawk from Hell and his all girl pit crew!
http://members.aol.com/bondobill1/index.htm
See our line of Studebaker Shirts at
http://members.aol.com/bondobill1/spam.htm
http://members.aol.com/bondobill1/toypage.htm
JETman
>
> >best results were obtained at 450 dpi for mixed pages, (text, photos,
> >line art), as you have to overcome the effects of moire on photos.
>
> My I interject something? At least 3 times a week, we get some "art work" that
> needs to be converted to art for a T-shirt. 450 dpi, is the minimum I can use,
> to make art for a screen, I perfer 600/900, since I can clean it up by
> auto-reduce. When we get photos, you need about 300 to get a sharp image that
> can be "blown up" without losing information and definition. To print out a
> useful picture, other than a line drawing you need a high resolution print, or
> it will look just a bad as one of the early re-printed service manuals you can
> buy. One thing I did do on the 56 Hawk during the restoration was to shoot a
> stat of the plate I am working on and have a 14x17 taped to car, or on garage
> wall. Unless you make the images/drawings sharp and detailed it will serve no
> purpose. Most folks will not have a laptop under the car with them.. I think
> the ideas you have offered are great, but maybe we could do something more
> useful, and that would be to offer on CD a parts substitution data base. That
> would be the ultimate. I believe that could be done with OCR, and Excel or
> other spread sheet program. These are my thought you got them for free and you
> know information is owth what you pay.
>
> Bill
> Bondo Billy, proud owner of the Hawk from Hell and his all girl pit crew!
>
A few years ago, I did just the same thing, (contract), for a maker of
novelty coffee mugs. All of our output had to be 1,200 dpi in order to
generate a good screen for the finished imppressions. A rule of thumb
is that the input, (artwork), resolution must be 3x the finished product
in the silk screen process.
NOSP...@hange.com.comnospam
A couple of more thoughts.....
1.) I'm not sure that you want to go to with a formal approach to this
project, but I've seen many "let's build it and they will come"
approaches fail. When developing a commercial piece of software (or
hardware) you would generally start with a "Requirements Definition".
And just as it sounds, it usually consists of the 'users needs'. Once
defined, you can then generate a "Functional Description" document. It
expresses a complete solution to the 'needs' expressed in the
"Requirements Definition". It includes a high level overview and it
does not usually specify architecture or internal design of project
components. That is done by a "Design Document" or "Functional
Specification". The people creating the product use this document to
communicate architecture, relationships, and other design details.
Additionally, you should create a test criteria or "Acceptance Test
Plan". (Note that the criteria are independent of the design, and can
be written before the product is designed or implemented.) The purpose
of this test criteria is to determine if the work produced matches the
functionality expressed in the "Functional Description".
After these documents are in place, actual development work is then
started. Now, it may sound like too much formal work, but it prevents
common developmental maladies such as "feature creep". I actually
think these documents could be done in a day or two (once all details
are agreed upon). It's too easy stumble in other ways in this kind of
effort, it pays to do this kind of stuff up-front. (Believe me,
software is never "done"). It also makes it easy to analyze if the
project was a success or not. Again, if others are willing, so I am.
2.) This month's issue of "Imaging and Document Solutions" contain's a
good article on "The State of the Art in ICR and OCR" for those who
care. Their web site is www.imagingmagazine.com, but I haven't checked
it out, it may or may not have the article I referred to on-line.
don
Bob Kapteyn
Shiva ---) wrote:
> HEY BOB.... I sent you an email, on the zip van parts manual.. You
> gave me a price and I said YES, but I need a snail mail address to
> send money...Is your email screwy again??
Shiva. My E-Mail works but I am way behind on mailing stuff out.
Please give me your mailing address.
I got several orders from this post
R.Kapteyn