A last missing link for interoperable representation

[Tex via Unicode]

This thread has gone on for a bit and I question if there is any more light that can be shed.

 

BTW, I admit to liking Asmus definition for functions that span text being a definition or criteria for rich text.

I also liked James examples of the twitter use case.

 

The arguments against italics seem to be:

·        Unicode is plain text. Italics is rich text.

·        We haven't had it until now, so we don't need it.

·        There are many rich text solutions, such as html.

·        There are ways to indicate or simulate italics in plain text including using underscore or other characters, using characters that look italic (eg math), etc.

·        Adding Italicization might break existing software

·        The examples of  existing Unicode characters that seem to represent rich text (emoji, interlinear annotation, et al) have justifications.

 

The case for it are:

·        Plain text still has tremendous utility and rich text is not always an option.

·        Simulations for italics are non-standard and therefore hurt interoperability. This includes math characters not being supported universally, underscore and other indicators are not a standard, nor are alternative fonts.

·        There are legitimate needs for a standardized approach for interchange, accessibility (e.g. screen readers), search, twitter, et al. 

·        Evidence of the demand is perhaps demonstrated by the number of simulations, and the requests for how to implement it to vendors of plain text apps (such as twitter).

·        Supporting italics can be implemented without breaking existing documents and should be easily supported in modern Unicode apps.

·        The impact on the standard for adding a character for italics (and another for bold and perhaps a couple others) is miniscule as it fits into the VS model.

·        The argument that italics is rich text is an ideological one. However, as with other examples, there are cases where practicality should win out.

·        This isn’t a slippery slope.

 

Personally, I think the cost seems very low, both to the standard and to implementers. I don’t see a lot of risk that it will break apps. (At least not those that wouldn’t be broken by VS or other features in the standard.)

It will help many apps.

I think the benefits to interoperability, accessibility, search, standardization of text are significant.

 

Perhaps the question should be put to twitter, messaging apps, text-to-voice vendors, and others whether it will be useful or not.

If the discussion continues I would like to see more of a cost/benefit analysis. Where is the harm? What will the benefit to user communities be?

 

tex

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20190114/b6f03e08/attachment.html>