This question is not answered.


Permlink Replies: 99 - Pages: 7 [ Previous | 1 2 3 4 5 6 7 | Next ] - Last Post: 20-Sep-2018 10:02 Last Post By: AndreWolff
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 03-Aug-2017 16:29   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
What is welcome.cp1252.html demonstrating?
karlmistelberger

Posts: 567
Registered: 5-Dec-2013
Re: jAlbum 14 mutilates Lightroom comments
Posted: 03-Aug-2017 17:42   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
What is welcome.cp1252.html demonstrating?

This page was downloaded from http://lge-laufen.de/welcome.html using Firefox and looked quite normal. Any application on my machine displays the text in the downloaded file as:

Den nächsten Lauf, der beim Läufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardmäßig findet die Kirchweih ...

But jAlbum Textpad displays the htt template as:

Den n�chsten Lauf, der beim L�ufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardm��ig findet die Kirchweih ...

And the processed page uploaded to jAlbum is displayed as:

Den n�chsten Lauf, der beim L�ufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardm��ig findet die Kirchweih ...
AndreWolff

Posts: 1,704
Registered: 14-Dec-2007
Re: jAlbum 14 mutilates Lightroom comments
Posted: 03-Aug-2017 19:34   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
karlmistelberger wrote:
Den nächsten Lauf, der beim Läufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardmäßig findet die Kirchweih ...
Under Windows 10 this is correctly displayed in the jAlbum text editor, with and without ' -Dfile.encoding=UTF-8'
karlmistelberger

Posts: 567
Registered: 5-Dec-2013
Re: jAlbum 14 mutilates Lightroom comments
Posted: 03-Aug-2017 20:34   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
AndreWolff wrote:
karlmistelberger wrote:
Den nächsten Lauf, der beim Läufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardmäßig findet die Kirchweih ...

What is the encoding of the file on your machine? The file on the server is pure ASCII, but some download programs are tricked into conversion.

Under Windows 10 this is correctly displayed in the jAlbum text editor, with and without ' -Dfile.encoding=UTF-8'

The same with X Emacs, Kate, Kwrite, Leafpad, Vi ... under Linux.
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 03-Aug-2017 23:20   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
Attachment JTextPad.jar (1.4 MB)
karlmistelberger wrote:
This page was downloaded from http://lge-laufen.de/welcome.html using Firefox and looked quite normal. Any application on my machine displays the text in the downloaded file as:

Den nächsten Lauf, der beim Läufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardmäßig findet die Kirchweih ...

But jAlbum Textpad displays the htt template as:

Den n�chsten Lauf, der beim L�ufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardm��ig findet die Kirchweih ...

And the processed page uploaded to jAlbum is displayed as:

Den n�chsten Lauf, der beim L�ufer-Cup (LC) gewertet wird,
war in Allersberg. Mit Peter, der ja beim LC aufholen will!
Standardm��ig findet die Kirchweih ...

Thanks for reporting this Karl. I've updated jAlbum's TextPad to be more clever in its encoding detection and added support for loading and saving files in specified encodings. To try it out, first do a core update, which should take you to 14.0.13, then drop the attached update to jAlbum's text editor inside jAlbum's "ext" folder and restart jAlbum.

If you've set jAlbum's encoding to match the one in that file or to ISO-8859-1 (basically the same as Windows 1252), then you should be able to open the file fine in jAlbum's text editor now.

Now to the issue with custom .htt files not displaying properly in the generated web view:
This is due to the fact that you have set jAlbum to generate UTF-8 encoded pages, but the charset meta attribute of the files is set to charset=windows-1252. This fools the web browser which reads the charset attribute instead of auto-detecting the encoding. Solve that issue by either switching off "Write-UTF-8", or better, set the charset meta attribute of your template files to UTF-8 so the line reads:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
jGromit

Posts: 7,579
Registered: 31-Jan-2006
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 04:10   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
...set the charset meta attribute of your template files to UTF-8 so the line reads:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Not valid HTML5, so unless you're writing HTML4, what you want is:
<meta charset="UTF-8">
karlmistelberger

Posts: 567
Registered: 5-Dec-2013
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 08:27   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:

Thanks for reporting this Karl. I've updated jAlbum's TextPad to be more clever in its encoding detection and added support for loading and saving files in specified encodings. To try it out, first do a core update, which should take you to 14.0.13, then drop the attached update to jAlbum's text editor inside jAlbum's "ext" folder and restart jAlbum.

Upgraded to v14.0.13 and updated jAlbum's TextPad.

Great: Loading and saving files in specified encodings now works as advertised and is what presumably most knowledgeable users want to have.

Encoding detection still lags when comparing to other applications installed on the system.

If you've set jAlbum's encoding to match the one in that file or to ISO-8859-1 (basically the same as Windows 1252), then you should be able to open the file fine in jAlbum's text editor now.

That works too, even when files with encodings ASCII, Windows-1252 and UTF-8 are present in a project, all of them being displayed correctly. And for sake of completeness: Metadata are still displayed correctly such as: Copyright=© 2016 André Wolff :-)

Now to the issue with custom .htt files not displaying properly in the generated web view:
This is due to the fact that you have set jAlbum to generate UTF-8 encoded pages, but the charset meta attribute of the files is set to charset=windows-1252.

I designed http://lge-laufen.de/ in 1999. Its maintainers in 2017 still stick to my recommendation to use ASCII consistently.

But their Frontpage and Word messes with metas:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
...
<meta http-equiv="Content-Type"  content="text/html; charset=iso-8859-1">
  <meta http-equiv="Content-Language" content="de">
This triggers Firefox to convert the file on storing locally. The canonical way is downloading with "wget http://www.lge-laufen.de/welcome.html", which leaves the download unaltered. I don't worry doing this. But most users will not be aware of what is going on and will be left puzzled.

Edited by: karlmistelberger on 04-Aug-2017 09:02 Metadata
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 09:47   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
karlmistelberger wrote:

Encoding detection still lags when comparing to other applications installed on the system.

Please give examples! I know of one: Browsers check the charset attribute of html files. JTextPad doesn't. It relies solely on binary analysis and BOM markers (if they exist). JTextPad should now properly detect native, UTF-8, UTF-16 encodings. It however doesn't figure out what native encoding to use but relies on jAlbum's encoding setting for that. I don't know of any editor that figures out what native (8-bit) encoding to use.
karlmistelberger

Posts: 567
Registered: 5-Dec-2013
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 10:10   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Attachment jalbum12.png (27.7 KB)
Attachment jalbum11.png (144.2 KB)
davidekholm wrote:
karlmistelberger wrote:

Encoding detection still lags when comparing to other applications installed on the system.

Please give examples! I know of one: Browsers check the charset attribute of html files. JTextPad doesn't. It relies solely on binary analysis and BOM markers (if they exist). JTextPad should now properly detect native, UTF-8, UTF-16 encodings.


That works indeed.

It however doesn't figure out what native encoding to use but relies on jAlbum's encoding setting for that. I don't know of any editor that figures out what native (8-bit) encoding to use.

See screen shots. X Emacs by default figures out what encoding to use automatically. I never tinkered with any of its settings. I think it relies on: https://www.google.de/search?q=charsetdetect+java
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 10:19   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
Thanks for that link. If JTextPad was a novel-text editor and not a coders editor one may benefit more from such best-guess auto detection. Quoting from the link you provided:

"Character set detection is at best an imprecise operation. The detection process will attempt to identify the charset that best matches the characteristics of the byte data, but the process is partly statistical in nature, and the results can not be guaranteed to always be correct.

For best accuracy in charset detection, the input data should be primarily in a single language, and a minimum of a few hundred bytes worth of plain text in the language are needed. The detection process will attempt to ignore html or xml style markup that could otherwise obscure the content. "
karlmistelberger

Posts: 567
Registered: 5-Dec-2013
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 12:01   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
Thanks for that link. If JTextPad was a novel-text editor and not a coders editor one may benefit more from such best-guess auto detection.

Really? I did a search and found https://www.emacswiki.org/emacs/unicad.el (X-)Emacs indeed uses an elisp port of the Mozilla Universal Charset Auto Detector.

Although it comes WITHOUT ANY WARRANTY it worked for me without any single flaw and with any kind of text. Just in case it gets in the way for some file it can be disabled.

Best-guess auto detection is similar to vaccination: There is no guarantee that it will always help. But you want to have it.

https://www.google.de/search?q=novel-text+editor+emacs
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 12:56   in response to: karlmistelberger in response to: karlmistelberger
 
  Click to reply to this thread Reply
karlmistelberger wrote:
davidekholm wrote:
Thanks for that link. If JTextPad was a novel-text editor and not a coders editor one may benefit more from such best-guess auto detection.

Really? I did a search and found https://www.emacswiki.org/emacs/unicad.el (X-)Emacs indeed uses an elisp port of the Mozilla Universal Charset Auto Detector.

Although it comes WITHOUT ANY WARRANTY it worked for me without any single flaw and with any kind of text. Just in case it gets in the way for some file it can be disabled.

Best-guess auto detection is similar to vaccination: There is no guarantee that it will always help. But you want to have it.

https://www.google.de/search?q=novel-text+editor+emacs


Well, now you can at least explicitly load a file with a specified encoding. It's rare to juggle multiple 8-bit encodings on the same machine. You probably use the one relevant for your region. Just set jAlbum to the same encoding and you should be fine.
AndreWolff

Posts: 1,704
Registered: 14-Dec-2007
Re: jAlbum 14 mutilates Lightroom comments
Posted: 04-Aug-2017 15:49   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
David,

if you are busy with textpad corrections, don't forget this!
AndreWolff

Posts: 1,704
Registered: 14-Dec-2007
Re: jAlbum 14 mutilates Lightroom comments
Posted: 12-Sep-2017 11:38   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
Well, a skin developer might want to investigate the handling of EXIF data that may be hidden by xmp equivalents, another user may want to ignore xmp data for whatever reason (broken/incorrect xmp data for instance). Remember the default setting is checked and that this is an advanced setting.
Yes I like to do that with the GPS informaition, but that is not working, see this post.
davidekholm

Posts: 3,623
Registered: 18-Oct-2002
Re: jAlbum 14 mutilates Lightroom comments
Posted: 13-Sep-2017 09:00   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
AndreWolff wrote:
David,

if you are busy with textpad corrections, don't forget this!


... and my answer is the same. This will fix itself when we bundle jAlbum with Java 9. Java 9 is now scheduled for release on Sep 21 2017.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums