[Accepted with Revisions] SDL 0251 - Font Styles

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0251 - Font Styles" begins now and runs November 5, 2019. The original review of this proposal took place October 2 - 15, 2019. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0251-font-styles.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#828

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
[email protected]

[joeljfischer]

While I think that the idea is good, I'm not at all a fan of the implementation here.

1. The downside mentioned in the proposal I think is enough to reject the approach:

With this implementation, the whole line of text has to have the same font style. It's not possible to bold only a part of a line of text.

2. I'm not a fan of the repeated TextStyle structs that would need to be placed all over the place. One would need to be added for every string that can be modified.

3. This proposal needs to explicitly state each and every MOBILE_API change, and not just state things like:

InitialText for various RPCs.

Furthermore, how would this affect e.g. PerformInteraction? Only the title or initial search text can be modified? Nothing in the cells?

4. There's no discussion of capability declarations in this proposal and that would be required IMO.

5. I would think that the ScrollableMessage body would be one of the primary places this would be used, especially if text were permitted to be formatted inline.

6. As I said, the idea here is a good one. Instead of this approach, I would suggest something like the following (based on Alternative 1):

a. Design a markup language or simply use Markdown or HTML for strings (Markdown or HTML is probably preferred).
b. Declare whether the head unit supports that markup by returning a new capability in the window capability.
c. Perhaps set up a SetGlobalProperties for the app to declare if it wants to turn on / off markup support (with it off it'll render the markup as text). This is probably unnecessary since escape characters could just be used.
d. The downside mentioned of this approach is minimized because either (1) devs know not to send markup when connected to older systems, or (2) the app library managers can strip those tags when sent to head units that don't support them automatically (this is additional implementation work).
e. We can simply up the character limits if needed.

Perhaps others will disagree with me on this implementation approach, but I think it has much greater upside and simplicity compared to the proposed approach. Of course, there's additional burden on the HMI to parse the markup.

[Shohei-Kawano]

I think that it is a good idea because it improves readability by expressing bold, Italic, and Underline.
However, I think that it is not good that the SDL App side explicitly specifies the style.
I understand that my image of SDL is that HU has style, and SDL App send information only.

In other words:
I think that it is better to pass the attribute information such as title, caution, time, link , etc... instead of <b></b>, <i></i>, <u></u>, and HU display the style according to the attribute.
(It's hard to define...)

Code is below.
Current:
sdlManager.getScreenManager (). SetTextField1 ("Hello, this is MainField1.");
My idea:
sdlManager.getScreenManager (). SetTextField1 ("Hello, this is MainField1.", TEXT_PROPATY_TITLE);

[ghost]

Personally I like the idea of using hypertext format. As Joel suggested we could use TextField and add a bool param like hyperTextSupported. This would instantly add hyper text on any text field while the head unit can tell which one it supports. However there are a couple of concerns I have:

1. How much hyper text do we want to support? What elements should be available? b, i and u only? What about styles or even css?
2. How do we consider policies? Should we allow styling to all apps?
3. Font, family, color and size are more complicated than just make text bold, italic etc. Should we support hyper text fonts or rather look what @Shohei-Kawano suggested?
4. How do we know how much text is visible in a field when changing it's style?

[MichaelCrimando]

Great feedback @joeljfischer
I personally would prefer the HTML tag style especially since it's reasonably possible for OEMs to make a headunit based on HTML5. I just don't have the technical knowledge needed to write a proposal for that, nor do I know the complexity to implement it.

@Shohei-Kawano That's more or less what I'm going for with one of the alternatives. If we go that route, what would the actual list of styles be though?

@kshala-ford those are great questions. I did this proposal for bold, italic and underline as those are immediate asks that I've gotten and will be relatively simple to implement. I don't see any particular reason to get policies involved UNLESS we start getting more complex with styles. For example, font color or family starts encroaching on the UI design of the OEM headunit and would cause a lot more difficulty. To answer your last question - the same way that we do today - we don't know how much font fits regardless, an app has to test it

[Shohei-Kawano]

@MichaelCrimando -san
I think that it is better to extract from "HTML5 : Text-level semantics".
URL : https://www.w3.org/TR/html50/text-level-semantics.html

I would choose below:

• The "a" element (a : Anchor)
• The "em" element (em : Emphasis)
• The "strong" element
• The "small" element
• The "cite" element
• The "q" element (q : Quoted)
• The "time" element
• The "code" element ( May not be necessary for consumers )
• The "var" element ( May not be necessary for consumers )
• The "samp" element ( May not be necessary for consumers )
• The "kbd" element

I think that OEM decides how to display each element.

For example, in Japan, italics are not often used.
And, probably, the mainstream is red and bold when want to strong emphasize,
and bold when you want to just emphasize.

I think that the definition of expression differs depending on the country and OEM, so I think it is better to just send the attribute.

[joeljfischer]

I personally would prefer the HTML tag style especially since it's reasonably possible for OEMs to make a headunit based on HTML5.

The head unit does not have to be based on HTML5. The HMI would just have to have the ability to parse the simple HTML tags from the string and apply the styles. That doesn't require HTML at all and should be able to be done from a variety of systems. If we get much more complicated, then we do start requiring HTML browser HMIs which I think we should avoid.

To answer your last question - the same way that we do today - we don't know how much font fits regardless, an app has to test it

This is one of the primary problems with this proposal: there's no way that an app developer can test it against all of the SDL head units different manufacturers may implement. And if we go with @Shohei-Kawano's suggestions of more semantic naming, they won't have any idea how the text will appear.

With "bold", "italic", "underline", the developer has an idea of how the text will appear. With "strong", "emphasis", etc., they don't. It may appear in a way that violates their brand (such as appearing with colors that are outside of their palette or that look bad with their template color scheme.

If this proposal were to be accepted, I strongly advocate that the app developers need a set of predictable rules that they can use. e.g. strong will always appear bolded with their primary text color, emphasis will always appear in the standard text color either bolded or italic, etc.

7. Regarding font-face / styles / sizes / css etc. I see many problems with that approach. font-face is going to be very much based on what the OEM has on their platform unless we want to support uploading fonts which has manifold security risks (modern font-faces are just arbitrary code that has to be run). Font sizes / CSS bring us to the driver distraction issue. OEMs could restrict sizing (e.g. only allow 13pt. - 17pt.) but font points vary wildly based on the font.

8. Regarding @Shohei-Kawano's list of styles, I'm strongly against all of these as well outside of perhaps em and strong as replacements for italic and bold. The others simply don't make sense in a vehicle context. We shouldn't have users reading small, cite, quoted, time, anchor, code, var, samp, or kbd elements in the vehicle.

[theresalech]

The Steering Committee voted to return this proposal for revisions. The author will revise the proposal to move forward with using HTML tags for formatting individual parts of messages as mentioned in the Alternatives considered section, and this comment from the Project Maintainer. The revisions will also include the requirement that this feature be gated by a capability so that the head unit can declare whether or not it supports the feature, and that managers be updated to strip HTML tags if the feature is not supported by the head unit.

[theresalech]

The author has revised this proposal based on the Steering Committee's feedback, and the revised proposal is now in review until 2019-11-05.

[joeljfischer]

1. The TextFieldStruct section does not mention updating TextField with updates to the width parameter up from 500 to 1000 characters as well.
2. Technically the ScreenManager is a "manager of managers" that delegates all of its work and does not need to scan the strings. So that line can be removed.
3. The downside "This adds some HMI complexity and would require the SDL mobile libraries to handle translating the 1000 characters in text fields to 500 characters on older headunits" needs to be added to the proposed solution.

Other than those minor points, I'm in favor of this proposal.

[Jack-Byrne]

Also arrays use minsize and maxsize to describe the size requirements, not minvalue/maxvalue.

[theresalech]

The Steering Committee voted to accept this proposal with the revisions included in this comment and this comment. Additionally, the proposal revisions will include formatting specifications for the elements in the hyperTextSupported array. The author can work with the Project Maintainer to finalize this description.

[theresalech]

@MichaelCrimando Please advise when a new PR has been entered to update the proposal to reflect the agreed upon revisions. I'll then merge the PR so the proposal is up to date, and enter issues in the respective repositories for implementation. Thanks!

[theresalech]

Proposal has been updated to reflect agreed upon revisions, and implementation issues have been entered:
Core
RPC
iOS
Java Suite
JavaScript Suite
SDL HMI
Generic HMI