summaryrefslogtreecommitdiff
path: root/test/scr/feh_lwi_scroll_rd
diff options
context:
space:
mode:
authorDaniel Friesel <derf@finalrewind.org>2021-12-24 11:58:34 +0100
committerDaniel Friesel <derf@finalrewind.org>2021-12-24 11:58:34 +0100
commit2a9a7e2557407d5b0c7e6b9680828fb431776ff5 (patch)
treec3d3faa10d1450495fe7e1d9ba2fa8b30b1ba1c6 /test/scr/feh_lwi_scroll_rd
parent7076b7a221768d5153130fe38d3b84f23d0a581d (diff)
Disable --auto-rotate in feh builds compiled wiht Imlib2 1.7.5+
Imlib2 v1.7.5 introduces automatic (and transparent) orientation adjustment based on EXIF orientation tags. This makes feh's --auto-rotate function both superfluous and erroneous: It doesn't know about Imlib2's adjustments, so it rotates an image which is already correctly oriented, leading to incorrect orientation. I am not aware of a simple run-time check for detecting whethen running Imlib2 < 1.7.5 or ≥ 1.7.5. For now, feh disables --auto-rotate entirely when compiled on a system with Imlib2 1.7.5+ and outputs a warning when the option is used. Rationale: The Imlib2 version available at run-time should in most cases be at least as recent as the Imlib2 version used at compile-time. So, while there may be cases where feh was compiled with Imlib2 1.7.4 and exhibits erroneous auto-rotate behaviour on an Imlib2 1.7.5 system, the inverse case (a feh with disabled auto-rotate support running on Imlib2 1.7.4) should be sufficiently rare. If it does occur, it can be remedied by compiling feh from source locally. Possible caveat: Imlib2 only adjusts for EXIF orientation when loading JPEG and TIFF images. If there are additional EXIF-aware file formats supported by feh, but not Imlib2, they lose auto-rotate support. Reference: GitHub issue #642
Diffstat (limited to 'test/scr/feh_lwi_scroll_rd')
0 files changed, 0 insertions, 0 deletions