RE: A last missing link for interoperable representation

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

 
Received on Mon Jan 14 2019 - 04:08:26 CST