<!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><div><br></div><p>Thank you for replying. I had not seen your email until after I had sent my previous email.</p><p><br></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; line-height: 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;"><p>> I believe the terminology used in the spec is clear and that no additional terminology is needed.<br/><br/>Fine, I accept your expert opinion.<br/><br/>> How concepts are referred to in font development tools is up to the designers of those tools.<br/><br/>Again I accept your expert opinion.<br/><br/>There does however remain the parlance available in more generic textual contexts, including my novel, general manuals on fontmaking and so on. It would be good if someone could move from one proprietary brand of fontmaking software to another proprietary brand to a generic text book and be able to use the same parlance and not need to keep learning different parlance for each. So maybe the parlance used in my novel will become the norm, maybe not, maybe there will not be a norm.<br/><br/>>> Does the system now allow/ will you please consider allowing, similar 'tunnel through' colours</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;"> </span></p><p class="MsoNormal" style="box-sizing: border-box; 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; line-height: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; 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;">> I don’t think defining specific palette index values as special “accent” colours is such a good idea.<br/><br/>Well, that is one vote for and one vote against. So maybe others will vote too, and we can note the result.<br/><br/>> Whereas all text necessarily has some “foreground” colour, that is not the case for “accent” colours: in many contexts, they simply will not be defined, and so there would be no predictability as to how they would appear. <br/><br/>Actually I think that that is not necessarily the case, because dec col 1 and dec col2 would each have a default colour in the specification and a fontdesigner could change either or both of those colours during the fontmaking process. So an application program would always have a default colour provided to it for dec col 1 and dec col 2 as if they were any other colours.<br/><br/>> <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; line-height: 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;">And in such applications, there is nothing to prevent the application from providing UI for users to define custom palettes that get used instead of the palettes in the CPAL table.<br/><br/>Well, that sounds like a good idea. I had not thought of that.<br/><br/>> Since the usage scenarios for your feature would only make sense for such apps that have UI for content palettes, I think having such apps allow the user to define the palette for the font makes the most sense.<br/><br/>Well, the idea is before the group so let us leave the matter open and hopefully get some more views from the group.<br/><br/>Whichever way it goes maybe in one way or another the display effects in the end user produced document that can be produced by application software will be enhanced because of ideas people get implemented as a result of this discussion. In fairness it does seem to me that your suggestion would also work using COLRv0 fonts as well as COLRv1 fonts whereas my suggestion would not work with COLRv0 fonts even if my suggestion were to be accepted for COLRv1, so that seems a big advantage for your idea in the short term at least and maybe in the long term too.<br/><br/>Best regards,<br/><br/>William Overington<br/><br/>Friday 22 January 2021<br/><br/><br/><br/><br/></span><br/><br/><br/></p><p><br/><br/><br/></p></span><p><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></p><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br><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 16:47<br>Subject: RE: [MPEG-OTSPEC] Requesting progress update on COLRv1 in fontTools, FreeType, etc.<br><br> <div class="WordSection1"> <p class="MsoNormal">Hi, William</p> <p class="MsoNormal"> </p> <p class="MsoNormal">I believe the terminology used in the spec is clear and that no additional terminology is needed. How concepts are referred to in font development tools is up to the designers of those tools.</p> <p class="MsoNormal"> </p> <p class="MsoNormal">> Does the system now allow/ will you please consider allowing, similar 'tunnel through' colours</p> <p class="MsoNormal"> </p> <p class="MsoNormal">I don’t think defining specific palette index values as special “accent” colours is such a good idea. Whereas all text necessarily has some “foreground” colour, that is not the case for “accent” colours: in many contexts, they simply will not be defined, and so there would be no predictability as to how they would appear. </p> <p class="MsoNormal"> </p> <p class="MsoNormal">There are certain applications, such as PowerPoint, that have content colour palettes that would provide “accent” colours, but such applications are very much the exception. And in such applications, there is nothing to prevent the application from providing UI for users to define custom palettes that get used instead of the palettes in the CPAL table. Since the usage scenarios for your feature would only make sense for such apps that have UI for content palettes, I think having such apps allow the user to define the palette for the font makes the most sense.</p><p class="MsoNormal"> </p> <p class="MsoNormal"> </p> <p class="MsoNormal">Peter</p> <p class="MsoNormal"> </p> <p class="MsoNormal"> </p> <div> <div style="border: none;border-top: solid rgb(225,225,225) 1.0pt;padding: 3.0pt 0.0in 0.0in 0.0in;"> <p class="MsoNormal"><b></b><br></p></div><p><br></p><p><br></p><p><br></p></div></div></blockquote></div></body></html>