1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-05-28 23:34:49 -05:00
Simon Tatham b6ef4f18d5 Support Unicode flag glyphs in terminal.c (works in GTK).
This is the only one of the newly added cases in test/utf8.txt which I
can (try to) fix unilaterally just by changing PuTTY's display code,
because it doesn't change the number of character cells occupied by
the text, only the appearance of those cells.

In this commit I make the necessary changes in terminal.c, which makes
flags start working in GTK PuTTY and pterm, but not on Windows.

The system of encoding flags in Unicode is that there's a space of 26
regional-indicator letter code points (U+1F1E6 to U+1F1FF inclusive)
corresponding to the unaccented Latin alphabet, and an adjacent pair
of those letters represents the flag associated with that two-letter
code (usually a nation, although at least one non-nation pair exists,
namely EU).

There are two plausible ways we could handle this in terminal.c:

  (a) leave the regional indicators as they are in the internal data
      model, so that each RI letter occupies its own character cell,
      and at display time have do_paint() spot adjacent pairs of them
      and send each pair to the frontend as a combined glyph.

  (b) combine the pairs _in_ the internal data model, by
      special-casing them in term_display_graphic_char().

This choice makes a semantic difference. What if a flag is displayed
in the terminal and something overprints one of its two character
cells? With option (a), overprinting one cell of an RI pair with a
different RI letter would change it into a different flag; with
option (b), flags behave like any other wide character, in that
overprinting one of the two cells blanks the other as a side effect.

I think we need (a), because not all terminal redraw systems
(curses-style libraries) will understand the Unicode flag glyph system
at all. So if a full-screen application genuinely wants to do a screen
redraw in which a flag changes to a different flag while keeping one
of its constituent letters the same (say, swapping between BA and CA,
or between AC and AD), then the redraw library might very well
implement that screen update by redrawing only the changed letter, and
we need not to corrupt the flag.

All of this is now implemented in terminal.c. The effect is that pairs
of RI characters are passed to the TermWin draw_text() method as if
they were a wide character with a combining mark: that is, you get a
two-character (or four-surrogate) string, with TATTR_COMBINING
indicating that it represents a single glyph, and ATTR_WIDE indicating
that that glyph occupies two character cells rather than one.

In GTK, that's enough to make flag display Just Work. But on
Windows (at least the Win10 machine I have to test on), that doesn't
make flags start working all by itself. But then, the rest of the new
emoji tests also look a bit confused on Windows too. Help would be
welcome from someone who knows how Windows emoji display is supposed
to work!
2024-05-06 13:36:40 +01:00
2024-04-15 19:42:50 +01:00
2024-04-15 19:42:50 +01:00
2022-09-03 11:59:12 +01:00
2023-12-18 14:47:48 +00:00
2023-12-18 14:47:48 +00:00
2023-12-18 14:47:48 +00:00
2024-04-15 19:42:50 +01:00
2024-04-15 19:42:50 +01:00
2024-04-15 19:42:50 +01:00
2024-04-19 19:35:20 +01:00
2022-10-20 23:55:19 +01:00
2023-12-18 14:47:48 +00:00
2024-04-15 19:42:50 +01:00
2024-04-06 10:42:52 +01:00
2022-09-01 20:43:23 +01:00
2022-04-15 17:46:06 +01:00
2020-01-30 06:40:21 +00:00
2022-09-13 11:26:57 +01:00
2023-11-18 09:09:55 +00:00
2022-10-23 12:37:20 +01:00
2022-09-12 09:34:01 +01:00
2023-07-31 20:01:24 +01:00
2024-04-15 19:42:50 +01:00
2022-09-14 16:10:29 +01:00
2022-09-13 11:26:57 +01:00

This is the README for PuTTY, a free Windows and Unix Telnet and SSH
client.

PuTTY is built using CMake <https://cmake.org/>. To compile in the
simplest way (on any of Linux, Windows or Mac), run these commands in
the source directory:

  cmake .
  cmake --build .

Then, to install in the simplest way on Linux or Mac:

  cmake --build . --target install

On Unix, pterm would like to be setuid or setgid, as appropriate, to
permit it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) The cmake install step
doesn't attempt to add these privileges, so if you want user login
recording to work, you should manually ch{own,grp} and chmod the
pterm binary yourself after installation. If you don't do this,
pterm will still work, but not update the user login databases.

Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory. If you aren't using one of our source snapshots,
you'll need to do this yourself. Halibut can be found at
<https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.

The PuTTY home web site is

    https://www.chiark.greenend.org.uk/~sgtatham/putty/

If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.

See the file LICENCE for the licence conditions.
Description
No description provided
Readme 340 MiB
Languages
C 89.7%
Python 8%
Perl 0.9%
CMake 0.8%
Shell 0.4%
Other 0.1%