Pre-press

[karl at aspodata.se]

Zdeněk Wagner:
> your file does not solve the problem at all because it does not take
> CTM into account and does not examine the the angle of the segments.
> The important point is that if you set 0 setlinewidth, the display
> postscript guarantees that the line segment will be displayed with the
> thinest possible width and 30 years old PS office printers from HP do
> the same (my PS printer died 10 years ago and spare parts are no
> longer available).

Yes, I know that I didn't care about the current tranformation matrix
in this simple example.

> The phototypesetters and digital printing machines
> do not guarantee that lines with a linewidth below a certain limit
> will be printed, they may disappear. Now imagine that you include a
> graphics while using 0.1 0.03 scale. It can thus happen that
> horizontal lines will be printed but the vertical lines disappear. If
> the graphics contains a sine curve, some segments will be missing.

Ok, I don't have experience of thoose kind of machines.
Anyhow, since the results of rendering such "zero-width" lines
are device dependent, their use is not recommended. Both PLRM2 and 3
says the same. So a user doing that is doing it on their own risk.

And, when working with things on the border of what it can accomplish
you always have to check the result.

> It
> is the same with fonts. In addition, the findfont operator does not
> inform you whether an embedded font is used or whether a system font
> is used.

No, it does not, I have to find that out in some other way.

> It is again a problem of included graphics generated by
> another tool where fonts need not be always embedded. It may look fine
> in display postscript on your computer but a CTP will replace the font
> with Courier which you certainly do not want to happen.

Well, if the font isn't on the printer and you don't sent it to the
printer in some way, isn't that the same as cutting the branch you
are sitting on ?

I think it is possible to detect missing fonts and warn the user, if
it is that problem you are reffering to.

> If you do not
> use \backgroundcolor, because you just want to have it while, and put
> an object with the alpha channel, the tgransparent area will be white
> on display postscript but black on CTP. It is therefore necessary to
> detect all transparent objects (both vectors and bitmaps) and upon
> request remove the alpha channel.

I havn't worked with this and I cannot find \backgroundcolor in PLRM,
but PLRM3 says (section 4.10.6 Masked Images):

In the graphic arts industry and page layout applications, however, it is common
to crop or “mask out” the background of an image and then place the masked im-
age on a different background, allowing the existing background to show through
the masked areas. A number of PostScript features are available for achieving
such masking effects:

Perhaps one could find a solution for this.

> LCMS for colorspace conversion can
> in theory be implemented in postscript but it is not an easy task. It
> would be easier to implement all these features in poppler and/or qpdf
> but it is not available now.
...

I havn't worked much with colour nor at the code level in poppler,
so I cannot comment much on this.

///

But all of the above is moot if people don't want to work with
postscript files.

> Med vänlig hälsning
> Zdeněk Wagner

:) unfortunately I don't know Czechoslovakian, hope some
german will suffice.

Mit freudlichen Grüßen
/Karl Hammar