v1.1.43 HEIF/AVIF support

[sylikc]

1.1.43

I wanted to make a special thanks to qbnu for adding HEIF/AVIF support to JPEGView!

A few new features to highlight along with WinXP support back again!

New features:

• HEIF/AVIF support
  Supports AV1/HEVC encoded still images and image collections
  (Not yet supported: thumbnails, animations, or AVC encoded images)
  (NOTE: Microsoft Visual C++ Runtime vcruntime140.dll required)
  Otherwise, download it for free from Microsoft.)
  PR Add HEIF/AVIF support with libheif #109, thanks qbnu

Changed behavior:

• KeyMap.txt is now optional, the defaults from KeyMap.txt.default will be loaded if a user-customized version does not exist
  KeyMap.txt search paths: %AppData%\JPEGView\KeyMap.txt -> (JPEGView.exe dir)\KeyMap.txt -> (JPEGView.exe dir)\KeyMap.txt.default
  (This means, extracting new releases will not overwrite your customized KeyMap.txt)
• KeyMap.txt is now simplified to only the include key mappings. The list of commands and help can be found in the KeyMap-README.html
  (KeyMap.txt from older versions will continue to work if you have customized one)
• Help Display now properly shows the on/off status of "hide window title bar" and "always on top" modes

Other changes:

• Updated French translation, thanks LaurentGrenet
• Updated Japanese translation, thanks maboroshin
• Updated Russian translation, thanks Dmitry Yerokhin
• Windows XP is still supported and special WinXP-compatible builds will be released (WinXP builds do not support new formats added after v1.0.37.1)
• WebP is now integrated into JPEGView without needing webp.dll

SHA-256 Checksums

Verify the release with these checksums on the release files:

fd68430f74db58520429d1fb076a5d482dc6f13c809c726df598cd4053e00ea5 *JPEGView32-WinXP_1.1.43.zip
a490c9930d001ec6e32a68c1a689b09759898b60f1a98946e7178b16e66c4f25 *JPEGView32_1.1.43.7z
a5b3b4442cec97e5f5f70d9aae8ca78409567a9d315e774caf211cd55fa52547 *JPEGView32_en-us_1.1.43.msi
5423dde60f80c521a7b484275c14897227a4f7afdbc0c8d13274b7ec844b3e39 *JPEGView64_1.1.43.7z
0e9902ebb9db89dd1fa9234d87c2afc0295fe628e3926bcf0697116e275a385b *JPEGView64_en-us_1.1.43.msi
e2eeb5dab25c9cdb743a7f98c743435cc4885c8594b15ed0cf5e861d8e818acd *JPEGView_1.1.43.7z
d95426ac4203d66ebb1947e02dbf7de230b3309b477e68c370b4b8ec44b33d75 *JPEGView_1.1.43.zip

---

This discussion was created from the release v1.1.43 HEIF/AVIF support.

[Hrxn]

Thank you for this new release, really appreciate it! 😄

If I also may add my 2ⅽ, I'd consider support for Windows XP a non-goal. I mean, why bother, as an open-source project, to support something that is not even supported anymore by MSFT themself?

[sylikc]

If I also may add my 2ⅽ, I'd consider support for Windows XP a non-goal. I mean, why bother, as an open-source project, to support something that is not even supported anymore by MSFT themself?

Well, sort of right... I had to fire up a really old VM to solve #51 . I don't know how big the community would be which uses JPEGView on XP, but apparently there are a few. It wasn't trivial to get WInXP working, so I figured I'd highlight it. Most people don't care though, you're right, so I'll probably never highlight it again.

I was pretty surprised that the new features which were added worked on XP. But anyways, as a side note, Windows 7 isn't supported either haha.

[LaurentGrenet]

Hi @sylikc
Thanks a lot for this new version.

Let me suggest you to apply now the same mechanism you have defined for Keymap.txt to JPEGView.ini.

I look forward reading in the next changelog :
JPEGView.ini is now optional, the defaults from JPEGView.ini.default will be loaded if a user-customized version does not exist
JPEGView.ini search paths: %AppData%\JPEGView\JPEGView.ini -> (JPEGView.exe dir)\JPEGView.ini -> (JPEGView.exe dir)\JPEGView.ini.default
(This means, extracting new releases will not overwrite your customized JPEGView.ini)

Let me also add just one remark : there is still in distrib a KeyMap_ru.txt file. I guess it is no more used in any case ?

[sylikc]

Yes, this is already designed and will apply to the INI. While it is the same mechanism that will be used, the INI is much more complicated than the KeyMap, and I was not comfortable with trying to release it in this release. Also, it is more complicated because it cascades, and it also has the *.tpl files, like saving separate settings, and all types of features around it.

The settings changes for INI are not ready for production, so I didn't include it in this release. I expect needing at least another release or two to make sure it really works and doesn't break anything

KeyMap_ru.txt was removed from the installer but currently exists in the self-extracting archives. As in our discussion #129 the new KeyMap-README.html needs to be translated instead of the old TXT files.

[LaurentGrenet]

Good news !
With this new mechanism, I'm not sure that the *.tpl files are still necessary ?

Another point now : I saw in the distrib the presence of a file named strings.txt and aiming at being the "reference".
I was very happy with that, and I began to check if the french file had to be fulfilled with some new strings...
But actually I discovered... that there are a lot of strings that are missing in this "reference"....

FYI, some examples of "missing" strings (I count +/- 90 missing strings by comparing with what is currently in french file)
Open image...
Open with
Save processed image...
Set modification date...

And some string are not in this file with their exact spelling
Example, currently there are two strings to translate, About JPEGView... and About JPEGView (64 bit version)...
In the Strings.txt, they are About JPEGView (32-bit version)... and About JPEGView (64-bit version)... (with a dash between 64 and bit...)

Since I fully agree it would be great to have such a reference, please have a look....

Last (but not least) : The current translation mechanism in which each string to be translated is identified by its english value (rather than with a resource id) makes that our translation files are "sensitive" to any change you may do in the original texts.... that are then actually the "key" of each string-to-translate
It would be great to be able to base translation files on resource IDs

[sylikc]

Well, that's why the INI changes haven't been done yet for this release... the *.tpl files are still necessary right now, but it may not be in the future. There's quite a bit of investigation to be done before the INI gets changed.

strings.txt is the reference. It is auto-generated from source code... any entry that exists in strings.txt needs a translation, and anything that does not exist in strings.txt is not used. So in your example, if it exists in strings_fr.txt but not in strings.txt it is not used and can be deleted. I didn't update any of the strings_XX.txt yet, but that's up to the translators when I can get a hold of volunteers :)

Unfortunately, the way the translation mechanism is written right now, it is sensitive to what's in code. There's no other way to do it without a complete revamp of that feature. Most English strings shouldn't change, as JPEGView is fairly stable, but there's not much that can be done about the string<->string coupling.

[LaurentGrenet]

I've not been clear... Most of these missing strings are used today, and mustn't be deleted from the strings_XX.txt files. I did the test to remove them from the strings_fr.txt : Result, I have texts that are no more translated in the app.
The first examples I gave you are actually all coming from the right-clic pop up menu. Maybe only this "source" is missing in your "reference", but at least this "source" (the main menu) is missing.
And if one source is missing, it is worth checking if another could not be missing as well....

Some of the "missing" entries are missing because not spelled exactly the same way.
And here an example of string "uncorrectly" spelled in the "reference"
In "reference", we find Licensed under the GNU general public license (GPL), see readme file for details
while it is currently in strings_fr.txt Licensed under the GNU general public license (GPL), see readme file for details: (with a comma at the end)
If I remove the comma in strings_fr.txt... corresponding translation is not done any more in the about window....
So, the "reference" is wrong without the comma....

About the last point (use english text as "key" or use IDs), I was already afraid it was too late to change that.... Too bad...

[sylikc]

I've not been clear... Most of these missing strings are used today, and mustn't be deleted from the strings_XX.txt files. I did the test to remove them from the strings_fr.txt : Result, I have texts that are no more translated in the app. The first examples I gave you are actually all coming from the right-clic pop up menu. Maybe only this "source" is missing in your "reference", but at least this "source" (the main menu) is missing. And if one source is missing, it is worth checking if another could not be missing as well....

It is possible that I had messed up the autogeneration. That's one of the reasons I have not really advertised the feature. Thanks for doing the test. I should go force the INI to a language to test myself.

I'll look into this. Thanks for the feedback.

[LaurentGrenet]

Complement : My example about "Licensed under..." is actually wrong. I made a mistake in my tests.

But this reveals the real issue of having english strings as keys...
The actual issue is that up to rev 1.1.42, the text to translate used to be Licensed under the GNU general public license (GPL), see readme file for details: (with the comma), but now in 1.1.43, the text to translate mustn't have any more the comma....
And then, all strings_XX.txt files have to be updated.....

So, despite you say that "Most English strings shouldn't change, as JPEGView is fairly stable"....

[sylikc]

I re-did a lot of strings, since I was changing strings.txt anyways. I removed the ":" from a lot of strings, and some strings previously had a space at the end, that was removed too. That was done 8cab7bf

It's the first step in making strings more streamlined, if removing punctuation will help in the long run, doing it now while the strings all have to change anyways.

Oh, I also sorted it alphabetically to make it easier to find these minor differences in the future. I'll write scripts in the next release to sort the existing and then do comparisons.

One step at a time. It's on my TODO list

[LaurentGrenet]

One step at a time. It's on my TODO list

Sure ! Take your time.

Maybe, it could be a solution to have strings IDs rather than english text as keys for translation, without modifying current translation mechanism.
It would consist in replacing each string in the source code with a string that would be a string ID (eg STR0001 fr the 1st one, STR0002, etc...), and then consider strings_en.txt as a translation as for any other language.
I don't know how much this replacement in the code could be automated : if it cannot, my proposal doesn't make sense, but if it could be automated, this could be a great evolution in having a more clean code....

Anyway, in order to try to help you (not to "boost" you ;-)), I did a comparison between your "reference" file, and french file as it is currently.
I have found three categories that have to be managed :

1. Entries present in "reference" but currently missing in french file : to be managed by me, to add missing translations
2. Entries slightly modified vs previous version : I can also manage them (for french translation) , modifying accordingly the "key" in french file
3. Entries present currently in french file, but missing in "reference" (and not due to a "slight" modification)
   Most of them are currently used in the application, but maybe not all of them
   For this 3rd category (the largest one...) I cannot manage them only myself. I can remove those that are really no more used, but I need you to identify those that are really no more used and those that are erroneously missing in your reference.

I attach to this post the "list of differences" as categorized above, and the (provisional) updated french file, in which I have added new entries, and updated entries with key "slightly" modified.
List of differences.txt
strings_fr-NEW.txt

[LaurentGrenet]

I did some deeper investigations, and among "missing lines in reference", I've been able to verify that these ones are actually used

About   JPEGView...
Actual size of image
Auto correction
Backup parameter DB...
Batch rename/copy...
Change size...
Clear parameters from DB
Copy Selection to Clipboard
Copy original size image
Copy to clipboard
Creation date
Crop Mode
Crop Selection
Crop Selection Lossless...
Delete current file on disk   permanently
Display order
Do you really want to   permanently delete the file %filename%?
Edit user settings...
Exit
Fit window to image
Fixed size...
Free
Full screen mode
Mirror horizontally
Mirror vertically
Movie
Open containing folder in   Explorer
Open image with
Open image...
Play folder as slideshow/movie
Reload image
Restore parameter DB...
Rotate +90
Rotate -90
Rotate 180
Rotate...
Save parameters to DB
Save processed image...
Set as default viewer...
Set as desktop wallpaper
Set current parameters as   default values...
Set modification date
Settings/Admin
Span all screens
Transform image
Update user settings...
Use original image
Use processed image as   displayed
Waiting time
Zoom
Zoom to Selection
to EXIF date
to EXIF date (all files in   folder)
to current date

On the other hand, I've not been able to display the following ones

Edit global settings...
Fast
No file or folder name was provided as command line parameter!
Normal
PgDn or Right
PgUp or Left
Rename:
Rotate the following file lossless by 270 deg?\n%filename%
Rotate the following file lossless by 90 deg?\n%filename%
Slow
Stop slide show/movie
To use JPEGView, associate JPG, JPEG and BMP files with JPEGView.
Transition Speed
User commands
Very fast
Very slow
Window mode
[new entry]
copied
renamed
up/down

And finally, I found 3 new text needing translation, not present in "reference" :

Copy file path
Hide window title bar
Set window always on top

I have added these 3 new text in french translation , plus some minor modifications.
I attach the file (I'm currently using operationally).

strings_fr-NEW2.txt

[sylikc]

@LaurentGrenet I updated the latest revision of this on a branch... I haven't merged it back to the main branch, but the future will look like this:

strings.txt reference looks like this

strings_fr.txt - your FR file converted looks like this

[LaurentGrenet]

Sounds very good ! Thank you.

About missing translations in french file, most of them were not "necessary" since in these cases french translation is identical to english text. Nevertheless, it's more clear to have them "translated". This will avoid to "hide" some really missing translation among them in the last auto-generated paragraph
And 3 or 4 of them were "really" missing.

So I updated your file with all missing (really or not) translations, and upload it just below.
I have voluntarily kept the paragraph of "no more used" (to keep track of translations as they have been), but removed the auto-generated paragraph of "missing"

strings_fr.txt last update with missing translations

[Tom4tot]

Just a quick thank you! Well, thank you so much. This is one of my favorite software ever and I'm glad to see its development continue. Long Live JPEGVIEW!