Weird ligature issues

[welchp]

I work at a printing company and we do prepress on InDesign CS5 print jobs. We have ran into a type problem that we would like to know if others have had and if there is a preventative solution for. We've had two InDesign CS5 jobs develop this strange problem in the past month.

If automatic ligatures are turned on (and they are invariably), certain letter pairs will swap out with single glyphs as if they are ligatures despite the fact that they should not be ligatures. Once you turn automatic ligatures off, the pairs go back to the way they are supposed to be (but, all your good ligatures go away as well).

Here is an example:

In the document I have currently, the pairs ek and eh convert to the ligature glyph fi and the > symbol. Thus, if I type "seek behind", you would get "sefi b>ind". Turn off the automatic ligatures, and the problem goes away.

This problem is particularly insidious in that there is no warning for it. You load up the fonts, you open the InDesign file, and the pairs have changed themselves since the last time it was opened. If you aren't looking for it, you will not notice that it has changed.

Has anyone seen this problem or know what causes it? What preventative measures can be done to keep it from occurring other that manually turning off ligatures on all text in all InDesign jobs?

[Jongware]

Mattwbrt wrote:

[..]

So far no one has had this issue in CS4?

Not me. Can you find out the exact version number of the Times New Roman you are experiencing this with?

[Mattwbrt]

This was Times used in 2 different jobs one was a Postscript from our Linotype library Disk we have  other was an Opentype from the Adobe Opentype Library

• Times LT Std-Roman version 1.040 Adobe Systems Heidelberger Linotype <Open Type>
• Times New Roman PS -Medium Version 1.0 <postscript version>

[Peter Spier]

Matt, can you possibly share a sample of one of these files for testing on other systems?

[Mattwbrt]

Peter,

I can e-mail you the file.

We had to cut the text out of the job just leaving the word Johns in the file. We were able to get it to happen on one machine.

We are trying to get the issue to happen again on another. It gets frustrating because you have to open and close open and close a lot.

you can e-mail me at [link removed by forum host]

Thanks

Matt

[Peter Spier]

I removed your email so the spam bots don't find you and I'm sending you an upload link by private message.

[Peter Spier]

I've lost rack of the number of times I opened your test file, but it's been more than 30 I'm pretty sure, and it hasn't doen anything strange yet, either in ID or on expor to PDF using a bunch of different presets. I still suspect a local problem on your system.

[Mattwbrt]

This is the problem that we have.

Our sister company was the first to experience the problem and we never saw the problem for months even on the files they supplied to us.

I have the same issue here I can open and close it on machines and never see the issue while on another machine i can open it and get the problem.

I have found once i get the problem to happen on the machine i can keep getting it to happen until i restart the computer. Which yes leads to the cache issue. But I still think its something to do with the Indesign ligatures. If i can recall didn't adobe do something different to their ligature engine between cs4 and cs5?

[Peter Spier]

I'm not aware of any changes to ligatures, but that means nothing.

It's possible that you are dealing with a corrupt font, too, if you are using the font supplied by the client or your sister company. Have you tried deleting the font inthe folder and replacing with a brand new fresh copy from your original media?

You keep coming back to ligatures, and that might be involved, but I think it's a red herring. hn just isn't a ligature in Adobe Garamond Pro, so there is no way it should be recognized as one, which is one of the reasons I think the font might be wonky.

[niegocki]

But somehow it is tied to something improper about the ligature function in that when trying to click on an erroneous Ü, I can arrow through it and get two letters out of it, not just one [I-beam gets me two taps, one right in the middle]. What I have suggested to Adobe is that maybe Indesign rechecks the file at certain times and the composition engine takes two letters and tries to make them into one character. I have had it happen to both OpenType and T1 faces, and in all sorts of families. It is real, and it is a pain. I wouldn't wish it on anyone.

[John Hawkinson]

Does this problem persist across an export to IDML?

[Mattwbrt]

We have had the problem happen with various fonts as well. Opentype and Postscript

I know that this issue is going to be difficut for anyone to try to fix when it is such a random issue and we can not replicate the problem 100% of the time.

Or even give Adobe or anyone else this is what you need to do to fix the issue.

The more people that see this problem and then see they have seen the same issues. It can help everyone try to figure out what is going.

It is good that other people are seeing the same problems as well.

We are looking at creating in the Pastboard/Slug area of the master pages a list of the affected characters

hn hk io il sy SY then have these listed in every font that is used in the book.

When we open the job and if we see these characters are replaced we can try it on another machine to create our PDFs.

We are also looking to not have Ligatures on for the entire document but only using a grep style to call out ligatures for fi fl ffi ffl Th and the other basic ones the clients wish to have.

Its a terrible work around but at present these are the only other ways we can think about looking for this issue.

[Jongware]

Here is another long shot. Are these fonts installed in your system, or are they inside a Fonts folder inside the one your document is saved? Be careful to check, possibly both are true.

(Reason of my suspicion is in one of the first releases of CS5 the Small Caps feature failed to work with this scenario.)

[Jongware]

(What do you know, it's been a year since that one has been *noticed* and promptly *fixed* and people are still falling for it: http://forums.adobe.com/thread/938784?tstart=0

Guys, that's what those updates are for.)

[Peter Spier]

[Jongware] wrote:

Here is another long shot. Are these fonts installed in your system, or are they inside a Fonts folder inside the one your document is saved? Be careful to check, possibly both are true.

(Reason of my suspicion is in one of the first releases of CS5 the Small Caps feature failed to work with this scenario.)

Matt has noted above that he's uisng 7.0.3 (should update to 7.0.4), and I was using his test file withthe document fonts folder to be sure I used his copy instead of mine for any fonts.

[Jongware]

Well that's about all I had to offer then 😕 Paint me clueless.

[Mattwbrt]

Also let me explain Peter,

This is not happening in every job. Since 9.10.11 till now we have seen the issue in a total of 9 Jobs. We on average have 170 NEW Jobs come thru our offices.

Now take in account that these Jobs can be open on an average of 6 times during the course of the life of the job between those months I am not even counting revised pass's of  older jobs that we get as well. This is a very small percent that it is happening too.

But as you know one mistake that gets printed can loose a client.

It has us trying to determine what is different in the files as well as how can we check to make sure this is not happening in the jobs before we send them to the client.

[Peter Spier]

I don't doubt that both of you see this. Nor do I dispute that it's a terrible problem for you. That said, this is either a bug so hard to trigger in terms of exact conditions in the file and ID that it may be impossible to find because it can't be reliably reproduced, or it is some other intermittent conflict that is completely localized. The only way this is going to get fixed, though, is if you are able to produce a file that shows the problem 100% of the time, or can determine a set of conditions that will cause it in any file 100% of the time so there is something to trace.

[John Hawkinson]

The only way this is going to get fixed, though, is if you are able to produce a file that shows the problem 100% of the time, or can determine a set of conditions that will cause it in any file 100% of the time so there is something to trace.

It's not quite that bad! If you can make it happen 10% of the time that's probably good enough.

It's only when the bug only happens 0.05% of the time that they really have trouble.

[Mattwbrt]

"Here is another long shot. Are these fonts installed in your system, or are they inside a Fonts folder inside the one your document is saved? Be careful to check, possibly both are true."

Yes we make sure all the font locations and the system fonts are cleaned out with only the fonts the OS needs to work.

Then we load the fonts into the Indesign Font folder. We were using suitcase fusion but we stopped that thinking Suitcase was the issue causing this.

New  job discovered withthis issue

The font in question was Cresci Regular is a T1 font the characters in question are "il"

Mac OS is 10.5.8

Indesign is ID-CS5 ver 7.0.3

We were able to catch it in the indesign file first and again turning the ligatures off will fix the issue, but at this stage of the job we can not turn all ligatures off.

We also have had this issue last week in a Indesign ID-CS5 ver 7.0.4 with the font Adobe Garamond Pro Regular characters "hn"

Over in the other thread the latest post.

http://forums.adobe.com/message/4089761#4089761

kjohn73

Since first posting in this thread a few months ago to simply update the OS I've since heard from others (one teacher and one student/intern) who have seen this issue as well, and apparently CS5.5 doesn't resolve it. Personally, though, I still haven't experienced the problem on my iMac.

[Mattwbrt]

Posting more screenshots of the new file we had problems with so you can see the the ligature issue.

The first is with ligatures on you all see the character Paragraph style we have set up.

With the Ligatures off.

[Mattwbrt]

Ok Another weird solution to this.

Looking above at the post jong wrote and the link.

We do not use document fonts or a collect for output.

all of our font folders have a unique 5 digit number with a _fonts on them

So I went to the machine i have left on with this issue.

The first steps I did i open and closed the Indesign file to make sure the bug was still happening it was.

I left the fonts loaded into the Adoobe Indesign fonts folder.

I renamed the fonts folder adding a _1 after the _fonts and then opened the file and it work the file was fixed.

So question what does this lead one to think I don't think its a bad cache file I thinking it has something to do with Indesgn holding the path for fonts in its files?

[John Hawkinson]

Can I repeat my question from post #35?: Does this problem persist across an export to IDML?

[Mattwbrt]

@John,

John I have not done an IDML export.

The reason I think that this test for me would be a waste at present is that this problem doesn't happen all the time.

So then I can export the to IDM then open it up on the same computer and it would not happen.

I will give it a shot just to see if it happens again.

For me at present the just changing the name of the font folder was intresting why that worked I have no idea at present.

But I am continuing to look into this, that it may be something in the way Indesign is looking at the fonts locations of a job

Example we have our fonts on our server withing a specific path

Client Number >job number> job_core>job_fonts

My next step is going to keep the copy on my local desktop which I have been for testing but disconnect my network drives so Indesign can not find them.

I am thinking that Indesign is getting lost in trying to figure out where the fonts are.

We do not package or collect for output, but maybe Indesign is retaining some information on path location of the last opened fonts.

[Mattwbrt]

John,

I tried to export as IDM and then reopen the IDM file back up on the same machine with CS5 and it still had the problem.

[John Hawkinson]

Matt: I agree that it certainly sounds like ID's ligature engine is to blame, esp. if it happens with Type 1 fonts. I'm not sure how smart their ligature coding is. I'm still holding out the possibility that it's a complex-interaction.

If the problem happens when you open the IDML file, then you have the opportunity to look inside the IDML file and see if there is something strange about the font coding. IDML files are just .ZIP files containing an XML representation of the document. I am not really sure whether you are likely to find anything amiss, but it's probably worth a look-see.