file too big to print?

[Harry Radaza]

laid out a picture on 18x24 size for a memorial plaque on marble. processed it on photograv. 500dpi. file size came out to 40mb. printed it. my laserpro mercury 25watts errored. tur ned out da onboard memory is only 16mb.

i dont want to print at lower dpi. i might lose resolution. can i print tnis in tiles? is there a feature in corel10? and if so iwould have to print this in tiles with no gaps in between them. if printed un tiles i might be abe to devide it up to fit the onboar memory of 16mb.

or is there another solution?

[Lee DeRaud]

Is your other machine a ULS? If it can handle a piece that size, some of their drivers send the job in chunks rather than a full download (or at least mine does).

[Lee DeRaud]

Hmm...(18x24x500x500)/8 is only about 13.5MB for the actual monochrome bitmap. Where's the rest of that 40MB coming from?

You might also want to try a test at 250dpi...I'm not sure you'd notice the difference on marble, and it would reduce the size by a factor of 4.

[Jerry Allen]

Harry,
Lee is right. The file should be much smaller. ~13MB. So it looks like it being stored a grayscale, not black and white.
Nevertheless, If it fits in a proper Mercury format, 25.0 x 18.031" with the origin in the lower left, it should still print. I'm guessing that either your format is not right or one edge is touching the border which will make it get a clip error.
Set your format from the Layout menu/Page Setup in Draw and use the Set from Printer button (save the format as "Mercury"). Then zoom in and make sure no part of the bitmap is touching the page border. (i.e., reduce the bitmap to 24x17.95 and center it on the page)
The the bitmap can be 250 dpi and still print it out at 500 dpi, and although I do not think the file size is the issue, it probably wouldn't hurt because it would speed up the output.

[Kevin Huffman]

Hello Harry,

Yes a file that comes out at 40 mb will cause the machine to error out. The machine has a 16mb buffer built onto it, it is upgradeable to 64mb if needed. You can contact your sales department about getting it if you plan on doing more jobs that require more than 16mb's of space.

You can save the file as what ever dpi you want, you just want the dpi setting in the driver to the same as you set it in photograv software. If not it will not come out right.

The DPI setting in the driver isn't going to any effect on the size of the file. The DPI setting in the driver should read LPI (Lines Per Inch). The beam diameter is deteremined by your lens, not by the DPI setting in your software. When you change the DPI setting in your driver you are just determining how many lines/pass's it needs to create your image. The less the lines longer it will fire to create that spot. The more the lines, the less it will fire and the more detailed you can get.

One thing that you want to make sure you aren't doing is putting the driver mode into 3D mode. When you put the driver into 3D mode it re RIP's (Raster Image Process) it. The file size is going to be 3 to 4 times larger than the original (Hense the 13mbx3=39mb, or 13mbx4=52mb). Your 40mb is right inbetween there. Make sure you are on black and white mode inside the driver, not 3D.

Jerry, your 0,0 needs to be in the upper left hand corner, not the bottom left hand corner. The page size should mimic your table for exact placement. Don't click and drag the rulers to set the 0,0, it will be off. Click Layout, Page Setup. Select Rulers on the left, horizonal should be 0 and vertical should be 18.0.

[Jerry Allen]

Yeah, Kevin, slip of the thumb. Upper left. (Draw pages default to lower left.)

I was under the impression that the file could be spooled from Draw. Guess I've never had a file that big.
However, Harry states that he processed in Photograv, and therefore should have a file that is approx. 13MB which should work even at 500 DPI in a 1 bit (black and white) file. It has also been my experience that 250DPI should work okay even if using 500DPI in the driver. I have done it both at 250DPI, 250DPI in the driver and 250DPI file, 500DPI in the driver with successful output to marble. At 24x18" 250/250 should be fine. If the file was black and white at 250DPI it should only be around 3.2MB.

[Harry Radaza]

Guys,

checked the ORIGINAL File and found that my artist had copies of the same big picture way outside the paper which made it 40mb. when I deleted those and stuck with the only file to be printed, it was 2mb. So it seemed the mercury didn't accept the file in the first place because the onboard memory is only 16mb.

now that we cut it down to 2mb, something weird happened. the file saved is only 2mb in my doc properties. however, when printed from corel, the printer spool stats the file size is 20mb and sometimes 250mb. really unusual. then the next time the problem just went away.

And secondly, the graph clipped error. we are 100% sure that the file to be printed is INSIDE the paper. way inside. and the ruler margins on x and y axis are right. 0's on upper left. and still graph clipped.


As for processing, we used 250 in adobe, 250 in photograv and 250 in print driver. isn't mercury defaulted to 300 ? does it make a big difference ?

Anyway, we really had lot's of weird stuff happening to this one particular file. it's supposed to be a memorial plaque (18x24") for this young lady that was a landslide victim and passed away months ago. Everyone in the shop was joking around that maybe it was her that didn't want to get the job done... And the more we tried to print the file, the more wierd stuff coming up. We decreased the DPI to 100 and the file size increased to 300mb. We increased the dpi to 500 and the file size decreased to 100mb. etc... suddenly the jokes didn't seem so funny anymore.

[Mike Hood]

Can you start fresh with a new workspace and just copy & paste only the portion of the graphic you're printing into the new drawing?

Might get you to a clean copy at least. Sounds like the original artist has some bad habits.

[Kevin Huffman]

Hello Harry,

I know that there had to be something different going on. I am glad to see that you got it working.

As far as the copy/paste item, I actually have a rule against that. Actually my golden rule is never to copy/paste anything. When you copy something from one program and paste it in another. It leaves the first program and enters Microsofts world then it goes from Microsofts (MS) world and goes into the other program. Bill Gates and his teams know everything about OS's but as far as graphics programs................. It is less than desireable. Go look up Acrylic Beta, it is their atempt at a raster/vector program that was suppose to rival Photoshop and Corel Draw.
Copy and paste is only ok when doing it from MS word to MS Excel, or any of the other Microsoft products.

As far as the graphic was clipped is concerned your image isn't inside the entire area. If the image is 18.0 inches tall then both of the edges of the picture are going to be on the edge of the paper. The edge of the paper can be considered out of bounds. Try making the image 17.998 high. Move it down 0.001 inch away from the top.

The default for all GCC machines is 500 DPI.

If you would like, you can email me the file you are working with and maybe I can see what is going on. My email address is Kevin.Huffman@signwarehouse.com. You can send me the original, the processed version, maybe I can spot something we are missing.

Let me know,

[Lee DeRaud]

As far as the copy/paste item, I actually have a rule against that. Actually my golden rule is never to copy/paste anything. When you copy something from one program and paste it in another. It leaves the first program and enters Microsofts world then it goes from Microsofts (MS) world and goes into the other program. Bill Gates and his teams know everything about OS's but as far as graphics programs................. It is less than desireable.
Copy and paste is only ok when doing it from MS word to MS Excel, or any of the other Microsoft products.I realize that Windows-bashing and Gates-bashing are popular and fashionable activities, but I feel I should point out that the format and content of data going to/from the clipboard is not altered by Windows: that is strictly the responsibility of the receiving application.

Not to mention that what was suggested in this case was a cut from one Corel drawing and a paste into a different (empty) Corel drawing.

[Joe Pelonio]

I realize that Windows-bashing and Gates-bashing are popular and fashionable activities, but I feel I should point out that the format and content of data going to/from the clipboard is not altered by Windows: that is strictly the responsibility of the receiving application.

Not to mention that what was suggested in this case was a cut from one Corel drawing and a paste into a different (empty) Corel drawing.

My experience has been that Lee is right, I copy and paste from Corel to
various MS products all the time with no problem. Having done some laser jobs for that company, they do have people with real graphics programs that can provide perfectly good vector files. One person told me she used
a MS program called Visio, which can produce vector files in formats that Corel can import.

[Kevin Huffman]

I am not Gates Bashing or Microsoft bashing, I am sorry if it came off that way. I just use that as one of my rules when working in any graphics program. I have had some of the weirdest things happen to me when I copy/pasted, as soon as I exported/imported all the issues went away.
I guess that is just the tech talking, I see the weirdest cases of all my customers and import/exporting fixed almost every one of them.

[Dave Jones]

If you are copying and pasting completely different formats of data, then problems can happen (ie: copying a vector graphic and pasting into a spreadsheet). Some programs can even handle those odd combinations. Even copying what we all think of as the same data (ie: vectors) from one program to another can sometimes be a problem if the two programs deal with the data objects very differently (ie: 3D vectors in AutoCAD into some 2D vector programs)

But since what was suggested was just from one drawing to another within the same program, there would be no conflicts.