Embedded Fonts Render Then Disappear

This is Ben from Typekit. I believe this is being caused by a bug in Chrome.

Here is the issue report, if you would like to subscribe to updates or leave a comment:
https://code.google.com/p/chromium/issues/detail?id=236298

Because this is an issue with Chrome, there doesn't appear to be anything we can do on our side. The good news is it's been fixed. The not so good news is that the next stable release will be out in February. We're keeping an eye on this and will make sure it's resolved when Chrome is updated.

Feel free to drop us a line at: support@typekit.com with any specific questions.

Cheers,
Ben

Why are my embedded fonts rendering improperly?

I think I figured this out. adding these rules to my stylesheet seemed to fix it:

body, body * {
  background-color: #fff;
  -webkit-font-smoothing: subpixel-antialiased;
}

Just setting subpixel-antialiased didn't work, and just adding a background color to the body didn't work. This could probably be simplified to select just * or html *. Also, given that subpixel-antialiased is the default, removing that rule should work as well.

Disappearing characters in cairo font rendering

i removed cairo support - the problem is not longer relevant.

SDL2 TTF text renders randomly disappearing

Its because you keep loading more textures and surfaces without freeing them. You only need to load them once. Put your buffer setup before the loop, also check the memory usage when its running im almost certain its gonna be rising alot

Pdf embedded fonts ignored by pdftops

There's a problem with your file Bergamo Std-embeded.pdf. Embedded font is marked as "Type1C" (Type1 Compact, or CFF) in FontDescriptor > FontFile3 > Subtype entry of font dictionary. And it's reported as such by e.g. pdffonts (poppler-utils) or mutool (of MuPDF). But in reality, it's embedded unchanged in original OpenType format. You can extract it from PDF with e.g. mutool and compare with BergamoStd-Regular.otf - same files.

What C#/iText should have done (or you, if it's developer responsibility with this library) is either explicitly mark Subtype of embedded FontFile as OpenType (PDF 1.6 feature), or convert BergamoStd-Regular.otf to pfb (or further to cff, maybe - if everything is controlled manually) before embedding.

I changed "Type1C" string to "OpenType" in your Bergamo Std-embeded.pdf (using Enfocus PDF Browser, but PoDoFo or PDFEdit should do the job, too), and then pdftops created correct (i.e. font embedded) postscript from fixed pdf. I think (but didn't check) that converting otf file to cff and embedding it in-place will also fix original pdf.

It looks like all utilities you mentioned are very permissive regarding minor PDF syntax violation, but pdftops is not.

gs 9.22 on Linux doesn't render embedded fonts in pdf generated on Mac

Ghostscript 9.22 built from the tagged release source (available at the bottom of the table here currently) on Fedora 23, renders the file as expected for me.

So it seems likely that its not 'gs9.22 on Linux' its 'the build of Ghostscript 9.22 on my flavour of Linux, compiled by the package maintainer on the Linux distribution I'm using' which is most probably at fault.

There could be many reasons for this. Firstly the various distributions apply their own patches to the Ghostscript source tree. Secondly, the packagers insist on using system shared libraries, instead of the 3rd party library sources shipped with the Ghostscript source. We, the Ghostscript development team, know those work, because that's what we test. We can't test every possible version (and patch) of all the system libraries shipped with every flavour of Linux and you may have hit some kind of incompatbility (most likely with FreeType since its fonts).

Note that what you are seeing there are not 'missing font blocks' but missing glyphs. That's the /.notdef glyph which is used to render in place of a glyph when that glyph is not present in the font. You haven't given the back channel output from Ghostscript when rendering the file, if the fonts were missing then there would be some warnings about that.

I would suggest that you fetch the Ghostscript source, either the tarball from the link above, or use Git and get the latest sources. Build it yourself (you will need gcc, make and autotools installed) and test that. If that doesn't work, then please file a bug report here Please be sure to describe how you built Ghostscript, specify the command line you used, and attach the offending file to the bug report.

There is a pre-built Linux binary at the same location, and you could try that, but there's a reasonable chance that it simply won't work on your Linux.

By the way, having the fonts available on your system won't help at all, because the fonts in the PDF file have been subset and re-encoded. There's essentially no way to use the system fonts to replace the ones embedded in the PDF file, the interpreter must use the embedded fonts.

Embedded fonts in external SWF conflict

The problem was, as3 doesn't like to register fonts on different domains. So I passed an instance of the parent "ApplicationDomain" to the child swf and the child swf registered fonts to this instance.

Embedded Fonts Render Then Disappear