On Mon, Aug 6, 2012 at 10:25 AM, Norbert Preining <preining@logic.at> wrote:
> Hi Reinhard,
>
> thanks for your answers
>
> On Mo, 06 Aug 2012, Reinhard Tartler wrote:
>> > Unfortunately, xdg-open, at least under gnome, is non-blocking, i.e.,
>> > immediately returns (in fact it is the underlying gvfs-open that
>> > returns immediately), which makes it impossible to use texdoc
>> > for searching and viewing compressed docs.
>>
>> That sounds like an easy-to-implement extension in xdg-open.
>
> Unfortunately not. Since it calls gvfs-open it is the fault of
> gvfs-open in this case. In other cases it calls evince, which is
> blocking.
>
> It depends on the program xdg-open chooses, whether it is blocking
> or not. So that is something that cannot be easily fixed in xdg-open.
Quick research reveals:
https://bugzilla.redhat.com/show_bug.cgi?id=571932
which points to
https://bugzilla.gnome.org/show_bug.cgi?id=652262
The proposed solutions do not indicate that the problem was unfixable...
>
>> > I see several options here:
>> > * forget about compressed documentation
>> > PDF since format 1.4 has internal compression, meaning that
>> > the other compression does not win a lot at all
>> > We could advise packagers to use dh_compress -X.pdf
>>
>> I'm not sure, but wouldn't it be better to change dh_compress to do
>> the right thing and use the pdf format internal compression instead of
>> running gzip?
>
> THat is not something dh_compress can do, that is pdf creation time.
> I guess there *might* be a way to recompress pdfs, but that is dangerous
> at least I guess.
Well, lossy compression (such as done by imagemagick's convert tool or
ghostscript) may or may not be "dangerous", however, lossless
compression (such as done by pdftk or qpdf) should do fine. But I do
not claim particular PDF expertise, so maybe others can comment.
--
regards,
Reinhard