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

Re: [AutoTrace] pstoedit

Expand Messages
  • Wolfgang Glunz
    ... From: é×ÁÎ ìÏÈ To: Sent: Sunday, March 31, 2002 6:14 PM Subject: Re: [AutoTrace] pstoedit ... not ...
    Message 1 of 21 , Mar 31, 2002
      ----- 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 2 of 21 , May 6, 2002
        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 3 of 21 , May 6, 2002
          > 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 4 of 21 , May 6, 2002
            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 5 of 21 , May 8, 2002
              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 6 of 21 , May 9, 2002
                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 7 of 21 , May 10, 2002
                  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 8 of 21 , May 10, 2002
                    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 9 of 21 , May 11, 2002
                      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 10 of 21 , May 11, 2002
                        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 11 of 21 , May 13, 2002
                          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 12 of 21 , May 14, 2002
                            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 13 of 21 , May 19, 2002
                              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.