WTF Text

zacgil · March 23, 2015, 02:31:00 PM

For some reason the text is getting all jumbled up when I output to plate. Everything looks fine on my VPS Proofs as well as the PDF. But turns to shit when I output. I've been able to fix this by flattening the image in Photoshop and then (re)refining through Prinergy.

Background info - The stroke has been expanded/converted to outlines. But, the rest of the text is set up as such(text). We are running Prinergy 5.1.

So there's a couple of questions:

A: Is this something I should be able to identify before it goes to plate?
a: Is this issue on our side of things or can I put it back on the client?

B: Why???

I remember something like this being discussed before, I just wasn't exactly sure where to find it.
(image - The sig on the left is the press product and the sig on the right is the proof... )

Ear · March 23, 2015, 02:36:21 PM

That is the problem of non-rendered proofs.

Are you able to view it in rendered mode, prior to plate output?

Joe · March 23, 2015, 02:40:15 PM

Run your VPS at the same resolution as your plate files and my guess it will come out the same as the plates. I've seen it happen before with some cheapo freeware fonts.

zacgil · March 23, 2015, 02:42:51 PM

Quote from: Ear on March 23, 2015, 02:36:21 PMThat is the problem of non-rendered proofs.

Are you able to view it in rendered mode, prior to plate output?

Not the rendered file that is going to the plate, no. We are only looking at the VPS proofs...

David · March 23, 2015, 02:45:41 PM

I've seen that, it's a font that is not embedded correctly. And like Joe said, it's probably a weird font anyways.
Try to fully embed the font and see if that works.

Ear · March 23, 2015, 02:49:49 PM

Quote from: zacgil on March 23, 2015, 02:42:51 PM
Quote from: Ear on March 23, 2015, 02:36:21 PMThat is the problem of non-rendered proofs.

Are you able to view it in rendered mode, prior to plate output?
Not the rendered file that is going to the plate, no. We are only looking at the VPS proofs...

Bummer. In XMF, there is an option to view the screened, fully rendered imposition. It's super handy.

zacgil · March 23, 2015, 03:03:34 PM

Ear - Yeah, it also makes it hard to test out different work-arounds, as I can't check it unless I plate it.

Joe - It worked! I guess we'll just need to use full res from now on to identify the issue.

Is there a way to fix this in Pitstop??

abc · March 23, 2015, 03:09:45 PM

Can you ping me the PDF please?

andrewb@enfocus.com

we'll take a look if you want

Joe · March 23, 2015, 03:24:43 PM

Quote from: Ear on March 23, 2015, 02:49:49 PM
Quote from: zacgil on March 23, 2015, 02:42:51 PM
Quote from: Ear on March 23, 2015, 02:36:21 PMThat is the problem of non-rendered proofs.

Are you able to view it in rendered mode, prior to plate output?
Not the rendered file that is going to the plate, no. We are only looking at the VPS proofs...
Bummer. In XMF, there is an option to view the screened, fully rendered imposition. It's super handy.

The VPS is a fully rendered screened imposition but most people don't want to output/view that proof at 2400 dpi. We do ours at 600 dpi because they process quicker and display quicker. 99.9% of the time they are accurate to the plate file. It's that .1% of the time it can bite you in the ass.

Ear · March 23, 2015, 03:39:25 PM

Right. In XMF, we too can output a .jar file, for virtual proof, where we dictate the res and such. What I'm saying is that the operator, in Imposition Mode, can switch to Rendered view and see the plates exactly as they will run, in composite or toggle seps... it shows the exact dots and placement, as they will image on the plate. I cannot share it with clients but it is a super handy tool for seeing a plate before it burns.

Joe · March 23, 2015, 03:53:03 PM

Quote from: Ear on March 23, 2015, 03:39:25 PMRight. In XMF, we too can output a .jar file, for virtual proof, where we dictate the res and such. What I'm saying is that the operator, in Imposition Mode, can switch to Rendered view and see the plates exactly as they will run, in composite or toggle seps... it shows the exact dots and placement, as they will image on the plate. I cannot share it with clients but it is a super handy tool for seeing a plate before it burns.

Yeah that is what a VPS is (a rendered proof, screened and viewed as composite or seps) if the operator chooses to run it at full res. It's just like we used to use for proofing when we sent screened one-bit tiffs to our impo printer. Lower res screened files than the plate files but all created with the same engine...just a lower res.

zacgil · March 27, 2015, 02:50:44 PM

I just had a customer call in about this exact issue. They were wanting to know if there are ways on their end(InDesign Preflight or such) that they can identify these problem fonts. Besides just outlining all text, is there a good way for them to check? Can they stay away from subset fonts and just fully embed all fonts?

Joe · March 27, 2015, 02:59:40 PM

Can you run an Acrobat or Pitstop preflight on the original file and see if it flags anything about that particular font? Obviously Prinergy preflight didn't but the Prinergy preflight is pretty crappy to begin with.

David · March 27, 2015, 03:09:24 PM

Quote from: zacgil on March 27, 2015, 02:50:44 PMI just had a customer call in about this exact issue. They were wanting to know if there are ways on their end(InDesign Preflight or such) that they can identify these problem fonts. Besides just outlining all text, is there a good way for them to check? Can they stay away from subset fonts and just fully embed all fonts?

do you know what that font name was?
is it licensed for print and embedding?

zacgil · March 27, 2015, 03:25:19 PM

Joe - It passed all tests in the Pitstop preflight. Can't find anything different about that specific file/font. It is subset, I don't know if that is THE issue though

David - The font is Rokkit and Rokkit Bold

News:

WTF Text