Loading ...
Sorry, an error occurred while loading the content.

Re: [patch] windows font antialiasing styles

Expand Messages
  • Ondrej Balaz
    Hi Mike, ... I ve noticed there s also MacOS X specific :set antialias=true/false option which might suit better and will be same across the supported
    Message 1 of 11 , Mar 19, 2013
    • 0 Attachment
      Hi Mike,

      > I think there is value in the patch. If VIM moves on the base supported
      > version of Windows to XP then we know cleartype can potentially be used.
      > Perhaps it would better with a simple control whether to anti-alias or not
      > (some people really don't want it at all). With anti-alias on check if
      > cleartype is enabled and if so use it, else use the normal anti-alias - if
      > cleartype has not been enabled it is not likely to have been set up for the
      > display so may look worse that normal anti-alias.

      > You should also be aware there is a patch floating around that lets VIM use
      > DirectWrite for text rendering which has a better font renderer and provides
      > more control on anti-aliasing. This does require Win7/2k8r2 or better.
      > There is potential here for having too many controls over text rendering if
      > we are not careful.

      I've noticed there's also MacOS X specific :set antialias=true/false
      option which might suit better and will be same across the supported
      platforms and not introducing another way to do the same. But when I
      started my patch I really wasn't sure if there are other places where
      guifont-like spec string can be used so I wanted to give user choice
      to use different styles per-font (I'm really not sure how e.g.
      guifontset works).

      I personally started the patch in order to avoid Cleartype, not to add
      it. As most of opensource fixed width fonts I use simply look bad and
      in putty or mintty I always disable antialiasing for them. Again, :set
      antialias=true/false does not work here as some fonts look ugly with
      Cleartype but just Antialiased is fine.

      > It would also be good to maintain existing behaviour (starting quality is
      > PROOF_QUALITY) which follows the principle of least surprise for existing
      > users. Also the default font settings are used for print font selection
      > which does not support cleartype. I have no idea what quality value it uses
      > in that case - default? It should stay at PROOF_QUALITY until we know more
      > about how it affects printing.
      >

      Aww, sure. I'm sorry about that, I've been testing DEFAULT_QUALITY
      with fonts other than Fixedsys and forget to revert that change. Also,
      'DEFAULT' in my patch should set PROOF_QUALITY as well as it maps to
      Vim's default behavior not the renderer's.

      Revised patch is attached. But I still don't know where should I start
      with has("cleartype") indicator.

      Thanks.

      --
      Ondrej Balaz

      e-mail: blami@...

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Mike Williams
      ... Never easy trying to solve a problem you don t know if you have. ;-) It would be better to separate font selection from font rendering, so working off of
      Message 2 of 11 , Mar 23, 2013
      • 0 Attachment
        On 20/03/2013 00:49, Ondrej Balaz wrote:
        > Hi Mike,
        >
        >> I think there is value in the patch. If VIM moves on the base supported
        >> version of Windows to XP then we know cleartype can potentially be used.
        >> Perhaps it would better with a simple control whether to anti-alias or not
        >> (some people really don't want it at all). With anti-alias on check if
        >> cleartype is enabled and if so use it, else use the normal anti-alias - if
        >> cleartype has not been enabled it is not likely to have been set up for the
        >> display so may look worse that normal anti-alias.
        >
        >> You should also be aware there is a patch floating around that lets VIM use
        >> DirectWrite for text rendering which has a better font renderer and provides
        >> more control on anti-aliasing. This does require Win7/2k8r2 or better.
        >> There is potential here for having too many controls over text rendering if
        >> we are not careful.
        >
        > I've noticed there's also MacOS X specific :set antialias=true/false
        > option which might suit better and will be same across the supported
        > platforms and not introducing another way to do the same. But when I
        > started my patch I really wasn't sure if there are other places where
        > guifont-like spec string can be used so I wanted to give user choice
        > to use different styles per-font (I'm really not sure how e.g.
        > guifontset works).

        Never easy trying to solve a problem you don't know if you have. ;-)

        It would be better to separate font selection from font rendering, so
        working off of the antialias setting would be better. We can't change
        it from its current boolean behaviour, so you would need a new setting,
        something like antialiasquality (antiq for short) taking a string with a
        single value. The set of values can then depend on the platform and
        possibly rendering engine.

        In your case setting noantialias would map to NONE. Setting antialias
        would then set the level based on antiq - an empty string would map to
        DEFAULT with the allowed options being default, antialias, and cleartype.

        If and when someone uses a guifontset on Windows and has problems with
        rendering between the fonts in the set then we can sort out a solution -
        possible no more than extending antiq to be a comma separated list of
        fontname followed by colon and the quality setting.

        > I personally started the patch in order to avoid Cleartype, not to add
        > it. As most of opensource fixed width fonts I use simply look bad and
        > in putty or mintty I always disable antialiasing for them. Again, :set
        > antialias=true/false does not work here as some fonts look ugly with
        > Cleartype but just Antialiased is fine.

        The old GDI font renderer does not produce the best results for fonts
        that have not been explicitly designed for it as you are aware. The new
        DirectWrite font renderer is much better but is limited to more recent
        versions of Windows, look back for the patch and give it a whirl and see
        what you think. Your patch will still be useful for those still using
        Win2K or XP.

        >> It would also be good to maintain existing behaviour (starting quality is
        >> PROOF_QUALITY) which follows the principle of least surprise for existing
        >> users. Also the default font settings are used for print font selection
        >> which does not support cleartype. I have no idea what quality value it uses
        >> in that case - default? It should stay at PROOF_QUALITY until we know more
        >> about how it affects printing.
        >>
        >
        > Aww, sure. I'm sorry about that, I've been testing DEFAULT_QUALITY
        > with fonts other than Fixedsys and forget to revert that change. Also,
        > 'DEFAULT' in my patch should set PROOF_QUALITY as well as it maps to
        > Vim's default behavior not the renderer's.

        There is still the issue of CLEARTYPE_QUALITY not being defined if
        WINVER is not at least 0x0501, which it is not by default currently.
        Until that issue is resolved you will need to hard code in a value for
        CLEARTYPE_QUALITY and check at runtime which version of Windows VIM is
        running on to see if it can be used.

        > Revised patch is attached. But I still don't know where should I start
        > with has("cleartype") indicator.

        I don't think this will work since support for cleartype will depend on
        the version of Windows VIM is running on, not if it has been compiled
        in. In which case what is needed is a function that reports the version
        of Windows (or possibly more generically the name/version of the
        platform VIM is running on) so checks on base versions can be made
        before trying to use a feature.

        Mike
        --
        Success has a million parents, failure is an orphan.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      Your message has been successfully submitted and would be delivered to recipients shortly.