version 12.88 and odt files (LibreOfficeWriter)

Started by sevy, July 12, 2024, 12:09:28 PM

Previous topic - Next topic

sevy

Hello,

Thanks for this new version of this useful program :-)
As a I used a lot LibreOfficeWriter and .odt files, I noticed differences between version 12.87 and 12.88 (32 & 64 bits) for windows.
Does I need to install  another program, as I read - with the 12.88 - "Install Archive::Zip to decode compressed ZIP information" ?

thanks in advance

Sevy


for the same odt file
metadata available in 12.87
ExifTool Version Number : 12.87
File Name :
Directory :
File Size :
File Modification Date/Time
File Access Date/Time
File Creation Date/Time
File Permissions
File Type
File Type Extension
MIME Type
Creation-date
Editing-duration
Editing-cycles
Generator
Keyword
Date
Document-statistic Table-count
Document-statistic Image-count
Document-statistic Object-count
Document-statistic Page-count
Document-statistic Paragraph-count
Document-statistic Word-count
Document-statistic Character-count
Document-statistic Non-whitespace-character-count:
Template Type
Template Actuate
Template Title
Template Href
Template Date
Preview PNG

metadata available in 12.88 :
ExifTool Version Number : 12.88
File Name
Directory
File Size
File Modification Date/Time
File Access Date/Time
File Creation Date/Time
File Permissions
Warning : Install Archive::Zip to decode compressed ZIP information
File Type
File Type Extension
MIME Type
Zip Required Version
Zip Bit Flag
Zip Compression
Zip Modify Date
Zip CRC
Zip Compressed Size
Zip Uncompressed Size
Zip File Name



StarGeek

Did you make sure that the exiftool_files directory is in the same directory as exiftool.exe?  This is a change from previous versions.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

sevy

hello,
yes, both are in the same directory
see :
12-07-24  20:14    <DIR>          .
12-07-24  20:14    <DIR>          ..
12-07-24  17:51               977 1288.txt
24-05-23  18:54           136.961 a.odt
10-07-24  15:48            38.400 exiftool.exe
11-07-24  16:00    <DIR>          exiftool_files
11-07-24  13:36               493 README.txt


Phil Harvey

I can reproduce this problem, however the package does in include Archive::Zip, so I can't see why this doesn't work.  It will take me a few days to look into this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

You can see this problem clearly with the exiftool -v -ver output:

pic.png
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

Here is the reason.  Now all I have to do is to figure out what is going wrong...

pic2.png

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

StarGeek

I was fiddling with this earlier and that's exactly what I saw when I used this to test if Archive::Zip was available
exiftool -p "${filename;use Archive::Zip}" y:\!temp\Test4.jpg
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

Fixed in 12.89 (just released).

What a crazy problem.  I was pulling out my hair trying to figure this one out.  The problem occurs because I check my files into CVS, and there was a CVS revision number as a comment in the header of these files that was getting changed.  Unfortunately this number seems to be significant.  I still don't understand, but I solved the problem be restoring all of the original library modules, then zipping the whole set before checking into CVS.  Then I un-zip it again before I build the Windows versions.  It's the sort of problem I really hate... That's a few hours of my life I'll never get back. :(

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

sevy

Thanks a lot, it's now working as usual.
What a great job.

sevy

obetz

Quote from: Phil Harvey on July 12, 2024, 10:40:46 PMthere was a CVS revision number as a comment in the header of these files that was getting changed.

version control systems shouldn't mess with files unless explicitly requested

Phil Harvey

@obetz:  The first 3 lines of Encode.pm from your bundle are:

#
# $Id: Encode.pm,v 3.08 2020/12/02 01:27:44 dankogai Exp $
#

These were added by some revision control system.  I don't know how.  When I check in files to my CVS repository, these lines aren't added.  But apparently their existence implicitly gives CVS permission to update them.  I've seen these before but never used them or looked into their behaviour.  More surprising to me is that the loader (presumably XSLoader.pm) actually cares about these CVS comments, and will reject a file if these change.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).