Results 1 to 10 of 10
  1. #1
    zBret is offline Member
    Join Date
    Feb 2008
    Posts
    43

    Default ripping/saving issues?? anydea why??

    Anyone have any Idea what may be causing this to happen, see attached, Image (Cover_bluewhoops.jpg)

    Also see attached (imaged ripped to epson.jpg) for proofing.

    We are using CS5.5 Indesign to print, PC platform, This seems to happen about once a month or so when printing a ps. to a pdf, and when printing the Indesign document direct to an Epson 9900.

    Here is an another instance it happens, job was design, proofed and approved with minor corrections, reopen the photoshop file and this is what it looks like. didn't look like that when the file was saved.

    Pulled the image from the tape archived and it looks fine.
    Let me know if you need more info.
    Thanks
    Attached Images Attached Images

  2. #2
    DCurry is offline Senior Member
    Join Date
    Aug 2007
    Posts
    255

    Default

    I've seen things like that occur when saving a file over a network. If there is a hiccup in the communication between your workstation and the server, the data doesn't get written properly.

    I typically save locally, then copy to the server. Takes a bit longer, but it seems safer.
    Dan Curry
    Looking for prepress work in the Baltimore area. FusionPro, Apogee, & Prinergy.

  3. #3
    MacTwidget is offline Member
    Join Date
    Sep 2007
    Location
    Carlsbad, CA
    Posts
    81

    Default

    I've also seen while a file is being written to a hot folder and the hot folder script is attempting to simultaneously move or process the file.

  4. #4
    akalaray's Avatar
    akalaray is offline Member
    Join Date
    Aug 2007
    Posts
    66

    Default Ripping Files

    We have this same exact problem. Also corruption lines. We think it's a sever issue. We are going to rebuild the server. We have a 10 disk 10 terbybte drive. I will post the results

  5. #5
    erdly is offline Junior Member
    Join Date
    Nov 2008
    Posts
    2

    Default

    ditto on DCurry's assessment

  6. #6
    zBret is offline Member
    Join Date
    Feb 2008
    Posts
    43

    Default

    Quote Originally Posted by akalaray View Post
    We have this same exact problem. Also corruption lines. We think it's a sever issue. We are going to rebuild the server. We have a 10 disk 10 terbybte drive. I will post the results
    Hi akalaray
    Just checking, Any luck on the server rebuild? I'm still having the same issues.
    Had 2 yesterday right before noon, See attached files
    Attached Images Attached Images
    Attached Files Attached Files

  7. #7
    curveto is offline Member
    Join Date
    Mar 2011
    Location
    Scottsdale, AZ
    Posts
    46

    Default

    Quote Originally Posted by zBret View Post
    Hi akalaray
    Just checking, Any luck on the server rebuild? I'm still having the same issues.
    Had 2 yesterday right before noon, See attached files
    I looked at your file (in a HEX editor) and it left me with some thoughts (some questions, other thoughts)...

    1) Did someone retouch the lower right corner at some point? (i.e., the blue error at the lower, right / sweater+elbow). The "image" within the PDF isn't simply one entity (which it would be if it were actually a single stream). If it was retouched you might verify your practices / network at *that* level of the (greater) process.

    2) Please disable Flate coding Distiller/PDF Optimization (for a while) for files like this (makes manually reading files like this difficult). You might also want to upgrade from Distiller 7. I'll have to deflate the data in order to actually determine what form the image stream(s) is(are) and from that one can determine if a resilient data type was employed (i.e., one that maintains integrity from start to end of the data set).

    3) There's an all too common "programming" error to copy a file when a move is more correct. Ignoring (for the moment) that end users don't generally see the difference (or know/have access to know) a move operation (and delete) simply changes a file system whereas a copy operation physically copies bytes from A to B. I say this because (aside from being WAY faster) a move will typically fail (rapidly) if multiple parties are accessing the file. It will certainly fail if a file is open for write (but has not been properly locked). Moves aren't appropriate when spanning file systems, however. You may also add a verification step to any copy operation (e.g., MD5 hash A and B and if the hashes don't match the copy operation failed regardless of what your "program" indicates).

  8. #8
    Stephen Marsh is offline Senior Member
    Join Date
    Apr 2009
    Location
    Sydney, Australia
    Posts
    580

    Default

    I agree with DCurry's post #2 and others saying the same. Don't open/save over the network direct. Save locally then move the files back. See links below for previous discussions.

    Snow leopard file serving issue

    Corruption in workflow


    Hope this helps,

    Stephen Marsh
    Last edited by Stephen Marsh; 11-23-2011 at 02:45 PM.

  9. #9
    Lukas Engqvist's Avatar
    Lukas Engqvist is offline Senior Member
    Join Date
    Jul 2008
    Location
    Sweden
    Posts
    1,601

    Default

    Yes I seen it too, Adobe officially say that they don't support saving over network.

  10. #10
    zBret is offline Member
    Join Date
    Feb 2008
    Posts
    43

    Default

    Thanks for all the info, Been saving over the network for 20 plus years and never seen this issue, We will save locally and keep you posted on the results.
    Happy Thanksgiving
    zBret


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Sponsors

Esko Sponsored Content