Hi Jürgen,
thank you for comment.
I am quite sure it's not an APL-character problem.
The characters in question are defined within the APL-keyboard layout as
normal UTF-8 characters.
The "overlay" I experience is different from APL-Character over strike:
An APL over strike is character-backspace-character
The UTF-8 character display problem is:
- enter APL-character, see half-space-left-half-character
- enter [SPACE], see right-half-character-half-space
- in effect having one character displayed in two consecutive positions.
- Entering a third character. It will not display. 'Covered' by [SPACE]
The following code (run in Konsole 21.04.1)
* KDE Frameworks 5.82.0
* Qt 5.15.2 (kompiliert gegen 5.15.2)
* Das xcb Fenstersystem
displays a couple of UTF characters (many non APL).
Then selecting a line the selection will show that selected characters
move to the left.
for ((a=128;a<192;a=a+1)); do
for ((n=128;n<190;n=n+1));do
printf -vh '\\x%2x\\x%2x\\x%2x' 226 $a $n;
echo -en "$h";
done;
echo;
done
It seems to me, that eg. Chinese characters take twice the space
compared with simple UTF characters.
When the Chinese characters get selected, they do not 'shrink'.
However, there are "graphically oriented" UTF characters (including
⍝⊖⍟⍱), that take two character positions when being displayed
and take one character position when being selected.
So it's not an APL character / font handling problem. It Just happened
to be the first popup.
I'll open a bug report with Fedora.
Best Regards
Hans-Peter
Am 03.06.21 um 11:49 schrieb Dr. Jürgen Sauermann:
Hi Hans-Peter,
the behaviour that you describe looks like somewhere in your platform
there
is some character-backspace-character detector active that replaces the
characters displayed when they are being overstruck.
I wrote such character-backspace-character detectors myself in the 1980s
as part of (APL-) terminal drivers and my experience from that time is
that they
were somewhat unreliable (for example, you had to consider the time
between the
different keystrokes to distinguish between a valid overstrike
sequence and the
same sequence with backspace meaning to delete (the first character)
rather than
overstrike, auto-line feed of the terminal at the end of a long line,
etc.).
For that reason i took care not to implement overstrike sequences in GNU
APL but to maintain a strict 1:1 relation between keystrokes and APL
characters (which was not possible in the 1980s due to the lack of
Unicode).
As a consequence, your platform should not become aware of APL
in the first place but rather behave like a standard Unicode terminal.
Note that Unicode has its own overstrike-like mechanism which is
entirely incompatible with the old APL overstrikes (and this mechanism
should not be used either with GNU APL).
I believe the other applications follow suit here (in not supporting
overstrikes)
while firefox (or maybe X) tries to.
Again, GNU APL was specifically designed to not not need APL fonts in
the first
place and using them nevertheless will therefore cause more trouble
then help.
Best Regards,
Jürgen
On 6/2/21 11:23 AM, Hans-Peter Sorge wrote:
Hi,
I am on Fedora 34 now (apl SVN: 1198:1472M)
The apl font partially fails to work with keyboard layout apl.
The "over strike characters" ⌽⍉⍟⍝⍱⍲ ,when entered in a terminal,
appear in half....
The left half of the character is being displayed when entered.
The right half appears when space bar is being pressed.
Anny further character entered is being offset by one.
That is ⌽[space]ABC -> ends up as ⌽BC where space bar "overlays"
character A!
The Apl-Session, terminal, emacs, vi are affected too. slikedid,
Firefox are OK.
If changing the layout via *setxkbmap -layout "apl"* I get ����
instead of ⌽⍉⍟⍝.
The � are being displayed the same way as described above: Left half
character, [SPACEBAR] right half of the character.
I installed apl from the repository to verify the behavior - that
segfaults.
The font-manager shows
⍝ APL FUNCTIONAL SYMBOL UP SHOE JOT U+235D
So there is nothing special about this and 'normal' UTF-8 characters.
The terminal font is set to *latarcyrheb-sun16* in
*/etc/voconsole.conf.*
Changing the terminal font to either Unifont-APL8x16-12.1.02 or
NotoSansMono did not help.
Emacs:
After some 'fiddling around' font changes with emacs *M-x
menu-set-font* will display ⍝ in one go,
Char ⍝ will be displayed for different fonts - even if the
font-manager does not show it.
Char ⍝ with font NotoSansMono selected will be displayed in one shot
but with additional spacing to the left and right.
Char ⍝ with Unifont selected will be displayed w/o spacing.
( The console fonts and the content of *menu-set-font* are different...)
Hopefully some one has an idea where / how to dig deeper into the
problem.
Best Regards
Hans-Peter
Is there / some where an experiment going on to 'improve' character
composition?
