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... )
That is the problem of non-rendered proofs.
Are you able to view it in rendered mode, prior to plate output?
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.
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...
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.
Quote from: zacgil on March 23, 2015, 02:42:51 PMQuote 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.
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??
Can you ping me the PDF please?
andrewb@enfocus.com
we'll take a look if you want
Quote from: Ear on March 23, 2015, 02:49:49 PMQuote from: zacgil on March 23, 2015, 02:42:51 PMQuote 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.
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.
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.
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?
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.
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?
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
Quote from: zacgil on March 27, 2015, 03:25:19 PMDavid - The font is Rokkit and Rokkit Bold
...and the very first Google result shows it's a free font :(
Easily the majority of our Prinergy font problems are because of free fonts downloaded off the web. You're in a tough place because you won't know the outcome until you refine the file. I doubt most customers understand the licencing/permission issues David mentioned, either.
Save yourself the headache and just tell them to outline the fonts. That way when they get the printed piece and they're not happy with the type, it's on them, not you. Then -and only then- you get paid for a reprint. Profit!
That is a Google web font which should NOT be used in print production.
Quote from: gig0 on March 27, 2015, 03:48:06 PMQuote from: zacgil on March 27, 2015, 03:25:19 PMDavid - The font is Rokkit and Rokkit Bold
...and the very first Google result shows it's a free font :(
Easily the majority of our Prinergy font problems are because of free fonts downloaded off the web. You're in a tough place because you won't know the outcome until you refine the file. I doubt most customers understand the licencing/permission issues David mentioned, either.
Save yourself the headache and just tell them to outline the fonts. That way when they get the printed piece and they're not happy with the type, it's on them, not you. Then -and only then- you get paid for a reprint. Profit!
Unfortunately this problem doesn't show up at refine. Doesn't even show up in the VPS unless you output the VPS at the same resolution as the plate files and who does that?
Kodak I think posted a knowledgebase article about a google font called 'Roboto'
I guess the same issue might apply to this font if it's from the same source
Quote from: abc on March 27, 2015, 04:42:33 PMKodak I think posted a knowledgebase article about a google font called 'Roboto'
1000% agree. Our marketing person seems to gravitate towards this font and I always end up outlining it.
Quote from: Joe on March 27, 2015, 04:26:57 PMUnfortunately this problem doesn't show up at refine. Doesn't even show up in the VPS unless you output the VPS at the same resolution as the plate files and who does that?
Yup, hence our conundrum with free google fonts.
Quote from: abc on March 27, 2015, 04:42:33 PMKodak I think posted a knowledgebase article about a google font called 'Roboto'
I guess the same issue might apply to this font if it's from the same source
Yes they did and they claim to have fixed it in Prinergy 6.1.1 but I haven't got around to updating to it yet.
At least you can build an Acrobat Pro Preflight Check or a PitStop Pro/Server Action List to warn and or outline any incoming font that matches Roboto or Rokkit etc.
EDIT: The KB article that ABC mentioned can be accessed here if you are a Partner Place member:
https://services.kodak.com/app/answers/detail/a_id/67124/kw/roboto
Somewhat related but last week we had a outlined font go wacky but it was on the customer side, it came in like that. I'm just glad someone noticed it.
We have some very, very picky commercial clients but the absolute worst are the financial clients. The only re-runs we have done in recent memory were their jobs. Insane time demands, picky press approvals and even with a signed sheet they bitch about the smallest things. All for a book that won't even be read and tossed in the garbage.
I always hated doing work for photographers, architects, engineers and related fields. For whatever reason, they always seemed to be more of a PITA than "designers".
QuoteThe fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works.
It does allow embedding, but strangely, it does not say "print" in the list... dunno
may be part of the problem, not sure.
Had another job go to press last night with the funked up text. This time it didn't show up on the full res VPS proofs either. Is my only defense to upgrade my software? Or get a Tiff Catcher that allows viewing the exact imaged plate? Can't count on customers to use the right fonts so I can only try to correct them before they go to press. Which leaves me with outlining all fonts... :banghead:
Same font as last time? Can you send me the offending original PDF from this last instance? I'd like to take a look at it.
joe at b4print dot com
Also, you can open the individual one-bit tiffs in Photoshop to view them.
This time it was Kalinga, another web only font I believe.
I'll send it over
Good to know about PS though!
Hmmmm...
[attachimg=1 width=440]
OK, I guess there are two different Kalinga fonts. The one by MS and then the freeware one in your PDF. Pitstop does not flag it for not having the outline or embedding license but still...freeware = bad.
microsoft can't even display their own fonts...
here is what it should look like.
Sadly, they coulda used helvetica or arial...
Quote from: david on March 31, 2015, 11:14:05 AMmicrosoft can't even display their own fonts...
here is what it should look like.
Sadly, they coulda used helvetica or arial...
Yeah the one from Microsoft is an Indian font and not the one in the PDF. The one in the PDF is a crappy freeware font and yeah, why would anyone use that since every computer on the planet has arial and/or helvetica.
Quote from: Joe on March 31, 2015, 11:16:11 AMQuote from: david on March 31, 2015, 11:14:05 AMmicrosoft can't even display their own fonts...
here is what it should look like.
Sadly, they coulda used helvetica or arial...
Yeah the one from Microsoft is an Indian font and not the one in the PDF. The one in the PDF is a crappy freeware font and yeah, why would anyone use that since every computer on the planet has arial and/or helvetica.
Because they are "Special"...... and unique and original. Might as well use some obscure web fonts that no one has ever seen before. Maybe there's a reason for that?
:drunk3: :drunk3:
The other question is, how do you guys deal with these freeware, problem-prone fonts?
If you don't catch them before the press, are they responsible for replating/press down time?
Quote from: zacgil on March 31, 2015, 11:34:52 AMThe other question is, how do you guys deal with these freeware, problem-prone fonts?
If you don't catch them before the press, are they responsible for replating/press down time?
I ran your pages through Prinergy 6.1. No problems on the full res VPS or the plate files output at 2400 dpi 150 LS.
Hopefully we catch them in prepress. If not there hopefully the plate person will see it. If not there the pressman should catch it. If it is missed by all of those there is hell to pay.
Screenshot attached of the plate files from Photoshop:
Hmmm, so updating our software could fix some of these issues?
The other issue may be that I am trying to pick up the pieces from night shift. So the file I sent you could have been a revised file. I have very little info besides the final product, when the error occured.
Well I can't guarantee an upgrade will solve it 100% of the time as we still very rarely see that issue but it does pop up every now and then. I will say I've never had one come out on plate that the full res VPS didn't show the issue also.
This is why I may bitch about my pressmen bothering me about every little thing but it means they care and are really looking at what they are producing.
guess what I got today...
this is from our Prinergy Super Admins...
quote from an email:
QuoteWe have had some font issues with a couple of different sites and wanted to make everyone aware. It is possible that you have already had to deal with this but we wanted to make you aware of a way to catch any known fonts. Converting the fonts to outlines generally fixes the problem, but catching it before plating can be problematic.
The symptoms appear only at a high resolution or when a file is rotated. The files look fine when proofed normally either to a printer or vps. The only way to catch the problem is to either rotate the file and/or proof at 1200dpi or higher.
These fonts are "free" which is why customers are using them. I think the fonts were really created for Web use, but work their way into print. If you create or modify your existing Preflight profile to "error" when encountering the font will give you a chance to catch them. Right now I'm only aware of 5 that have caused us problems. Please let us know if you have experienced any others not listed. Attached is a screen shot of a preflight profile.
Fonts: Segoe, Kalinga, Amatic, Kartika, Boswell
Quote from: david on April 03, 2015, 10:41:06 AMguess what I got today...
this is from our Prinergy Super Admins...
quote from an email:
QuoteWe have had some font issues with a couple of different sites and wanted to make everyone aware. It is possible that you have already had to deal with this but we wanted to make you aware of a way to catch any known fonts. Converting the fonts to outlines generally fixes the problem, but catching it before plating can be problematic.
The symptoms appear only at a high resolution or when a file is rotated. The files look fine when proofed normally either to a printer or vps. The only way to catch the problem is to either rotate the file and/or proof at 1200dpi or higher.
These fonts are "free" which is why customers are using them. I think the fonts were really created for Web use, but work their way into print. If you create or modify your existing Preflight profile to "error" when encountering the font will give you a chance to catch them. Right now I'm only aware of 5 that have caused us problems. Please let us know if you have experienced any others not listed. Attached is a screen shot of a preflight profile.
Fonts: Segoe, Kalinga, Amatic, Kartika, Boswell
Oh thanks Kodak! They are just so helpful.... :strangle:
Quote from: david on April 03, 2015, 10:41:06 AMguess what I got today...
this is from our Prinergy Super Admins...
:wtf: is a Prinergy Super Admin?
those are the ones at QG that are way more into Prinergy than I am.
I am just a Prinergy Lead, so I do not dictate the rules.
I just thought it was weird that someone else (could possibly be a member here and I don't know it) had the exact same font give them trouble at the same time as the OP here.
que the twilight zone music
Oh I thought it was someone at Kodak that gave themselves the title. :rotf:
Anyhoo...Kodak put a memo out about those kinds of fonts a few moths ago though I don't think Kalinga was specifically mentioned at that time. I do know Kodak "people" lurk here. :peep: Not sure about QG other than yourself though.