On Mon, Oct 27, 2008 at 7:56 PM, Luca Capello <[email protected]> wrote: > On Mon, 20 Oct 2008 08:33:20 +0200, Martin-Éric Racine wrote: >>> 2) CUPS-PDF not catching all the Ghostscript errors [2] >> >> Nor should it. A Ghostscript error doesn't imply failure to print. It >> could be e.g. failure to embed certain fonts, etc. > > A failure to embed certain fonts *is* an error, since the resulting PDF > is not what I was expecting. However, frankly speaking, I already > expressed my opinions, thus I'll stop to reiterate them.
It is not an error. Several fonts explicitly have a bit set in their metadata to prevent embedding. Some software, such as OpenOffice, respect this bit and will transparently substitute with another font from the same family style. >> When used with a normal system user it creates the directory and sets >> ownership, if it's absent. > > And indeed my remark was about the particular situation when the output > directory already exists: if, even in this case, CUPS-PDF would set > ownership, then I'd have discovered this bug before [3]. That can probably be implemented. However, there is a gotcha: By default, we create the directory to a very restrictive permission so that only the user itself can read the content. However, we respect the fact that someone might afterwards decide to change those permission and issue a "chmod -R a+rX ~/PDF" which is why we don't interfere with permissions after the initial directory creation. Thus, there _could_ be a configuration option to determine whether CUPS-PDF will reset the permissions of the output directory at every printout action, separate from the configuration option for the permissions it will use upon creation. Volker: what do you think of this suggestion? Does it make sense to you? Martin-Éric
