german umlauts

23 posts / 0 new
Last post
DL2KI
german umlauts

Hi,

with version 2.5.0 I noticed that german umlauts are not taken over in the name field.

Example:

Name = "Günter
Displayed name in the "Last QSO Area" = "Günther".

This behavior was not observed in the previous versions.

73, Wolfgang
DL2KI

DL2KI
Hi,

Hi,

one more addendum.

The behavior also occurs, for example, in the "Comment to callsign" field. In the exported adif file all German umlauts are transcoded.

How can I set the correct display of the umlauts again? How can this be undone in the complete database?

73, Wolfgang
DL2KI

oh1kh
german umlauts

Hi Wolfgang !

That should not be problem if your Linux is set to use UTF-8 character set.
Installed 2.5.0 and made a fake qso. See the screen shot.

File: 

--
Saku
OH1KH

DL2KI
german umlauts

Hi,

my Linux is and always was set to UTF-8.

$ locale
LANG=de_DE.UTF-8
LANGUAGE=de
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
~ $

When I enter a fake QSO and enter "Günter" in the "Name" field, the name changes to "Günter" after "Save QSO [enter]".

If I call "Show QSO list" and change the name "Günter" there to "Günter", after saving the QSO's "Günter" is displayed again.

73, Wolfgang
DL2KI

DL2KI
german umlauts

If I compile CQRLOG from the current sources and copy it via "/usr/bin/cqrlog", the same behavior occurs.

73, Wolfgang
DL2KI

oh1kh
german umlauts

HI Wolfgang!

As you are able to compile, have you tried QT5 version?
You need libqt5pas1 package. Then if you compile from command console with "make" you have to fix the "Makefile" in source root. Find "gtk2" two times in file and replace both with "qt5" before issuing "make".

If you use Lazarus GUI then: Project/Project options/ Set LCL widget type/Value qt5 and then Targets: check checkbox qt5 (if not already checked) an uncheck gtk2. After that: Run/ Clean up and build

Would be interesting to see if problem exist with both gtk2 and qt5 versions.

--
Saku
OH1KH

DL2KI
german umlauts

Hi Saku,

"gtk2" can be found in the makefile not twice, but four times. I assume that you meant "--ws=gtk2".
The qt5 version I then compiled with "make cqrlog_qt5", since I assume that this is how it is supposed to be done.

The qt5 version shows the same behavior as the gtk2 version.

73, Wolfgang
DL2KI

oh1kh
german umlauts

Ok!

I forgot that Petr just recently added make option "cqrlog_qt5"

So then there must be something different in your Linux settings, perhaps keyboard side.
Please try to paint and copy following text and palce it to "test.adi" file with text editor:
--------------

ADIF export from CQRLOG for Linux version 2.4.0 (135)
Copyright (C) 2021 by Petr, OK7AN and Martin, OK1RR

Internet: http://www.cqrlog.com

<ADIF_VER:5>3.1.0
<CREATED_TIMESTAMP:15>20210119 153803
<PROGRAMID:6>CQRLOG
<PROGRAMVERSION:11>2.4.0 (135)
<EOH>
<QSO_DATE:8>20210118<TIME_ON:4>1501<STATION_CALLSIGN:5>OH1KH<CALL:5>DL1AB<MODE:2>CW<FREQ:5>7.025<BAND:3>40M<RST_SENT:3>599<RST_RCVD:3>599<NAME_INTL:6>Günter<COMMENT_INTL:6>Günter
<EOR>

-------------
Then we can see is the umlaut ok when imported from adif. And if it is, then it is your keyboard routine doing something weird.

I have tested to paint and copy from this message and paste to text file test.adi and then import to cqrlog and umlauts are ok in my Fedora 32.

--
Saku
OH1KH

DL2KI
german umlauts

Hi Saku,

the import of the test.adi is not possible. See screenshot. The dialog shows "Complete!"; but no record is imported.

If I create a new, empty database with "New Log", a previously exported adif file cannot be imported either. The access rights to the directory "~/.config/cqrlog" are set correctly.

Below I had already written

if I replace the binary "/usr/bin/cqrlog" (2.5.0) with the binary "cqrlog" from the package "cqrlog_2.4.0-1~eoan_amd64", the umlauts work again as before.

So I can't see what should have changed in my Linux settings.

I continue to use the binary from the package "cqrlog_2.4.0-1~eoan_amd64" for now, the umlauts work there.

73, Wolfgang
DL2KI

File: 

oh1kh
german umlauts

HI !

What is "-1~eoan_amd64" ?
Must be a Linux vendor specific package. Would be nice to know what they have added there.

--
Saku
OH1KH

DL2KI
german umlauts

Hi Saku,

it is the official Ubuntu installation package "cqrlog_2.4.0-1~eoan_amd64.deb" from the CQRLOG- repository of Petr Hlozek.

https://launchpad.net/~ok2cqr/+archive/ubuntu/ppa

I assume that Petr did not add anything additional here.

73, Wolfgang
DL2KI

oh1kh
german umlauts

Hi Wolfgang !

My I ask what versions of free pascal and lazarus do you use for compile?

With the latest versions fpc 3.2.0 and Laz 2.0.10 I had problems with regexp and if I remember right also with special characters.
See this issue: https://github.com/ok2cqr/cqrlog/issues/323

So If you are doing compile by your self you should use Laz2.0.8/fpc3.0.4. It works.

Regexp problem should have been fixed in fpc trunk, but no official release have been done after July 11, 2020 as seen from lazarus-ide.org web page.

--
Saku
OH1KH

DL2KI
german umlauts

Hi,

if I replace the binary "/usr/bin/cqrlog" (2.5.0) with the binary "cqrlog" from the package "cqrlog_2.4.0-1~eoan_amd64", the umlauts work again as before.

Apparently the problem is therefore somewhere in the package "cqrlog_2.5.0-1~groovy_amd64.deb".

73, Wolfgang
DL2KI

DL2KI
german umlauts

Hi Saku,

i have installed here the Lazarus version 2.0.10 and fpc 3.2.0.

But this is not relevant for the problem, because I have the problem with the original installation. This was not compiled by me.

When I run this loop

for f in `find | egrep -v Eliminate`; do echo "$f" ' -- ' `file -bi "$f"` ; done

in the "src" directory, I see that most of the files there are coded in "us-ascii". Additionally you can find "iso-8859-1" and some "utf-8".

Excerpt:
...
...
./fChangeFreq.lfm -- text/plain; charset=us-ascii
./gline2.pas -- text/plain; charset=iso-8859-1
./fAddRadioMemory.pas -- text/plain; charset=us-ascii
./fBigSquareStat.pas -- text/html; charset=us-ascii
./fPreferences.pas -- text/plain; charset=us-ascii
./fAbout.pas -- text/plain; charset=us-ascii
./rig.pas -- text/plain; charset=us-ascii
./fQTHProfiles.pas -- text/plain; charset=us-ascii
./fMain.pas -- text/plain; charset=us-ascii
./dUtils.lfm -- text/plain; charset=us-ascii
./fSort.lfm -- text/plain; charset=us-ascii
./dLogUpload.pas -- text/plain; charset=us-ascii
./dDXCC.pas -- text/plain; charset=us-ascii
./fFindCommentToCall.pas -- text/plain; charset=us-ascii
./fAbout.lfm -- text/plain; charset=utf-8
...
...

It is possible that the cause is to be found here.

73, Wolfgang
DL2KI

oh1kh
german umlauts

How you determine those files? See the "man file" chapter "description"
There is no header like html has and if there are not used any other characters than between 0x20 -0x7e they look like plain ascii.
Language will be set us as pascal uses English word commands.

I do not think that has any effect to compile result. But I know you will get problems with laz2.0.10 and fpc 3.2.0.
I suggest to uninstall laz2.0.10 and fpc 3.2.0 and download older versions Laz2.0.8/fpc3.0.4 from lazarus-ide.org and then try to compile.
This is just to see does it make any difference.

You can also try compiler option (with 2.0.10 and 2.0.8 if you install it)
Lazarus GUI-> Project/Project options/Compiler options/Custom options/ you find button "Add -FcUTF-8" use it to add -FcUTF-8 compiler option and try then compile again.

This is little weird as you are the only one who has reported these problems with 2.5.0
Either there are no problems with others (like me), or then they do never need special characters and have not noticed this problem.

But i any case it would be good to find the root reason for this and concentrate to find a way to compile working result, not to compare old an new packages as we do not know what kind of compiler versions and options they have been done. And note also that between packages the maker's compile environment may have changed and so you can not expect that two version of packages are made with similar setup even when the maker is same.

--
Saku
OH1KH

DL2KI
german umlauts

Hi Saku,

as I already said, I don't use a self-compiled binary, but the one from the official Ubuntu installation package. So the problem with the umlauts cannot be related to my Lazarus/fpc version!

Since the umlauts are displayed correctly with the binary of version 2.4.0, the cause can only lie in the version 2.5.0 package.

It therefore makes no sense for me to experiment with different Lazarus/fpc versions at the moment.

In the meantime, my hint that the adif import does not work has already been confirmed.
https://www.cqrlog.com/node/3086

73, Wolfgang

oh1kh
german umlauts

" So the problem with the umlauts cannot be related to my Lazarus/fpc version!
Since the umlauts are displayed correctly with the binary of version 2.4.0, the cause can only lie in the version 2.5.0 package.
It therefore makes no sense for me to experiment with different Lazarus/fpc versions at the moment."

Of course your compiler does not affect to packages.

As I said: Even when packages 2.4.0 and 2.5.0 are from same package maker it does not ensure that they are made with same package makers setup. His linux may have been changed, at least there are updates installed meanwhile.
So you can not expect 2.4.0 and 2.5.0 are similar. Not even when they would have been done from same 2.4.0 source because time has passed over one year and the background, meaming his PC and program versions, has changed.

As you are not willing to test different compilers, nobody else complains about this, and I am not able to reproduce the problem here there is nothing more to be done about this.

I can not fix problem that does not exist.
Sorry.

--
Saku
OH1KH

DL2KI
german umlauts [Cause clarified]

Hi,

i have compiled cqrlog 2.5.0 myself in a LinuxMint20 VM. With this binary the german umlauts work as well as the adif import.
But this does not change the malfunction of the binary in the package from the cqrlog PPA.

Anyway, Petr now has a usable reference to work with.

References to allegedly non-existent problems are generally of little help in troubleshooting and do not contribute to systematically clarifying the cause of malfunctions. No forum user will report problems they don't have.

73, Wolfgang
DL2KI

oh1kh
german umlauts [Cause clarified]

HI Wolfgang!

How is it now with cqrlog release 2.5.1 ?

--
Saku
OH1KH

DL2KI
german umlauts [Cause clarified]

Hello Saku,

with version 2.5.1 from the cqrlog PPA, the German umlauts and the ADIF import do not work.

With a self-compiled binary (Mint 20) and your binary from "cqr0.zip" both work.

73, Wolfgang
DL2KI

oh1kh
german umlauts [Cause clarified]

HI Wolfgang!

Have you tried special charcters now with cqrlog compiled from very latest source?

--
Saku
OH1KH

DL2KI
german umlauts [Cause clarified]

Hi Saku,

with version 2.5.2 from the cqrlog PPA, the German umlauts do not work.
With a self-compiled binary (Mint 20) and your binary from "cqr0.zip" both work.

73, Wolfgang
DL2KI

oh1kh
german umlauts [Cause clarified]

Oh yes!

I forgot that problem was with package (as usual).

There is not the latest updates in that package, I think. Compare dates of package to this:

https://github.com/ok2cqr/cqrlog/commits/master --> Commits on Feb 13, 2021 Bug fix for UTF8 …

I'm bit lazy to write today, so read also "warning of this new version" from beginning README from here:
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled

--
Saku
OH1KH