[Pkg-cups-devel] Bug#501719: Bug#501719: cups-pdf: doesn't play well with NetWare shares

[Martin-Éric Racine]

On Mon, Oct 27, 2008 at 7:56 PM, Luca Capello <luca at pca.it> 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