610 reputation
415
bio website
location
age
visits member for 2 years, 10 months
seen Nov 28 at 9:34

Nov
24
awarded  Notable Question
Sep
9
comment TIFFReadDirectory warning: unknown field
[output from preceding command; \n denotes a newline] STDOUT: Compression: None \n Compression: JPEG \n STDERR: identify.im6: Unknown field with tag 37553 (0x92b1) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768. \n identify.im6: Unknown field with tag 37554 (0x92b2) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768. \n
Sep
9
comment TIFFReadDirectory warning: unknown field
Thanks for your explanation. I think the problem might relate to the fact that TIFF container consists of two images, one is 2048x2048 and contains the full-resolution image; the other is, I suppose for thumbnail display by file browsers, and consists of a 62x62 low-resolution version of the same image. I believe the layers have different compressions, layer 1 being uncompressed and layer 2 being compressed with JPEG. This is shown by running the following command (the output of which is shown in the succeeding comment). $identify -verbose temp.tif | grep -i compression [output follows]
Sep
9
comment TIFFReadDirectory warning: unknown field
@Anthon: The images come from a Spot digital camera. Do you think that the feh-related problem I described might be unrelated to the errors about the unrecognized tag?
Sep
9
comment TIFFReadDirectory warning: unknown field
@VolkerSiegel: That's a good idea. I will have to look into tag stripping.
Sep
9
comment TIFFReadDirectory warning: unknown field
Thanks. So it sounds like TIFFReader might only be able to interpret official tiff tags, and throws an error whenever it encounters private or custom tags. I wonder why this causes dysfunctionality with the viewer (feh) that depends on the TIFFReader library.
Sep
9
asked TIFFReadDirectory warning: unknown field
Sep
9
comment feh: maintain zoom setting
Thank you. I notice that this works well for certain image formats (e.g., png, jpeg) but not for tif files. In this case, the image displays, but the viewport settings change each time a new image is loaded (along with printing to standard error of the message: "TIFFReadDirectory: Warning, Unknown field with tag 37553 (0x92b1) encountered.").
Sep
9
accepted feh: maintain zoom setting
Sep
9
asked feh: maintain zoom setting
Sep
4
comment support for utf-8 encoding with lpr
Thanks. I already have the latest version of HPLIP on my system. I tried to find where one can specify this in http://localhost:631 but I could not find anything about driver selection.
Aug
28
revised lpr ignores options specified by -o
expanded scope of problem from `-o prettyprint` to `-o *`
Aug
28
comment How to install some packages from “unstable” Debian on a computer running “stable” Debian?
The apt.conf files seems to no longer exist in Debian testing (wiki.debian.org/AptConf), its role apparently having been assumed by /etc/apt/apt.conf.d/70debconf. If this is correct, perhaps the answer should be amended to indicate this release-dependence?
Aug
28
asked lpr ignores options specified by -o
Aug
28
awarded  Nice Question
Aug
27
comment support for utf-8 encoding with lpr
Thanks very much for your reply. I'm aware of paps and wanted to know if there was a possibility of native support within CUPS so that external dependencies needn't be invoked.
Aug
27
comment support for utf-8 encoding with lpr
@Netch: Thanks for pointing out the a2ps filter. I was not aware of it. The printer in question is an HP4650 scanning laser printer. How can one determine the encoding used by CUPS? The characters actually printed, which bear no discernible relation to the input, included a Greek capital gamma, a capital C with a cedilla, an o with a circumflex, and a Latin capital W and T. Beyond this the failure to respect newline characters results in truncation of output at the paper margin.
Aug
26
awarded  Critic
Aug
26
comment openbox window positioning
Thanks, the placement options are what I needed for both questions. As far as conky goes, I want maximized applications to be able to hide it (so I can take advantage of the entire screen when desired), but when new windows are opened, I would prefer that they don't obscure the conky window by default. It seems that the center option in the placement settings of the openbox rc.xml file is the key here. So far as I can currently tell, it only accepts yes/no values, but if one could set it more quantitatively (e.g., 10% in from top left corner), that would be most useful.
Aug
24
asked openbox window positioning