Serving html "documents' instead of PDF or Docs

[phil]

We need to "serve" multi-page documents to website visitors. Documents
are personalized for the visitor with relevant JPG photos- 1 on each
page. Visitors will print these documents and enclose in a binder.

For these to print "nicely" am I correct in assuming we would have to
first dynamically merge into a pdf document using available software,
and serve it to site visitors for downloading, or can we get away
cheaper (software-wise) by just letting them print a dynamically
generated web page. Any way to improve on screen resolution of 72dpi
(?). I assume with a pdf we could control dpi of the documents we are
serving to insure quality printouts.

Can we do similar with Word, and would that be cheaper software? Can
word control dpi in final doc, as would pdf? Thanks.

 

[Jan Harders]

We need to "serve" multi-page documents to website visitors. Documents
are personalized for the visitor with relevant JPG photos- 1 on each
page. Visitors will print these documents and enclose in a binder.

For these to print "nicely" am I correct in assuming we would have to
first dynamically merge into a pdf document using available software,
and serve it to site visitors for downloading, or can we get away
cheaper (software-wise) by just letting them print a dynamically
generated web page. Any way to improve on screen resolution of 72dpi
(?). I assume with a pdf we could control dpi of the documents we are
serving to insure quality printouts.

I guess the dpi of images in html-pages (text is printed with dpi set in the
properties of the print anyhow, since it's not grafics, but digital
information) depends on the image itself, not so much on the filetype that
includes it. Long story short: putting no design-elements in that break the
print (e.g. table that is wider than a leaf of paper is) should work with
html, too.

 

[Karl Groves]

We need to "serve" multi-page documents to website visitors. Documents
are personalized for the visitor with relevant JPG photos- 1 on each
page. Visitors will print these documents and enclose in a binder.

Can you go into more detail as to the context the visitor will be using the
website?
One of the biggest issues you're going to have to deal with is the amount of
data you're passing to the visitor.
No matter what format you use, if you're serving up a high-resolution image
(be that as part of a PDF, a jpg, or PSD), you're dealing with a lot of
data.
If this is a site on the web, you may want to rethink this idea (bear in
mind, I don't know the context).
So, perhaps with a little more detail, some ideas can be ferretted out.

-Karl

 

[rf]

We need to "serve" multi-page documents to website visitors. Documents
are personalized for the visitor with relevant JPG photos- 1 on each
page. Visitors will print these documents and enclose in a binder.

This does not really sound like the kind of application a web page is
designed for.

Example?

 

[Jeff Thies]

We need to "serve" multi-page documents to website visitors. Documents
are personalized for the visitor with relevant JPG photos- 1 on each
page. Visitors will print these documents and enclose in a binder.

For these to print "nicely" am I correct in assuming we would have to
first dynamically merge into a pdf document using available software,
and serve it to site visitors for downloading, or can we get away
cheaper (software-wise) by just letting them print a dynamically
generated web page. Any way to improve on screen resolution of 72dpi
(?). I assume with a pdf we could control dpi of the documents we are
serving to insure quality printouts.

The resolution will affect only the image. Text will always print sharp.
The same is true with PDFs.

You can try this:

Let's say you have an image that will print 2 inches wide, 144 pixels. Use a
larger image and resize it with the image width.

<img width="144" ...>

Not tested...

Jeff

 

[phil]

Karl and others:

Our requirement is that visitors log in, and a printable 8 page, 8.5 x
11 document of some type generates (either PDF, Word, or hopefully
just the printable web page so no additional software needed on
server, or downloading reqd by visitor). 8 Page document needs to
dynamically generate with a JPG photo, unique to that individual,
inserted on each page (sorry for being inexact, but "tell you but have
to kill you" type thing). There will also be some merging text into a
few spots on each of 8 pages. A basic template will be used for the 8
page document and stored on server, and the relevant, merging photo
and text will be stored in database on server & linked to the member
id.

This is a fee based service, so theoretically the bandwith usage will
grow in proportion to revenue, but any guidance on such costs would be
appreciated. I think that bandwith gets much cheaper as you get into
high volume...but I will check this. These will be "graphics-rich" 8
pages, with colorful borders, standard fonts, set at a dpi
(hopefully!) enough for home printing on typical color inkjet
printer...perhaps 125-150 dpi. I dont know typical final file
sizes...hope above helps.

At beginning perhaps we may serve out 100s of the 8 page documents
daily, eventually 1000s...

The colors and even size of printable image need be close to 8.5 x 11,
so it all fits on printed page, but need not be exact, which is why we
hope we can get away with html only, not PDF or Word. If we use PDF
files we will include target punches for 3 hole binders on left side
of page, but if html I assume different browsers will print slightly
differently in size, so we wont attempt this....but can we get it to
print to fit on 8.5 x 11 page with decent resolution?

 

[Toby A Inkster]

For these to print "nicely" am I correct in assuming we would have to
first dynamically merge into a pdf document using available software,
and serve it to site visitors for downloading, or can we get away
cheaper (software-wise) by just letting them print a dynamically
generated web page.

You could theoretically serve it as a web page -- CSS 2 allows you a great
amount of control over how a document is printed. In practice though,
Opera is the only browser that supports CSS 2 well enough.

 

[phil]

I am reposting this at the bottom of the thread - also appears above-
I didnt realize responses to prior postings get inserted midway into
thread....
______________________________________

Karl and others:

Our requirement is that visitors log in, and a printable 8 page, 8.5 x
11 document of some type generates (either PDF, Word, or hopefully
just the printable web page so no additional software needed on
server, or downloading reqd by visitor). 8 Page document needs to
dynamically generate with a JPG photo, unique to that individual,
inserted on each page (sorry for being inexact, but "tell you but have
to kill you" type thing). There will also be some merging text into a
few spots on each of 8 pages. A basic template will be used for the 8
page document and stored on server, and the relevant, merging photo
and text will be stored in database on server & linked to the member
id.

This is a fee based service, so theoretically the bandwith usage will
grow in proportion to revenue, but any guidance on such costs would be
appreciated. I think that bandwith gets much cheaper as you get into
high volume...but I will check this. These will be "graphics-rich" 8
pages, with colorful borders, standard fonts, set at a dpi
(hopefully!) enough for home printing on typical color inkjet
printer...perhaps 125-150 dpi. I dont know typical final file
sizes...hope above helps.

At beginning perhaps we may serve out 100s of the 8 page documents
daily, eventually 1000s...

The colors and even size of printable image need be close to 8.5 x 11,
so it all fits on printed page, but need not be exact, which is why we
hope we can get away with html only, not PDF or Word. If we use PDF
files we will include target punches for 3 hole binders on left side
of page, but if html I assume different browsers will print slightly
differently in size, so we wont attempt this....but can we get it to
print to fit on 8.5 x 11 page with decent resolution?

 

[rf]

I am reposting this at the bottom of the thread - also appears above-
I didnt realize responses to prior postings get inserted midway into
thread....
______________________________________

Karl and others:

<snip>

Phil.

With all due respect you seem to be out of your depth. This is probably why
you are resorting to asking us.

Your explanation of your requirements does not actually make sense, probably
because, as you say, you will have to kill me.

I think it is about time to tell your superiors to hire a professional web
designer who will advise them on them on the errors in their ways. This
professional will give you answers far faster and better than you will get
here, after all you will be paying said professional.

I would also throw in a professional programmer, a database expert, a
graphic designer and probably a greenie to complain about the paper wastage

 

[The Doormouse]

8 Page document needs to
dynamically generate with a JPG photo, unique to that individual,
inserted on each page (

Looks like you have some ASP programming ahead of you to generate web pages
from dynamic XML content.

The Doormouse

 

[Mark Parnell]

This is a fee based service, so theoretically the bandwith usage will
grow in proportion to revenue, but any guidance on such costs would be
appreciated.

I think Karl was more thinking of your visitors having to download an
8-page hi-res pdf (or whatever) - on an intranet that isn't an issue,
but on the web, many users are still on dialup. Downloading something
like that will be very slow. Heck, it will probably be slow for those on
broadband.

 

[Karl Groves]

Karl and others:

Our requirement is that visitors log in, and a printable 8 page, 8.5 x
11 document of some type generates (either PDF, Word, or hopefully
just the printable web page so no additional software needed on
server, or downloading reqd by visitor). 8 Page document needs to
dynamically generate with a JPG photo, unique to that individual,
inserted on each page (sorry for being inexact, but "tell you but have
to kill you" type thing). There will also be some merging text into a
few spots on each of 8 pages. A basic template will be used for the 8
page document and stored on server, and the relevant, merging photo
and text will be stored in database on server & linked to the member
id.

This is a fee based service, so theoretically the bandwith usage will
grow in proportion to revenue, but any guidance on such costs would be
appreciated. I think that bandwith gets much cheaper as you get into
high volume...but I will check this. These will be "graphics-rich" 8
pages, with colorful borders, standard fonts, set at a dpi
(hopefully!) enough for home printing on typical color inkjet
printer...perhaps 125-150 dpi. I dont know typical final file
sizes...hope above helps.

At beginning perhaps we may serve out 100s of the 8 page documents
daily, eventually 1000s...

The colors and even size of printable image need be close to 8.5 x 11,
so it all fits on printed page, but need not be exact, which is why we
hope we can get away with html only, not PDF or Word. If we use PDF
files we will include target punches for 3 hole binders on left side
of page, but if html I assume different browsers will print slightly
differently in size, so we wont attempt this....but can we get it to
print to fit on 8.5 x 11 page with decent resolution?

Apologies to the group for keeping all of the original text. I didn't want
it to get lost and felt it all worthwhile to keep.

Your #1 problem here is the fact that you're trying to send people what will
undoubtedly be a very *large* file. While PDF is a great format for text, a
300dpi photo is a 300dpi photo whether it is embedded into a PDF or served
up by itself. The end result is a massive file that will be more burden to
your users than benefit them.

Usability studies show that people have about a 10-12 second threshold
before they'll get sick of waiting for a page to load. They'll typically
wait longer (into the 30second+ range) if they have a vested interest in the
information, such as home banking information. Chances are, if your users
have paid to access the site, then they will wait longer than most.

If you absolutely must have such a large file then you need to ensure two
things: 1) that you warn them about the file size ahead of time. Don't just
say "Filename.pdf, 8pages", give them a file size. It'd be even better if
you gave them a typical download time 2) That you give them some sort of
"status indicator". The little blue bar at the bottom of their browser
window is not enough. One of the most important things in ensuring
ease-of-use is to display system status for the user so that they know what
is going on.

-Karl

 

[phil]

Thanks Karl and everyone- great info.

 

[derek giroulle]

sorry less indulgent (snip)
Your #1 problem here is the fact that you're trying to send people what will
undoubtedly be a very *large* file. While PDF is a great format for text, a
300dpi photo (snip) result is a massive file
2 things: 1) that you warn them about the file size ahead of time. give them a file size.

2) That you give them some sort of "status indicator".totally agree with Karls observations

suggestions
1- provide the user with a request form that terminates with a window
(target _blank) which states request for ......(details)... submitted
and processing just continue browsing in your browser..
leave this window open and return the user to his original browser to
continue his searches

1a- the request processes server-side and the server creates a PDF
document ( I think you want your document such that it cannot be
modified afterwards by the receiver --- think this issue thouroughly
through - a document you send can be construed as a binding contract in
most countries and indicate that you offer something on paper that is
not available in reality ... a issue akin to that situation)
1b- the document is send as an automated ftp download when ready like
CNET does when terminated sending the file the screen is closed
1c- if the document cannot be send that way it is mailed to the customer

2- provide the user with a request form that terminates with a window
(target _blank) which states request for ......(details)... submitted
the resulting document will be mailed to you
this allows for more confidentiality : anyone can submit the request but
the data will be delivered to the preconfigured email address
so if someone receives document he didn;t request he has a problem of
unauthorised access
2b- a user that pays for the service can provide a number of uids and
linked mailboxes to grant his staff have access to the service or can
decide he wants a number of uids on one mailbox such that he can check
on the use of the service... etc

Moreover if you - as i assume from experience - are working with CV's or
profiles of people you outsource, then you should consider privacy
issues here, and suerly then I would advise against direct download but
prefer the controlled sending via email and the use of PDF documents

I would make the website so that the http server submits the request as
an instruction to an application server ( running a merging tool) which
requests his data from the database server
The merging tool the produces a document that is then fed to Acrobat n
order to produce a pdf document
so rather then thinking in terms of templates (like word would) I would
use units of preformatted text that can be selected according to a
skeleton-template.

I've helped make this happen using powerbuilder, access, Sybase-server,
word, and Acrobat / for smaller (1 page) and bigger documents (12-20 pages)
the average waiting time for a document of 12 pages for data to be
collected , collated, to be produced and send to a print_Q, printed and
then signed was at the start of the project 4-8 minutes 20 pages could
take up to 15 mins
after 2.5 years of experimenting we had it down to over 2 and 6 mins
Those were acceptable and workable times at a bank public office desk (
not the cashiers counter) remember that issue when you take on this project

and respect all the principles (database standardisation, OO) and use
the products with the least of overhead

I know I shouldn't make assumptions ...