topr8
msg:4239741 | 4:23 pm on Dec 7, 2010 (gmt 0) |
i think it's one of those things where just because it's done before and because everyone else does it, then it must be right.
it's ludicrous that in this age of permanent internet connections - and even being able to get webpages on a phone! datasheets should be 'live' on a website, (printer friendly of course) ... as they can be updated in realtime for all instantly.
|
engine
msg:4239743 | 4:36 pm on Dec 7, 2010 (gmt 0) |
Are they neccessary? No. Are they helpful? Yes.
Obviously, it allows full control over the page layout, images and fonts, and for some content, that's very useful.
In addition, some documents are created in a word processor or graphics package, which has package-specific file types, and these are not necessarily share-friendly, whearas a PDF is likely to be more compatible. HTML just doesn't give you that 'control' or that 'flexibility.'
|
jimbeetle
msg:4239749 | 4:42 pm on Dec 7, 2010 (gmt 0) |
Is the info in the datasheets also on the html pages? If so, you might consider an on-the-fly pdf converter for folks who want pdf copies.
|
Mark_A
msg:4239756 | 4:57 pm on Dec 7, 2010 (gmt 0) |
Hi all,
Yes the stuff in the pdfs is largely in the html also .. in most cases..
It is just a bit of a mess with pdfs made in different times with different software, most of which are not to our todays agreed standards and a pile of work to get them into any reasonable form.
I just wonder if there is a better way - a wholly cleverer solution to the problem of data-sheet presentation.
|
piatkow
msg:4239790 | 6:18 pm on Dec 7, 2010 (gmt 0) |
Half the problem is conceptual, stop thinking of the PDF as a source document, it isn't, it is just a display format, only one designed for paper rather than a screen.
I publish the same information in print - which goes to the printer in PDF format, and on the web. No problem, one database, two queries for the different formatting requirements.
|
Feydakin
msg:4240083 | 1:44 pm on Dec 8, 2010 (gmt 0) |
We use TCPDF to generate all of our PDFs on the fly as needed.. This way, as was said above, we store the data in a table and then spit it out as needed either to a php/html file or to a pdf..
|
Mark_A
msg:4240090 | 1:54 pm on Dec 8, 2010 (gmt 0) |
| store the data in a table and then spit it out as needed either to a php/html file or to a pdf.. |
|
Yes, that seems to be a valid idea.
But I have quite a variety of products to deal with, there is no common file or dbase structure that I can yet think of which would be adequate to describe them all.
|
Mark_A
msg:4240910 | 10:04 am on Dec 10, 2010 (gmt 0) |
Well, because they can be emailed, downloaded and easily printed we think we have to stay with having a pdf datasheet.
But there may be a difference between the html page and the pdf. The html page can be the sales blurb and the pdf a technical datasheet.
But, who then is responsible for producing, updating and maintaining the pdfs. It seems to me that it would have to be engineering, rather than the web department!
|
piatkow
msg:4240916 | 10:21 am on Dec 10, 2010 (gmt 0) |
But, who then is responsible for producing, updating and maintaining the pdfs. It seems to me that it would have to be engineering, rather than the web department!
|
|
The datasheet is something that you might want in your hand when working (depending on the product) so a print format is probably a good idea. A common database structure for technical info on a disparate product set is a separate issue and again not a web one. There are ways around this but it takes you into some fairly obscure areas of data modelling. If you have some skilled entity relationship modellers in the company then drop the problem on them.
|
|
