Re: text-style to font mapping algorithm

• To: York@lucid.com
• Subject: Re: text-style to font mapping algorithm
• From: Meir Laker <meir@watson.ibm.com>
• Date: Mon, 07 Dec 92 15:04:29 -0500
• Cc: clim@BBN.COM, clim-support@lucid.com
• Reply-To: meir@watson.ibm.com

   Date: Fri, 4 Dec 92 18:30:50 PST
   From: york%oakland-hills@lucid.com (Bill York)

   The code is trying to find the "best" font for a given style, by
   which it means the one that it thinks comes closest to the size you
   specified.  It does this by looking at each font that matches the
   text style family (that is, all the "*-helvetica-*" fonts in your
   whole search path) and calculating the actual screen size for the
   font.  The calculation is based on the value of
   xlib:screen-height-in-millimeters and the sizing and resolution
   information built into the font name.

   Without knowing the screen-height-in-millimeters for your display I
   can't run the calculation, but my theory is that the linotype font
   is calculating out to be closer to 12 (the defined size for
   :NORMAL) than the adobe font in your environment.

You are correct.  On my RS/6000, the -linotype-helvetica font
calculates to 12.64148622047244 points high, whereas the
-adobe-helvetica font calculates to 11.061300442913387 points high.

So, the -linotype-helvetica should be a better font.  Unfortunately,
what "most people" would call :bold is called :normal by linotype and
their bold is like NEON LIGHTS!  I guess CLIM can't be expected to
handle lies!

Is anyone aware of code that computes the average luminoscity of a
font (how many pixels per square inch are covered) to determine just
how bold it really is.  Then, :BOLDER (as SWM mentioned in an earlier
post) might really be doable!

Thanks,

Meir


0,,

• Prev: DRAW-CIRCLE* bug inside WITH-ROTATION
• Next: Interrupting a process with a pointer press
• Index: CLIM Mailing list (1-Sep-92 to 31-Dec-92)
• Thread: CLIM Mailing list Index (1-Sep-92 to 31-Dec-92)