Hacker News new | past | comments | ask | show | jobs | submit login

I think you are seeing different problems here than I was complaining about. Maybe I can restate the case: Baseline PDF 1.0 is something like (but not exactly) rendering to print to a specific PostScript printer that understands embedded PostScript fonts, somewhat like but not exactly like virtual version of an early Apple LaserWriter. PDF has been extended over the versions and included extensions and upgrades over the years and now that target "printer" that PDF represents has upgraded and also understands Unicode in its PostScript and also understands embedded OpenType fonts (and their many extensions of character mapping and ligatures and contextual alternates, etc). But because its legacy was a dumber printer for the easiest "backwards compatibility" a lot of PDF rendering apps still do dumb things like encode ligatures "by hand" in quaint encodings like some of the extended ASCII code pages or the pre-combined Unicode forms that today we consider obsolete as if they were printing to a PostScript printer that doesn't understand ligatures directly because it is still only capable of printing older PostScript fonts.

Yes, if you don't embed your fonts (or at least their metrics) in the PDF layout is less deterministic and will shift from font to font. The point is that we can embed modern fonts in PDF, the virtual printer has upgraded support for that, but for all sorts of reasons some of the tools that build PDF are still acting like they are "printing" to the lowest common denominator and using legacy EBCDIC ligature encodings in 2024. (Fun fact: Unicode's embeddings of the ligatures are somewhat closer to some classic EBCDIC report printing code pages than Extended ASCII's equivalents because there was a larger backwards compatibility gulf there.)




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

Search: