New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isPrintableText() seems to return false if string contains \n or \r #55
Comments
That's disturbing. Fixed and added tests. Emojis are inherently printable since they are always comprised of printable characters. |
Bumped PNG, JPEG, and TIFF integrations. |
Amazing! Thank you, I'll test it :) |
Seems to work... except for the GoPro camera model string, which is empty now (should be JPEG file: https://github.com/photoprism/photoprism/blob/develop/internal/meta/testdata/gopro_hd2.jpg |
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>
.
|
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.
|
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. |
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>
.
|
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>
> .
>
|
I've been upgrading from an earlier version of your library as the last version had the issue with 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! |
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. |
Bumped all image-formats and go-exif-knife to use latest go-exif. |
Can't upgrade somehow - do you know what's going on here? Wrong Go version?
|
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 |
Excellent, thank you! Seems to work |
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:
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.
The text was updated successfully, but these errors were encountered: