Awesome! Thanks!
When importing a PDF, you get to choose between a Poppler/Cairo importer, or a custom Inkscape one. Presumably the Inkscape one has many fixes and tweaks and should be the preferred choice. However, text in embedded fonts is not handled by this importer (#5624), resulting in messed up text sections.
In many cases, the text doesn't need to be editable, so I'd like the option for the Inkscape importer to render text as paths. Just like the Poppler/Cairo importer.
Right now, I have to choose the Popple/Cairo importer, and lose all other benefits that the Inkscape importer has.
Text is jumbled around as the incorrect font is used and hence glyph sizes are wrong.
I should have got the option to import the text as paths instead, preserving the text's appearance.
Inkscape 1.1.2 (0a00cf5339, 2022-02-04)
GLib version: 2.70.5
GTK version: 3.24.34
glibmm version: 2.66.2
gtkmm version: 3.24.5
libxml2 version: 2.9.13
libxslt version: 1.1.34
Cairo version: 1.17.4
Pango version: 1.50.4
HarfBuzz version: 2.9.1
Poppler version: 21.08.0
OS version: Fedora Linux 35 (Workstation Edition)
Pierre Ossman (Work account) (0c3623cf) at 26 Aug 13:34
This is actually the common ISO "102nd" key, found between the left shift and "Z".
Note that this is still technically wrong, as macOS swaps the key codes for ANSI_Grave and ISO_Section for ISO layouts. This magic is not something we can encode here though, so that swapping will have to be done by the implementations using this data.
I agree and we've been bitten by this in TigerVNC as well. A brief glance of the GnuTLS code suggests this can happen in a lot of different scenarios, so fixing the implementation seems to be non-trivial.
A more reasonable short term goal is to update the documentation to warn about this. Right now the documentation implies that you will only get GNUTLS_E_AGAIN
if the underlying pull function sets errno
to EAGAIN
, which is obviously not true.
In our case we got this problem when interoperating with x11vnc, using OpenSSL. The issue seems to be reception of a session ticket that contains no data. Debug output from GnuTLS for this:
gnutls[10]: READ: Got 5 bytes from 0x2765530
gnutls[10]: READ: read 5 bytes from 0x2765530
gnutls[10]: RB: Have 0 bytes into buffer. Adding 5 bytes.
gnutls[10]: RB: Requested 5 bytes
gnutls[5]: REC[0x2756ee0]: SSL 3.3 Application Data packet received. Epoch 2, length: 250
gnutls[5]: REC[0x2756ee0]: Expected Packet Application Data(23)
gnutls[5]: REC[0x2756ee0]: Received Packet Application Data(23) with length: 250
gnutls[10]: READ: Got 250 bytes from 0x2765530
gnutls[10]: READ: read 250 bytes from 0x2765530
gnutls[10]: RB: Have 5 bytes into buffer. Adding 250 bytes.
gnutls[10]: RB: Requested 255 bytes
gnutls[5]: REC[0x2756ee0]: Decrypted Packet[1] Handshake(22) with length: 233
gnutls[3]: ASSERT: buffers.c[get_last_packet]:1169
gnutls[4]: HSK[0x2756ee0]: NEW SESSION TICKET (4) was received. Length 229[229], frag offset 0, frag length: 229, sequence: 0
gnutls[3]: ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1429
gnutls[4]: HSK[0x2756ee0]: parsing session ticket message
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1577
gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1775
At this point we go back to doing select()
on the socket, which never completes as we've already read the data and we have more records in our buffer ready to be pulled by GnuTLS.
Downstream bug report, with references to workaround:
I'd ideally like a real test, but I don't think that will happen any time soon. So I'm good.
Oddly enough, the xorg "kbd" driver also uses 0x71/0x72, which is odd given that those are the values after the offset of 8. They are also reversed compared to everyone else. Might just be coincidence.
Pierre Ossman (Work account) (6119e6e1) at 11 Nov 12:54
Fix scan codes for Korean keys
Pierre Ossman (Work account) (82049f70) at 11 Nov 12:44
Fix XT/AT set 1 scan codes for Korean keys
FreeRDP also likes 0x71/0x72:
So I think we have enough circumstantial evidence to move forward with those values.
There is a conflict with KEY_EXIT
and KEY_MOVE
though. However I'm not sure those are correct as I cannot find those in drivers/input/keyboard/atkbd.c
.
Can we confirm this using e.g. a Windows guest in QEMU?
0x71 and 0x72 are in a similar range as the Japanese keys (0x77, 0x79, 0x7b, 0x7d), so that makes it plausible. Or were those 71 and 72 in decimal?
I can't seem to find any handling for those keys except in the USB HID driver, unfortunately. :/
Also note that XKB's data contradicts the mapping suggested here, but it might be buggy. See discussion here:
This fixes up handling of Apple Japanese keyboards, and as a side effect Korean ones as well.
However it exposes a major problem in that there are no XT scan codes for the Korean keys. I cannot find any documentation, and it doesn't look like QEMU handles them right now.
So how do we proceed assigning numbers to these?
Windows uses almost-XT, so perhaps someone can test a Korean keyboard there?
Pierre Ossman (Work account) (685684a8) at 11 Nov 09:53
Fix argument order in output headers
... and 7 more commits
Pierre Ossman (Work account) (279b5f86) at 05 Apr 11:03
Done.
Pierre Ossman (Work account) (279b5f86) at 03 Apr 13:37
Compare DNs by comparing their string representations
... and 26 more commits