On my Adobe CS3 installation DVDs, there is a folder Goodies/Fonts containing in particular a font called AdobeHeitiStd-Regular.otf (and other fonts that look Chinese to me, AdobeKaitiStd-Regular.otf, AdobeMingStd-Light.otf etc). Did you have a look there?

The problem you mention sounds strange to me. I never have any problem with embedding any chinese font into PDF from any of the Adobe software.

Is your designer friend using Mac or PC? Is she using the original Adobe software? If you are using any Mac machine with original Adobe softwares you shouldn't have such problem, because logically speaking, any system font came along with Mac OS would be covered by the licensing.

A lot of designers in developing countries (including those in mine) like to install Mac OS in PC and use pirated softwares. Once you do that, you would have a lot of problems.

weng

Thank you both for taking time to respond.

I work on a Macintosh, and so does the designer who has the font issue. I don't know if she's running Tiger or Leopard, we're a few hundred miles apart, and I don't generally do house calls.

That might work Michel. I opened AdobeHeitiStd-Regular.otf and Apple's STHeiti.ttf in FontLab, and although I see Adobe's version has a somewhat smaller glyph count, it has "Editing of the document allowed" which should allow it to be saved into the PDF. Bravo.

One would think that Weng. The font software is licensed to Apple and supplied with the System install disk, I can open it in FontLab and see that it's from Changzhou SinoType Technology Co., Ltd. and that "Embedding of this font is not allowed." That is where our problem resides. I think substituting AdobeHeitiStd might resolve the issue, IF all the glyphs used are present. If memory serves, when we were using MacOS 9, there was also a "simplified" version of the supplied Chinese font that had a reduced glyph set.

Makes design more complicated when you're not fluent in the language.

Thanks again, I'm going to try a font substitution and see if the line endings change.

Bill Lomax

Bill --

Ken Lunde, who is the CJK guy at Adobe, sometimes comes around the Typophile forums and could probably offer some insight or direction. But since he hasn't shown up in this thread yet, so you might contact him directly: http://lundestudio.com/

“Embedding of this font is not allowed.” That is where our problem resides.

Yes, but it also says "allow subsetting" and I don't see why InDesign refuses to "subset".

I don’t know Michel. It should allow subsetting. Up until this morning, I had not tried saving text set in STHeiti as a PDF. I copied an article written in Chinese this morning from worldjournal.com into TextEdit, changed the font to STHeiti and saved it as a PDF. It worked fine, no issues. I tried it using the same text in InDesign, and got this error message. "This font could not be embedded due to restrictions in the font file. The font must be installed to view or print this file properly with Adobe Acrobat. View additional errors?"

Since we're working in a Mac and PC environ, it's not a given that the client or the translators will have that font installed. I believe the final form will be posted as a PDF on the Internet, as well as being printed.

Thank you for the pointer Kentlew, after checking into this further, I will contact Ken directly if I cannot resolve this.

Bill Lomax

it’s not a given that the client or the translators will have that font installed.

I tried a step further: I went on the Bank of Montreal Chinese homepage, selected Traditional Chinese, copied some text there, pasted it in InDesign with STHeiti selected, exported the text as pdf (without STHeiti being embedded), and copied the resulting pdf file here; I then tried to read it from my PC using Internet explorer. Internet explorer (in fact some Adobe plugin) complained that a resource was missing, went to fetch the missing font and could eventually display the text.

My guess is that if you use Adobe applications to access the pdf file, the font STHeiti will be properly displayed even if it is not embedded (provided the application accessing the file can connect to the internet to get the missing resource).

Michel

(Provided the application accessing the file can connect to the internet to get the missing

That probably is true Michel. The place it's likely to fail is at press, and it could potentially be an expensive fix. Remember the bad ol' days when PostScript printers would set Courier when a font could not be located? That sort of thing still happens. Think your solution of using AdobeHeitiStd instead of Apple’s version, STHeiti, is going to be the ticket, ...if the brochure text doesn’t use one or more of the 2,200 odd glyphs that are not mutually shared.

- Bill Lomax

I’m going to consider this issue resolved. I substituted AdobeHeitiStd-Regular.otf for STHeiti.ttf in the IDCS3 file and was able to generate a PDF without error messages.

My sincere thanks to all who took the time to respond.

- Bill Lomax

As the person at Adobe who built AdobeHeitiStd-Regular.otf, I can tell you with much confidence that its design is the same as STHeiti.ttf. Substituting the fonts as you did was the right solution. The OS/2.type value of STHeiti.ttf is set to 2, which explicitly denies embedding. The value in AdobeHeitiStd-Regular.otf is set to 8, which allows embedding.

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development
Adobe Systems Incorporated
lunde@adobe.com

I've noticed that as well after the publisher used 汉仪中等线简.OA / 汉仪中黑简.OA with no problem.

The OS/2.type value of STHeiti.ttf is set to 2, which explicitly denies embedding.

Ken

If I run the Mac Fonttools command ftxdumperfuser -A d -t 'OS/2' on STHeiti, I get in the resulting <filename>.OS_2.xml the following

<!-- Microsoft version 1 'OS/2' data -->
<OS_2Table version="1">
        <xAvgCharWidth value="481" />
        <usWeightClass value="Normal" />
        <usWidthClass value="Medium" />
        <fsType>
                <bit0_Reserved value="FALSE" />
                <bit1_RestrictedLicense value="TRUE" />
                <bit2_PreviewAndPrint value="FALSE" />
                <bit3_Editable value="FALSE" />
                <bit8_NoSubsetting value="FALSE" />
                <bit9_BitmapEmbedOnly value="FALSE" />
        </fsType>
        <subscript>
                <ySubscriptXSize value="100" />
...


I am curious; what does NoSubsetting value="FALSE" mean?

Michel

From the OpenType Specification: "No subsetting: When this bit is set, the font may not be subsetted prior to embedding. Other embedding restrictions specified in bits 0-3 and 9 also apply." In other words, if this bit is *not* set, the font can be subsetted prior to embedding.

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development
Adobe Systems Incorporated
lunde@adobe.com

And, given the Opentype fsType spec, the value

<fsType value="00000000 00000010"/>

returned by ttx -t 'OS/2' on STHeiti says indeed unequivocally (since the only bit to be 1 is bit one)

bit 1 (mask 0x0002)

Restricted License embedding:
Fonts that have only this bit set must not be modified, embedded or exchanged in any manner without first obtaining permission of the legal owner.
Caution: For Restricted License embedding to take effect, it must be the only level of embedding selected.

Thanks,

Michel

Yet, if I paste some text in TextEdit, change the font to STHeiti, generate the pdf (with print), open it with acroread or acrobat, select "File > Properties...", I see this

which says a subset of STHeiti has effectively been embedded.

The pdf generated by InDesign (with export) gives a font info that looks different.

This is generally not too surprising. Historically there were a bunch of Mac system fonts set to "no embedding." My impression is that some of them have been changed to allow embedding in more recent versions of Mac OS.

There's a valid question as to why Apple or their vendor set the font to "no embedding" in the first place. There's an even better question as to why creating a PDF at the system level would embed such a font.

I'd say InDesign is behaving as it ought to from what we know of the situation. Luckily you've found a good substitute font. IIRC, Heiti was produced by a sort of consortium and there are lots of different vendors' versions of what is basically the same design.

Cheers,

T

I’d say InDesign is behaving as it ought to from what we know of the situation.

I wonder if InDesign could not do it in a more user friendly fashion. If Acrobat Professional or Acrobat Reader use AdobeHeitiStd-Regular to display pdf files for which STHeiti has not been embedded (that's what I deduce from the fact that Adobe Reader installed that font in its Contents/MacOS/Resource/CIDFont resource folder when I tried to view the pdf file for which STHeiti had not been embedded), why would InDesign not propose users that same substitution when exporting? Why are the resources available to Acrobat not available to InDesign? That would have saved time to Bill since he eventually did exactly that substitution. Of course, I would never propose that InDesign do a substitution without asking the user.

Michel

This is timely, I'm having the same problem with STHeiti in exported pdfs (ID CS2 / OSX 10.4.11).

From what I can see from my client's scans, STHeiti automatically gets substituted with Hei on their PCs, with missing glyphs.

Looks like getting my hands on AdobeHeitiStd-Regular.otf might be the only solution?

Posted by Michel Boyer 6.Jul.2009 4.10pm:
On my Adobe CS3 installation DVDs, there is a folder Goodies/Fonts containing in particular a font called AdobeHeitiStd-Regular.otf

Before I ask my boss to look for the CS2 installation DVD (we can't find it in the studio, I'm guessing she might have it at home), is anyone able to confirm if the same advice applies to CS2?

The CS2 Resources and Extras disc has Goodies > InDesign CS2 > Adobe Fonts, but I don't see Adobe Heiti.

According the the Myriad Wikipedia entry:

Adobe Heiti is a simplified Chinese typeface that borrows its Latin glyphs from Myriad. It is included with Adobe Illustrator CS3, Adobe Reader 8 Simplified Chinese font pack, Adobe Creative Suite 4.0.

Michel asked: If Acrobat Professional or Acrobat Reader use AdobeHeitiStd-Regular to display pdf files for which STHeiti has not been embedded (that’s what I deduce from the fact that Adobe Reader installed that font in its Contents/MacOS/Resource/CIDFont resource folder when I tried to view the pdf file for which STHeiti had not been embedded), why would InDesign not propose users that same substitution when exporting? Why are the resources available to Acrobat not available to InDesign? That would have saved time to Bill since he eventually did exactly that substitution. Of course, I would never propose that InDesign do a substitution without asking the user.

I think you're making a few tacit assumptions, and missing some information.

If Acrobat/Reader needs a Japanese or Chinese font for substitution, and you don't have the East Asian language support for Reader installed, it will offer to download it. Acrobat/Reader uses Adobe Heiti to substitute for just about *any* Chinese font not embedded in the PDF. The fact that in your case it *happened* to be another version of Heiti was just a happy coincidence.

Not knowing that it's a similar font, there's no particular reason that InDesign would choose to substitute it on export. And for that matter, why embed the generic substitution font, when anybody viewing that document will get that font anyway? It would be like embedding Adobe Sans in a PDF.

Regards,

T

> And for that matter, why embed the generic substitution font, when anybody viewing that document will get that font anyway?

The PDF might not be going (just) to Acrobat Reader.

I think you’re making a few tacit assumptions, and missing some information. [...] Acrobat/Reader uses Adobe Heiti to substitute for just about *any* Chinese font not embedded in the PDF.

I was missing information indeed. I thought that a user that would be asked if he wants his nice font to be replaced by Abobe Sans would click on "No". What are the fonts with fsType AND 0x0002 equal to TRUE that a professional using InDesign is likely to have to live with?

Michel

[edit 1] [edit 1 removed]
[edit 2] If I rely on this document on the font embedding site, only Enschede and Letterhead would have fonts with nothing allowed. To that I guess we need to add some Mac system fonts. What else?

I don't have a complete list, but other then those few Mac system fonts, fonts set to "no embedding" are fairly uncommon.

> The PDF might not be going (just) to Acrobat Reader.

True.

I should have mentioned, if you want to substitute a font in InDesign, just use the "Find Font" mechanism to replace it, before making the PDF. In most other apps you could search and replace the formatting to change the font.

Cheers,

T

InDesign's "Find font" works fine indeed and having Chinese fonts grouped together in the replacement menu makes life easier.

Michel

My impression is that some of them have been changed to allow embedding in more recent versions of Mac OS. [Thomas]

I just looked on a Mac with OS 10.5 and the font info given by FontBook says indeed that STHeiti is embeddable.

Hi, this discussion was extremely usefgul to me, but I am still having some problems. I started a new thread about it at http://typophile.com/node/71159. Thought you guys might be interested. The original post is below:

Hello fellow typophiles,

I am having a problem embedding chinese fonts on PDF to print and view. This topic has been discussed before on http://typophile.com/node/59688, but I have hit another roadblock and would like to ask if anyone with the same problem found a solution.

I designed a magazine (260+ pages) on InDesign CS3 on a Mac running OS 10.4 in mandarin, using the native mac font STHeiti. When it was time to send the piece to the printers, I discovered that the font was blocked and could not be embedded on a PDF.

In the above mentioned post, I discovered that Adobe has a font (Adobe Heiti) which is identical to STHeiti and can de embedded. But then ran into another problem. In the publication (remember, 260+ pages) I used STHeiti Light and the Adobe mentioned font - at least the one I have in my system which came from my CS3 package - only has a Regular set.

This slight change will force me to redesign most pages, since they are mostly running text.

I also noticed that in Snow Leopard, Apple has changed the native chinese font to a similar Heiti family. Therefore STHeiti no longer exists in the system.

I have 3 questions I hope you can help me with:

1- Do you know of any system upgrades that could allow access to STHeiti Light in a format that can be embbeded?

2- Do you know if Adobe Heiti exists as a Light font and where I can get it?

3- (And this is not really related) How do I substitute STHeiti for Adobe Heiti in 50 separate InDesign documents at once?

Thanks,
Gabriel Attuy

On my MacBook Pro with OS X 10.5.8, STHeiti Light (which is in fact STXihei) is embeddable:

Thanks Michel, today I was able to get my hands on an iMac with OS 10.6 and found that Heiti SC Light (new font name, same family) is also embeddable and almost identical to STHeiti Light, which solved my problem.

Hi,
Thanks for those explanation.
I had the same issue: I'm using STKaiti in an Indesign document.
I chose this font because it appears as "embeddable" on my MacBook Pro (OS X) font library.
The thing is: I can't save that document in PDF with this font (I still get the message saying that font is protected)... when I'm switching to STHeiti it works though...
I don't really get why Indesign PDF export tool doesn't behave the same way with those two fonts.
Any clue?
Thanks

Even if FontBook says Kaiti is embeddable, the font file itself contains fsType equal to 0x0002 which means, according to the specification on the Microsoft site

Restricted License embedding:
Fonts that have only this bit set must not be modified, embedded or exchanged in any manner without first obtaining permission of the legal owner.

The hex value 0002 means exactly that bit 1 and only bit 1 is set. InDesign complies with what is written (without asking if you got permission).

Added: To answer completely your question, I should have added that the fsType of ST Heiti is not the same as that of ST Kaiti.

There are now many open-source and free Chinese fonts, and so using one of those would solve your problem, I would think.

Here are the fonts with fsType equal to 0x0002 on OS X 10.8 in /Library/Fonts

Full Name fsType (16 bits) (hexa)

Ayuthaya 0000 0000 0000 0010 0x0002
Krungthep 0000 0000 0000 0010 0x0002
Sathu 0000 0000 0000 0010 0x0002
Silom 0000 0000 0000 0010 0x0002
Songti SC Black 0000 0000 0000 0010 0x0002
Songti SC Bold 0000 0000 0000 0010 0x0002
Songti SC Light 0000 0000 0000 0010 0x0002
STSong 0000 0000 0000 0010 0x0002
Kaiti SC Black 0000 0000 0000 0010 0x0002
Kaiti SC Bold 0000 0000 0000 0010 0x0002
Kaiti SC Regular 0000 0000 0000 0010 0x0002
STKaiti 0000 0000 0000 0010 0x0002
STFangsong 0000 0000 0000 0010 0x0002

Err.. Do we have free-but-not-open-source Chinese fonts at all?

All that being said about the possible reasons InDesign does not embed the fonts, Microsofts' own Word 2011 embeds them all without problem (except that I had to enter 华文仿宋 to select STFangsong).

Correction: I see that I have to enter 华文楷体 to get the Chinese characters in ST Kaiti. Putting the English name to select the font does not give access to the Chinese characters in Word; the other fonts fail the same way; I have not checked if selecting something other than the English name solves the problem for those other fonts.

I had to deactivate the font SimSun in the folder /Library/Fonts/Microsoft; it was causing a name clash with Songti. Now I have that Word embeds all four Songti SC fonts, all three Kaiti SC fonts, using their English names, as well as STSong, STKaiti and STFangsong, but I had to use the Chinese name to get them. On the left is the name chosen in the fonts menu, on the right the Chinese (PRC) fullname written in that font, and the translation when the English name was giving problem

That is a grab of the pdf produced by Word 2011 for Macintosh. Here are the last three names for those that may need them for a copy-paste.

   华文宋体   (STSong)
   华文仿宋   (STFangsong)
   华文楷体   (STKaiti)