Serving html "documents' instead of PDF or Docs

Discussion in 'HTML' started by phil, Jun 26, 2004.

  1. phil

    phil Guest

    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.
    phil, Jun 26, 2004
    #1
    1. Advertising

  2. phil

    Jan Harders Guest

    phil <> typed:
    > 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.
    Jan Harders, Jun 26, 2004
    #2
    1. Advertising

  3. phil

    Karl Groves Guest

    "phil" <> wrote in message
    news:...
    > 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
    Karl Groves, Jun 26, 2004
    #3
  4. phil

    rf Guest

    "phil" <> wrote in message
    news:...
    > 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?

    --
    Cheers
    Richard.
    rf, Jun 26, 2004
    #4
  5. phil

    Jeff Thies Guest

    "phil" <> wrote in message
    news:...
    > 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

    >
    > Can we do similar with Word, and would that be cheaper software? Can
    > word control dpi in final doc, as would pdf? Thanks.
    Jeff Thies, Jun 26, 2004
    #5
  6. phil

    phil Guest

    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?
    phil, Jun 26, 2004
    #6
  7. phil wrote:

    > 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.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me - http://www.goddamn.co.uk/tobyink/?page=132
    Toby A Inkster, Jun 26, 2004
    #7
  8. phil

    phil Guest

    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?
    phil, Jun 27, 2004
    #8
  9. phil

    rf Guest

    "phil" <> wrote in message
    news:...
    > 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
    :)

    --
    Cheers
    Richard.
    rf, Jun 27, 2004
    #9
  10. (phil) wrote:

    > 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

    --
    The Doormouse cannot be reached by e-mail without her permission.
    The Doormouse, Jun 27, 2004
    #10
  11. phil

    Mark Parnell Guest

    On 26 Jun 2004 13:32:20 -0700, phil <> declared
    in alt.html:

    > 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.

    --
    Mark Parnell
    http://www.clarkecomputers.com.au
    "Never drink rum&coke whilst reading usenet" - rf 2004
    Mark Parnell, Jun 28, 2004
    #11
  12. phil

    Karl Groves Guest

    "phil" <> wrote in message
    news:...
    > 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
    Karl Groves, Jun 28, 2004
    #12
  13. phil

    phil Guest

    Thanks Karl and everyone- great info.
    phil, Jun 29, 2004
    #13
  14. Karl Groves wrote:
    > "phil" <> wrote in message


    >>Our requirement is that visitors log in, and a printable 8 page, 8.5 x
    >>11 document of some type generates (either PDF)
    >>dynamically generate with a JPG photo,

    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 ...
    derek giroulle, Jun 29, 2004
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Molochnikov
    Replies:
    11
    Views:
    2,681
    Mohun Biswas
    May 4, 2004
  2. KYG
    Replies:
    2
    Views:
    872
    Ian Collins
    Aug 18, 2008
  3. AAaron123
    Replies:
    1
    Views:
    987
    Alexey Smirnov
    Nov 17, 2009
  4. -Lost
    Replies:
    7
    Views:
    164
    Randy Webb
    Jun 20, 2007
Loading...

Share This Page