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

Re: [patch] windows font antialiasing styles

Expand Messages
  • mattn
    One more request. You ve better to add part of feature-list like has( font_antialias ). :) Thanks for your work. -- -- You received this message from the
    Message 1 of 13 , Mar 14, 2013
      One more request.

      You've better to add part of feature-list like has('font_antialias'). :)
      Thanks for your work.

      --
      --
      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.
    • Ondrej Balaz
      Hi mattn, thanks for review. Good point, I m going to use #ifdef CLEARTYPE_QUALITY instead of WINVER. Regarding the feature-list - you mean to add
      Message 2 of 13 , Mar 17, 2013
        Hi mattn,

        thanks for review. Good point, I'm going to use #ifdef
        CLEARTYPE_QUALITY instead of WINVER. Regarding the feature-list - you
        mean to add has('has_cleartype') only for cleartype feature so the
        users are able to detect cleartype ability of their build and use same
        .vimrc on machines with/without it (yep that makes sense to me)? In
        original code antialiasing is always on if Windows provide it as
        PROOF_QUALITY was used instead of DEFAULT_QUALITY so it's hard to tell
        in runtime. Could you please send me pointer to source file where I
        can do the feature-list change? I seem a little lost in Vim codebase.
        :)

        Also, is there any register of Exxx error identifiers? How I can
        allocate one (simply grep and sort and take highest one?).

        Thanks

        On Fri, Mar 15, 2013 at 6:43 AM, mattn <mattn.jp@...> wrote:
        > One more request.
        >
        > You've better to add part of feature-list like has('font_antialias'). :)
        > Thanks for your work.
        >
        > --
        > --
        > 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.
        >
        >



        --
        Ondrej Balaz

        e-mail: blami@...
        GSM: (+420)-724-308-083
        jabber: blami@...
        skype: blami_
        twitter: http://twitter.com/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
        ... You must have special build runes. ;-) WinGDI.h checks for _WIN32_WINNT_WINXP as you say but the supplied Windows makefiles set WINVER to 0x0400 or
        Message 3 of 13 , Mar 18, 2013
          On 15/03/2013 05:40, mattn wrote:
          >> attached patch adds a new field called 'a' into guifont spec for
          >> gui_win32. This allows Windows user to control font antialiasing style
          >> in same fashion as Putty or Mintty does.
          >> As this is my first Vim patch and also my first patch for MS Windows
          >> related code I am not sure about MS SDK macro usage policy, precisely
          >> if I can use WINVER check directly in case of CLEARTYPE_QUALITY
          >> constant (which was introduced in 7.0A). If it is not good enough just
          >> tell me how to do it properly and I will rework my patch.
          >
          > Nice. It's working good for me. One thing, for about checking WINVER, I prefer to #ifdef CLEARTYPE_QUALITY. This make be possible to work on WindowsXP.

          You must have special build runes. ;-) WinGDI.h checks for
          _WIN32_WINNT_WINXP as you say but the supplied Windows makefiles set
          WINVER to 0x0400 or 0x0500 which map to NT4 and 2K, so the cleartype
          flag will not be compiled in by default.

          If Bram wants to keep VIM as backwardly compatible on Windows as
          possible (i.e.back to NT4 and 2K) then we can't support cleartype out of
          the box - these will have to be custom builds for more recent versions
          of Windows.

          (FWIW the cgwin/ming makefiles specify 0x0500 and borland/ms makefiles
          specify 0x0400 - this means there is a subtle difference in
          modify_fname() in eval.c depending on the compiler used, is that really
          intended? Hmm, if_ruby.c blats it for recent compilers, a workaround
          due to this problem? It's all getting messy here.)

          > static struct antialiasing_pair
          > antialiasing_pairs[] =
          > {
          > {"DEFAULT", DEFAULT_QUALITY},
          > {"NONE", NONANTIALIASED_QUALITY},
          > {"ANTIALIASED", ANTIALIASED_QUALITY},
          > #ifdef CLEARTYPE_QUALITY
          > {"CLEARTYPE", CLEARTYPE_QUALITY},
          > #endif
          > {NULL, 0}
          > };
          >


          Mike
          --
          Dragon, a lizard with indigestion.

          --
          --
          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.
        • George V. Reilly
          On Mon, Mar 18, 2013 at 4:58 AM, Mike Williams ... Let s not make life any harder for semi-modern versions of Windows at the expense of versions that have
          Message 4 of 13 , Mar 18, 2013
            On Mon, Mar 18, 2013 at 4:58 AM, Mike Williams
            <mike.williams@...> wrote:
            > If Bram wants to keep VIM as backwardly compatible on Windows as possible
            > (i.e.back to NT4 and 2K) then we can't support cleartype out of the box -
            > these will have to be custom builds for more recent versions of Windows.

            Let's not make life any harder for semi-modern versions of Windows at
            the expense of versions that have been obsolete for a decade. XP
            still has approximately one-third market share. Anything before that
            is lost in the noise. Anyone obdurate enough to run NT4 or Win2K can
            settle for Vim 7.3.800.
            --
            /George V. Reilly george@... Twitter: @georgevreilly
            http://www.georgevreilly.com/blog http://blogs.cozi.com/tech

            --
            --
            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.
          • Ondrej Balaz
            On Mon, Mar 18, 2013 at 12:58 PM, Mike Williams ... Good to know. What about removing the cleartype style from patch completely. As the most of Win7 and Win8
            Message 5 of 13 , Mar 18, 2013
              On Mon, Mar 18, 2013 at 12:58 PM, Mike Williams
              <mike.williams@...> wrote:
              > On 15/03/2013 05:40, mattn wrote:
              >>>
              >>> attached patch adds a new field called 'a' into guifont spec for
              >>> gui_win32. This allows Windows user to control font antialiasing style
              >>> in same fashion as Putty or Mintty does.
              >>> As this is my first Vim patch and also my first patch for MS Windows
              >>> related code I am not sure about MS SDK macro usage policy, precisely
              >>> if I can use WINVER check directly in case of CLEARTYPE_QUALITY
              >>> constant (which was introduced in 7.0A). If it is not good enough just
              >>> tell me how to do it properly and I will rework my patch.
              >>
              >>
              >> Nice. It's working good for me. One thing, for about checking WINVER, I
              >> prefer to #ifdef CLEARTYPE_QUALITY. This make be possible to work on
              >> WindowsXP.
              >
              >
              > You must have special build runes. ;-) WinGDI.h checks for
              > _WIN32_WINNT_WINXP as you say but the supplied Windows makefiles set WINVER
              > to 0x0400 or 0x0500 which map to NT4 and 2K, so the cleartype flag will not
              > be compiled in by default.

              Good to know. What about removing the cleartype style from patch
              completely. As the most of Win7 and Win8 installations come with
              cleartype enabled system-wide it will be still available through the
              'default' setting. Such patch will not change build-time compatibility
              from the previous state. Also, despite knowing the rule #1 'never
              predict what user may want' I assume that user who wants cleartype in
              Vim probably wants cleartype everywhere else so 'default' which is
              default is ok. Sounds this reasonable to you for retaining the
              pre-cleartype Windows compatibility?

              Regards,

              --
              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
              ... 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
              Message 6 of 13 , Mar 18, 2013
                On 18/03/2013 16:02, Ondrej Balaz wrote:
                > On Mon, Mar 18, 2013 at 12:58 PM, Mike Williams
                > <mike.williams@...> wrote:
                >> On 15/03/2013 05:40, mattn wrote:
                >>>>
                >>>> attached patch adds a new field called 'a' into guifont spec for
                >>>> gui_win32. This allows Windows user to control font antialiasing style
                >>>> in same fashion as Putty or Mintty does.
                >>>> As this is my first Vim patch and also my first patch for MS Windows
                >>>> related code I am not sure about MS SDK macro usage policy, precisely
                >>>> if I can use WINVER check directly in case of CLEARTYPE_QUALITY
                >>>> constant (which was introduced in 7.0A). If it is not good enough just
                >>>> tell me how to do it properly and I will rework my patch.
                >>>
                >>>
                >>> Nice. It's working good for me. One thing, for about checking WINVER, I
                >>> prefer to #ifdef CLEARTYPE_QUALITY. This make be possible to work on
                >>> WindowsXP.
                >>
                >>
                >> You must have special build runes. ;-) WinGDI.h checks for
                >> _WIN32_WINNT_WINXP as you say but the supplied Windows makefiles set WINVER
                >> to 0x0400 or 0x0500 which map to NT4 and 2K, so the cleartype flag will not
                >> be compiled in by default.
                >
                > Good to know. What about removing the cleartype style from patch
                > completely. As the most of Win7 and Win8 installations come with
                > cleartype enabled system-wide it will be still available through the
                > 'default' setting. Such patch will not change build-time compatibility
                > from the previous state. Also, despite knowing the rule #1 'never
                > predict what user may want' I assume that user who wants cleartype in
                > Vim probably wants cleartype everywhere else so 'default' which is
                > default is ok. Sounds this reasonable to you for retaining the
                > pre-cleartype Windows compatibility?

                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.

                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.

                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.

                Mike
                --
                Dragon, a lizard with indigestion.

                --
                --
                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.
              • Bram Moolenaar
                ... So long as we can give the user an error message. Not just crashing and giving the user the difficult task to find out why. -- hundred-and-one symptoms of
                Message 7 of 13 , Mar 18, 2013
                  George Reilly wrote:

                  > On Mon, Mar 18, 2013 at 4:58 AM, Mike Williams
                  > <mike.williams@...> wrote:
                  > > If Bram wants to keep VIM as backwardly compatible on Windows as possible
                  > > (i.e.back to NT4 and 2K) then we can't support cleartype out of the box -
                  > > these will have to be custom builds for more recent versions of Windows.
                  >
                  > Let's not make life any harder for semi-modern versions of Windows at
                  > the expense of versions that have been obsolete for a decade. XP
                  > still has approximately one-third market share. Anything before that
                  > is lost in the noise. Anyone obdurate enough to run NT4 or Win2K can
                  > settle for Vim 7.3.800.

                  So long as we can give the user an error message. Not just crashing and
                  giving the user the difficult task to find out why.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  63. You start using smileys in your snail mail.

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --
                  --
                  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.
                • 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 8 of 13 , Mar 19, 2013
                    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 9 of 13 , Mar 23, 2013
                      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.
                    • mattn
                      Bram, this thread is too old. But I still want this patch. Because some fonts will be rendered correctly with specifying ANTIALIASED_QUALITY or
                      Message 10 of 13 , Jan 4, 2016
                        Bram, this thread is too old. But I still want this patch. Because some fonts will be rendered correctly with specifying ANTIALIASED_QUALITY or CLEARTYPE_QUALITY instead of PROOF_QUALITY expressly. For example:

                        https://github.com/yascentur/RictyDiminished

                        This font is not rendered good with PROOF_QUALITY.

                        https://i.gyazo.com/c8979a10f27337d3f546bd7244244cc7.png

                        But this is rendered good with ANTIALIASED_QUALITY.

                        https://i.gyazo.com/e01fb1fee186b73305d7c901b3822367.png

                        If you prefer prefix "qXX" not "aXX", please use my patch.

                        https://gist.github.com/mattn/c9b429f98f3146364a94

                        - mattn

                        --
                        --
                        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/d/optout.
                      • Christian Brabandt
                        Hi mattn! ... I like the idea. BTW: I don t know, if I have ever mentioned that problem here, but I tried to use the relative new renderoption setting on a
                        Message 11 of 13 , Jan 4, 2016
                          Hi mattn!

                          On Mo, 04 Jan 2016, mattn wrote:

                          > Bram, this thread is too old. But I still want this patch. Because some fonts will be rendered correctly with specifying ANTIALIASED_QUALITY or CLEARTYPE_QUALITY instead of PROOF_QUALITY expressly. For example:
                          >
                          > https://github.com/yascentur/RictyDiminished
                          >
                          > This font is not rendered good with PROOF_QUALITY.
                          >
                          > https://i.gyazo.com/c8979a10f27337d3f546bd7244244cc7.png
                          >
                          > But this is rendered good with ANTIALIASED_QUALITY.
                          >
                          > https://i.gyazo.com/e01fb1fee186b73305d7c901b3822367.png
                          >
                          > If you prefer prefix "qXX" not "aXX", please use my patch.
                          >
                          > https://gist.github.com/mattn/c9b429f98f3146364a94

                          I like the idea.

                          BTW: I don't know, if I have ever mentioned that problem here, but I
                          tried to use the relative new renderoption setting on a system where I
                          installed my fonts using regfont¹ (basically a way to install fonts as a
                          user per session, without the need to become admin user to install the
                          fonts regularly). Unfortunately, when using this, then basically no text
                          will be rendered anymore and gvim does not show anything.

                          I tried debugging this with MS Visual Studio to trace the problem but I
                          could only see, that whenever a CreateFontIndirect() call was made, a
                          handle is returned that looks like this: 0xc011751 {unused=???}

                          I don't understand what this means or how to prevent this.

                          It would be great, if some Windows user, that knows the Win API better
                          than me and fix this ;)


                          Oh, and sorry for hijacking this thread.

                          ¹ http://www.marshwiggle.net/regfont


                          Best,
                          Christian
                          --
                          Wenn ein Schneeball ein Ball aus Schnee ist - was ist dann ein Fußball?

                          --
                          --
                          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/d/optout.
                        Your message has been successfully submitted and would be delivered to recipients shortly.