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

Re: [qcad-user] Qcad-displaced objects?

Expand Messages
  • Eduard Werner/Edward Wornar
    ... I have never had this sort of problem. But anyway, I wouldn t *export* stuff only qcad needs because you might break things for other programs as a side
    Message 1 of 8 , Dec 29, 2006
    View Source
    • 0 Attachment
      Pjatk 29 decembra 200601:40 Andrew Mustun pisaše:
      > A possible fix might be to set the environment manually to something
      > other than German and then launching QCad from the same console:
      >
      > $ export LC_ALL=en_US.UTF-8
      > $ export LANG=en_US.UTF-8
      > $ locale
      > LANG=en_US.UTF-8
      > LC_CTYPE="en_US.UTF-8"
      > LC_NUMERIC="en_US.UTF-8"
      > LC_TIME="en_US.UTF-8"
      > LC_COLLATE="en_US.UTF-8"
      > LC_MONETARY="en_US.UTF-8"
      > LC_MESSAGES="en_US.UTF-8"
      > LC_PAPER="en_US.UTF-8"
      > LC_NAME="en_US.UTF-8"
      > LC_ADDRESS="en_US.UTF-8"
      > LC_TELEPHONE="en_US.UTF-8"
      > LC_MEASUREMENT="en_US.UTF-8"
      > LC_IDENTIFICATION="en_US.UTF-8"
      > LC_ALL=en_US.UTF-8
      > $ ./qcad

      I have never had this sort of problem. But anyway, I wouldn't *export* stuff
      only qcad needs because you might break things for other programs as a side
      effect, but just put it onto one line for a shell command (and LANG should
      not be relevant here):

      LC_ALL=en_US.UTF-8 qcad

      or

      LC_ALL=C qcad

      which you can easily put into

      a one-line script (named, say, Qcad) like

      #!/bin/sh
      LC_ALL=C
      /path/to/qcad.binary/qcad $*

      (variables stay local to script)

      Best regards

      Edi

      (who is still waiting for a reply about his - and not only his - printing
      issues)
    • Richard Lyons
      ... A minor point, but all of the non-anglophone world uses commas -- certainly all of non-anglophone Europe and the countries where French, Italian, Spanish
      Message 2 of 8 , Dec 30, 2006
      View Source
      • 0 Attachment
        On Fri, Dec 29, 2006 at 01:40:14AM +0100, Andrew Mustun wrote:

        > Hi,
        >
        > As far as I can tell this is a problem with a few German Linux
        > installations. It has to do with the fact that in Germany
        > a , (comma) is used as decimal point while the rest of the world
        > uses a . (point).

        A minor point, but all of the non-anglophone world uses commas --
        certainly all of non-anglophone Europe and the countries where French,
        Italian, Spanish etc are spoken. If there have been no other
        complaints, it is just that most of these people are used to having to
        reverse the notation for computer uses, which are so american-dominated.

        I haven't had this problem on my boxes with Italian keymapping, but I
        have had to use hybrid LC_* settings that retain anglo-saxon decimal
        marks. This is because I constantly use the command line entry of
        relative coordinates and it becomes impossible to enter '@100,9.5'
        with normal european settings. It is, however a real inconvenience
        when it comes to dimensioning drawings, as local builders are of
        course used to seeing decimal commas.

        Andrew: would it not be possible to simply filter the data between
        the dxf file and the rest of the application, and so be able to allow
        alternative decimal and separator characters? The most convenient
        arrangement would be if the three characters '@' ',' '.' could all be
        configuration variables.

        Obviously, the decimal and separator marks would be either one way or
        the other, but the 'at' sign is inconvenient on many keyboards and
        needed extremely frequently in qcad. So the option to customise it
        differently, depending on the local keymap, would be good.

        On the italian keyboard, for example, the '@' is accessed using
        right-alt plus another key, so it is less than optimal for the kind
        of use I make of qcad, where the majority of setting out work entails
        relative coordinates. Given the chance to customise it, I would choose
        an unmodified key such as '\' or o-grave or a-grave (right hand end of
        third row of the keyboard, and therefore handy) to specify relative
        coordinates. The 'at' sign is a good mnemonic for 'relative' in
        english, but the rest of the world do not know that the symbol has a
        meaning and call it by names which are as relevant as 'squiggle'
        or 'swirl' would be.

        I have not researched this, but I assume the < for polar coordinates
        is easy to access on most keyboards, and may not benefit from being
        customisable.

        --
        richard
      • Andrew Mustun
        ... Interesting.. I ve lived in Europe all my life and would never even think about using a comma although this seems to be indeed the official separator for
        Message 3 of 8 , Dec 30, 2006
        View Source
        • 0 Attachment
          Richard Lyons wrote:
          > On Fri, Dec 29, 2006 at 01:40:14AM +0100, Andrew Mustun wrote:
          >
          >> Hi,
          >>
          >> As far as I can tell this is a problem with a few German Linux
          >> installations. It has to do with the fact that in Germany
          >> a , (comma) is used as decimal point while the rest of the world
          >> uses a . (point).
          >
          > A minor point, but all of the non-anglophone world uses commas --
          > certainly all of non-anglophone Europe and the countries where French,
          > Italian, Spanish etc are spoken. If there have been no other
          > complaints, it is just that most of these people are used to having to
          > reverse the notation for computer uses, which are so american-dominated.

          Interesting.. I've lived in Europe all my life and would never even
          think about using a comma although this seems to be indeed the
          official separator for many countries, including those where I've
          lived.

          > I haven't had this problem on my boxes with Italian keymapping, but I
          > have had to use hybrid LC_* settings that retain anglo-saxon decimal
          > marks. This is because I constantly use the command line entry of
          > relative coordinates and it becomes impossible to enter '@100,9.5'
          > with normal european settings. It is, however a real inconvenience
          > when it comes to dimensioning drawings, as local builders are of
          > course used to seeing decimal commas.

          Yes, the dimension label format could be adjusted to display commas.
          I've added that to the TODO list - no promises though.

          > Andrew: would it not be possible to simply filter the data between
          > the dxf file and the rest of the application, and so be able to allow
          > alternative decimal and separator characters? The most convenient
          > arrangement would be if the three characters '@' ',' '.' could all be
          > configuration variables.

          Problem is that the comma is also used to separate x and y values when
          entering coordinates. Of course one could use / instead but slash is
          already used for divisions. Bottom line is that I think this would
          increase the confusion rather than solving the problem. Not even to
          mention that documentation and tutorials would no longer fit for
          people with such configurations.

          > Obviously, the decimal and separator marks would be either one way or
          > the other, but the 'at' sign is inconvenient on many keyboards and
          > needed extremely frequently in qcad. So the option to customise it
          > differently, depending on the local keymap, would be good.
          >
          > On the italian keyboard, for example, the '@' is accessed using
          > right-alt plus another key, so it is less than optimal for the kind
          > of use I make of qcad, where the majority of setting out work entails
          > relative coordinates. Given the chance to customise it, I would choose
          > an unmodified key such as '\' or o-grave or a-grave (right hand end of
          > third row of the keyboard, and therefore handy) to specify relative
          > coordinates. The 'at' sign is a good mnemonic for 'relative' in
          > english, but the rest of the world do not know that the symbol has a
          > meaning and call it by names which are as relevant as 'squiggle'
          > or 'swirl' would be.
          >
          > I have not researched this, but I assume the < for polar coordinates
          > is easy to access on most keyboards, and may not benefit from being
          > customisable.

          I'll make a note in the todo list about that. Thanks for pointing
          it out.

          Andrew
          --
        • Eduard Werner/Edward Wornar
          ... Qcad could honor the LOCALE settings here as defaults. ... How about using ; and : ? However, please distinguish between the UI and the file format.
          Message 4 of 8 , Dec 30, 2006
          View Source
          • 0 Attachment
            Sobotu 30 decembra 200616:23 Andrew Mustun pisaše:
            > > A minor point, but all of the non-anglophone world uses commas --
            > > certainly all of non-anglophone Europe and the countries where French,
            > > Italian, Spanish etc are spoken. If there have been no other
            > > complaints, it is just that most of these people are used to having to
            > > reverse the notation for computer uses, which are so american-dominated.

            Qcad could honor the LOCALE settings here as defaults.

            > Problem is that the comma is also used to separate x and y values when
            > entering coordinates. Of course one could use / instead but slash is
            > already used for divisions. Bottom line is that I think this would
            > increase the confusion rather than solving the problem. Not even to
            > mention that documentation and tutorials would no longer fit for
            > people with such configurations.

            How about using ';' and ':'?

            However, please distinguish between the UI and the file format. It's one of
            the most terrible "issues" in MS VB, XLS and friends that the comma separator
            makes it into the file format so a VB program might not run in a different
            country. (I am merely mentioning this because I do not know how much is
            specified by the dxf file format.)

            Edi
          • Markus Meyer
            ... The way, for example, Microsoft Excel solves this is that they use the semicolon as the separator in those countries where the decimal separator is a
            Message 5 of 8 , Dec 30, 2006
            View Source
            • 0 Attachment
              Andrew Mustun schrieb:
              > Problem is that the comma is also used to separate
              > x and y values when entering coordinates. Of course
              > one could use / instead but slash is already used for
              > divisions.

              The way, for example, Microsoft Excel solves this is that they use the
              semicolon as the separator in those countries where the decimal
              separator is a comma. Thus, for example a Excel formula for calculating
              the sum could either read "=SUM(1.23,2.34)" or "=SUMME(1,23;2,34)",
              depending on the locale.

              As for the displacement bug (which is not a user interface issue but a
              completely different problem): I do use Ubuntu Edgy too, and my locale
              setting is "LANG=de_DE.UTF-8" and I don't have this problem with QCad.
              That is, DXF files are written just fine (with dots in them, not
              commas). However, I do know this field of problem from my work on
              Audacity, a free sound editor. The problem is basically that glibc
              respects the decimal separator when the locale is set using setlocale().
              E.g., the following problem will output "0,500000" on my system:

              1 #include <stdio.h>
              2 #include <locale.h>
              3
              4 int main()
              5 {
              6 setlocale(LC_ALL, "");
              7 printf("%f\n", 0.5);
              8 }
              9

              When commenting out the call to setlocale(), it will output "0.5000000".
              Now you'll probably say that QCad never calls setlocale() and thus this
              is a non-issue. The problem is, that it is possible that some
              (ill-behaving) third-party library may call setlocale() in its startup
              code. This makes all further calls to, say, printf() use commas instead
              of dots.

              Thus, the problem may occur on some systems (because the ill-behaving
              third-party library calls setlocale()), but not on others (because
              another version of the third-party library does not call setlocale()).

              On Windows, this is not a problem. It seems that, for example, Microsoft
              Libc's printf() function always uses the dot regardless of the locale
              set via setlocale().

              There are two possible solutions to this problem:

              1. After intialization and startup, manually set back the locale
              setting, for example, call setlocale(LC_ALL, "C") or even only
              setlocale(LC_NUMERIC, "C"). The problem with this is two-fold: first,
              you don't know if the (ill-behaving) third-party library depends on its
              setlocale() setting and thus will not function properly if you set back
              the locale and second, you don't know when the illegal setlocale() call
              occurs, so you don't know for sure when to set it back.

              2. With Audacity, we use a conservative approach that we use our own
              custom functions for converting numbers to strings and back. This does
              NOT mean that we don't respect the user's locale setting -- infact, we
              do! It just means that we don't need to be unsure about whether, say,
              sprintf() will return a number with commas or dots in it, depending on
              the platform and locale used. Infact, this has the side effect of making
              life easier in many places. For example, the "%f" format specifier will
              behave very differently with respect to trailing zeros on Windows and Linux.

              I know that was probably off-topic (for a user's list anyway), but maybe
              it helps in getting a feeling for the problem.


              Markus
            • Ferenc Veres
              Hi all, ... And very often I enter coordinates in command line like this: @1,4,1,3 ... (And sometimes, when the difference from the expected and the actual
              Message 6 of 8 , Jan 2, 2007
              View Source
              • 0 Attachment
                Hi all,

                Eduard Werner/Edward Wornar wrote:
                > Sobotu 30 decembra 200616:23 Andrew Mustun pisaše:
                > > > A minor point, but all of the non-anglophone world uses commas --

                And very often I enter coordinates in command line like this:

                @1,4,1,3

                :-) And the program does not complain(!!), it draws my line to x=1 y=4.
                (And sometimes, when the difference from the expected and the actual
                result is not so big, I don't even realize the problem in time! :-( )

                So I would like to get, an error message in this case, "invalid numeric
                input, trailing characters", or something like that.

                I don't know what separator would be better, but an error message would
                help a lot too. (Not on file open, I am talking about command line input
                only.)

                Markus, thanks for the interesting explanation!

                Many thanks,
                Ferenc
              Your message has been successfully submitted and would be delivered to recipients shortly.