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

Re: On 16x16 document icons

Expand Messages
  • Nico Weber
    ... I misunderstood Damien: he does not want Envy Code R Bold to be in our repository (but he might allow us to add a font he s currently working on, once he s
    Message 1 of 20 , Feb 1, 2009
    • 0 Attachment
      > Unfortunately it doesn't. The function
      > ATSFontActivateFromFileReference() is new to OS X 10.5. Maybe you can
      > somehow not compile loadfont.c on 10.4? (Or use the old API, but
      > that's kind of silly since the function won't be called anyway.)


      I misunderstood Damien: he does not want Envy Code R Bold to be in our
      repository (but he might allow us to add a font he's currently working
      on, once he's done – even more awesome!). In the meantime, the
      attached version of the patch simply assumes that Envy Code R Bold is
      installed (else, it falls back to the old docicons). This means the
      people building MacVim have to download it from http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
      before building.

      This conveniently makes the Tiger-compatibility of loadfont.c a moot
      point for now; I will revisit this once it becomes necessary.

      Nico


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Niklas Lindström
      ... Would it be ok to add something like: ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip if [[ ! -e EnvyCodeR.zip ]]; then curl
      Message 2 of 20 , Feb 1, 2009
      • 0 Attachment
        On Mon, Feb 2, 2009 at 5:14 AM, Nico Weber <nicolasweber@...> wrote:
        > I misunderstood Damien: he does not want Envy Code R Bold to be in our
        > repository (but he might allow us to add a font he's currently working
        > on, once he's done – even more awesome!). In the meantime, the
        > attached version of the patch simply assumes that Envy Code R Bold is
        > installed (else, it falls back to the old docicons). This means the
        > people building MacVim have to download it from http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
        > before building.

        Would it be ok to add something like:

        ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip
        if [[ ! -e 'EnvyCodeR.zip' ]]; then
        curl $ENVYCODE_URL -o EnvyCodeR.zip
        unzip EnvyCodeR.zip
        fi

        to the build process?

        (Thanks for the great work btw!)

        Best regards,
        Niklas

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Nico Weber
        ... That s a great idea. I asked, and it s ok. Hooray. The attached patch grabs the font file through curl and then loads the font from the ttf file. I tried
        Message 3 of 20 , Feb 2, 2009
        • 0 Attachment
          > Would it be ok to add something like:
          >
          > ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip
          > if [[ ! -e 'EnvyCodeR.zip' ]]; then
          > curl $ENVYCODE_URL -o EnvyCodeR.zip
          > unzip EnvyCodeR.zip
          > fi
          >
          > to the build process?

          That's a great idea. I asked, and it's ok. Hooray.

          The attached patch grabs the font file through curl and then loads the
          font from the ttf file. I tried to fix the tiger build problems too; I
          hope that worked out.

          Nico


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Nico Weber
          ... This patch has now been merged. I pulled the latest version from the repo today on a machine that had both python 2.4 and 2.5 installed, and for some
          Message 4 of 20 , Feb 5, 2009
          • 0 Attachment
            > The attached patch grabs the font file through curl and then loads the
            > font from the ttf file. I tried to fix the tiger build problems too; I
            > hope that worked out.

            This patch has now been merged.

            I pulled the latest version from the repo today on a machine that had
            both python 2.4 and 2.5 installed, and for some reason the loadfont
            module was compiled with 2.4 but the script executed with 2.5, which
            resulted in a crash.

            The attached patch makes compilation of the loadfont module more
            portable. I first added a few additional parameters to the gcc
            invocation in the makefile, but that will probably cause other
            problems in the future. Instead, the patch now uses python's
            distutils, which is the recommended way to build C extensions for
            python. With this patch, the crash went away and the icons were
            generated correctly.

            Nico


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... Thanks Nico, I ve merged this patch. I did notice one _very_ minor thing: if you type make twice in a row, then the second (and any consequtive calls to)
            Message 5 of 20 , Feb 6, 2009
            • 0 Attachment
              2009/2/6 Nico Weber:
              >> The attached patch grabs the font file through curl and then loads the
              >> font from the ttf file. I tried to fix the tiger build problems too; I
              >> hope that worked out.
              >
              > This patch has now been merged.
              >
              > I pulled the latest version from the repo today on a machine that had
              > both python 2.4 and 2.5 installed, and for some reason the loadfont
              > module was compiled with 2.4 but the script executed with 2.5, which
              > resulted in a crash.
              >
              > The attached patch makes compilation of the loadfont module more
              > portable. I first added a few additional parameters to the gcc
              > invocation in the makefile, but that will probably cause other
              > problems in the future. Instead, the patch now uses python's
              > distutils, which is the recommended way to build C extensions for
              > python. With this patch, the crash went away and the icons were
              > generated correctly.

              Thanks Nico, I've merged this patch. I did notice one _very_ minor
              thing: if you type make twice in a row, then the second (and any
              consequtive calls to) "make" will unpack the font zip file again. Any
              idea why this is?

              Björn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Nico Weber
              ... No idea. (couple minutes pass) This is because `unzip` uses the file modification date from the zip file, see: $ ls -l Envy* -rw-r--r-- 1 thakis eng
              Message 6 of 20 , Feb 6, 2009
              • 0 Attachment
                > Thanks Nico, I've merged this patch.  I did notice one _very_ minor
                > thing: if you type make twice in a row, then the second (and any
                > consequtive calls to) "make" will unpack the font zip file again.  Any
                > idea why this is?

                No idea. (couple minutes pass) This is because `unzip` uses the file
                modification date from the zip file, see:

                $ ls -l Envy*
                -rw-r--r-- 1 thakis eng 83856 May 26 2008 Envy Code R Bold.ttf
                -rw-r--r-- 1 thakis eng 172849 Feb 5 10:30 EnvyCodeR.zip

                Hence, make thinks the zip file is newer than the ttf file and unpacks
                it again. I can't find a flag that tells unzip to set the extraction
                date on the files it creates, but the patch of this mail works around
                the problem.

                Nico

                ps: Not a real patch; group's web interface doesn't support
                attachments:

                --- a/src/MacVim/icons/Makefile
                +++ b/src/MacVim/icons/Makefile
                @@ -11,6 +11,9 @@ loadfont.so: loadfont.c

                Envy\ Code\ R\ Bold.ttf: EnvyCodeR.zip
                unzip -jo EnvyCodeR.zip
                + # unzip uses the file date from the zip file. Change the file
                date to
                + # "now", so that the zip is not unzipped in every `make` run.`
                + touch Envy\ Code\ R\ Bold.ttf

                ENVYCODE_URL=http://download.damieng.com/latest/EnvyCodeR
                EnvyCodeR.zip:


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... Thanks, I have merged and pushed the patch. Björn --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_mac
                Message 7 of 20 , Feb 6, 2009
                • 0 Attachment
                  2009/2/6 Nico Weber:
                  >
                  >> Thanks Nico, I've merged this patch. I did notice one _very_ minor
                  >> thing: if you type make twice in a row, then the second (and any
                  >> consequtive calls to) "make" will unpack the font zip file again. Any
                  >> idea why this is?
                  >
                  > No idea. (couple minutes pass) This is because `unzip` uses the file
                  > modification date from the zip file, see:

                  Thanks, I have merged and pushed the patch.

                  Björn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Tobia Conforto
                  Sorry for the late reply I think the green, bold icons (Option 3. in the OP) look awesome. I d rather have all icons green, as a hint that the file will be
                  Message 8 of 20 , Feb 12, 2009
                  • 0 Attachment
                    Sorry for the late reply

                    I think the green, bold icons (Option 3. in the OP) look awesome. I'd
                    rather have all icons green, as a hint that the file will be opened
                    with MacVim.

                    A suggestion: I don't know if it's feasible with the API you're using,
                    but I would shift the text 0.5 pixels to the left (or maybe 0.333 or
                    0.667 pixels) I think it would make it more readable and better
                    centered, especially for 3 char extensions.

                    All in all, a very good job!

                    Tobia

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Nico Weber
                    Hi Tobia, ... this is now in snapshot 43 :-) ... I agree, but I couldn t get this to work with Cocoa. I tried passing fractional coordinates to -[NSString
                    Message 9 of 20 , Feb 22, 2009
                    • 0 Attachment
                      Hi Tobia,

                      > I think the green, bold icons (Option 3. in the OP) look awesome.  I'd  
                      > rather have all icons green, as a hint that the file will be opened  
                      > with MacVim.

                      this is now in snapshot 43 :-)

                      > A suggestion: I don't know if it's feasible with the API you're using,  
                      > but I would shift the text 0.5 pixels to the left (or maybe 0.333 or  
                      > 0.667 pixels)  I think it would make it more readable and better  
                      > centered, especially for 3 char extensions.

                      I agree, but I couldn't get this to work with Cocoa. I tried passing
                      fractional coordinates to -[NSString drawAtPoint:withAttributes:]
                      directly, and I also tried using a fractional translational
                      NSAffineTransform. It seems that Cocoa truncates the coordinate before
                      drawing the text.

                      Nico
                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Tobia Conforto
                      ... That s a shame. What about putting some fractional space before the text and shifting the coordinates to the left? Unicode has several space characters,
                      Message 10 of 20 , Feb 23, 2009
                      • 0 Attachment
                        Nico Weber wrote:
                        > I agree, but I couldn't get this to work with Cocoa. I tried passing
                        > fractional coordinates to -[NSString drawAtPoint:withAttributes:]
                        > directly, and I also tried using a fractional translational
                        > NSAffineTransform. It seems that Cocoa truncates the coordinate
                        > before drawing the text.

                        That's a shame. What about putting some fractional space before the
                        text and shifting the coordinates to the left? Unicode has several
                        space characters, some of which are quite tiny:

                        U+0020 space
                        U+2002 en space
                        U+2003 em space
                        U+2004 three-per-em space
                        U+2005 four-per-em space
                        U+2006 six-per-em space
                        U+2007 figure space
                        U+2008 punctuation space
                        U+2009 thin space
                        U+200A hair space

                        -Tobia

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      Your message has been successfully submitted and would be delivered to recipients shortly.