Re: bolder/lighter defintion

On Tue, May 19, 2009 at 10:33 AM, Thomas Phinney
<tphinney@cal.berkeley.edu> wrote:
> On Mon, May 18, 2009 at 7:16 PM, Stephen Zilles <szilles@adobe.com> wrote:
>> I do not think it is a big deal to map the above values to weights in the 100-900 range. In the above case, using the nearest greater multiple of 100 would give 200(175), 300, 400, 600(550), 700(650), 800. Then the existing rules in CSS 2.1 section 15.6 for filling the holes would make 100 be the same as 200 and 900 be the same as 800. This does not solve the issue of the "bolder/lighter" computed value skipping some weights; it only gives a way of making the above font work in the font matching algorithm. (Note that there were no weight collisions (two weights getting the same table entry) in the above font using the nearest greater multiple of 100, but one could see that such collisions might actually happen if weights are less than 100 units apart.)
>
> Just to explain more, the evils inflicted by GDI apps mean that
> weights below 250 don't work, *and* restrict what weights one can use
> when style-linking is involved to weird relationships.
>
> Cases where two weights in a family differ by less than 100 are not
> the most common, but are not at all unusual, either. For example,
> *any* family (in the Mac/Adobe/WPF sense) that works in Windows apps,
> and has two weights which are both lighter than "regular" will have
> two weights that differ by less than 100. Just off the top of my head,
> my own Hypatia Sans (registration incentive for Adobe's Creative Suite
> 3), Lithos (one of the most popular retail fonts on the planet, also
> bundled with CS apps), Gotham (the President's logo typeface) all have
> this characteristic.

While I would prefer a magically intelligent algorithm that selects
the font face I want no matter what, I now understand some of the
craziness and difficulties in font weights, and can accept this
hard-line mapping proposal.

~TJ

Received on Wednesday, 20 May 2009 04:13:13 UTC