Gimp is also, for now, limited to srgb, so anything coming from gimp
will work fine with cairo.
And, for a postscript printer, jpegs should be converted directly to ps,
not via pdf, so that wouldn't matter either.
But if you used a workflow which used, say, AdobeRGB as the colour
working space,
pdftocairo is limited by the fact that cairo only handles sRGB.
It is therefore unsuitable any time color is important, eg if the pdf
uses cmyk or named colors or icc profiles, et cetera.
It is fine for printing most web pages, since the browser likely also is
limited to sRGB.
And for simple
pdftops and pdftocairo are both from poppler.
pdftops is based on the original xpdf code and does not use cairo at
all.
modern cairo tries to limit the size of tranparency groups to just where
it is needed.
--
You received this bug notification because you are a member of Desktop
Packages,
The cups log shows that you configured the printer as an IPP printer.
(Or that something did so for you.)
Try configuring it as a socket printer (sending the postscript to port
9100).
You may need to use the printer’s web interface or control panel to
enable port9100 if you have disabled it.
Ah. I didn’t intially read every comment.
I suspect that the method cups now uses to discover network attached printers
is what triggers the crash/reboot.
It will ipp-query any it finds which advertise ipp capability in lieu of
requiring PPD files to specify the printer’s capabilities. That
The bug is in fontconfig.
Fontconfig added the Gyre font names to the list of suitable
replacements for the base PostScript fonts because the shapes and
metrics are compatible.
What they didn’t notice (until the bug reports started) is that the Gyre
authors use the names /f_i, /f_l, /f_f, /f_f_i
6 matches
Mail list logo