<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body><div class="auto-created-dir-div" dir="ltr" style="unicode-bidi: embed;"><style>p{margin:0}</style><div>Hi Peter</div><p><br></p><p>Thank you for explaining.</p><p><br></p><p>I had been thinking about it further and I had decided that your idea was a much better way to do it. I was about to post to say so when I saw your later post.</p><p><br></p><p>Just to round things off.</p><p><br></p><p>> Would this be just to set the values to a default (since you mention a default in your other message)?</p><p><span style="display: inline !important; float: none; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0); font-family: arial,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre-wrap; word-spacing: 0px;"> <br/>Yes.<br/><br/>If I have understood what you have written I get the impression that implementing your idea might also have problems, except perhaps for printing of a hardcopy document directly from the application program, though perhaps it might also be possible to be useful if one makes an SVG graphic, converting text to curves and then importing the graphic and including it in a PDF document. This would depend upon the application, but, use for, say, a decorative border for a poem might be useful. So I hope that your idea will become widely implemented. Maybe it will become a widely used technique and that my suggestion will simply be a like booster rocket that led to your idea being published and discussed and implemented.<br/><br/>Anyway, thank you again for replying to my ideas and to my comments. I have enjoyed discussing it all and I feel that I have learned a lot.<br/><br/>Best regards,<br/><br/>William Overington<br/><br/>Friday 22 January 2021<br/><br/></span><br></p><blockquote style="margin: 0 auto; padding: 0 2em; border-left:2px solid #00ADE5; white-space: pre-wrap "><br><br>------ Original Message ------<br>From: "Peter Constable" <pgcon6@msn.com><br>To: "William_J_G Overington" <wjgo_10009@btinternet.com>; "mpeg-otspec@lists.aau.at" <mpeg-otspec@lists.aau.at><br>Sent: Friday, 2021 Jan 22 At 20:02<br>Subject: RE: [MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.<br><br> <div class="WordSection1"> <p class="MsoNormal">William</p> <p class="MsoNormal"> </p> <p class="MsoNormal">It would be relatively quite easy for the creator of a font development tool to add UI for the font designer to specify colours for your “dec col 1”, etc. However, I thought the point was to have colours that can be controlled by the end user, not the font developer. Would this be just to set the values to a default (since you mention a default in your other message)?</p> <p class="MsoNormal"> </p> <p class="MsoNormal">Assigning colour values to FFFD and FFFE would be problematic. In the case of FFFF, no colour value is specified in the font at all, and that is a necessary assumption. The reason is that, if a value were specified in the font for FFFF, it would imply that there must be 65536 entries in every CPAL palette. That would be extremely wasteful. Because FFFF refers to a colour that is only specified _<i>outside the font</i>_, there is no need to have for FFFF to be a valid index into the color record array. The same would apply to FFFD and FFFE: If you want to give FFFD a special meaning but also allow the font creator to assign a default colour that gets recorded in the font, then it would have to be recorded in the 65534<sup>th</sup> color record. Either that, or else the formats would need to be changed to add special fields in the CPAL table that store only the “dec col 1” etc. values.</p> <p class="MsoNormal"> </p> <p class="MsoNormal">But this still doesn’t address the problems that exist for users. With FFFF, a content author specifies text foreground colour in their content. Every document format that supports rich (styled) text will include some means of storing the text foreground colour styling. If a content author needs to specify “dec col 1”, etc., then not only do font specs need to define that but now content formats also need to define a way for that author-determined information to be conveyed as part of the content; and applications for viewing the content would need to support that. For example, CSS would need a way to specify “dec col 1”, and browsers would need to read and apply it when displaying text with a colour font. IOW, you’d have to sell your idea to a lot of other groups than just those involved in defining OFF or OpenType.</p> <p class="MsoNormal"> </p> <p class="MsoNormal">For a spec like CSS that gets used in many contexts and implemented in many applications, selling that would be an uphill challenge. For an app that uses a proprietary content format, e.g., Affinity Designer (ignoring for the moment any export to other formats), because they own their proprietary format there isn’t a need for industry-wide agreement on interoperable formats. But then we’re into a scenario in which it would make just as much sense for the app to give the content author complete control over the colour palette used by a given font. The cost for them to create the UI and define ways in their document format to represent the choices are comparable.</p> <p class="MsoNormal"> </p> <p class="MsoNormal"> </p> <p class="MsoNormal"> </p> <p class="MsoNormal">Peter</p> <p class="MsoNormal"> </p> <div> </div></div></blockquote></div></body></html>