Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is the same as saying "we are removing your ability to look at jpg, use heic instead".

T1 is a perfectly fine file format with many quality fonts. It does not burden a system to have it. Support is not lost on Linux systems which use the freetype renderer.



This is about removing support from applications creating PDF files (InDesign, Acrobat, ...).

From the article:

> Keep in mind that older PDFs created with Type 1 fonts are safe—as long as their font data was embedded in the PDF when it was made. PDF readers, whether from Adobe or elsewhere, will continue to render these documents as they always have.


This is the part I don’t understand. They retain the ability to render Type 1 glyphs, but they remove the ability to load those from external font files, and/or don’t ship any “built-in” Type 1 fonts anymore?

My question is just about rendering/viewing. I understand that support is completely removed for authoring.


> are safe—as long as

This does not sound like "safe" to me.


PDF's have virtually always embedded fonts except for a small collection of core fonts like Times New Roman that are part of the PDF standard. You've got to really go out of your way not to embed, and I'm not sure which software even gives you that option at all.

Otherwise it's kind of defeating the whole purpose of a PDF which is that everybody sees the same thing. Font embedding has been with PDF from the start.

It's safe.


Not sure if this is the kind of not-embedding-fonts you're referring to, but in layout and design software you often see PDF saving options to either rasterize fonts or embed the fonts as vector curves.

I believe both Gimp and Inkscape have been able to do this for a while, for example.


This is why PDFs intended for long term use or wide distribution should always (and often do) embed nom-standard fonts (eg as in PDF/A).


My usecase is to create pdfs through the "print to pdf" menu. I kinda assumed the fonts were embeded.

I don't seem to have any options when creating pdfs to embed or not embed fonts. Is this some feature of PDF creation software?


Yes. From the top of my head the usual print to PDF behaviour is to embed the relevant subsets of any font other than the fourteen core ones given in the PDF standard.


The default is to mostly embed, except for a number of standard fonts.

You can list the embedded fonts using standard tools. The pdffonts binary is pretty universal, as part of the Poppler set of tools.


And a fair number of old Adobe, Apple, and BeOS technical docs lack embedded fonts for some reason.


Can you send a link to an example? Which fonts were they using that weren't embedded?

Never in my life have I come across a PDF intended for public distribution missing an embedded font. (The sole exception being the PDF standard fonts like Times New Roman that are never embedded.)


I remember an Adobe presentation[1] tried to walk back the "14 standard fonts" thing as being an Acrobat "convenience" feature rather than a PDF standard feature, probably because it doesn't look good to attempt to standardize a (format unimplementable without a) set of fonts you're unwilling or unable to let people freely redistribute. (But then that presentation also promised the nascent ISO PDF standard would always stay accessible free of charge, and we know how that turned out.) Certainly PDF/A does not permit you to omit them, though that's only one specific kind of PDF.

In any case, sure, here you go:

- The Be Book[2] for DR8 uses but does not embed AvantGarde-* fonts.

- Inside Macintosh: Interapplication Communication[3] uses but does not embed Palatino-* fonts (for this one I could be convinced it's because the uploader merged the original per-chapter PDFs[4] incorrectly, though).

- The Mac OS 8 Human Interface Guidelines[5] also have the Palatino problem (and look legit, even though other Apple HIGs from that era do embed their fonts).

- Even the bloody spec[6] for PDF 1.3 uses and does not embed Caecilia-Heavy and MyriadMM_565_600_, whatever those are.

[1] https://www.youtube.com/watch?v=poc9PVmFzpc

[2] http://bebits.irixnet.org/be/docs/DR8/BeBook/acrobat/05_Medi... and others in that directory (1996 metadata)

[3] https://vintageapple.org/inside_r/pdf/Interapplication_Comm_... (1993 copyright, 2014 metadata)

[4] https://thrysoee.dk/InsideMacintoshInterapplicationCommunica...

[5] http://interface.free.fr/Archives/Apple_HIGOS8_Guidelines.pd... (1997 metadata)

[6] https://web.archive.org/web/20101214132912/http://partners.a... (2000 metadata)


Thanks!

I took a look at a few of these, and some of them are maybe just strange bugs.

E.g. the Adobe PDF spec embeds almost everything including most versions of Myriad, just not those two you mention. Similarly the Apple Guidelines embed Palatino Roman and Standard (as TrueType), just not Bold (as Type 1).

The Media Kit one does just not embed anything though (no Avant Garde), so that's clearly intentional.

It does make me wonder if technical documentation intended for a specific platform would sometimes try to save space by not embedding fonts standard not to PDF but to the platform. E.g. Avant Garde has shipped with Macs for a very long time. Still, what a terrible idea.

But fascinating to see documents with these problems in the wild, first time I've ever come across it. Thanks for taking the time!


As another data point, I've run into a variety of old DEC VMS documentation prominently featuring non-embedded New Century Schoolbook, e.g.,

http://www.vaxhaven.com/images/a/a7/AA-PS6KA-TE.pdf

It's probably not a coincidence that New Century Schoolbook was one of the fonts included with all PostScript Level 2 printers, but not included with older PostScript printers or Acrobat.

Note that the documentation in question was originally distributed as PostScript .ps files, not PDF, and it indeed makes no sense to embed New Century Schoolbook in a Level 2 or higher PostScript file, for both practical and likely legal reasons.


Per a handy diagram in MacWorld's review[1] of the original release of Myriad as one of the first multiple-master[2] Type 1 fonts, "MyriadMM_565_600_" is a semibold, regular-width instance.

Myriad Pro Semibold and Myriad Variable Concept Semibold should both be very close matches.

Myriad Variable Concept is bundled with the current version of Adobe Illustrator (and possibly with other Adobe apps not currently installed on my system); Myriad Pro was bundled with most (all?) versions of the pre-cloud Adobe Creative Suite, and has the benefit of being a traditional, non-variable OpenType font that should work pretty much everywhere.

This suggests an interesting question: are tools available to faithfully convert multiple-master Type 1 fonts to variable OpenType format?

"Caecilia-Heavy" is PMN Caecilia 85 Heavy; Caecilia LT Std 85 Heavy, a currently-available OpenType font, is presumably a close match.

Both Myriad Pro and Caecilia LT Std 85 Heavy are included in Adobe Font Folio 11 and, um, maybe available for activation via Creative Cloud, but this is not immediately clear from Adobe's Web site, and I'm having problems launching the damn CC app to check.

Of the many Adobe products I happened to have licensed before discontinuation in favor of a subscription-only replacement, Font Folio is probably my favorite. And, unlike older Adobe applications, it's still 100% compatible with every modern OS, and likely to remain so in perpetuity.

Or at least until OpenType is deprecated in favor of some dystopian online-only replacement…

[1] https://archive.org/details/MacWorld_9207_July_1992/page/n19...

[2] https://en.wikipedia.org/wiki/Multiple_master_fonts


Back then it could have been due to file size?


Coupled with the lack of builtin compression in contemporary PDF versions (and a strange but widespread aversion to gzipped pdf), perhaps, but then there shouldn’t be anything special about those particular companies. Maybe there isn’t, though, maybe that’s just where I come across mid-to-late-90s PDFs.


If the document was intended for distribution, it is likely that any non-embedded fonts are going to be common system fonts that will either have direct replacements or compatible replacements. Of course all bets are off, if someone created a document for personal use, to share with family/friends, or simply didn't know what they were doing.


Unless I'm missing something, if the fonts aren't embedded in the first place then it shouldn't make any difference. The text should be encoded properly so that it can render now without the fonts (in which case we know which glyphs to use), the same will be true later.


From what I understand, currently, if the font (actually: the parts of it needed to render the PDF) isn’t embedded, but you have the font installed, the renderer will use that font, an you’ll see the document as intended.

When support is removed, the renderer will look for/guess at the best replacement you have installed. As the article says, that may have subtle or not so subtle differences.

I don’t think it will be that bad, though. If you care, I think you’ll already have embedded fonts in your PDFs for decades, even for fonts that ‘everybody’ already has, because the probability that ‘my Font’ is exactly the same font as ‘your Font’ is fairly slim.


As you say, I feel like it probably doesn't really matter that much. If you're relying on a PDF rendering correctly based on an unusual local font then you're in trouble as soon as you send the document to another machine. If you have the Type1 font locally, you could always convert it.

You could have a situation where your font has really weird cmaps and without that specific font the text becomes garbled. More likely, you can substitute it for another font and it's mostly fine.

Keep in mind that the PDF standard has 14 base fonts that are used for a lot of documents that people send about. https://appligent.com/what-are-the-base-14-fonts/


I don't have a dog in this fight, but this sounds to me like an optimistic view of people and their behaviour.


Your typical “save as PDF” will embed fonts nowadays.

I think only professional (typically commercial, costing serious money) PDF writers have had a flag to NOT embed fonts in PDFs for decades.


> It does not burden a system to have it.

any file format you support poses a significant attack surface, especially an old and creaky one whose parser you've written in the 90ies and ever touched.


> any file format you support poses a significant attack surface,

and yet the trend is to use more and more libraries, sometimes from dubious sources and sometimes (hello npm) with malware.


> It does not burden a system to have it.

Any and all software is a burden.


There’s no code better than no code.


Some is a negligible burden, or a net unburdening because it replaces something else that was a bigger problem


Any old code is burden by definition.

You can still use old versions of Adobe software. (I… guess? I am not sure how do the Adobe Creative Cloud licensing shenanigans work nowadays, I haven’t used Adobe suite for ages)


Actually it’s the same as “removing support for XBM because nobody uses it anymore”.

Would you not make completely out of scale comparisons just to be contrarian on HN? Please?


How many xbm files were used to store archival copies of documents?

Adobe Reader has always been terrible; I’ll happily continue to avoid Adobe software whenever possible.

However, I hope this doesn’t lead to other PDF software ending support for Type 1 fonts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: