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

Re: :hardcopy E673 in gVim on GTK2

Expand Messages
  • Benji Fisher
    ... I had problems with a similar setup (Linux/GTK2 and utf-8) but they were solved a while ago. I do not have any problem with the current version.
    Message 1 of 9 , May 1, 2006
    • 0 Attachment
      On Sun, Apr 30, 2006 at 09:19:01PM -0400, Steve Hall wrote:
      >
      > In every beta of gVim I've tried on Linux/GTK2 (through 70g) I get the
      > following error with :hardcopy :
      >
      > E673: Incompatible multi-byte encoding and character set.
      >
      > This is with utf-8 and latin1. My binary is feature-full, it includes
      > everything except:
      >
      > -ebcdic -footer -gettext -hangul_input -mouse_jsbterm -mzscheme
      > -osfiletype -sniff -sun_workshop -tag_any_white -tcl -xfontset
      > -xterm_save
      >
      > The runtime is soley the directory in the vim-7.0g.tar.bz tarball.
      > What am I doing wrong?

      I had problems with a similar setup (Linux/GTK2 and utf-8) but they
      were solved a while ago. I do not have any problem with the current
      version. (Actually vim 7.0f.)

      Have you set any of the print* options to non-default values? How
      about 'guifont'? Do you have problems with plain ASCII? What kind of
      printer do you have? Does

      :hardcopy > temp.ps

      work?

      HTH --Benji Fisher
    • dax2
      On Mon, 1 May 2006 08:39:25 -0400 ... A question: Is it possible to have ASCII (or C or POSIX) + UTF-8? latin-1 is an eight bit character set, one eight-bit
      Message 2 of 9 , May 1, 2006
      • 0 Attachment
        On Mon, 1 May 2006 08:39:25 -0400
        Benji wrote:

        > On Sun, Apr 30, 2006 at 09:19:01PM -0400, Steve Hall wrote:
        > >
        > > In every beta of gVim I've tried on Linux/GTK2 (through 70g) I get the
        > > following error with :hardcopy :
        > >
        > > E673: Incompatible multi-byte encoding and character set.
        > >
        > > This is with utf-8 and latin1.


        A question: Is it possible to have ASCII (or C or POSIX) + UTF-8?

        latin-1 is an eight bit character set, one eight-bit byte is
        mapping 256 characters. UTF-8 needs the high order bit for
        indicating we are going multi-byte.




        > > My binary is feature-full, it includes
        > > everything except:
        > >
        > > -ebcdic -footer -gettext -hangul_input -mouse_jsbterm -mzscheme
        > > -osfiletype -sniff -sun_workshop -tag_any_white -tcl -xfontset
        > > -xterm_save
        > >
        > > The runtime is soley the directory in the vim-7.0g.tar.bz tarball.
        > > What am I doing wrong?
        >
        > I had problems with a similar setup (Linux/GTK2 and utf-8) but they
        > were solved a while ago. I do not have any problem with the current
        > version. (Actually vim 7.0f.)
        >
        > Have you set any of the print* options to non-default values? How
        > about 'guifont'? Do you have problems with plain ASCII? What kind of
        > printer do you have? Does
        >
        > :hardcopy > temp.ps
        >
        > work?
        >
        > HTH --Benji Fisher


        --
        dax2-tele2adsl:dk -- http://d-axel.dk/ Donald Axel
      • Steve Hall
        ... Yes, the bug is in &printencoding. With gvim -u NONE -U NONE, these ... This is with the default utf-8, with :set enc=latin1 prior, it is avoided. -- Steve
        Message 3 of 9 , May 1, 2006
        • 0 Attachment
          On Mon, 2006-05-01 at 08:39 -0400, Benji Fisher wrote:
          > On Sun, Apr 30, 2006 at 09:19:01PM -0400, Steve Hall wrote:
          > >
          > > In every beta of gVim I've tried on Linux/GTK2 (through 70g) I get
          > > the following error with :hardcopy :
          > >
          > > E673: Incompatible multi-byte encoding and character set.
          > >
          > > This is with utf-8 and latin1. My binary is feature-full, it
          > > includes everything except:
          > >
          > > -ebcdic -footer -gettext -hangul_input -mouse_jsbterm -mzscheme
          > > -osfiletype -sniff -sun_workshop -tag_any_white -tcl -xfontset
          > > -xterm_save
          > >
          > > The runtime is soley the directory in the vim-7.0g.tar.bz tarball.
          > > What am I doing wrong?
          >
          > I had problems with a similar setup (Linux/GTK2 and utf-8) but they
          > were solved a while ago. I do not have any problem with the current
          > version. (Actually vim 7.0f.)
          >
          > Have you set any of the print* options to non-default values?

          Yes, the bug is in &printencoding. With gvim -u NONE -U NONE, these
          lines produce the error:

          :let &printencoding = &encoding
          :hardcopy

          This is with the default utf-8, with :set enc=latin1 prior, it is
          avoided.


          --
          Steve Hall [ digitect mindspring com ]
        • Benji Fisher
          ... Does that mean that the problem is solved now? HTH --Benji Fisher
          Message 4 of 9 , May 1, 2006
          • 0 Attachment
            On Mon, May 01, 2006 at 05:31:47PM -0400, Steve Hall wrote:
            >
            > Yes, the bug is in &printencoding. With gvim -u NONE -U NONE, these
            > lines produce the error:
            >
            > :let &printencoding = &encoding
            > :hardcopy
            >
            > This is with the default utf-8, with :set enc=latin1 prior, it is
            > avoided.

            Does that mean that the problem is solved now?

            HTH --Benji Fisher
          • Steve Hall
            ... Not at all in my mind, this is a bug! I m not sure what changed in 7.0, but this was always possible in 6.x. Was there actually a conversion happening
            Message 5 of 9 , May 2, 2006
            • 0 Attachment
              On Mon, 2006-05-01 at 22:15 -0400, Benji Fisher wrote:
              > On Mon, May 01, 2006 at 05:31:47PM -0400, Steve Hall wrote:
              > >
              > > Yes, the bug is in &printencoding. With gvim -u NONE -U NONE,
              > > these lines produce the error:
              > >
              > > :let &printencoding = &encoding
              > > :hardcopy
              > >
              > > This is with the default utf-8, with :set enc=latin1 prior, it is
              > > avoided.
              >
              > Does that mean that the problem is solved now?

              Not at all in my mind, this is a bug!

              I'm not sure what changed in 7.0, but this was always possible in 6.x.
              Was there actually a conversion happening automatically and Vim now
              refuses to hide it? To me, if &printencoding is not a valid option for
              :hardcopy, automatic conversion with a warning is better than just
              aborting on an error. (Which raises the question, what ARE the valid
              options for &printencoding?)


              --
              Steve Hall [ digitect mindspring com ]
            • Bram Moolenaar
              ... utf-8 is not a valid value for printencoding . It must be an 8-bit character set. The help mentions that it would fall back to latin1 when
              Message 6 of 9 , May 2, 2006
              • 0 Attachment
                Steve Hall wrote:

                > On Mon, 2006-05-01 at 22:15 -0400, Benji Fisher wrote:
                > > On Mon, May 01, 2006 at 05:31:47PM -0400, Steve Hall wrote:
                > > >
                > > > Yes, the bug is in &printencoding. With gvim -u NONE -U NONE,
                > > > these lines produce the error:
                > > >
                > > > :let &printencoding = &encoding
                > > > :hardcopy
                > > >
                > > > This is with the default utf-8, with :set enc=latin1 prior, it is
                > > > avoided.
                > >
                > > Does that mean that the problem is solved now?
                >
                > Not at all in my mind, this is a bug!
                >
                > I'm not sure what changed in 7.0, but this was always possible in 6.x.
                > Was there actually a conversion happening automatically and Vim now
                > refuses to hide it? To me, if &printencoding is not a valid option for
                > :hardcopy, automatic conversion with a warning is better than just
                > aborting on an error. (Which raises the question, what ARE the valid
                > options for &printencoding?)

                "utf-8" is not a valid value for 'printencoding'. It must be an 8-bit
                character set.

                The help mentions that it would fall back to "latin1" when
                'printencoding' is not a supported encoding, but this apparently doesn't
                happen.

                I don't know if the help should be updated (the error can be a useful
                hint why printing doesn't work as expected) or that Vim should fall back
                to "latin1" and perhaps print something weird. Falling back would be
                fine if you use only latin1 even when the encoding is utf-8.

                --
                BEDEVERE: Wait. Wait ... tell me, what also floats on water?
                ALL: Bread? No, no, no. Apples .... gravy ... very small rocks ...
                ARTHUR: A duck.
                "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ download, build and distribute -- http://www.A-A-P.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
              • Steve Hall
                From: Bram Moolenaar , May 2, 2006 9:22 AM ... This must have changed in 7.0, 6.4.10 and prior work fine. ... Your top line above would be
                Message 7 of 9 , May 2, 2006
                • 0 Attachment
                  From: Bram Moolenaar <Bram@...>, May 2, 2006 9:22 AM
                  >
                  > "utf-8" is not a valid value for 'printencoding'. It must be an
                  > 8-bit character set.
                  >
                  > The help mentions that it would fall back to "latin1" when
                  > 'printencoding' is not a supported encoding, but this apparently
                  > doesn't happen.

                  This must have changed in 7.0, 6.4.10 and prior work fine.

                  > I don't know if the help should be updated (the error can be a
                  > useful hint why printing doesn't work as expected) or that Vim
                  > should fall back to "latin1" and perhaps print something weird.
                  > Falling back would be fine if you use only latin1 even when the
                  > encoding is utf-8.

                  Your top line above would be appreciated at :help 'printencoding. Or
                  tweaking :help 'penc-option, it currently reads that with +multi_byte
                  and +iconv conversion is automatic. (Or maybe the bug prevents this?)


                  --
                  Steve Hall [ digitect mindspring com ]
                • Bram Moolenaar
                  ... Sorry, it s not true that printencoding must be an 8-bit encoding. You can use utf-8 , e.g., when printing Japanese. That is actually a new feature in
                  Message 8 of 9 , May 2, 2006
                  • 0 Attachment
                    Steve Hall wrote:

                    > > "utf-8" is not a valid value for 'printencoding'. It must be an
                    > > 8-bit character set.
                    > >
                    > > The help mentions that it would fall back to "latin1" when
                    > > 'printencoding' is not a supported encoding, but this apparently
                    > > doesn't happen.
                    >
                    > This must have changed in 7.0, 6.4.10 and prior work fine.
                    >
                    > > I don't know if the help should be updated (the error can be a
                    > > useful hint why printing doesn't work as expected) or that Vim
                    > > should fall back to "latin1" and perhaps print something weird.
                    > > Falling back would be fine if you use only latin1 even when the
                    > > encoding is utf-8.
                    >
                    > Your top line above would be appreciated at :help 'printencoding. Or
                    > tweaking :help 'penc-option, it currently reads that with +multi_byte
                    > and +iconv conversion is automatic. (Or maybe the bug prevents this?)

                    Sorry, it's not true that 'printencoding' must be an 8-bit encoding.
                    You can use "utf-8", e.g., when printing Japanese. That is actually a
                    new feature in Vim 7. And also why it was ignored in Vim 6.4, even
                    though it was an illegal value then.

                    This is an example where not giving an error message for an unsupported
                    value causes trouble when later supporting that value.

                    Mike, perhaps when checking the encoding the check for a matching
                    charset should also be done when 'printmbcharset' is empty. Using the
                    default charset then doesn't work.

                    --
                    If your company is not involved in something called "ISO 9000" you probably
                    have no idea what it is. If your company _is_ involved in ISO 9000 then you
                    definitely have no idea what it is.
                    (Scott Adams - The Dilbert principle)

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ download, build and distribute -- http://www.A-A-P.org ///
                    \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
                  Your message has been successfully submitted and would be delivered to recipients shortly.