4 Replies Latest reply on Jun 1, 2015 10:13 AM by dmb_fmp

    FMS 14 WebDirect PDF Resolution Issue in Static-Content Container

    dmb_fmp

      My containers optimized for static content are displaying PDFs as having very poor resolution in FMS 14 WebDirect.

       

      This was not an issue with FMS 13 WebDirect, and it remains a non-issue when viewing the containers remotely via either FMP 13 or FMGo 14.

       

      Has anyone had a similar experience or have a suggestion on how to resolve this issue?

        • 1. Re: FMS 14 WebDirect PDF Resolution Issue in Static-Content Container
          dmb_fmp

          I have not resolved this problem. Any insight would be appreciated.

           

          What I think is happening is that my containers optimized for static content are, in WebDirect, displaying either the low resolution ".jpg" or ".png" thumbnails generated by FM for each stored PDF.

           

          Things I've Tried:

          1. DIDN'T WORK: I have attempted to turn off the "generate thumbnail" option, hoping my above thinking was correct & that this would leave only the PDFs left for the containers to display. But for PDFs, the thumbnails still seem to be generated regardless of whether the "generate thumbnail" box is checked or not.
          2. DIDN'T WORK: I have tried simply deleting the FM generated ".jpg" and ".png" files - but then the respective containers display the "missing" message rather than the PDFs.
          3. WORKED: Original JPG, JP2, & TIFF files seem to work perfectly - no visible loss of resolution in WebDirect, and the PDF to JPG conversion I tried yielded files similar in size to my original PDFs. Accordingly, I have tried converting my PDFs (each a single page) into JPG files, and this works. I may end up using this as a workaround (however, I'm in no rush to do it this way for several reasons, such as:
            1. time consuming;
            2. limited storage on server;
            3. I'd still need to keep the PDFs on the server for end users to download (unless there's a way to have FMS export stored JPGs as PDFs...which as I'm typing this seems like it would make this workaround superior to any other method I've tried considering the specific issues I've encountered).

           

          Some Things I'm Wondering (all of which is based on my theory that WebDirect is displaying FM generated thumbnails):

          • Can I force WebDirect containers optimized for static content to show the original PDFs?
          • Can I generate my own ".jpg" thumbnails instead of having FM generate them for me & my PDFs?
            • If so, can I then force WebDirect containers to display my own thumbnails, specifically the ".jpg" ones?
          • Can I prevent FM from generating thumbnails for PDFs, so that the only thing left for WebDirect to display are the original full-resolution PDFs?

           

          Again, any help with this would be very much appreciated. If there is any additional info I can give that may provide some insight, please do not hesitate to let me know.

          • 2. Re: FMS 14 WebDirect PDF Resolution Issue in Static-Content Container
            mardikennedy

            Just floating untested possibilities here - haven't been using pdfs on FMS 14.

            1.  Some people have experienced pdf 'annoyances' if the client machine also has Acrobat installed.  Various threads on that.  Apparently it can 'mess with' the FMP controls.

            2. Saving own .jpg 'thumbnails' - this might be a silly idea, depends on your req's.  If they're one-pagers and if you're on a Mac, import them into Photo/ iPhoto.  You can do lots in a single import.  Then bulk export, selecting the .jpg/ ?high res/ ?medium file size, with the same file name.  You'd still need to add them to your db which might be a bit tedious, but scriptable if there are lots.

            • 3. Re: FMS 14 WebDirect PDF Resolution Issue in Static-Content Container
              dmb_fmp

              mardikennedy wrote:

               

              Just floating untested possibilities here - haven't been using pdfs on FMS 14.

              1.  Some people have experienced pdf 'annoyances' if the client machine also has Acrobat installed.  Various threads on that.  Apparently it can 'mess with' the FMP controls.

               

              Thank you - good idea to look into this, & please know it was actually the first thing I looked into prior to my original post, as I have experience with at least some of these 'annoyances' & the corresponding threads. Unfortunately, the issue at hand occurs regardless of whether the client machine is running Adobe or not.

               

              mardikennedy wrote:

               

              2. Saving own .jpg 'thumbnails' - this might be a silly idea, depends on your req's.  If they're one-pagers and if you're on a Mac, import them into Photo/ iPhoto.  You can do lots in a single import.  Then bulk export, selecting the .jpg/ ?high res/ ?medium file size, with the same file name.

              Yes, perhaps it is silly, especially if my own thumbnails would not be accepted by FM as replacements for FM generated ones. And perhaps "thumbnails" is a misnomer here for what I intended: I intended to make full-size ".jpg" files that took the place of the FM generated thumbnails, so that if my hypothesis is correct (that WebDirect is displaying FM generated ".jpg" thumbnails in static-content containers instead of my original PDFs) then by creating my own full-size ".jpg thumbnail" images for WebDirect to display, I could at least get WebDirect to displaying an image with high enough resolution to meet my needs. In retrospect, I should have clarified my intent.

               

              In any event, using Photo/ iPhoto would work, however what I've been doing is using a simple Automator Workflow to Change Type of Images from PDF to JPEG, which has worked well enough for me to keep doing it this way. The main benefit of using Automator for my purposes is I am able to do it all very easily on external storage devices (& without the added steps of first importing them into an additional program, and subsequent deleting them afterwards). Another thing I left out is that I am working with about 250,000 single-page PDFs scanned gray-scale at 400 dpi, which yields a file size of about 1 MB each.

              mardikennedy wrote:

               

              You'd still need to add them to your db which might be a bit tedious, but scriptable if there are lots.

              I'm happy to say this will be minimally tedious in the event I cannot find an alternate solution. Each PDF has a unique filename, and so I am able to simply

              1. create a new field like JPG_filename
              2. fill it's contents with a calculation like Substitute (GetContainerAttribute (PDF_container; "filename") ; ".pdf" ; ".jpg" )
              3. and then import a folder filled with my new JPGs by matching the filenames of the JPGs to JPG_filename.
              • 4. Re: FMS 14 WebDirect PDF Resolution Issue in Static-Content Container
                dmb_fmp

                Just for some relative closure to this for now, what I ended up doing was converting all of my 400 dpi PDFs into 150 ppi JPGs. This solved the problem I had with displaying static-content container images with desirable resolution via WebDirect 14. It also had the added benefit of reducing my total DB file size by more than 50% (from ~320GB down to ~140GB) because (1) FM does not generate its own JPG and PNG thumbnails for my new JPGs; & (2) each new JPG is a slightly smaller file size than its original PDF.


                However, this workaround creates a new problem: I still need for users to be able to download/export the JPGs as PDFs via WebDirect 14. And I don't have room on my server right now to hold all of the new JPGs, along with the original PDFs (and the FM generated JPG & PNG thumbnails I can't figure out how to turn off. seeRe: Disable Thumbnail Generation).


                Accordingly, I'm leaving this thread categorized as unanswered for the time being.