Question about the browser XMP tab in 1.97.4

[CameronD]

several example screenshots have been emailed.

Edit - oops - misinterpreted your question. Example jpeg file sent...

[xnview]

If i check, there no CR+LF or CR or LF, only SPACE

[CameronD]

If i check, there no CR+LF or CR or LF, only SPACE

Do you mean in the XMP block itself?
If so then yes, that is what I was saying before.
The XMP tab in XnView reflects exactly the formatting that was written by the last program to write the XMP block.

What I was referring to was as follows:
If I select the image with a single line XMP, edit IPTC, 'write' (without changing anything), then XnView reprocesses the XMP block and it becomes nicely formatted again.

So could you use that same reformatting code to simply generate the text to show in the XMP tab window, without rewriting the image?

[Silversleeves]

If i check, there no CR+LF or CR or LF, only SPACE

Do you mean in the XMP block itself?
If so then yes, that is what I was saying before.
The XMP tab in XnView reflects exactly the formatting that was written by the last program to write the XMP block.

What I was referring to was as follows:
If I select the image with a single line XMP, edit IPTC, 'write' (without changing anything), then XnView reprocesses the XMP block and it becomes nicely formatted again.

So could you use that same reformatting code to simply generate the text to show in the XMP tab window, without rewriting the image?

CameronD and Pierre:

Something else must have changed between versions 1.99 and 2.20, because now the Browser XMP tab displays the XML data no differently whether I've added it with XnView, Exiv2 or ExifTool. I'm loath to mention this to Phil Harvey; he and I spent the better part of two weeks ironing out changes I made in my ExifTool config file to make a custom XMP namespace (that I had to register on-the-fly in Exiv2) semi-permanent. But more on point: I'd already noted that the key reason I started using his app versus Andreas Huggel's (written in well-documented C and significantly faster) was this display issue.

And whatever did change to make this possible, it wouldn't need to do with metadata. I'm not too well-versed at reading between the lines in Release Notes, so I'll venture to say that changing something someone else thought needed improvement made this change "in its wake," so to speak.

BZT