File Window Tip no longer showing line breaks

[JohnZeman]

I don't know if this a bug or if something has changed in my IMatch configuration but the following line in my File Window Tip configuration no longer shows line breaks in the description.

Code Select Expand

<Run Foreground='#cccccc' FontWeight='Normal' FontSize='14'>Description:</Run><LineBreak/>{File.MD.description|pereplace:{cr}{lf}==<LineBreak/>}
Line breaks aren't working in the file window tip Hierarchal categories either.

It used to work but now it doesn't.  Any ideas?

[Mario]

This is what I see when I copy & paste your expression into a File Window Tip:



I've set the text of a file like shown below, adding line breaks using <Shift>+<Enter> and <Ctrl>+<Enter>:



The text copied from the MD Panel into Notepad:



Maybe something else in your File Window Tip setup?
Does the line breaks show when you go to Edit > Preferences > File Window Tip and point at the test area?

[JohnZeman]

Maybe something else in your File Window Tip setup?
Does the line breaks show when you go to Edit > Preferences > File Window Tip and point at the test area?

No they don't as you can see in the attached screen shots.

They show in the metadata panel ok but not in the tooltip or when I put the mouse pointer over the Test Tip in file window tip configuration.  Ran database diagnostics, but no problems were found.

I closed my normal database and opened a test database, line breaks don't show in there either.  In File window Tip configuration I removed everything except for the description, line breaks still don't show.

[Mario]

No idea.
Works here, even with descriptions containing lots of text, double-line feeds etc.

When did this stop working? Suddenly?
I see no changes in the way File Window Tooltips are rendered in the code base for a long time.

Maybe something in the description that trips the XAML parser?
What if you just enter two rows into the description, with a Shift+Return to create a line feed?

This is line 1.
This is line 2.

[JohnZeman]

Well this is getting interesting.  When I copied and pasted your two test lines into an image the line breaks showed.

So I took one of my regular image descriptions and copied it to the clipboard.  Then I used my Pure Text app to remove all formatting from the description.  Pasted that back into the image description but line breaks still didn't show.

So next I pasted the Pure Text output into my NoteTab Pro text editor, copied it again from NoteTab, and pasted that into the image description, and suddenly line breaks showed again.

So my problem appears to be some unknown formatting lurking within my descriptions.

But I'm wondering where the unknown formatting comes from?  When I want to enter a description, I always write it in my NoteTab text editor before copying and pasting it into an image in IMatch.

While I've only recently noticed this problem with tool tips, the problem appears to be in all of the images in my IMatch database.  Even images over 10 years old.

Well at least I know now how to solve the problem although it's going to take me a long time to go through all of the images in my database.

Thanks for your help Mario.

[thrinn]

Well at least I know now how to solve the problem although it's going to take me a long time to go through all of the images in my database.

Do you have any HEX editor? I would first try to look at the problematic texts. Maybe there is some invisible control character causing this problem? It is difficult to reproduce it here if the text gets somehow changed with Copy & Paste - which seems to be the case according to your description.

[JohnZeman]

Thanks for your suggestion, Thorsten.  Using the free hex editor at https://mh-nexus.de/en/hxd/ I see the hex code of 0A where there should be a line break.  I believe 0A is an ASCII line break.

I just found a quick way to solve the problem.

Using the IMatch metadata panel if I select the entire description, do CTRL+C to copy it to the clipboard then immediately do a CTRL+V to paste it right back into the image, line breaks will show then.  Strange.

[Mario]

0x0D, 0x0A (in hex) (13,10 in ASCII) is a Windows carriage-return / linebreak.
UNIX applications only use a single 0x0A instead. Always cause of trouble when one works in Linux and Windows.

Either PureText or NoteTab Pro causes this, apparently. You should set both application to use Windows-style line breaks, not UNIX-style line breaks.

Apparently, the XAML parser expect Windows line breaks only,. while the text output functions and edit field in the MD panel deals with it.

You said you always did it that way. So, what has changed? The XAML component in IMatch has not changed for a long while and neither the way the MD panel stores tag values in the database.

[JohnZeman]

You said you always did it that way. So, what has changed?

I have no idea Mario.

The only thing that's changed recently that I can think of, is I've been using a new computer since April.  I don't know if my line break problem started then or if that's just a coincidence.

And apparently, I'm the only one who has this problem.

I'm thinking Pure Text is the guilty party here but I've only been using Pure Text for about a year and my description problem affects all of the images in my database including the ones added to my database before the turn of the century.

Scratch the above, I just discovered when this happens.  It's when I writeback metadata with IMatch.  If I fix the description by doing a copy and paste in the metadata panel, I see line breaks.  Until I do a metadata writeback to the image, then the line breaks disappear.

I just did another test on a single CR3 file (no file relations).
Using the metadata panel I entered
This is a line
And did SHIFT+ENTER to enter a line break.  Added additional lines the same way, line breaks look good.

But as soon as I writeback the metadata the line breaks disappear.

[Mario]

I tried that. Adding 3 lines of text in the MD panel and writing back.
IMatch sends (among others) this command to ExifTool:

Code Select Expand

-XMP-dc:Description-x-default=This is a description.
Another line in this description.
A third line.
(This is from the output panel).

The carriage returns and line feeds are encoded as required.

Looking at the file in the ExifTool Command Processor, I see

Code Select Expand

[IPTC]          Caption-Abstract               : This is a description...Another line in this description...A third line.
[XMP-dc]        Description                    : This is a description...Another line in this description...A third line.
[XMP-exif]      User Comment                   : This is a description...Another line in this description...A third line.
[XMP-tiff]      Image Description              : This is a description...Another line in this description...A third line.

Forcing a metadata reload and a full reload of the file retains the line breaks.

Removing the file from the database and adding it again retains the line breaks.

Adding a fourth row of text and writing back again adds the new row in the same fashion to all synchronized description tags.

Looking at the metadata in the file in Affinity Photo, Photoshop and Lightroom shows the description with all line breaks intact.

If you repeat these tests (e.g. looking at the metadata in ECP), what do you see?

[JohnZeman]

I repeated your steps on a new test DNG created by my iPhone 14 Pro.

Line breaks looked good until I did a writeback, then they disappeared.

Attached is the zipped output panel results.

Repeated the test on another new DNG before I used ExifTool to delete all XMP metadata but had the same results.

[Mario]

IMatch is writing the line breaks:

Code Select Expand

-XMP-exif:UserComment=This is a description.
Another line in this description.
A third line.
-XMP-tiff:ImageDescription=This is a description.
Another line in this description.
A third line.
-XMP-dc:Description-x-default=This is a description.
Another line in this description.
A third line.
-XMP-tiff:ImageDescription-x-default=This is a description.
Another line in this description.
A third line.
-XMP-exif:UserComment-x-default=This is a description.
Another line in this description.
A third line.
Did you look at the metadata in the DNG with ExifTool Command Processor (Using the "List Metadata" preset)?
Special characters are there represented by a . to a line break (0x0D,0x0A) shows as .. in the description.

[JohnZeman]

After running the List Metadata preset in the ExifTool Command processor on the DNG the results look ok to me.

I've zipped and attached the results to this.

[Mario]

The description tags stored in the image all seem to contain the proper carriage-returns and line-feeds.
Where do they get lost? IMatch re-reads the metadata after a write-back. It should read the CR/LF pairs just fine. It does here.

I've considered the Protection settings in Edit > Preferences > Metadata 2 and kept them all off in my tests. So they are not relevant in this case.

The Keep existing XMP setting is "Yes" by default (same preferences dialog) and it prevents that IMatch unnecessarily re-creates XMP from legacy IPTC, EXIF and GPS data. Is this set to "Yes" in your installation?

Maybe you can send me a DNG file which causes this problem to support email address or upload it and send me a link?

[JohnZeman]

Instead of a large DNG I've emailed your support address a small zipped TIFF which has the same problem.  Virtually all of the images in my database have this problem.

I have a feeling the image will work fine for you.  It seems odd to me that this problem affects JPGs, TIFFs, DNGs, CR2s and CR3s in my database.

I have run database diagnostics but no problems were found.

[JohnZeman]

The Keep existing XMP setting is "Yes" by default (same preferences dialog) and it prevents that IMatch unnecessarily re-creates XMP from legacy IPTC, EXIF and GPS data. Is this set to "Yes" in your installation?

I forgot to answer this.  Took me awhile to find the setting, I had to enable expert mode to find it.

In Preferences > Metadata2 > Protection

I have the Protect existing XMP option set to Yes (It's been that way I didn't change it).

[Mario]

I have received the file. The metadata contains the correct carriage-return/line-feed sequences and IMatch displays the text correctly wrapped in the MD panel or in the VarToy when I use {File.MD.description}

I think the pereplace is the problem. For some yet unknown reasons, it does not seem to find the {cr}{lf} sequence you're trying to replace. For example:

{File.MD.description|pereplace:{cr}==<LineBreak/>}

does nothing!
If you change this to

{File.MD.description|pereplace:{lf}==<LineBreak/>}

it works just fine and the File Window Info Tip does the proper formatting. This is your work-around.
The metadata in your files is fine.

Probably the combination of two tokens is not handled by pereplace, due to the way it works. I'll have a look for the next release.

[JohnZeman]

That does seem to have solved my problem Mario, thank you!

[Mario]

OK, I've spend almost two hours on this. Dang.
This is really a moving target.

I noticed that the description the variable "sees" does not contain CRLF pairs for line breaks, but only LF - UNIX-style.
Windows uses CRLF (two characters of hex value 0x0D, 0x0A) and UNIX uses only LF (0x0A).

But wherever I looked, I always saw CRLF pairs. When looking at the XML data produced by ExifTool in an editor. When looking at the text value in the database browser tool. Or in the ECP!

But when I looked at the description value in the debugger and made it convert special characters to escape codes, I saw 0x0A,0x0A. The description in the sample file contains two line breaks, both encoded as 0x0A, 0x0A.

Windows text output (e.g. metadata panel) treats 0x0D,0x0A the same as a single 0x0A. This is also true for the Var Parser output field, which is why the text "looks" OK. But the line breaks are UNIX-style and not Windows style.

As soon as you "touch" the data, e.g. copying it into the clipboard, the single 0x0A are silently converted into 0x0D,0x0A pairs. Which made it so hard to figure out what's going on. Every editor/tool and their grand mother silently converts the UNIX-style line feeds in your data into Windows-style carriage-return / line-feed pairs.

The only way to figure out what's really encoded in the description tags in your files was to search each tag value for \n\n (two consecutive line feeds (0x0A,0x0A) and then break into the debugger. This is what finally showed me that the data you have manged to create text with UNIX-style line feeds using your 2 extra application workflow.

This does not harm, as the MD panel and IMatch in general will display the 0x0A in the same way as Windows line feeds.
But when you search the text for CRLF like you do in your variable, you will not find anything, since there are no carriage returns in the data.

{File.MD.description|pereplace:{cr}==[CR]}

does nothing.

{File.MD.description|pereplace:{lf}==[LF]}

produces output like this:

Code Select Expand

man's father.[LF][LF]My gra
It replaces the two consecutive line feeds with [LF][LF] as it should.

When you copy the description into the clipboard and back into the MD Panel (which you explained as a way to fix this), you use the silent magic that converts the UNIX-style line feeds you have in the text into Windows-style line feeds. And then your variable works.

I guess something in your workflow produces UNIX-style line feeds (IMatch does never) and this remains invisible until you explicitly search for and try to replace Windows-style linefeeds with <LineBreak/>.

[JohnZeman]

Wow.  I had no idea I'd opened such a big can of worms.  Glad you got it sorted out though.

[sinus]

Great!
Maybe this helps me also. Because I had this also from time to time, in design & print. Perhaps this helps also, I will see.

Thanks John, for freeing the can of worms and thanks to Mario, for select all together again.