Major problem with fonts and pdfs

I'm experiencing a strange problem. When I view pdfs using Preview, many of
the characters of the fonts are either missing or (more commonly) replaced
by black boxes. This happens with pdfs I've created on this machine and which
were working perfectly (the pdfs were created using TeXshop). It also happens
with downloaded pdfs. What is also strange is that if I quit Preview and re-open
the same pdf file, I get different patterns of missing/blacked out characters.

If I try printing the file to a printer (HP LasterJet) the character mess remains.

If I try opening the file in Adobe Acrobat, then the file is perfectly fine.

I've tried deleting my plist files, the problem remains.

I've re-installed Preview from the OS discs using Pacifict - the problem remains.

If this were a problem with one or two pdfs, I would put it down to badly constructed pdf files. But this now occurring with about 60-70% of all
the pdfs on my machine!! And as I mentioned above, even ones I created and
that had been working perfectly a week or so ago.

If anyone has any thoughts on why this is happening and how to fix it, I would be most grateful. I'm a researcher and I have a large number of pdfs
for my work that I can no longer read or print!

Many thanks,

Adrian

PowerPC G5, Mac OS X (10.4.10)

Posted on Aug 14, 2007 3:21 PM

Reply
17 replies

Aug 15, 2007 7:31 AM in response to AdrianBurd

This is an issue with font embedding and subsetting.

First off, you'll need to make sure when you create the PDF files, you turn on 'embed all fonts' when creating the PDF. Most likely you are using one of the pre-set options that are standard with Acrobat ie: "Smallest file size". Try "press quality" instead Not all the PDF creation options will embed the fonts.

Now all that being said, there are certain fonts with manufacturer licences that do not allow embedding. Lastly if it is the same font displaying this way in all the files, perhaps the font itself is corrupt. This can be fixed by replacing the font with an original copy, or fixing it using one of the many font utilities available.

I also suggest you repair permissions if you have instaled or changed anything lately, as well - if you are using CS2, delete all the folders in adobe applications that say legal.localized or legal. (these are not likely related to your issue, but could have an effect in other ways)

I don't think it's an issue with preview. Also, make sure the fonts being used in the original document (the one that created the pdf's) are running if embedding is an issue.

Aug 17, 2007 5:41 AM in response to colin clarke1

Hi Colin,

I'm not sure it is a problem with font embedding. If it were, I would expect that the pdf would never show correctly using Preview, whereas viewing the same pdf file 10 times in succession might show perfect views 2 or 3 times.

Secondly, the pdfs that I create are made using pdfTex (via Texshop)
and the fonts are embedded in the documents by default.

What is more, this is the only machine that this happens with. I can transfer
the pdf to another Mac with identical software and view the pdf without
any problems.

It seems to me that there is a problem with the pdf viewing/printing set up
on this machine, and I'm not sure where to look to fix it. As I've mentioned,
I've re-installed Preview without fixing the problem. I suspect that something
somewhere has corrupted a driver, but I'm not sure.

Adrian

Aug 17, 2007 9:53 AM in response to AdrianBurd

Font embedding affects only the printing, not the viewing of the file. but your problem does sound like a Preview one. I never use preview, I'm almost exclusively an Acrobat user for PDf's.

I suggest eliminating the font embedding issue (if it exists) by printing the same file from several different machine on both PC and Mac platforms. If it prints properly then the fonts are correctly embedded.

I have had similar but not exactly the same issue but they have been font related or due to an error in one of the support files.

Good luck, sorry I couldn't be more help.

Aug 17, 2007 10:44 AM in response to AdrianBurd

I agree that this behavior is not an embedding problem.

You mentioned deleting plists, but have you tried other more general things like repairing preferences? If not, try that first.

If the problem persists, I'd suspect that you might have some damaged fonts. This can cause all sorts of weird, unstable problems. Apple's Font Book can "verify" fonts, but not fix them. I'd start there, turning off any damaged fonts.

If you need to fix fonts, then I think you'll need a third-party application.

Hope this helps.

Chopec

Sep 11, 2007 10:28 AM in response to colin clarke1

Font embedding affects only the printing, not the viewing of the file.


Actually, embedding effects both. If Acrobat can't find the required font (for example, if the font was not properly embed/subset), it will substitute. As well, if the option is checked, Acrobat may use local fonts instead of embedded fonts (won't have the problem with subset fonts).

Best option is to set Acrobat Distiller to embed/subset ALL the time (threshold set to 100%). This ensures necessary fonts are ALWAYS in the PDF, and subset allows only necessary glyphs within the font to be embedded - and renames in the process (which prevents ANY substitution).

Apple's print-to-pdf option is great, but Distiller is still the only solution for managed PDF workflow.

Don

Don Montalvo, NYC

Sep 24, 2007 10:25 AM in response to don montalvo

"+Best option is to set Acrobat Distiller to embed/subset ALL the time (threshold set to 100%). This ensures necessary fonts are ALWAYS in the PDF, and subset allows only necessary glyphs within the font to be embedded - and renames in the process (which prevents ANY substitution).+"

Actually ... subsetting the fonts can cause both problems with RIP's and editing the PDF's. The best option is NOT to subset if the PDF file will eventually be used for printing purposes. I'm talking about Press/digital printers. Once the PDF leaves the originating computer, subsetting can and does cause many problems. Embedding the entire font is a much better solution than subsetting the parts of it that are in use. Sure it will make the PDF file 'slightly' larger, but it also ensures that the file can be used and edited outside the parameters that the creator set. This is important in the pre-press and editing world.

I should have been more clear about font embedding ... It Will NOT affect the preview unless the PDF is not on the originating system. Even if the font is not embedded but still running on the OS - as long as that PDF stays on the same machine and the font is active, no visual difference can be seen.... the font will not substitute... Of course - it will if the PDF is opened another system where the identical font isn't running.

Sorry, I should have been more concise...

Sep 29, 2007 11:06 AM in response to colin clarke1

+Actually ... subsetting the fonts can cause both problems with RIP's and editing the PDF's. The best option is NOT to subset if the PDF file will eventually be used for printing purposes. I'm talking about Press/digital printers. Once the PDF leaves the originating computer, subsetting can and does cause many problems. Embedding the entire font is a much better solution than subsetting the parts of it that are in use. Sure it will make the PDF file 'slightly' larger, but it also ensures that the file can be used and edited outside the parameters that the creator set. This is important in the pre-press and editing world.+

We never want anyone to edit a PDF. Best practice is to edit the original document and recreate the PDF. Embed/subset fonts have never caused a problem on any of the RIPs we send to (at full service bureaus there's a wide variety of RIPs we send to). We subset to prevent substitution (which can and does happen on some RIPs) and to prevent Acrobat from using local fonts for display. In all our workflows, the PDF is final.

+I should have been more clear about font embedding ... It Will NOT affect the preview unless the PDF is not on the originating system. Even if the font is not embedded but still running on the OS - as long as that PDF stays on the same machine and the font is active, no visual difference can be seen.... the font will not substitute... Of course - it will if the PDF is opened another system where the identical font isn't running.+

Why not prevent substitution all together and embed/subset? Which RIPs are you having problems with? If they're old, I would point the finger there instead of at embed/subset which is standard workflow in most shops, bureaus, etc.

Don

Oct 1, 2007 11:12 AM in response to don montalvo

+Why not prevent substitution all together and embed/subset? Which RIPs are you having problems with? If they're old, I would point the finger there instead of at embed/subset which is standard workflow in most shops, bureaus, etc.+

Actually Dan, I see you are not familiar with what subsetting does to a font... read up on it. Subsetting does NOT mean embedding. And - most shops/bureaus etc. may need to edit/fix a PDF - since most designers know very little about the print world. This why print shops/bureaus pay thousands of dollars to purchase PDF RIP's and PDF editing tools.... I suggested (I guess you didn't read properly) that people should fully embed the font not subset them. (Why would you want to do both anyways, it's just repetitive?)

Dan - why would someone want to go back to the original document to add a comma that was forgotten, when fixing the PDF is easier, faster, less costly and safer. There isn't a single reason why a pre-press tech wants to go backwards. The graphic designer can do the AA's on his original, but unless there are massive changes, there is now reason to go back to source files when PDF editing is so easily done.

P.S. Apogee X 2006 is our PDF renderer - hardly old.

Oct 1, 2007 8:36 PM in response to colin clarke1

If you want to allow PDFs to be edited in a particular workflow, nobody can fault you, it's your decision. However, for my clients, ALL editing is done on the original document. A simple Google search brought this up on the first hit:

*• Embed All Fonts: On*

*Select this option to prevent font substitution at print time. (Distiller embeds all PostScript fonts used in the document.) This option also enables Distiller to subset fonts.*

*• Subset All Embedded Fonts Below: On, at 100%*

*Select the Subset Fonts Below option and specify 100% so that Distiller will embed only the font characters used in the document. Distiller also renames the subsetted fonts in the PDF file to prevent an available font with the same name from being used for viewing or printing.*




...by renaming the font, you prevent any chance that the recipient's Acrobat or RIP will substitute a font. Again, every workflow is tailored to the company. We use Dalim Twist with custom workflows (Xinet FullPress enviornment). Our PDFs go out a finals. Period. Any edits are done on the original document and a new PDF is generated and sent out to printer. Works quite well for our high profile clients...but a workflow that works for one company may not work for another. 🙂

Don

Oct 2, 2007 1:00 PM in response to don montalvo

Hi Don,

I understand where your coming from... here's where I'm coming from.

I work in a commercial printing plant, that specializes in process colour work and huge books - mostly scientific journals. - 200-2000 pages most of the time.

Here's an example: You are my client and supply a PDF for print. After I impose the book into signatures, I create a digital proof, which is then returned to the client. Client reads over, makes AA's and returns the book. So here I am with 25 typos to edit spread across 652 pages.

I can .. A) contact designer and ask them to change it and send a new PDF (So I get new files the following business day if I'm really lucky). Since most of these books are done in Tek or 3B2 software, they cannot generate a single PDF easily. They must first edit the XML code, overwrite old text, then re-import the XML stream into the layout program, this often results in reflow so they must check for changes in text-flow and photo positioning etc. etc. then regenerate another .ps file, then re-distill it. If I'm really lucky, I get the return PDF in 48 hours.
or B) If they DID NOT Subset the font, I can make the changes in perhaps 10 minutes and generate another proof by the end of the hour.

Imagine if I had to go back to source files every time an AA came back or they wanted a photo a little darker etc... it would take forever... I advise my clients to NOT Subset, but to EMBED only. And with the PDF RENDERER's (not a RIP anymore really) I have not hasd any problems.

Now if you are the client, and your deadline is - lets say tight - do you really want to add 48 hours to the time restraints? I'm sure (100% sure actually) that my clients want me to fix the AA's and supply a new proof within the hour, rather than within the week.

So Where I'm coming from is that the printing industry is fast becoming a PDF work-flow environment and we rarely even require going into your Quark or In-Design originals.

We can edit PDF's to the extent now that most AA's including colour, text, positioning, transparencies can be done in Acrobat. It's not that we want to, with how competitive the industry has become we now HAVE to think speed and error free work.

Oct 2, 2007 7:36 PM in response to colin clarke1

Ahhh...editable PDFs make perfect sense for your workflow. For ours, it doesn't.

We do inhouse catalog production. We produce several dozen catalogs per month, often with just days notice, and each with 200-400 high quality pages. Sale items come in the door, gets barcoded, sent to one of three dozen high resolution photo studios, where images are taken in RAW format and processed through our Twist server where profiles are applied during conversion to required colorspace. Then images are put into our Xinet system where production artists pull FPO images into catalogs. Text is handled by specialists and proofreaders and is pulled in using CatalogMaker. Once text and images are brought in, the document is sent via Automator scripts to Twist server where the document is processed into high resolution press ready PDFs.

If ANY change needs to be made to a section of any catalog, it's done by production staff and new PDF is produced within minutes. Once the final PDFs are created, they are sent via MassTransit to one of our internal print houses (either here or in London). Any edits done to any of our PDFs would be a wrench in our workflow, especially since our production folks can easily and quickly make any necessary changes to the original document and send through the system again. Since our catalogs are handled in sections, production doesn't have to stop if one section has to be edited/resent.

Ours is a very structured, tightly controlled workflow. For us, edits to PDFs would not make sense. 🙂

Don

Oct 12, 2007 5:27 PM in response to Kurt Lang

I'm having a similar issue, except i'm not the one creating the PDFs. i get these pdfs sent to me every couple days for work info. When i open it in Preview the document is nothing but boxes and odd characters. One day i opend the file in photoshop and i could read all the fonts!

i have no idea how to reset preferences, font cache files or any of the other suggestions above. I've tried everything i know to do.

any suggestions?

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Major problem with fonts and pdfs

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.