Pre-press (was Re: Adobe ditching Type 1 fonts)

Don Hosek don.hosek at gmail.com
Thu Sep 22 18:40:47 CEST 2022


It’s a long time since I’ve had to manage printing and the technologies have shifted dramatically in those 20+ years, but prepress these days is pretty much exclusively based on a PDF workflow. In the olden days, I would provide monochrome PDFs to a service bureau to get film which I’d ship to the printer and I was responsible for all color separation/management. There were a lot of potential traps in those old workflows—it was not uncommon for a tyro designer to inadvertently spec a file with some large number of spot colors that would color separate out into, say 15 press runs for each color instead of being correctly indicated as CMYK mixes. These days, a lot of short press runs (<1000 copies) will be done with direct digital imaging onto the press right out of a provided PDF file.

That said, TeX’s idiosyncratic font management has been a growing time bomb since (at least) the 90s. pdf(La)TeX wanting to pull in type 1 (and bitmaps) out of its own installation rather than using fonts installed via standard system mechanisms make it an outlier in many ways, not least of which is the fact that you end up with mutually exclusive islands of TeX fonts and everything else fonts. At least the XeTeX and LuaTeX engines can use system-installed fonts, which really should be the standard for any application in 2022.

-dh

> On Sep 22, 2022, at 10:17 AM, karl at aspodata.se wrote:
> 
> Paulo Ney de Souza:
> ...
>> We will suffer more on pre-press. None of the solutions posted here are able
>> to perform pre-press on a PDF file in any meaningful way.
> ...
> 
> Isn't it possible to do pre-press with PostScript ?
> 
> Regards,
> /Karl Hammar
> 




More information about the tex-live mailing list.