<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED --- - size specific design selection support in OS/2 table version 5"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=71287#c9">Comment # 9</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED --- - size specific design selection support in OS/2 table version 5"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=71287">bug 71287</a>
              from <span class="vcard"><a class="email" href="mailto:akira@tagoh.org" title="Akira TAGOH <akira@tagoh.org>"> <span class="fn">Akira TAGOH</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=71287#c8">comment #8</a>)
<span class="quote">> + lower_size = os2->usLowerOpticalPointSize / 20;
> + upper_size = os2->usUpperOpticalPointSize / 20;

> Float division instead?</span >

Ah, you're right. fixed.

<span class="quote">> + if (os2)
> + {
> + r = FcRangeCreateDouble (lower_size, upper_size);
> + if (!FcPatternAddRange (pat, FC_SIZE, r))

> If the range is not available (either old os2 or that the range is
> all-inclusive), then, NOT set size?  That would preserve most
> backward-compatibility.</span >

The default value for lower_size and upper_size is set to 0 and DBL_MAX as same
as freetype does for old os2 or the case where those properties are not
available. so should be no problem even with setting size. why we have to set
any value to SIZE would be rather not to get confused in the matcher because
it's the matter to affect the score now.
not sure for all-inclusive. after think of the use-case for bitmap fonts where
it may be more likely to see this situation, that sounds sane to behave like
this.

<span class="quote">> + if (FcRangeIsInRange (r1, r2))
> + ret = 0.0;
> + else
> + ret = fabs (r1->u.d.end - r2->u.d.end);

> This sounds wrong.  If not in-range, then we want min((r1.end - r2.start),
> abs(r1.start - r2.end)).  No?</span >

indeed. fixed.

<span class="quote">> These don't make much sense.  I suppose we can initially not implement any
> of these, and add as we need them.</span >

Sure. not too much objection on it.

<span class="quote">> I haven't done any testing or a full close review.  It's a bit unsettling
> how much boilerplate changes we need for this.  But, again, thanks for
> working on this.</span >

Thank you for the comments!

<a href="http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=new-size-selection-mechanism-4">http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=new-size-selection-mechanism-4</a></pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>