GNOME Bugzilla – Bug 382234
libjpeg?
Last modified: 2007-06-24 17:42:29 UTC
The manual currently says: Image Viewer has special support for digital camera pictures and displays EXIF metadata recorded with the image. This feature requires libexif to be installed on your system. If libjpeg is also available all JPEG image modifications are lossless. That is, saving rotated and flipped JPEG images will not recompress the image. Beside this all available metadata (like EXIF) will be preserved and updated according Is libjpeg a part of Gnome? If so, we don't need to mention it. If not, mention of it should be somewhere other than the introduction. Users don't need to be told about things they need to install in a short description of features.
No, neither libexif nor libjpeg are a part of GNOME. Theoretically we could avoid mentioning libjpeg, since it is as far as I know required by gdk-pixbuf (when the JPEG loader is enabled). Which means that if you don't have libjpeg, you won't have JPEG in EOG. We only need to have direct library access for doing lossless JPEG operations (we should keep a note what these are), which is why it is checked for during compile time. Furthermore, I think most (all?) distros automatically pull it in as a dependency for gtk+. But I am not sure what to do with libexif.
(In reply to comment #0) > The manual currently says: > > Image Viewer has special support for digital camera pictures and > displays EXIF metadata recorded with the image. This feature > requires libexif to be > installed on your system. If libjpeg is also available all JPEG > image modifications are lossless. That is, saving rotated and > flipped JPEG images will not recompress the image. Beside this all > available metadata (like EXIF) will be preserved and updated > according > > Is libjpeg a part of Gnome? > If so, we don't need to mention it. > If not, mention of it should be somewhere other than the introduction. Users > don't need to be told about things they need to install in a short description > of features. YEs, I think we could provide *just* the feature overview without mentioning the technical dependencies. On the other hand, if the user don't have the needed dependencies and consequently the respective features, he|she can get confused. Maybe some footnote/sidenote telling that some external dependencies should be filled to have those features available? Well, IMHO this is something that you (doc team) might have a better idea than us developers. :-)
This is not a problem that I can fix in the documentation. If I say: 'EOG might have this feature', then the manual is of poor quality. Documentation should reflect what the user has in front of them in the application, not be vague and indefinite. If I say: 'To get this feature, install libfoo'... then what? I can't tell the user how to do that, because I don't know what sort of package management they have, and I can't link to another help document explaining it because it doesn't exist as part of Gnome. So we're left with a manual that doesn't fully help, and uses arcane technical terms when we want to be simple & user-friendly. What does stock Gnome provide? Is it the same as our most common distros (Ubuntu, for example)? Otherwise, solutions include: - ensuring this feature is always available - killing all distros except Ubuntu - creating a standard Gnome distro
I think, that if most of the distros provide libjpeg as a dependence for gdk-pixbuf, then we could say "In a XYZ system, EOG is able to...", where XYZ \in {complete, standard, sane, ...}. Or, simply assume everyone has libjpeg. If only a minority doesn't include it, then only that minority would be affected. A much better solution, but I don't know if possible, is to generate that part of the documentation during configure time. If libjpeg is available, include the paragraph in question, otherwise, don't include it. Is that possible with our documentation system?
Hei, > I think, that if most of the distros provide libjpeg as a dependence for > gdk-pixbuf, then we could say "In a XYZ system, EOG is able to...", where XYZ > \in {complete, standard, sane, ...}. Hmm, not good. Add useless information (from the user POV) to the text. > Or, simply assume everyone has libjpeg. If only a minority doesn't include it, > then only that minority would be affected. I'd stay with this one. IMHO, it's not relevant (in the jpeg case) to explain the technicalities as in most of the cases libjpeg is present. > A much better solution, but I don't know if possible, is to generate that part > of the documentation during configure time. If libjpeg is available, include > the paragraph in question, otherwise, don't include it. Is that possible with > our documentation system? I think we can handle this simply with a good text. :-) Joachim, any feedback about it?
Ok, I replaced this... "If libjpeg is also available all JPEG image modifications are lossless" With this... "All modifications made in JPEG images are lossless"