<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 21 September 2015 at 07:12, peter sikking <span dir="ltr"><<a href="mailto:peter@mmiworks.net" target="_blank">peter@mmiworks.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> - removing "make their texts communicate better and to”<br>
<br>
that snippet is rather important to me,  it is really a<br>
different kettle of fish than “refine their texts’ aesthetic<br>
and typographical qualities.”<br>
<br>
it moves on from the, to put it bluntly, decorative, which<br>
any cold-hearted boor will give exactly zero seconds consideration<br>
(‘nice to have’). what we are trying to make clear is that there are<br>
cases where otf make a difference between communicating successfully<br>
or not (a financial report where the numbers to not line up in columns<br>
is unreadable).<br>
<br>
now that I have written that, I know I have to put it<br>
better in the vision.<br></blockquote><div><br></div><div>Okay cool</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
btw: thinking through this, I do believe that the way the<br>
character entry – character encoding – standard font tables +<br>
mandatory (automatic) otf has come about, there are no cases<br>
where user-controllable otf _must_ be used to get just the<br>
correct glyph to display.<br>
<br>
if I am wrong about this, I would really appreciate a chat with<br>
an expert in this field.</blockquote><div><br></div><div>I think this depends on what you mean by "correct" glyphs; for example, tabular numbers may not be the default, instead proportional numbers, and in that case the unicode for the numbers will not result in a table that lines up in cols. I think 'unreadable' is an overstatement, but if true then I suppose it follows that this is  case where user control must be exercised to get to the 'correct' result. </div><div><br></div><div>(Of course, a program could have some 'smart' features to activate optional OpenType features when available, such as detecting a col of numbers, the availability of a tnum feature in the font, and thus activating it.) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> - distinguishing 2 classes of end-users, general public (eg slide deck editors like LibreOffice) and typographers (eg Scribus users)<br>
<br>
</span>of course that was in my notes, but during the writing of the<br>
vision I noticed that typographers are (duh) part of ‘everyone’<br>
and I could not come up with any value that has to be delivered<br>
to them that is _different_ than the ones named for everyone.<br>
(typographer _may_ need a different UI design than ‘general public’,<br>
but I can tell you that… when I get there).<br>
<br>
I am open to hearing about extra/special value for typographers<br>
(would be cool to have that clear).</blockquote></div><br>I agree its possible a single solution can work so worth waiting to see how the UI turns out<br><div><br></div>-- <br><div class="gmail_signature">Cheers<br>Dave</div>
</div></div>