Re: [Inkscape-devel] my win32 patch does not work, why (splivarot.cpp)
Hi,
we decided that the best way to unify serialization is via a C++ stream. I just checked in src/svg/stringstream.h which is a beginning of such a class that can be used already. If we use this class throughout, later it will be easy to change precision or number formatting globally for all SVG output, as well as to add custom serializers for our own classes.
An example of using this class is in function sp_svg_write_path() in svg-path.cpp. You declare a variable (os) of this class and then feed it with the data you need to serialize using <<. To access the result, you call os.gcharp() which returns const gchar * of the accummulated string, and you'll probably want to also do a g_strdup on it (depending on whether it's going to be used immediately in the same function, or returned or sent elsewhere).
So, if you're interested in helping out, you can start searching for printf functions that are used for serializing into SVG (in splivarot and in other places) and replace them with the stream stuff. Of course the first to replace are printfs that serialize floating point numbers. Please do one function at a time and test it thoroughly after the replacement. Do a test patch for one file, and if it works we can give you developer access to CVS to speed things up.
_________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Wed, 2004-03-17 at 17:06, bulia byak wrote:
we decided that the best way to unify serialization is via a C++ stream.
Probably an ignorant point: Have you considered using libgsf for helping with most of your serialization issues?
On Wed, 2004-03-17 at 18:17, Charles Goodwin wrote:
On Wed, 2004-03-17 at 17:06, bulia byak wrote:
we decided that the best way to unify serialization is via a C++ stream.
Probably an ignorant point: Have you considered using libgsf for helping with most of your serialization issues?
About the streams, I have put some work on streams for the IO layer with the extension system in mind in CVS (check out the streams-*.h streams-*.cpp files in src/). Currently there are input streams which decompress gzip and jar/sxw on the fly. Locale and UTF behaviour isn't in yet. The design is not final as I'm looking into using libgsf optionally, probably through some zip/unzip methods in mixin classes.
Bulia, at first sight, I think there's a memory leak in SVGOStringStream by using the str() method, check out this link for further info about it: http://www.troubleshooters.com/codecorn/memleak.htm
Johan
bulia byak wrote:
So, if you're interested in helping out, you can start searching for printf functions that are used for serializing into SVG (in splivarot and in other places) and replace them with the stream stuff. Of course the first to replace are printfs that serialize floating point numbers. Please do one function at a time and test it thoroughly after the replacement. Do a test patch for one file, and if it works we can give you developer access to CVS to speed things up.
Excellent idea. Also, the code for the shapes (such as sp-ellipse.cpp), likely have their own serialization independent of repr-io.
Bob
On Wed, 2004-03-17 at 12:56, Bob Jamison wrote:
Excellent idea. Also, the code for the shapes (such as sp-ellipse.cpp), likely have their own serialization independent of repr-io.
This is actually one of the areas I'm aiming to address with the AST code -- the intent is to give the the XML, CSS, and SVG path (at least) parse trees a uniform interface, including parsing/serialization.
At this time I'm also using std::ostreams to serialize to, so I expect most of the work Bulia and you all are doing can eventually be directly transplanted into the AST serializer/parser code. So don't let me talking about the AST code discourage you from continuing work.
-mental
participants (5)
-
Bob Jamison -
bulia byak -
Charles Goodwin -
Johan Ceuppens -
MenTaLguY