1. pdfwrite must identically pass source colors to the
output PDF, i.e. without a conversion to any output color
model. Otherwise some color information may be lost.
For example if the source color space is CMYK and the
output color model is RGB, pdfwrite looses the
information about the specific BlackGeneration method
applied. Vise versa, if the source color space is RGB
and the output color model is CMYK, for producing a
correct result the viewer (rendering to an emission
device) must be compatible with the BlackGeneration
method used with pdfwrite. Perhaps it has no
information about it, and therefore it can disturb colors.
Currently images are not converted to the output color
model, but other colors are. This is an inconsistency.
Ideally all colors must not be converted. This requires
multiple changes to device interface about passing the
information about source color spaces and source
2. The passing of halftones and patterns in a vector
form. Currently they are converted to rasters, and
therefore loose an information. They must not. This
requires enhancements to device interface.
3. Unusual fonts in a vector form. pdfwrite writes a vector
representation only for fonts which use Type 1, 2 or True
Type glyphs. Other fonts are being converted to bitmap
fonts. A better way is to make a Type 3 font with a
vector representation, i.e. BuildChar should identically
pass paths, bitmaps and other objects.
Thanks to Peter L. Deutsch for pointing these issues.
Log in to post a comment.