I'm using Arch Linux and installed MComix from AUR. After I updated MComix to v2.3.0, MComix doesn't respect rotation metadata in PDF files.
I attached a sample manga comic PDF(Silver-Spoon-01-first-10-pages.pdf) that I scanned as an example. According to exiftool, rotation metadata is the following result in first 10 pages.
$ exiftool -v Silver-Spoon-01-first-10-pages.pdf | grep Rotate
| | | 6) Rotate = 0
| | | 6) Rotate = 0
| | | 6) Rotate = 270
| | | 6) Rotate = 90
| | | 6) Rotate = 270
| | | 6) Rotate = 90
| | | 6) Rotate = 270
| | | 6) Rotate = 90
| | | 6) Rotate = 270
| | | 6) Rotate = 90

As you can see in the screenshot, when I open this PDF in MComix v2.3.0, rotate information is ignored and the page and thumbnails remain in landscape state after page 2. I also enables Double page mode and Manga mode, but these settings are ignored, too.
Checking Preference -> Display -> Rotation -> Automatically rotate images according to their metadata in settings makes no change.

By downgrading to v2.2.1 MComix works properly. All pages are in portrait state, and Double page mode and Manga mode take effects.
Thank you for the excellent report. I assume this must be because MComix 2.3.0 was the first version to actually ship with the native Python PDF reader module instead of using the mutool binary. I will look into what causes the rotation not to be detected.
In the meantime, exporting the environment variable MCOMIX_DISABLE_PDF_MULTI=1 before MComix is started will disable the native Python PDF handler and fall back to the previous default mutool handler.
It seems that the API used to extract the image, Document.extract_image(), by design tries to extract the original image without applying any modifications to it. In this case, the PDF page has additional rotation metadata which is then ignored once the image has been extracted.
It would probably be necessary to detect this and manually apply the rotation to the image data before saving it to disk.
Last edit: Oddegamra 2023-09-15
This should probably be fixed now. I don't have many PDF test files, but it sure seems to work properly for the attached one now.
I hadn't seen this, thanks for fixing it @oddegamra.
@benoit-pierre basically predicted that rotation would be one of the things to trip up
FitzArchive, and I'm unsurprised that prediction turned out to be correct.