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

Re: [AutoTrace] 0.31

Expand Messages
  • Masatake YAMATO
    Sorry for late to answer. And thank you for your commmets. ... I ll use gdk-pixbuf-0.7 that is not part of gtk+-2.0. I think the most of GNU/Linux distro
    Message 1 of 21 , Mar 31, 2002
    • 0 Attachment
      Sorry for late to answer.
      And thank you for your commmets.

      > How many other library do these two depend on? I mean, usually gtk libs do
      > depend on many other gtk libraries. I'd like to avoid the situation where
      > I have to wait updating gtk-gnome because one program I use works with an
      > old version of a gtk library, or the other way around.
      > If the freeimage situation is better (and the library is good) I'd use it:
      > it's always better to ask the user to add a "stand-alone" library than one
      > that's part of one of the most complex susbystem we have in Open Source
      > today.

      I'll use gdk-pixbuf-0.7 that is not part of gtk+-2.0.
      I think the most of GNU/Linux distro contains gdk-pixbuf-0.7.

      > > 3.2 New bitmap data structure in C++? (Martin)
      > > ----------------------------------------------------------
      > > 3.3 Autotrace core in C++ (Martin)
      > > ----------------------------------------------------------
      > > 3.4 New splines data structure in C++? (Martin)
      >
      > More than "data structure", if we're going to use C++, it'll be "Objects".

      Yes. I'm wrong.

      > We have then to write some code to serialize the objects (save them) in a
      > series of lists that are C compatible.

      Yes. However..."series of lists" is kind of a data stricture even if it
      is simple data stricture. I think "series of lists" should be defined
      in "Splines Writer". See next.

      > =============================================================
      > > 4. Splines Writer(libsw, renamed from libgow, any good name?)
      > > 4.1 Splines data structure in C(Masatake?)
      >
      > I'd say the Splines data structures are to be declared in 3.4 (where you
      > can access C++ Objects) and accessed from 4.1.

      I don't think so. Splines Writer is a general library. It is not
      only for autotrace. Other client programs will use Splines Writer.
      Therefore, other client programs will construct "Splines data structure(
      == simple data stricture)". If the definition of the "Splines data structure"
      is part of autotrace as you say, other client programs must be linked
      with libautotrace in that the "Splines data structure" is defined.

      I have found an interesting thing on the net.
      I'll report it next.

      Masatake YAMATO
    • Masatake YAMATO
      I ve found that pstoedit is very useful for improving autotrace. pstoedit is a program(and library!) translate ps and pdf input to other formats includeing ...
      Message 2 of 21 , Mar 31, 2002
      • 0 Attachment
        I've found that pstoedit is very useful for improving autotrace.

        pstoedit is a program(and library!) translate ps and pdf input
        to other formats includeing ... too many. See
        http://www.pstoedit.net/pstoedit/

        We can you pstoedit as a general output backend for autotrace
        like imagemagick as a general input for autotrace.

        Further more, pstoedit provides what I need in the spline writer.
        From readme.txt of pstoedit_3.31/:

        The architecture of pstoedit consists of a PostScript frontend which
        needs to call a PostScript interpreter like Ghostscript and the
        individual backends which are plugged into a kind of framework.

        This framework can be used independently from the PostScript frontend
        from any other program. The framework provides a uniform interface to
        all different backends. Get in contact with the author if you need
        more information on how to use this framework.

        pstoedit could be distributed under GPL.
        We can link autotrace with it.

        pstoedit could be compiled on Windows. Too nice.

        I'll inspect the pstoedit and write a bridge between autotrace.
        It seems that some of output writers written by Martin and other are
        not supported in pstoedit or supported but shareware. I'll export
        output writers not supported in pstoedit but supported in autotrace
        to pstoedit. I've found the power of opensource again.

        Masatake
      • Иван Лох
        ... Really, pstoedit do no not support all format in free version. There is not any SVG support now.
        Message 3 of 21 , Mar 31, 2002
        • 0 Attachment
          > I've found that pstoedit is very useful for improving autotrace.
          >
          > pstoedit is a program(and library!) translate ps and pdf input
          > to other formats includeing ... too many. See
          > http://www.pstoedit.net/pstoedit/
          >
          > We can you pstoedit as a general output backend for autotrace
          > like imagemagick as a general input for autotrace.
          >
          Really, pstoedit do no not support all format in free version. There is not
          any SVG support now.
        • Martin Weber
          I think using gdk-pixbuf as also of other libaries is okay for input or output as long as we work with define statements to make shure that it could also be
          Message 4 of 21 , Mar 31, 2002
          • 0 Attachment
            I think using gdk-pixbuf as also of other libaries is okay for input or
            output
            as long as we work with define statements to make shure that it could
            also be
            compiled without.

            Martin

            Masatake YAMATO schrieb:

            > Sorry for late to answer.
            > And thank you for your commmets.
            >
            > > How many other library do these two depend on? I mean, usually gtk libs do
            > > depend on many other gtk libraries. I'd like to avoid the situation where
            > > I have to wait updating gtk-gnome because one program I use works with an
            > > old version of a gtk library, or the other way around.
            > > If the freeimage situation is better (and the library is good) I'd use it:
            > > it's always better to ask the user to add a "stand-alone" library than one
            > > that's part of one of the most complex susbystem we have in Open Source
            > > today.
            >
            > I'll use gdk-pixbuf-0.7 that is not part of gtk+-2.0.
            > I think the most of GNU/Linux distro contains gdk-pixbuf-0.7.
            >
            > > > 3.2 New bitmap data structure in C++? (Martin)
            > > > ----------------------------------------------------------
            > > > 3.3 Autotrace core in C++ (Martin)
            > > > ----------------------------------------------------------
            > > > 3.4 New splines data structure in C++? (Martin)
            > >
            > > More than "data structure", if we're going to use C++, it'll be "Objects".
            >
            > Yes. I'm wrong.
            >
            > > We have then to write some code to serialize the objects (save them) in a
            > > series of lists that are C compatible.
            >
            > Yes. However..."series of lists" is kind of a data stricture even if it
            > is simple data stricture. I think "series of lists" should be defined
            > in "Splines Writer". See next.
            >
            > > =============================================================
            > > > 4. Splines Writer(libsw, renamed from libgow, any good name?)
            > > > 4.1 Splines data structure in C(Masatake?)
            > >
            > > I'd say the Splines data structures are to be declared in 3.4 (where you
            > > can access C++ Objects) and accessed from 4.1.
            >
            > I don't think so. Splines Writer is a general library. It is not
            > only for autotrace. Other client programs will use Splines Writer.
            > Therefore, other client programs will construct "Splines data structure(
            > == simple data stricture)". If the definition of the "Splines data structure"
            > is part of autotrace as you say, other client programs must be linked
            > with libautotrace in that the "Splines data structure" is defined.
            >
            > I have found an interesting thing on the net.
            > I'll report it next.
            >
            > Masatake YAMATO
            >
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • Martin Weber
            Currently we have an output filter (p2e) that write files that can directly (without Ghostscript) be read from pstoedit. So there is no real need to have such
            Message 5 of 21 , Mar 31, 2002
            • 0 Attachment
              Currently we have an output filter (p2e) that write files that can
              directly
              (without Ghostscript) be read from pstoedit. So there is no real need to
              have
              such a direct interface but it is shurely a nice feature.

              Masatake YAMATO schrieb:

              > I've found that pstoedit is very useful for improving autotrace.
              >
              > pstoedit is a program(and library!) translate ps and pdf input
              > to other formats includeing ... too many. See
              > http://www.pstoedit.net/pstoedit/
              >
              > We can you pstoedit as a general output backend for autotrace
              > like imagemagick as a general input for autotrace.
              >
              > Further more, pstoedit provides what I need in the spline writer.
              > >From readme.txt of pstoedit_3.31/:
              >
              > The architecture of pstoedit consists of a PostScript frontend which
              > needs to call a PostScript interpreter like Ghostscript and the
              > individual backends which are plugged into a kind of framework.
              >
              > This framework can be used independently from the PostScript frontend
              > from any other program. The framework provides a uniform interface to
              > all different backends. Get in contact with the author if you need
              > more information on how to use this framework.
              >
              > pstoedit could be distributed under GPL.
              > We can link autotrace with it.
              >
              > pstoedit could be compiled on Windows. Too nice.
              >
              > I'll inspect the pstoedit and write a bridge between autotrace.
              > It seems that some of output writers written by Martin and other are
              > not supported in pstoedit or supported but shareware. I'll export
              > output writers not supported in pstoedit but supported in autotrace
              > to pstoedit. I've found the power of opensource again.
              >
              > Masatake
              >
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Wolfgang Glunz
              ... From: é×ÁÎ ìÏÈ To: Sent: Sunday, March 31, 2002 6:14 PM Subject: Re: [AutoTrace] pstoedit ... not ...
              Message 6 of 21 , Mar 31, 2002
              • 0 Attachment
                ----- Original Message -----
                From: "Иван Лох" <loh@...>
                To: <autotrace@yahoogroups.com>
                Sent: Sunday, March 31, 2002 6:14 PM
                Subject: Re: [AutoTrace] pstoedit


                | > I've found that pstoedit is very useful for improving autotrace.
                | >
                | > pstoedit is a program(and library!) translate ps and pdf input
                | > to other formats includeing ... too many. See
                | > http://www.pstoedit.net/pstoedit/
                | >
                | > We can you pstoedit as a general output backend for autotrace
                | > like imagemagick as a general input for autotrace.
                | >
                | Really, pstoedit do no not support all format in free version. There is
                not
                | any SVG support now.

                Of course there is a free SVG writer - use "-f plot-svg"

                Wolfgang
              • Glunz Wolfgang
                Hello Masatake, simply because I forgot to add this to the Makefile. Thanks - it ll be in the next version. Wolfgang ... From: Masatake YAMATO
                Message 7 of 21 , May 6 8:41 AM
                • 0 Attachment
                  Hello Masatake,

                  simply because I forgot to add this to the Makefile. Thanks - it'll be in the next version.

                  Wolfgang

                  -----Original Message-----
                  From: Masatake YAMATO [mailto:jet@...]
                  Sent: Montag, 6. Mai 2002 17:14
                  To: autotrace@yahoogroups.com
                  Cc: wglunz@...
                  Subject: pstoedit


                  Wolfgang, I'd like to use libpstoedit.so in autotrace.

                  However, libpstoedit.so is not installed when I type "make install".
                  Why libpstoedit.so is not installed?
                  I'm using version 3.31.

                  Regards,
                  Masatake YAMATO, co-deveoper of autotrace
                • Masatake YAMATO
                  ... I d like to know more. 1. Which files will be installed? pstoedit.h only? 2. Which way is the best to pass autotrace s splines to libpstoedit? I have to
                  Message 8 of 21 , May 6 8:53 AM
                  • 0 Attachment
                    > Hello Masatake,
                    >
                    > simply because I forgot to add this to the Makefile. Thanks - it'll be in the next version.
                    >
                    > Wolfgang

                    I'd like to know more.

                    1. Which files will be installed?
                    pstoedit.h only?

                    2. Which way is the best to pass autotrace's splines to libpstoedit?
                    I have to use temporally file?

                    Masatake
                  • Wolfgang Glunz
                    Hello Masatake, I m not sure how you plan to use libpstoedit.so. I tell you how for example gsview uses it. Gsview tries to load pstoedit.so using dlopen. If
                    Message 9 of 21 , May 6 1:23 PM
                    • 0 Attachment
                      Hello Masatake,

                      I'm not sure how you plan to use libpstoedit.so. I tell you how for example
                      gsview uses it.
                      Gsview tries to load pstoedit.so using dlopen. If it can load it, then
                      pstoedit is considered to be installed and then gsview retrieves the address
                      of "pstoedit" using dlsym and then calls it. Using this method you have no
                      compile and link time dependencies of pstoedit and thus don't need
                      pstoedit.h
                      Another way to use it is to link the pstoedit.so directly to autotrace (at
                      link-time). In this case you need pstoedit.h.
                      In both of the above cases you would use the already existing p2e driver to
                      create a temporary file and then pass that file to pstoedit applying the -bo
                      option.

                      Another - much closer integration - would be to create a target driver using
                      pstoedit's driver factory and then call the image functions directly. It's
                      possible, but - as said - a much closer integration. I'm not sure you want
                      that.

                      So - what are your plans ?

                      Wolfgang

                      ----- Original Message -----
                      From: "Masatake YAMATO" <jet@...>
                      To: <Wolfgang.Glunz@...>
                      Cc: <autotrace@yahoogroups.com>
                      Sent: Monday, May 06, 2002 5:53 PM
                      Subject: Re: pstoedit


                      | > Hello Masatake,
                      | >
                      | > simply because I forgot to add this to the Makefile. Thanks - it'll be
                      in the next version.
                      | >
                      | > Wolfgang
                      |
                      | I'd like to know more.
                      |
                      | 1. Which files will be installed?
                      | pstoedit.h only?
                      |
                      | 2. Which way is the best to pass autotrace's splines to libpstoedit?
                      | I have to use temporally file?
                      |
                      | Masatake
                      |
                    • Masatake YAMATO
                      Wolfgang, thank you for replying. ... This is the plan what I have. I ll call this plan1. However, I don t want to create a temporary file. So, ... this is
                      Message 10 of 21 , May 8 8:19 AM
                      • 0 Attachment
                        Wolfgang, thank you for replying.

                        > Another way to use it is to link the pstoedit.so directly to autotrace (at
                        > link-time). In this case you need pstoedit.h.
                        > In both of the above cases you would use the already existing p2e driver to
                        > create a temporary file and then pass that file to pstoedit applying the -bo
                        > option.

                        This is the plan what I have. I'll call this plan1.

                        However, I don't want to create a temporary file.

                        So,

                        > Another - much closer integration - would be to create a target driver using
                        > pstoedit's driver factory and then call the image functions directly. It's
                        > possible, but - as said - a much closer integration. I'm not sure you want
                        > that.

                        this is much interesting for me. I'll call this plan2.
                        I'd like to know image functions more.
                        "image functions" are the method os Image of image.h?

                        It seems that pstoedit's driver is drived by yacc's code.
                        I think autotrace can drive the drive if some of driver's methods
                        have public scope. But as far as I know, they have private scope.
                        How do you think introducing extern-"C"'ed-friend functions to
                        export such methods to pstoedit.

                        libpstoedit.so is stream input orientated, therefore I cannot find
                        the way to use it well in autotrace. I'd like to introduce
                        libpstoedit.so to sodipodi, a drawing as a file export backend.
                        I'd like to know how you think. I already know "stream input orientated"
                        is much efficient to implement pstoedit command in the memory usage aspect.

                        One more. I wonder which header files will be installed if I do "make install"
                        (in next version)? Should I include pstoedit.h with

                        #include <pstoedit.h>

                        or

                        #include <pstoedit/pstoedit.h>

                        ?
                        As a library, libpstoedit.so has not been refined yet.


                        If my english is not polite, forgive me.

                        Masatake YAMATO
                      • Wolfgang Glunz
                        Ohaio Masatake, Let me explain some more details about the two plans (plan1 and plan2). For plan1 you would rather need ptoedll.h and not pstoedit.h (although
                        Message 11 of 21 , May 9 1:04 PM
                        • 0 Attachment
                          Ohaio Masatake,

                          Let me explain some more details about the two plans (plan1 and plan2).

                          For plan1 you would rather need ptoedll.h and not pstoedit.h (although the
                          name is a bit misleading - I agree).
                          But why don't you like this plan ? I think this is a loose coupling and
                          autotrace could even run without pstoedit beeing installed. I think those
                          who don't need any pstoedit driver should not be bothered to get and install
                          pstoedit just to resolve the link time dependency. This was the basic idea
                          also behind the way gsview uses pstoedit. So pstoedit is like a plugin to
                          autotrace. I don't see a real problem with the temporary file for passing
                          the data. If outtrace were written in C++ one could even think of passing a
                          ostream derived object (e.g. an ostrstream) to pstoedit - but that is left
                          for the future.

                          For plan2 you would need much more headers - not just pstoedit.h.
                          Technically this would be possible of course, but so far this interface to
                          pstoedit is not documented sufficiently for "external users" - sorry !

                          Please also excuse my English if it sounds impolite - I'm also not a native
                          speaker.

                          Wolfgang

                          ----- Original Message -----
                          From: "Masatake YAMATO" <jet@...>
                          To: <autotrace@yahoogroups.com>; <Wolfgang.Glunz@...>
                          Sent: Wednesday, May 08, 2002 5:19 PM
                          Subject: Re: [AutoTrace] Re: pstoedit


                          | Wolfgang, thank you for replying.
                          |
                          | > Another way to use it is to link the pstoedit.so directly to autotrace
                          (at
                          | > link-time). In this case you need pstoedit.h.
                          | > In both of the above cases you would use the already existing p2e driver
                          to
                          | > create a temporary file and then pass that file to pstoedit applying
                          the -bo
                          | > option.
                          |
                          | This is the plan what I have. I'll call this plan1.
                          |
                          | However, I don't want to create a temporary file.
                          |
                          | So,
                          |
                          | > Another - much closer integration - would be to create a target driver
                          using
                          | > pstoedit's driver factory and then call the image functions directly.
                          It's
                          | > possible, but - as said - a much closer integration. I'm not sure you
                          want
                          | > that.
                          |
                          | this is much interesting for me. I'll call this plan2.
                          | I'd like to know image functions more.
                          | "image functions" are the method os Image of image.h?
                          |
                          | It seems that pstoedit's driver is drived by yacc's code.
                          | I think autotrace can drive the drive if some of driver's methods
                          | have public scope. But as far as I know, they have private scope.
                          | How do you think introducing extern-"C"'ed-friend functions to
                          | export such methods to pstoedit.
                          |
                          | libpstoedit.so is stream input orientated, therefore I cannot find
                          | the way to use it well in autotrace. I'd like to introduce
                          | libpstoedit.so to sodipodi, a drawing as a file export backend.
                          | I'd like to know how you think. I already know "stream input orientated"
                          | is much efficient to implement pstoedit command in the memory usage
                          aspect.
                          |
                          | One more. I wonder which header files will be installed if I do "make
                          install"
                          | (in next version)? Should I include pstoedit.h with
                          |
                          | #include <pstoedit.h>
                          |
                          | or
                          |
                          | #include <pstoedit/pstoedit.h>
                          |
                          | ?
                          | As a library, libpstoedit.so has not been refined yet.
                          |
                          |
                          | If my english is not polite, forgive me.
                          |
                          | Masatake YAMATO
                          |
                        • Masatake YAMATO
                          Guten Tag Wolfgang, ... Thank you. I ll inspect the files. ... configure check the existence of libpstoedit.a when building autotrace. If configure cannot find
                          Message 12 of 21 , May 10 9:16 AM
                          • 0 Attachment
                            Guten Tag Wolfgang,

                            > For plan1 you would rather need ptoedll.h and not pstoedit.h (although the
                            > name is a bit misleading - I agree).
                            Thank you. I'll inspect the files.

                            > But why don't you like this plan ? I think this is a loose coupling and
                            > autotrace could even run without pstoedit beeing installed. I think those
                            > who don't need any pstoedit driver should not be bothered to get and install
                            > pstoedit just to resolve the link time dependency. This was the basic idea
                            > also behind the way gsview uses pstoedit. So pstoedit is like a plugin to
                            > autotrace. I don't see a real problem with the temporary file for passing
                            configure check the existence of libpstoedit.a when building autotrace.
                            If configure cannot find libpstoedit.a, autotrace will be built without
                            libpstoedit.a. If configure can do, autotrace will be built with linking
                            to libpstoedit.a. I think passing a well structured data in a process
                            throught a file system is not elegant.

                            > If outtrace were written in C++ one could even think of passing a
                            > ostream derived object (e.g. an ostrstream) to pstoedit - but that is left
                            > for the future.
                            Yes. This one is more elegant.

                            > For plan2 you would need much more headers - not just pstoedit.h.
                            > Technically this would be possible of course, but so far this interface to
                            > pstoedit is not documented sufficiently for "external users" - sorry !
                            Only the problem of documentation?

                            How about the desing of the code?
                            It is designed for external users?
                            This is the point. There is no documentation for libautotrace.
                            However it was redesigned for external users.

                            I think there might be many external users if libautotrace
                            is designed for external users.

                            Martin might want to release autotrace-0.31.0 as soon as possible,
                            I'll choose the plan1. But I'd like to move to the plan2.

                            Masatake
                          • Wolfgang Glunz
                            Hello Masatake, ... From: Masatake YAMATO To: Sent: Friday, May 10, 2002 6:16 PM Subject: Re: [AutoTrace] Re:
                            Message 13 of 21 , May 10 1:53 PM
                            • 0 Attachment
                              Hello Masatake,


                              ----- Original Message -----
                              From: "Masatake YAMATO" <jet@...>
                              To: <autotrace@yahoogroups.com>
                              Sent: Friday, May 10, 2002 6:16 PM
                              Subject: Re: [AutoTrace] Re: pstoedit


                              | Guten Tag Wolfgang,
                              |
                              | > For plan1 you would rather need ptoedll.h and not pstoedit.h (although
                              the
                              | > name is a bit misleading - I agree).
                              | Thank you. I'll inspect the files.
                              |
                              | > But why don't you like this plan ? I think this is a loose coupling and
                              | > autotrace could even run without pstoedit beeing installed. I think
                              those
                              | > who don't need any pstoedit driver should not be bothered to get and
                              install
                              | > pstoedit just to resolve the link time dependency. This was the basic
                              idea
                              | > also behind the way gsview uses pstoedit. So pstoedit is like a plugin
                              to
                              | > autotrace. I don't see a real problem with the temporary file for
                              passing
                              | configure check the existence of libpstoedit.a when building autotrace.
                              | If configure cannot find libpstoedit.a, autotrace will be built without
                              | libpstoedit.a. If configure can do, autotrace will be built with linking
                              | to libpstoedit.a. I think passing a well structured data in a process
                              | throught a file system is not elegant.
                              This is correct, but a closer integration would mean that bigger changes on
                              either side.
                              Without any change on pstoedit's side, your plan2 would require autotrace to
                              use C++ since the current "API" consists of C++ classes.
                              Of course, I could provide a pure C interface on top / or in parallel to the
                              current C++ interface but that would mean some effort on my side.
                              So in the short term, I see no other way. Further, the file format also has
                              it's advantages. As the intermediate format of pstoedit is a special subset
                              of PostScript, you can check it for correctness using GhostScript.
                              A similar situation exists within pstoedit itself. Pstoedit has a frontend
                              and many backends and a backend driver. The interface between the frontend
                              (which is responsible to "parse" PostScript) and the backend driver is
                              exactly this intermediate PostScript. Believe me - I used this more than
                              once to find out whether a bug is a frontend or a backend bug.

                              Coming back to plan1 - I still think that dynamic linking would be more
                              flexible than static linking. You could provide the binary on the web in
                              just one version and the user could get pstoedit separately if needed. Just
                              like in gsview. What do you and others think ?


                              |
                              | > If outtrace were written in C++ one could even think of passing a
                              | > ostream derived object (e.g. an ostrstream) to pstoedit - but that is
                              left
                              | > for the future.
                              | Yes. This one is more elegant.
                              |
                              | > For plan2 you would need much more headers - not just pstoedit.h.
                              | > Technically this would be possible of course, but so far this interface
                              to
                              | > pstoedit is not documented sufficiently for "external users" - sorry !
                              | Only the problem of documentation?
                              |
                              | How about the desing of the code?
                              | It is designed for external users?

                              I would say yes, but only for C++ "users". Sorry.

                              Wolfgang


                              | This is the point. There is no documentation for libautotrace.
                              | However it was redesigned for external users.
                              |
                              | I think there might be many external users if libautotrace
                              | is designed for external users.
                              |
                              | Martin might want to release autotrace-0.31.0 as soon as possible,
                              | I'll choose the plan1. But I'd like to move to the plan2.
                              |
                              | Masatake
                              |
                              |
                              |
                              |
                              | Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                              |
                              |
                            • Masatake YAMATO
                              Hi, ... Don t forget we are in the world of free software. In this world, when I want to add just another function to your side, your side becomes my side:)
                              Message 14 of 21 , May 11 1:44 AM
                              • 0 Attachment
                                Hi,

                                > Without any change on pstoedit's side, your plan2 would require autotrace to
                                > use C++ since the current "API" consists of C++ classes.
                                > Of course, I could provide a pure C interface on top / or in parallel to the
                                > current C++ interface but that would mean some effort on my side.

                                Don't forget we are in the world of free software.
                                In this world, when I want to add just another function to your side,
                                your side becomes my side:) The important point is that the original
                                author encourags me to add such a function or not.

                                > So in the short term, I see no other way. Further, the file format also has
                                > it's advantages. As the intermediate format of pstoedit is a special subset
                                > of PostScript, you can check it for correctness using GhostScript.
                                > A similar situation exists within pstoedit itself. Pstoedit has a frontend
                                > and many backends and a backend driver. The interface between the frontend
                                > (which is responsible to "parse" PostScript) and the backend driver is
                                > exactly this intermediate PostScript. Believe me - I used this more than
                                > once to find out whether a bug is a frontend or a backend bug.

                                I see.

                                > Coming back to plan1 - I still think that dynamic linking would be more
                                > flexible than static linking. You could provide the binary on the web in
                                > just one version and the user could get pstoedit separately if needed. Just
                                > like in gsview. What do you and others think ?

                                I think I don't understand plan1 completely yet.
                                In linking, there are three levels.

                                L1) static linking against libfoo.a
                                L2) dynamic linking against libfoo.so.
                                The library name is given at compile time.
                                gcc and ld make this possible.
                                L3) dynamic linking against libfoo.so.
                                The library name is given at run time.
                                dlopen and dlsym make this possible.

                                I think you are talking about L3. Right?
                                I'd like to choose L2 because the library, libpstoedit.so is known
                                at compile time. If the library name is unknown at compile time,
                                L3 should be chosen.

                                As far as I know, either 2 or 3, dynamically linked library could be
                                update after compile time. As I wrote the existence of libfoo.so in
                                configure.in. The advantages of L3 in autotrace, the autotrace user
                                can use libpstoedit functions after compiling autotrace that is built
                                without libpstoedit. However, this is not so important I think.
                                Do you think this is important point?

                                In other hand, libpstoedit itself should be linked the 3rd party drivers
                                in L3 linking method. (And it is nice if autotrace could link input/output
                                plugins in L3 linking method. However, it should be done under autotrace
                                input/ouput plugin interface. )

                                ...now reading pstoedit.h and dynload.cpp...

                                Wow! How could I use pstoedit_plainC in my C program?
                                The ways I found:

                                1) Include pstoedit.h.
                                Fail => C compiler will raise an error because
                                C compiler cannot understand - extern "C" -.

                                (This is something to do with L2.)

                                2) Include pstoedit.h. Nice gcc might understand this file.
                                However, how to bind implementation of pstoedit_plainC to
                                pstoedit_plainC_func typed variable?
                                I cannot find the pointer to pstoedit_plainC.
                                At first dlltst.cpp is good sample for me.
                                However, DynLoader used in the sample is a C++ class.
                                Fail => I cannot find the pointer to pstoedit_plainC.

                                (This is something to do with L3.)

                                How could I do?

                                Masatake YAMATO
                              • Masatake YAMATO
                                I ve implemented output-pstoedit, new output handler. With this output handler, you don t have to use pipe to call pstoedit. You can call pstoedit functions
                                Message 15 of 21 , May 11 9:37 PM
                                • 0 Attachment
                                  I've implemented output-pstoedit, new output handler.
                                  With this output handler, you don't have to use pipe to call pstoedit.
                                  You can call pstoedit functions directly from autotrace command line,
                                  libautotrace frontline and sodipodi.

                                  ----------------------------------------------------------------------
                                  [jet@chuf autotrace]$ ./autotrace --list-output-formats
                                  Supported output formats:
                                  eps Encapsulated PostScript
                                  ai Adobe Illustrator
                                  p2e pstoedit frontend format
                                  sk Sketch
                                  svg Scalable Vector Graphics
                                  fig XFIG 3.2
                                  swf Shockwave Flash 3
                                  emf Enhanced Metafile format
                                  mif FrameMaker MIF format
                                  er Elastic Reality Shape file
                                  dxf DXF format (without splines)
                                  epd EPD format
                                  pdf PDF format
                                  cgm Computer Graphics Metafile
                                  dr2d IFF DR2D format
                                  gnuplot gnuplot format
                                  idraw Interviews draw format (EPS)
                                  fig .fig format for xfig
                                  fig .fig format for xfig
                                  obj Tgif .obj format (for tgif version >= 3)
                                  sam sample driver: if you don't want to see this, uncomment the corresponding line in makefile and make again
                                  tk tk and/or tk applet source code
                                  hpgl HPGL code
                                  pic PIC format for troff et.al.
                                  tex LaTeX2e picture format
                                  m Mathematica Graphics
                                  mp MetaPost Format
                                  sk Sketch Format
                                  kil .kil format for Kontour
                                  pdf Adobe's Portable Document Format
                                  meta ASCII GNU metafile
                                  meta binary GNU metafile
                                  java2 java 2 source code
                                  java java 1 applet source code
                                  dxf CAD exchange format
                                  dxf CAD exchange format with splines
                                  rpl Real3D Programming Language Format
                                  rib RenderMan Interface Bytestream
                                  lwo LightWave 3D Object Format
                                  fps Flattened PostScript (no curves)
                                  fps PostScript
                                  dbg for test purposes
                                  dbg for test purposes (same as debug)
                                  gs any device that GhostScript provides - use gs:format, e.g. gs:pdfwrite
                                  ai Adobe Illustrator via ps2ai.ps of GhostScript
                                  [jet@chuf autotrace]$
                                  ----------------------------------------------------------------------

                                  --- Discussion ---

                                  1. (Wolfgang) Interface between pstoedit.

                                  I've added following code to output-pstoedit.h *in autotrace*.
                                  However, I think it should be in part of pstoedit.

                                  ====================================
                                  #include <pstoedll.h>
                                  int pstoedit_plainC(int argc,
                                  const char * const argv[],
                                  const char * const psinterpreter /* if 0, then pstoedit will look for one using whichpi() */
                                  );
                                  struct DriverDescription_S* getPstoeditDriverInfo_plainC(void);
                                  void pstoedit_checkversion (unsigned int callersversion);
                                  ====================================

                                  We can use c++ compiler predefined constant "__cplusplus" to make
                                  satisfied both c++ compilers and c compilers.

                                  2. (Wolfgang) libpstoedit's header file.

                                  Which should I include <pstoedll.h> or <pstoedit/pstoedll.h>?
                                  When will 3.32 be released?
                                  ...
                                  I'd like to work on pstoedit in order to make libpstoedit
                                  more library-user friendly.

                                  I think we cannot release autotrace that contains output-pstoedit.[ch]
                                  after pstoedit-3.32 is released.

                                  3. MS-Windows
                                  3.1 (Wolfgang) Is libpstoedit available only GNU/Linux?
                                  How about ms-windows?
                                  3.2 (Martin) temporary file
                                  (If libpstoedit is available on MS-Windows)
                                  I used mkstemp to create a tmp file that is passed to libpstoedit
                                  from autotrace. Read http://groups.yahoo.com/group/autotrace/message/369

                                  I wonder mkstemp is available on MS-Windows?

                                  Masatake
                                • Glunz Wolfgang
                                  Hello Masatake, I try to answer your questions - see below. Wolfgang ... Looks quite good. There are some questions though. 1. I see two entries for dxf and
                                  Message 16 of 21 , May 13 1:07 PM
                                  • 0 Attachment
                                    Hello Masatake,

                                    I try to answer your questions - see below.

                                    Wolfgang

                                    > -----Original Message-----
                                    > From: Masatake YAMATO [mailto:jet@...]
                                    > Sent: Sunday, May 12, 2002 6:38 AM
                                    > To: autotrace@yahoogroups.com
                                    > Subject: Re: [AutoTrace] Re: pstoedit
                                    >
                                    >
                                    > I've implemented output-pstoedit, new output handler.
                                    > With this output handler, you don't have to use pipe to call
                                    > pstoedit. You can call pstoedit functions directly from
                                    > autotrace command line, libautotrace frontline and sodipodi.
                                    >
                                    > ----------------------------------------------------------------------
                                    > [jet@chuf autotrace]$ ./autotrace --list-output-formats
                                    > Supported output formats:
                                    > eps Encapsulated PostScript
                                    > ai Adobe Illustrator
                                    > p2e pstoedit frontend format
                                    > sk Sketch
                                    > svg Scalable Vector Graphics
                                    > fig XFIG 3.2
                                    > swf Shockwave Flash 3
                                    > emf Enhanced Metafile format
                                    > mif FrameMaker MIF format
                                    > er Elastic Reality Shape file
                                    > dxf DXF format (without splines)
                                    > epd EPD format
                                    > pdf PDF format
                                    > cgm Computer Graphics Metafile
                                    > dr2d IFF DR2D format
                                    > gnuplot gnuplot format
                                    > idraw Interviews draw format (EPS)
                                    > fig .fig format for xfig
                                    > fig .fig format for xfig
                                    > obj Tgif .obj format (for tgif version >= 3)
                                    > sam sample driver: if you don't want to see this, uncomment
                                    > the corresponding line in makefile and make again
                                    > tk tk and/or tk applet source code
                                    > hpgl HPGL code
                                    > pic PIC format for troff et.al.
                                    > tex LaTeX2e picture format
                                    > m Mathematica Graphics
                                    > mp MetaPost Format
                                    > sk Sketch Format
                                    > kil .kil format for Kontour
                                    > pdf Adobe's Portable Document Format
                                    > meta ASCII GNU metafile
                                    > meta binary GNU metafile
                                    > java2 java 2 source code
                                    > java java 1 applet source code
                                    > dxf CAD exchange format
                                    > dxf CAD exchange format with splines
                                    > rpl Real3D Programming Language Format
                                    > rib RenderMan Interface Bytestream
                                    > lwo LightWave 3D Object Format
                                    > fps Flattened PostScript (no curves)
                                    > fps PostScript
                                    > dbg for test purposes
                                    > dbg for test purposes (same as debug)
                                    > gs any device that GhostScript provides - use gs:format,
                                    > e.g. gs:pdfwrite
                                    > ai Adobe Illustrator via ps2ai.ps of GhostScript
                                    > [jet@chuf autotrace]$

                                    Looks quite good. There are some questions though.
                                    1. I see two entries for dxf and three fig. How do you intend to let the user choose one.
                                    2. pstoedit provides some formats that are only usable in "ghostScript mode", i.e. not in the "backend-only" mode.
                                    I know this info is not returned so far and thus you have no chance to hide these entries. This is something I have to add.


                                    > ----------------------------------------------------------------------
                                    >
                                    > --- Discussion ---
                                    >
                                    > 1. (Wolfgang) Interface between pstoedit.
                                    >
                                    > I've added following code to output-pstoedit.h *in
                                    > autotrace*. However, I think it should be in part of pstoedit.
                                    >
                                    > ====================================
                                    > #include <pstoedll.h>
                                    > int pstoedit_plainC(int argc,
                                    > const char * const argv[],
                                    > const char * const psinterpreter /* if 0,
                                    > then pstoedit will look for one using whichpi() */
                                    > );
                                    > struct DriverDescription_S* getPstoeditDriverInfo_plainC(void);
                                    > void pstoedit_checkversion (unsigned int callersversion);
                                    > ====================================
                                    >
                                    > We can use c++ compiler predefined constant "__cplusplus" to
                                    > make satisfied both c++ compilers and c compilers.

                                    OK - I will add the __cplusplus around the extern "C" - but then you could use pstoedit.h instead.
                                    Pstoedll.h makes sense only if you want to do dynamic linking at runtime using dlopen and dlsym.
                                    I you need more info take a look to dynload.cpp. It encapsulates the dynamic runtime linking in a platform independent way.

                                    >
                                    > 2. (Wolfgang) libpstoedit's header file.
                                    >
                                    > Which should I include <pstoedll.h> or <pstoedit/pstoedll.h>?
                                    > When will 3.32 be released? ... I'd like to work on pstoedit
                                    This is hard to say - I don't have too much time at the moment - Sorry.

                                    > in order to make libpstoedit more library-user friendly.
                                    I have already done something towards this - but only for a C++ interface. A client code looks like:

                                    #include "pstoeditoutputlib.h"
                                    int main(const int argc, const char * const argv[])
                                    {
                                    PstoeditOutputInterface interfc;

                                    drvbase * outputdriver = interfc.getdriver("pdf");

                                    outputdriver->addtopath(new Moveto(10,20)); // delete will be done by the driver base class
                                    outputdriver->addtopath(new Lineto(110,120));
                                    outputdriver->dumpPath();

                                    outputdriver->dumpText("hello world",100,200);
                                    return 0;
                                    }

                                    I think this is sufficiently library-user friendly although there is certainly room for some optimizations.

                                    Ok - you can now think about a C API, but I see some technical problems. As C++ normally performs quite some code during load and unload time (construction and destruction of global objects) I'm not sure whether you will be able to call a C++ library from a program compiled and linked with a C compiler even if you give it a plain C wrapper interface. Normally the rule says that the calling program needs at least to be linked with the C++ compiler to get the startup/shutdown code handled correctly. It may work with the GNU compiler also in C mode since it is almost the same compiler anyway, but I think this is not generally guaranteed to work.

                                    >
                                    > I think we cannot release autotrace that contains
                                    > output-pstoedit.[ch] after pstoedit-3.32 is released.
                                    >
                                    > 3. MS-Windows
                                    > 3.1 (Wolfgang) Is libpstoedit available only GNU/Linux?
                                    > How about ms-windows?

                                    Yes, there is a pstoedit.dll (but no .lib). For your current approach with link-time dynamic linking or even static linking you would need also the .lib. If you choose the dynamic runtime linking instead, then the .dll would be sufficient. Anyway, I could also provide the .lib in addition if you still want to keep with the dynamic link-time linking. But believe me - runtime linking is not tricky. Take a look at dlltest.cpp and dynload.cpp. There you find all the code. Feel free to copy&paste it.


                                    > 3.2 (Martin) temporary file
                                    > (If libpstoedit is available on MS-Windows)
                                    > I used mkstemp to create a tmp file that is passed to libpstoedit
                                    > from autotrace. Read
                                    > http://groups.yahoo.com/group/autotrace/messag> e/369
                                    >
                                    > I
                                    > wonder mkstemp is available on MS-Windows?

                                    I would also be interested to know about this since pstoedit has the same "problem".

                                    Wolfgang


                                    >
                                    >
                                    > Masatake
                                    >
                                    > ------------------------ Yahoo! Groups Sponsor
                                    > ---------------------~--> Tied to your PC? Cut Loose and Stay
                                    > connected with Yahoo! Mobile
                                    > http://us.click.yahoo.com/QBCcSD/o1CEAA/sXBHAA> /_iFolB/TM
                                    >
                                    >
                                    > --------------------------------------------------------------
                                    > -------~->
                                    >
                                    >
                                    >
                                    > Your use of Yahoo! Groups is subject to
                                    > http://docs.yahoo.com/info/terms/
                                    >
                                    >
                                  • Glunz Wolfgang
                                    Recently I wrote: Ok - you can now think about a C API, but I see some technical problems. As C++ normally performs quite some code during load and unload time
                                    Message 17 of 21 , May 14 2:12 AM
                                    • 0 Attachment
                                      Recently I wrote:


                                      Ok - you can now think about a C API, but I see some technical problems. As C++ normally performs quite some code during load and unload time (construction and destruction of global objects) I'm not sure whether you will be able to call a C++ library from a program compiled and linked with a C compiler even if you give it a plain C wrapper interface. Normally the rule says that the calling program needs at least to be linked with the C++ compiler to get the startup/shutdown code handled correctly. It may work with the GNU compiler also in C mode since it is almost the same compiler anyway, but I think this is not generally guaranteed to work.



                                      I thought about this further and think that the above mentioned rule only applies to static linking (.a/.lib). When a .so or a .dll is used, I think its init section already contains the C++ startup code. So it should/could work for such cases.

                                      Wolfgang
                                    • Masatake YAMATO
                                      Wolfgang, thank you for advices. ... This is not easy to fix. First, I tried doubly defined output writer; I added code that don t display a format name
                                      Message 18 of 21 , May 19 1:37 AM
                                      • 0 Attachment
                                        Wolfgang, thank you for advices.

                                        > Looks quite good. There are some questions though.
                                        > 1. I see two entries for dxf and three fig. How do you intend to let
                                        > the user choose one.

                                        This is not easy to fix.

                                        First, I tried doubly defined output writer;
                                        I added code that don't display a format name supported in libpstoedit
                                        if the format is supported in autotrace natively.

                                        -------------------------------
                                        Supported output formats:
                                        eps Encapsulated PostScript
                                        ai Adobe Illustrator
                                        p2e pstoedit frontend format
                                        sk Sketch
                                        svg Scalable Vector Graphics
                                        fig XFIG 3.2
                                        swf Shockwave Flash 3
                                        emf Enhanced Metafile format
                                        mif FrameMaker MIF format
                                        er Elastic Reality Shape file
                                        dxf DXF format (without splines)
                                        epd EPD format
                                        pdf PDF format
                                        cgm Computer Graphics Metafile
                                        dr2d IFF DR2D format
                                        gnuplot gnuplot format
                                        idraw Interviews draw format (EPS)
                                        obj Tgif .obj format (for tgif version >= 3)
                                        sam sample driver: if you don't want to see this, uncomment the corresponding line in makefile and make again
                                        tk tk and/or tk applet source code
                                        hpgl HPGL code
                                        pic PIC format for troff et.al.
                                        tex LaTeX2e picture format
                                        m Mathematica Graphics
                                        mp MetaPost Format
                                        kil .kil format for Kontour
                                        meta ASCII GNU metafile
                                        meta binary GNU metafile
                                        java2 java 2 source code
                                        java java 1 applet source code
                                        rpl Real3D Programming Language Format
                                        rib RenderMan Interface Bytestream
                                        lwo LightWave 3D Object Format
                                        fps Flattened PostScript (no curves)
                                        fps PostScript
                                        dbg for test purposes
                                        dbg for test purposes (same as debug)
                                        gs any device that GhostScript provides - use gs:format, e.g. gs:pdfwrite
                                        -------------------------------

                                        However, there are still entries that have the same name: meta and fps.

                                        There are more problems that was already reported by Martin before.

                                        I wanted autotrace to select an output backend automatically
                                        according to given output file name.
                                        e.g.
                                        When I invoke the following command line:

                                        $ autotrace foo.png --output-file=foo.svg

                                        I wanted autotrace to select SVG backend automatically(and I implemented
                                        such a function) instead of


                                        $ autotrace foo.png --output-file=foo.svg --output-format=svg

                                        In many cases this is ok. However, there are backends that has
                                        the same file-suffix and different module names.

                                        e.g. dxf with spline and dxf without spline.

                                        autotrace itself has dxf without spline output module. However, if
                                        pstoedit backends are available, autotrace can use dxf with spline of
                                        pstoedit. How could I specify one of them? In such a case, automatic
                                        backend selection will not work well.

                                        ...You might be confused at my strange English. Sorry.

                                        What I'd like to say. There are 3 name space in autotrace with
                                        libpstoedit.

                                        1. autotrace backend moudule name(= autotrace backend suffix name)
                                        2. libpstoedit backend moudule name(DriverDescription_S::symbolicname)
                                        3. libpstoedit backend suffix name (DriverDescription_S::suffix)

                                        These 3 different name spaces might cause troubles.
                                        We need more simple backend module selection mechanism.
                                        Passing options to libpstoedit backend are also needed.

                                        > 2. pstoedit provides some formats that are only usable in
                                        > "ghostScript mode", i.e. not in the "backend-only" mode. I know
                                        > this info is not returned so far and thus you have no chance to hide
                                        > these entries. This is something I have to add.

                                        I agree.

                                        From: Glunz Wolfgang <Wolfgang.Glunz@...>
                                        Subject: RE: [AutoTrace] Re: pstoedit
                                        Date: Mon, 13 May 2002 22:07:15 +0200

                                        > > ----------------------------------------------------------------------
                                        > >
                                        > > --- Discussion ---
                                        > >
                                        > > 1. (Wolfgang) Interface between pstoedit.
                                        > >
                                        > > I've added following code to output-pstoedit.h *in
                                        > > autotrace*. However, I think it should be in part of pstoedit.
                                        > >
                                        > > ====================================
                                        > > #include <pstoedll.h>
                                        > > int pstoedit_plainC(int argc,
                                        > > const char * const argv[],
                                        > > const char * const psinterpreter /* if 0,
                                        > > then pstoedit will look for one using whichpi() */
                                        > > );
                                        > > struct DriverDescription_S* getPstoeditDriverInfo_plainC(void);
                                        > > void pstoedit_checkversion (unsigned int callersversion);
                                        > > ====================================
                                        > >
                                        > > We can use c++ compiler predefined constant "__cplusplus" to
                                        > > make satisfied both c++ compilers and c compilers.
                                        >
                                        > OK - I will add the __cplusplus around the extern "C" - but then you could use pstoedit.h instead.
                                        > Pstoedll.h makes sense only if you want to do dynamic linking at runtime using dlopen and dlsym.
                                        > I you need more info take a look to dynload.cpp. It encapsulates the dynamic runtime linking in a platform independent way.

                                        Thanks.

                                        > >
                                        > > 2. (Wolfgang) libpstoedit's header file.
                                        > >
                                        > > Which should I include <pstoedll.h> or <pstoedit/pstoedll.h>?
                                        > > When will 3.32 be released? ... I'd like to work on pstoedit
                                        > This is hard to say - I don't have too much time at the moment - Sorry.

                                        I could help in some aspects.

                                        > > in order to make libpstoedit more library-user friendly.
                                        > I have already done something towards this - but only for a C++ interface. A client code looks like:
                                        >
                                        > #include "pstoeditoutputlib.h"
                                        > int main(const int argc, const char * const argv[])
                                        > {
                                        > PstoeditOutputInterface interfc;
                                        >
                                        > drvbase * outputdriver = interfc.getdriver("pdf");
                                        >
                                        > outputdriver->addtopath(new Moveto(10,20)); // delete will be done by the driver base class
                                        > outputdriver->addtopath(new Lineto(110,120));
                                        > outputdriver->dumpPath();
                                        >
                                        > outputdriver->dumpText("hello world",100,200);
                                        > return 0;
                                        > }
                                        >
                                        > I think this is sufficiently library-user friendly
                                        > although there is certainly room for some optimizations.

                                        Really nice. This is what I've wanted.

                                        > Ok - you can now think about a C API, but I see some technical
                                        > problems. As C++ normally performs quite some code during load and
                                        > unload time (construction and destruction of global objects) I'm not
                                        > sure whether you will be able to call a C++ library from a program
                                        > compiled and linked with a C compiler even if you give it a plain C
                                        > wrapper interface. Normally the rule says that the calling program
                                        > needs at least to be linked with the
                                        > C++ compiler to get the startup/shutdown code handled correctly.
                                        > It may work with the GNU compiler also in C mode since it is almost
                                        > the same compiler anyway, but I think this is not generally
                                        > guaranteed to work.
                                        I'don't know well about this issue. I have to inspect this.

                                        > >
                                        > > I think we cannot release autotrace that contains
                                        > > output-pstoedit.[ch] after pstoedit-3.32 is released.
                                        > >
                                        > > 3. MS-Windows
                                        > > 3.1 (Wolfgang) Is libpstoedit available only GNU/Linux?
                                        > > How about ms-windows?
                                        >
                                        > Yes, there is a pstoedit.dll (but no .lib). For your current
                                        > approach with link-time dynamic linking or even static linking you
                                        > would need also the .lib. If you choose the dynamic runtime linking
                                        > instead, then the .dll would be sufficient. Anyway, I could also
                                        > provide the .lib in addition if you still want to keep with the
                                        > dynamic link-time linking. But believe me - runtime linking is not
                                        > tricky. Take a look at dlltest.cpp and dynload.cpp. There you find
                                        > all the code. Feel free to copy&paste it.

                                        ...

                                        > > 3.2 (Martin) temporary file
                                        > > (If libpstoedit is available on MS-Windows)
                                        > > I used mkstemp to create a tmp file that is passed to libpstoedit
                                        > > from autotrace. Read
                                        > > http://groups.yahoo.com/group/autotrace/messag> e/369
                                        > >
                                        > > I
                                        > > wonder mkstemp is available on MS-Windows?
                                        >
                                        > I would also be interested to know about this since pstoedit has the
                                        > same "problem".

                                        If there is no such a function, we have to implement by ourselves.

                                        Masatake
                                      Your message has been successfully submitted and would be delivered to recipients shortly.