okay. according to #fontface, OpenType PS does NOT have subpixel rendering when converted and used on Windows platforms. Crap Factor = 9. my question is, since it's cakey-pants to convert OpenType PS to OpenType TT, what happens to subpixel rendering? i've tried using some online converters and see ZERO difference: fonts look like crap.
so the question is HOW can i convert an OpenType PS file to an OpenType TT file WITH subpixel rendering coming along for the ride?
because once i have an OpenType TT file, i can get to EOT easily.
thanks!
WR!
okay. here's what i've figured out and it works. but, i can't verify that it'll work with the freeware FontStudio, but it should. i just didn't feel like installing cygwin to verify that it would for sure... meh.
i use FontLab Studio, but any font authoring tool should do the job. Simply open the PS version of the font. convert the PS paths to TT paths. this may take a minute or two, depending on font complexity. Once it's complete, generate a new TrueType font. convert this to EOT and you're away to the races.
TWO important notes:
1) if you are using an IDE like Dreamweaver or Aptana, the preview will NOT show the new subpixel rendering you just enabled. but it does show up where it matters: in the browser.
2) Mac users may not see this problem and be aware of it because the Mac type engine handles OpenType PS files differently. hopefully this will help them out.
bottom line, if you're going to be converting to EOT, start with a TrueType font. as great as OpenType PS is for layout & print, it explodes the brain when used for web layout.
hope this is useful to the community.
WR!
Related
A few weeks ago, our users pointed out that some large OCRed PDF (ABBYY generated) loads extremely slowly and asked us to do some optimisation on it.
After some investigation, the problem seems to be caused by the complex text embedded within the PDF. I tried different scripts to optimise the PDFs, such as ghostscript, qpdf, etc...
The only one I found did make a significant improvement was to use pdftops (from poppler) with the -passfonts option and convert it back to PDF with ghostscript ps2pdf: pdftops -passfonts intput.pdf output.ps && ps2pdf output.ps output.pdf.
However, the problem is I have no idea how -passfonts can make PDF loads faster and whether it is making a side effect that I am not aware of...
So can PDF gurus shed some lights on the reason/logic behinds this optimisation?
Thank you all in advance!!
Jeffrey
from http://linux.die.net/man/1/pdftops
-passfonts
By default, references to non-embedded 8-bit fonts in the PDF file are substituted with the closest "Helvetica", "Times-Roman", or "Courier" font. This option passes references to non-embedded fonts through to the PostScript file
When the file opens, the reader will look on the system for the non-embedded fonts, and load them when it finds them. The more non-embedded fonts there are, the more checks it has to make. Sometime fonts are not embedded for legal reasons, sometimes they are not embedded because they make the file size go out of proportion, and various other reasons. By substituting the non-embedded fonts with a more common font, I'd say you are forcing the PDF to load a smaller number of fonts, and possibly forcing the PDF to use fonts that have a smaller memory foot print leading to a faster load time.
Compare the fonts list before and after. Maybe that will shed more light.
If you open the document in Adobe Acrobat:
File -> Properties -> Fonts
Be cautious with font substitution! It may completely ruin the look and feel of a document.
I'm generating PDFs. One font in particular - Helvetica Neue Light - renders particularly poorly when the PDF is viewed on a Mac, thanks to subpixel antialiasing.
I want to disable subpixel antialiasing in the PDF. (Not in the PDF viewer.) The equivalent in CSS is -webkit-font-smoothing: antialiased.
Bad:
Good:
Is this possible?
No.
Somewhat longer answer? :)
Antialiasing is a device specific optimisation (anti-aliasing would be done differently on a printing device (if at all), on a monitor and on an LCD monitor for example).
PDF is by design a device agnostic file format and as such it stays away (tries to stay away) from device specific constructs. Anti-aliasing settings are by definition preferences from the viewer and cannot be influenced by the PDF file itself.
The result you're showing is quite different indeed - you're sure the font is accurately embedded in the PDF file (and is of decent quality)? It would also be worthwhile to look a bit further at the "On a Mac" statement. I'm assuming you're saying it looks bad in "Preview" on a Mac; in that case it's be interesting to see how it performs in Preview versus Adobe Acrobat. That could tell you whether it's a font issue or an application issue.
I have a PDF which renders fine in Acrobat but fails to print during the PDF to PS conversion process on our printer's RIP. After uncompressing with pdftk and editing I've found if I replace the usage of a certain font it will print.
The font is a strange one, a TrueType subset with a single character (space).
If I pass the PDF through Ghostscript it reports no errors, however an Acrobat pre-flight check will report a missing glyph for space. This error is not reported for the original file. I'm just using a basic command: gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -o gs.pdf original_sample.pdf
I've pulled out the font data from the original PDF and saved it. Running TTFDUMP.exe produces an interesting result where it seems that the 'glyf' table is missing:
4. 'glyf' - chksm = 0x00000000, off = 0x00000979, len = 0
5. 'head' - chksm = 0xE463EA67, off = 0x00000979, len = 54
Just wondering, am I interpreting this result correctly? Is it valid to run TTFDUMP like this on extracted data from a PDF? I think a 'glyf' table is required based on the spec, at least for the first 4 necessary characters.
TTFDUMP run on the ghostscript PDF produces a similar result but with a 1-byte 'glyf' table.
If so it seems that Acrobat doesn't particularly care about the missing space while other programs (including the printer) do. It's odd it isn't reported as missing though until it runs through Ghostscript.
The PDF is created by Adobe InDesign and the font is copyrighted like most so I can't share it.
Edit - I've accepted Ken's answer as he helped me on the Ghostscript bug tracker. In summary, it seems the font is broken as suspected due to the missing glyf table. Until I hear otherwise I'll have to suppose this is a bug in InDesign, and will continue investigating.
Yes you can run ttfdump on an embedded subset font, its still a perfectly valid font.
A missing glyph is not specifically a problem, because the .notdef glyph is used instead, a missing .notdef means a font isn't legal.
I think you are mistaken about the legality of sharing the PDF file (from the point of view of font embedding). Practically every PDF file you see will contain copyright fonts, but these are permitted to be embedded and distributed as part of a PDF (or indeed PostScript) file. TrueType fonts contain flags which control the DRM of the font, and which can deny embedding in in PDF (or other formats). Ghostscript honours these embedding flags in the font as does Acrobat Distiller and other Adobe products.
There were some fonts which inadvertently shipped with DRM which prevented embedding, and there's a list somewhere of these, along with an explicit statement from the font foundry that its permissible to embed these fonts. I think this was somewhere on the Adobe web site a few years back.
So if you have a PDF file with the font embedded in it (especially if it was produced by an Adobe application) then I would be comfortable that its legal to share.
I'm having some trouble figuring out what the problem actually is, and how you are using Ghostscript. If you are running the PDF->PS and then back to PDF then all bets are off frankly. Round-tripping files will often provoke problems.
In any event I'm happy to look at the file but you will have to make it available.
I'm using a CC-BY FontAwesome typeface for icons on my Twitter Bootstrap-driven website. Now I want to use it in an image editor for a prototype of another website. But it does not work. I cannot use its webfont-TTF with my image editing application. How can I convert it to a normal font?
Please dont give me links to free-/shareware closed-source utilites. I want to know, why does this happening and implement my own script which would "fix" this font.
FontAwesome should work out of the box. Heres how to use it:
Download FontAwesome. Then open fonts/FontAwesome.otf and install it (either with fontbook on osx or by adding it to your fonts folder on windows).
Use the Cheatsheet to actually use specific icons. Find the icon you want there, select the icon and copy it.
Switch to your image editor, create a text item, set the font to FontAwesome, and paste the symbol you copied.
I assume you are talking about http://fontawesome.io/ .
If so there is nothing wrong with the TTF version of this font and no reason to convert it. I have tested the font on linux by dropping the .ttf file in /usr/share/fonts/ and it is useable in LibreOffice, Gimp and Terminal.
You problem is almost certainly one of:
The process you used to install the font
You aren't entering the correct Unicode characters or your image editor doesn't support Unicode.
However you failed to provide enough details. You haven't even defined what you mean by "it does not work". Please update your question with details like the process you used, a link to the actual font you downloaded and the operating system and image editor you're using.
In case you're still looking for a solution: the easy way is to convert the included SVG font to usable TrueType or OpenType, using e.g. FontForge or an online service.
AFAIK SVG fonts have no DRM flags, unlike TrueType.
Well basically I'm finishing school in mid December so I'm just brushing up my resume and I'm wondering if there's a way to use custom fonts (in this case Calibri and Cambria) in a PDF file and make them render correctly on all computers.
Thanks in advance!
EDIT: I'm using MS Word 2007, but am open to suggestions
PDFs don't store text and fonts like other documents, they actually convert the font to vectors, that way no matter what font you use, the document displays exactly as expected. This is why searching for text inside the PDF is such a problem for 3rd party PDF Readers and why even Adobe themselves use to distribute 2 versions of Acrobat (one with text search, one without).
Another thing to keep in mind is, PDF isn't pixel exact, it's ratio exact. PDF readers generally do not use a 100% zoom level, instead most people read them at "fit to screen" or "fit to page". I point this out because I'm guessing the reason you are trying to use those new Vista/Office 2007 fonts is because of their LCD subpixel support (improves readability on LCD screens). This feature will not translate into the PDF, since the letter becomes a vector, subpixel information is lost, and even if it wasn't, becomes useless because the vector will be sized to something other than you intended at view time.
The PDF format is capable of embedding fonts, if the font has been marked embeddable by its creator. You'll have to check the software that's creating your PDF to see if it has the capability and how to enable it.
theoretically speaking, on technical side, embedding/not embedding ability, regarding the fonts, is settled with a special flag in font file (ttf or opentype or type1)
you can view this special embedding flag with any font editor program (I recommend
FontCreator (by High-logic)
http://www.high-logic.com/font-editor/fontcreator.html
with a free trial fully operative and without limitations
you can also change embedding/not embedding flag, but legally speaking, for the 99% of fonts commercially distributed, this breaks the license of font