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

0.31

Expand Messages
  • Masatake YAMATO
    We have not released 0.30 yet, however... 1. Freeimage and/or gdk-pixbuf(Thanks for GPL) ... 2. Input routines for Freeimage and/or gdk-pixbuf (Masatake?)
    Message 1 of 21 , Mar 21, 2002
    View Source
    • 0 Attachment
      We have not released 0.30 yet, however...

      1. Freeimage and/or gdk-pixbuf(Thanks for GPL)
      -------------------------------------------------------------
      2. Input routines for Freeimage and/or gdk-pixbuf (Masatake?)
      =============================================================
      3. Autotrace
      3.1 General Input routines with C interface (Masatake?)
      This will be very thin layer.
      ----------------------------------------------------------
      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)
      ----------------------------------------------------------
      3.5 Mapping New splines data structure of autotrace to
      that of libsw. This will be very thin layer.
      =============================================================
      4. Splines Writer(libsw, renamed from libgow, any good name?)
      4.1 Splines data structure in C(Masatake?)
      ------------------------------+---------------------------
      4.2a Functions to access | 4.2b Output plug-in
      splines data structure | interface in C
      in C with glib(Masatake?)| with glib(Masatake?)
      ------------------------------+---------------------------
      4.3 eps, svg, sk, cgm, ... output plugins

      Modify this layers diagram. I think these are too big change
      done in 0.31. We should give priorities to these tasks.

      About 4.1 I will use the same data structure of the current
      at_splines_type with changing the prefix "at" or
      I'll use libart data structure.

      Anyway too big changes. I'd like work on frontline more...
      Does anyone work on these tasks?
      Not only coding but also comments help us.
      I'd like to hear about the splines writer.

      Output or Input which we should change first?

      Masatake
    • rob@mediasolution.it
      ... 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
      Message 2 of 21 , Mar 21, 2002
      View Source
      • 0 Attachment
        > 1. Freeimage and/or gdk-pixbuf(Thanks for GPL)

        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.

        > 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".
        We have then to write some code to serialize the objects (save them) in a
        series of lists that are C compatible.

        =============================================================
        > 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.

        > Modify this layers diagram. I think these are too big change
        > done in 0.31. We should give priorities to these tasks.
        > Anyway too big changes. I'd like work on frontline more...

        I agree these are too big changes to be done toghether. It's better to
        change only one susbsystem at a time, especially if there aren't too many
        programmers available for the job.
        I myself have to work both on my own company (I've just started up, and
        there are a lot of things to be done) and my cartoon program (that
        hopefully one day will be part of my work too)

        > Output or Input which we should change first?

        I'd say input: should be the area where there is more to gain for
        autotrace: speed, memory efficiency and better windows dependancies.


        Ciao,
        Rob!
      • 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 3 of 21 , Mar 31, 2002
        View Source
        • 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 4 of 21 , Mar 31, 2002
          View Source
          • 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 5 of 21 , Mar 31, 2002
            View Source
            • 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 6 of 21 , Mar 31, 2002
              View Source
              • 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 7 of 21 , Mar 31, 2002
                View Source
                • 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 8 of 21 , Mar 31, 2002
                  View Source
                  • 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 9 of 21 , May 6, 2002
                    View Source
                    • 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 10 of 21 , May 6, 2002
                      View Source
                      • 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 11 of 21 , May 6, 2002
                        View Source
                        • 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 12 of 21 , May 8, 2002
                          View Source
                          • 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 13 of 21 , May 9, 2002
                            View Source
                            • 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 14 of 21 , May 10, 2002
                              View Source
                              • 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 15 of 21 , May 10, 2002
                                View Source
                                • 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 16 of 21 , May 11, 2002
                                  View Source
                                  • 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 17 of 21 , May 11, 2002
                                    View Source
                                    • 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 18 of 21 , May 13, 2002
                                      View Source
                                      • 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 19 of 21 , May 14, 2002
                                        View Source
                                        • 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 20 of 21 , May 19, 2002
                                          View Source
                                          • 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.