isPrintableText() seems to return false if string contains \n or \r

[lastzero]

This effectively converts a proper description like "Hello World\n\nWhere are you?" to "string with binary data (%d bytes)" which then shows up as image description throughout the application:

if isPrintableText(t) == false {
	phrase = fmt.Sprintf("string with binary data (%d bytes)", len(t))
	return phrase, nil
}

It seems better to allow \n, \r, and \t or return an empty string so that the value returned by Exiftool can be used as fallback. Same for Emojis if they don't qualify as printable text.

[dsoprea]

That's disturbing. Fixed and added tests.

Emojis are inherently printable since they are always comprised of printable characters.

[dsoprea]

Bumped PNG, JPEG, and TIFF integrations.

[lastzero]

Amazing! Thank you, I'll test it :)

[lastzero]

Seems to work... except for the GoPro camera model string, which is empty now (should be HD2):

photoprism/photoprism@28c5c1b#diff-a555f5d32b86bb2205dbe93eec001de1aeb93763192fd0483f85a210875438dcR97

JPEG file:

https://github.com/photoprism/photoprism/blob/develop/internal/meta/testdata/gopro_hd2.jpg

[dsoprea]

Darn it. Okay. I can't test it at the moment. Standby.

…

On Fri, Apr 30, 2021, 05:02 Michael Mayer ***@***.***> wrote: Seems to work... except for the GoPro camera model string, which is empty now (should be HD2): ***@***.*** #diff-a555f5d32b86bb2205dbe93eec001de1aeb93763192fd0483f85a210875438dcR97 <photoprism/photoprism@28c5c1b#diff-a555f5d32b86bb2205dbe93eec001de1aeb93763192fd0483f85a210875438dcR97> JPEG file: https://github.com/photoprism/photoprism/blob/develop/internal/meta/testdata/gopro_hd2.jpg — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOW2WD4TPTF4GAKRCWTS3TLJWY7ANCNFSM4XQSAGNA> .

[dsoprea]

I don't think that's related to this change. go-exif drops it regardless because it's defined as a NUL-terminated string and no NUL is present.

$ go run command/exif-read-tool/main.go -f /tmp/gopro_hd2.jpg -v
...
2021/05/08 02:39:50 exifcommon.parser: [WARNING]  ascii not terminated with nul as expected: [HD2p�3��A�]
2021/05/08 02:39:50 exif.utility: [WARNING]  Could not parse value for tag [IFD] (0110) [Model].
...

[lastzero]

Would it be possible to make the parsing (a bit) less strict or does this result in other issues?

An earlier version of go-exif returned it and exiftool does as well. So not a huge issue as most of our users have exiftool enabled as a fallback.

[dsoprea]

That's the type as defined by the standard. There are non-NUL-terminated strings and NUL-terminated strings. I'm hesitant to tell it to just "show everything and stop at nonprintable characters" as surely the standard must [impracticably] accommodate non-printable ASCII characters, but maybe it does more damage than not. It's from a different era. Just to clarify, Phil and my philosophies are somewhat divergent. His level of forgiveness makes for a dangerous precedent. I'd rather assume standards-adherent unless there's a clear, alternative approach that can be enabled via option. As much as I'd like to be as compatible, I'd like to give the appropriate amount of consideration to compatibility issues. Dustin

…

On Sat, May 8, 2021, 02:50 Michael Mayer ***@***.***> wrote: Would it be possible to make the parsing (a bit) less strict or does this result in other issues? An earlier version of go-exif returned it and exiftool does as well. So not a huge issue as most of our users have exiftool enabled as a fallback. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOW2SQLXTIFOYH4ZXARV3TMTNMFANCNFSM4XQSAGNA> .

[dsoprea]

Note that this is somewhat irrelevant to the current matter, though. None of this has changed, so why is your test suddenly breaking? Has it just been running through exiftool every time?

…

On Sat, May 8, 2021, 06:14 Dustin Oprea ***@***.***> wrote: That's the type as defined by the standard. There are non-NUL-terminated strings and NUL-terminated strings. I'm hesitant to tell it to just "show everything and stop at nonprintable characters" as surely the standard must [impracticably] accommodate non-printable ASCII characters, but maybe it does more damage than not. It's from a different era. Just to clarify, Phil and my philosophies are somewhat divergent. His level of forgiveness makes for a dangerous precedent. I'd rather assume standards-adherent unless there's a clear, alternative approach that can be enabled via option. As much as I'd like to be as compatible, I'd like to give the appropriate amount of consideration to compatibility issues. Dustin On Sat, May 8, 2021, 02:50 Michael Mayer ***@***.***> wrote: > Would it be possible to make the parsing (a bit) less strict or does this > result in other issues? > > An earlier version of go-exif returned it and exiftool does as well. So > not a huge issue as most of our users have exiftool enabled as a fallback. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#55 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAFOW2SQLXTIFOYH4ZXARV3TMTNMFANCNFSM4XQSAGNA> > . >

[lastzero]

Note that this is somewhat irrelevant to the current matter, though. None of this has changed, so why is your test suddenly breaking? Has it just been running through exiftool every time?

I've been upgrading from an earlier version of your library as the last version had the issue with isPrintableText(), in addition to the changed camera model parsing behaviour.

If you say this should not be touched, that's good enough for me... might have been something you want to look into.

Thank you very much!

[dsoprea]

We were already ignoring the lack of a NUL byte. We were specifically looking for nonprintable binary. So, instead of failing, we now just stop-short and return the bytes before that point.

[dsoprea]

Bumped all image-formats and go-exif-knife to use latest go-exif.

[lastzero]

Can't upgrade somehow - do you know what's going on here? Wrong Go version?

$ go get -u github.com/dsoprea/go-exif/v3
# github.com/dsoprea/go-logging
/go/pkg/mod/github.com/dsoprea/go-logging@v0.0.0-20200710184922-b02d349568dd/log.go:355:14: cannot use "github.com/go-errors/errors".Wrap(err, 2) (type error) as type *"github.com/go-errors/errors".Error in assignment: need type assertion
/go/pkg/mod/github.com/dsoprea/go-logging@v0.0.0-20200710184922-b02d349568dd/log.go:445:21: cannot use "github.com/go-errors/errors".Wrap(err, 1) (type error) as type *"github.com/go-errors/errors".Error in return argument: need type assertion
/go/pkg/mod/github.com/dsoprea/go-logging@v0.0.0-20200710184922-b02d349568dd/log.go:451:20: cannot use "github.com/go-errors/errors".Wrap(err, 1) (type error) as type *"github.com/go-errors/errors".Error in return argument: need type assertion

[dsoprea]

Because you're upgrading every component instead of just go-exif, and go-logging is currently broken because the stacktrace-management package that it (and the dozens of projects I've produced over the years) uses just introduced a breaking PR a couple of days ago (go-errors/errors#34).

Just do go get github.com/dsoprea/go-exif/v3@8213cfabc61b27b42b71133f18372eed1122a237.

[lastzero]

Excellent, thank you! Seems to work 🥳