• Why integer-only font sizes?

    From Donald Arseneau@21:1/5 to All on Mon Oct 18 23:37:41 2021
    Does anyone know why [font configure ... -size $x] only accepts integer sizes? For negative (pixel) sizes, maybe that makes sense, but for positive
    (points) sizes it doesn't.

    Is it something that could be changed, or are there hard intrinsic constraints?

    --
    Donald Arseneau asnd@triumf.ca

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Donal K. Fellows@21:1/5 to Donald Arseneau on Tue Oct 19 02:08:00 2021
    On Tuesday, 19 October 2021 at 07:37:44 UTC+1, Donald Arseneau wrote:
    Does anyone know why [font configure ... -size $x] only accepts integer sizes?
    For negative (pixel) sizes, maybe that makes sense, but for positive (points) sizes it doesn't.

    Is it something that could be changed, or are there hard intrinsic constraints?

    It was probably because XLFDs were integer-based, but there's no real reason why we have to stick to this rule; the TkFontAttributes structure itself uses a double size field. The critical change would be to ParseFontNameObj() and ConfigAttributesObj()
    in tkFont.c, and possibly also TkFontParseXLFD() in the same file. I guess it didn't matter too much in the days when bitmapped fonts dominated and screens weren't very high resolution, but it does matter now. (It also seems that Windows's
    CreateFontIndirect call might be integer-restricted, and the other font engine implementations are sometimes rather lax about converting back and forth between integers and floats.)

    I'd guess this is fixable and would be really just a bug as the underlying model is right.

    Donal.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Tue Oct 19 13:23:09 2021
    Am 19.10.2021 um 11:08 schrieb Donal K. Fellows:
    On Tuesday, 19 October 2021 at 07:37:44 UTC+1, Donald Arseneau wrote:
    Does anyone know why [font configure ... -size $x] only accepts integer sizes?
    For negative (pixel) sizes, maybe that makes sense, but for positive
    (points) sizes it doesn't.

    Is it something that could be changed, or are there hard intrinsic constraints?

    It was probably because XLFDs were integer-based, but there's no real reason why we have to stick to this rule; the TkFontAttributes structure itself uses a double size field. The critical change would be to ParseFontNameObj() and ConfigAttributesObj()
    in tkFont.c, and possibly also TkFontParseXLFD() in the same file. I guess it didn't matter too much in the days when bitmapped fonts dominated and screens weren't very high resolution, but it does matter now. (It also seems that Windows's
    CreateFontIndirect call might be integer-restricted, and the other font engine implementations are sometimes rather lax about converting back and forth between integers and floats.)

    I'd guess this is fixable and would be really just a bug as the underlying model is right.

    Donal.


    Donal,
    thank you for the message. May I add the Windows usage of the font size.
    The EM-Height is given as an integer and the following formula may
    calculate it from the fonts PointSize: PointSize * dpi/72 where dpi is
    the resolution of the output device. If the output resolution is
    superior to 72dpi, font size has sub-integer values. Also, an integer
    PointSize may only be fully respected on device resolutions which have
    72 as divisor.

    As a side note, I would support to specify the font PointSize as a
    double. The code I had sent to Kevin to implement printing did that to.
    But printers have resolutions like 1200dpi, so many sub-ponitsizes may
    be respected.

    Take care,
    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)