Add (7) Windows Property

[TheGhost78]

I used " <(System.Image.Dimensions)>" in the suffix of Add (7), to include the dimensions of images in the filenames. This worked but it also added a hidden character before and after the dimensions.

Hidden Character U+202A
Hidden Character U+202C

I only noticed it when I customised a folder with an icon file and it didn't work, so I looked at the desktop.ini file and the filename was shown with a question mark before and after the numbers.

Original file name: Picture.jpg
Expected new file name: Picture 1920 x 1080.jpg
Actual new file name: Picture ?1920 x 1080?.jpg

Can these hidden characters be removed before applying the new name?

[Luuk]

Until the bug is fixed, would need to include Replace(3) having a "Replace" like... \regex\[\u202a\u202c]
But this requires changing your Special(14) "Order", so that Remove(3) conducts after/below the Add(7).
NOTE: Using <(#Properties)> can also remove them, but this only preserves the 1st-set of digits!

IF the files had an exif, could instead try an Add(7) like... < (exif:ImageHeight) x (exif:ImageWidth)>
Those properties wont add any formatting-characters, so there isnt a need to insert the # character.
But Im still prefer using just the Replace(3) to fix any names already having those characters.

[Luuk]

im just realized the exif sample Im giving was "Height x Width", so just reverse it for "Width x Height" (if your exifs have them).
Without any exif the names cant be changed, as long as the 1st-space is like... < (exif:ImageWidth) x (exif:ImageWidthHeight)>

[Luuk]

Lol, that last exif example was supposed to be like... < (exif:ImageWidth) x (exif:ImageHeight)>
For myself, Im usually prefer the format more like.... < (exif:ImageWidth)x(exif:ImageHeight)>
Im sure this bug will be fixed by the next release, thanks for reporting!

[Admin]

Hi, yes, we fix this by removing the two invisible characters.... not sure why they are in the file properties.

[Luuk]

Its unfortunate, but now I do believe this problem might be coming from the Windows itself!
So <(System.Image.Dimensions)> is just a composite-metadata, custom-formatted from other metadata??
So like Windows saying its custom-format like... \u202aSystem.Image.Width x System.Image.Height\u202c

Im going all the way back to BRU version v3.3.1.0, and this bug was there, but nobody noticed because they're invisible!
All other metadata conducts fine, but maybe Windows has similiar composites (a custom-format of two other metadata)??
Its unfortunate, but Im not expert to know if there can be more composite Windows File Properties like this.

But if there are more, Im sure they probably all use \u202a and \u202c to start and stop their own custom-formats.
StarGeek at the exiftool forums is an expert on metadata/regex, and has always helped when Im having any problems.
But its mostly Linux users over there, and this seems most likely a Windows problem of formatting its composite(s)??

If anybody knows of similiar composites, where Windows just custom-formats some other metadata, please to post them.
For now, its best using something like... <(#System.Image.HorizontalSize) x (#System.Image.VerticalSize)>
That wont depend on having any correct exif-data, and you can specify your own custom-formats.

Thanks again for posting this bug!

[TheGhost78]

For now, I use <(System.Image.HorizontalSize)> x <(System.Image.VerticalSize)> and then remove the word 'pixels' from the filename.

[TheGhost78]

I didn't realise you could add the '#' symbol to make it just return the numerals.

[Admin]

We probably should remove both \u202a and \u202c if present in the file properties as you would not want to apply those character to the file names.

[Admin]

Hi, what version of BRU are you using ? Because in version 3.4.4.0 or newer these invisible characters should be already removed. thanks

[Luuk]

Every version (that supported Windows File Properties) did insert those characters with System.Image.Dimensions.
I was curious if some older Windows versions might not use \u202a and \u202c, but I only have the Windows 8.1.

Can use dir/b on the command-line, and the hidden-chars will look something like... ?width x height?.
Or after renaming, just to show their positions, RegEx(1) can use a v2 "Match" and "Replace" like...
\xe2\x80[\xaa\xac]/g
:

[TheGhost78]

I'm still using v3.4.0.0 mainly due to the right-click behaviour with network mapped drives in versions after that.

However, I've just tried it with v3.5.0.0 and the hidden characters ARE still inserted, confirmed via Show Unicode Character https://qaz.wtf/u/show.cgi).

[Admin]

Thanks, you are right, BRU currently only removes

// 0x200E LEFT-TO-RIGHT MARK
// 0x200F RIGHT-TO-LEFT MARK

I think version 3.5 should remove all these that are non-printable:

// 0x200B ZERO WIDTH SPACE
// 0x200C ZERO WIDTH NON-JOINER
// 0x200D ZERO WIDTH JOINER
// 0x200E LEFT-TO-RIGHT MARK
// 0x200F RIGHT-TO-LEFT MARK
// 0x202A LEFT-TO-RIGHT EMBEDDING
// 0x202B RIGHT-TO-LEFT EMBEDDING
// 0x202C POP DIRECTIONAL FORMATTING
// 0x202D LEFT-TO-RIGHT OVERRIDE
// 0x202E RIGHT-TO-LEFT OVERRIDE
// 0x202F NARROW NO-BREAK SPACE

[Admin]

You can copy and paste the BRU file properties here to see if there are non-printable Unicode characters :

https://www.soscisurvey.de/tools/view-chars.php

Right click on a file in BRU, and select "View List of File Properties" and then you can copy all the text into the above online tool.
The non-printable Unicode characters will be shown in purple with their code.
If you find more that BRU should drop, please post here, thanks!

[Admin]

Version 3.5.0.1 available : viewtopic.php?f=1&t=6600