Re: Encoding italic

[Asmus Freytag via Unicode]

On 1/30/2019 4:38 PM, Kent Karlsson via Unicode wrote: I did say "multiple" and "for instance". But since you ask: ITU T.416/ISO/IEC 8613-6 defines general RGB & CMY(K) colour control sequences, which are deferred in ECMA-48/ISO 6429. (The RGB one is implemented in Cygwin (sorry for mentioning a product name).) No need to be sorry; we understand that the motivation is not so much advertising as giving a concrete example. It would be interesting if anything out there implements CMY(K). My expectation would be that this would be limited to interfaces for printers or their emulators. (The "named" ones, though very popular in terminal emulators, are all much too stark, I think, and the exact colour for them are implementation defined.) Muted colors are something that's become more popular as display hardware has improved. Modern displays are able to reproduce these both more predictably as well as with the necessary degree of contrast (although some users'/designer's fetish for low contrast text design is almost as bad as people randomly mixing "stark" FG/BG colors in the '90s.) ECMA-48/ISO 6429 defines control sequences for CJK emphasising, which traditionally does not use bold or italic. Compare those specified for CSS (https://www.w3.org/TR/css-text-decor-3/#propdef-text-decoration-style and https://www.w3.org/TR/css-text-decor-3/#propdef-text-emphasis-style). These are not at all mentioned in ITU T.416/ISO/IEC 8613-6, but should be of interest for the generalised subject of this thread. Mapping all of these to CSS would be essential if you want this stuff to be interoperable. There are some other differences as well, but those are the major ones with regard to text styling. (I don't know those standards to a tee. I've just looked at the "m" control sequences for text styling. And yes, I looked at the free copies...) /Kent Karlsson PS If people insist on that EACH character in "plain text" italic/bold/etc "controls" be default ignorable: one could just take the control sequences as specified, but map the printable characters part to the corresponding tag characters... Not that I think that that is really necessary. Systems that support "markdown", i.e. simplified markup to provide the most main-stream features of rich-text tend to do that with printable characters, for a reason. Perhaps two reasons. Users find it preferable to have a visible fallback when "markdown" is not interpreted by a receiving system and users' generally like the ability to edit the markdown directly (even if, for convenience) there's some direct UI support for adding text styling. Loading up the text with lots of invisible characters that may be deleted or copied out of order by someone working on a system that neither interprets nor displays these code points is an interoperability nightmare in my opinion. Den 2019-01-30 22:24, skrev "Doug Ewell via Unicode" <unicode@unicode.org>: Kent Karlsson wrote: Yes, great. But as I've said, we've ALREADY got a default-ignorable-in-display (if implemented right) way of doing such things. And not only do we already have one, but it is also standardised in multiple standards from different standards institutions. See for instance "ISO/IEC 8613-6, Information technology --- Open Document Architecture (ODA) and Interchange Format: Character content architecture". I looked at ITU T.416, which I believe is equivalent to ISO 8613-6 but has the advantage of not costing me USD 179, and it looks very similar to ISO 6429 (ECMA-48, formerly ANSI X3.64) with regard to the things we are talking about: setting text display properties such as bold and italics by means of escape sequences. Can you explain how ISO 8613-6 differs from ISO 6429 for what we are doing, and if it does not, why we should not simply refer to the more familiar 6429? -- Doug Ewell | Thornton, CO, US | ewellic.org