You can subscribe to this list here.
2002 |
Jan
|
Feb
(40) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2007 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(21) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Darren S. <dsy...@gm...> - 2010-03-22 09:13:23
|
I wondered if this project was still active and anyone monitoring the list? I tried using the latest svgsharp library to load and render a diagram created within Visio. Most of the diagram rendered cleanly (better than firefox/chrome and Inkscape). However, arrows at the end of lines had an incorrect orientation - they were rotated 90 degrees anticlockwise. Reviewing the code I could see the marker orientation calculated for marker-end adding 270 for the start angle which forced an incorrect calculation for the marker angle to match the incoming line. The unit tests are very explicit about angle calculations in this area so I'm assuming that I don't understand the coordinate system used or there are some other transformations occurring (or should occur elsewhere). I then tried a simple marker example and the library failed to render this. Checking the unit tests each of the marker examples in the unit tests also failed to render. I wondered if this was a known issue or if anyone had experienced this in the past. -- Darren |
From: Cort S. <cor...@gm...> - 2009-02-06 20:31:50
|
No, my current production code is still based on my 'forked" version. I will be sure to check that though at that point. I will see if I can identify a test case to verify that it is or use as a basis to get it fixed. On Fri, Feb 6, 2009 at 12:52 PM, Pascal Craponne <pi...@gm...> wrote: > I fixed a matrix problem recently (related to a number parsing problem). > Did you try using the latest SVN version? > > > On Fri, Feb 6, 2009 at 20:32, Cort Schaefer <cor...@gm...>wrote: > >> Another issue that I have just lived with and hit me again today, is a >> problem with the polygon element. When one is read in and I then obtain the >> path for it -- the path is incorrect (scaled to small). I might be able >> able to identify a test case, but have instructed those creating the >> documents to simply them first so that we just don't have that element. >> Cort >> >> >> On Fri, Feb 6, 2009 at 11:14 AM, Pascal Craponne <pi...@gm...>wrote: >> >>> I don't go against the work previously done. I assume that if the DTD >>> loading was left it's for a good reason.We could probably implement an >>> option to disable schema loading, but I'm not sure it is the top priority >>> anyway :) >>> >>> There is still some work to do to fix potential issues. I found several >>> problems in string parsing and number to string conversion. These are maybe >>> the next things to fix. >>> >>> A XAML renderer would also be a priority. >>> Just as using a double-precision floating point values for internal >>> computations. >>> >>> Cort, what kind of changes did you make to SVG#? >>> >>> Pascal. >>> >>> jabber/gtalk: pa...@ja... >>> msn: pa...@cr... >>> >>> >>> >>> On Fri, Feb 6, 2009 at 19:05, Bryan Livingston < >>> bry...@gm...> wrote: >>> >>>> What is the value of loading the DTDs? I cut out the DTD loading all >>>> together in xamltune and it still ran fine for my test set of 8000 svg >>>> files, just 2.5x faster. It was tricky to figure out but I can find >>>> the line to change to do that if you'd like. >>>> >>>> Bryan >>>> >>>> On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> >>>> wrote: >>>> > I committed a version where the most common DTD files are embedded in >>>> the >>>> > assembly, so it is not necessary to download them anymore when loading >>>> a >>>> > document. >>>> > This makes the point for merging all assemblies: currently it is >>>> handled in >>>> > ObjectModel assembly, since it is related to SVG. Anyway, during unit >>>> tests, >>>> > we still have very slow loading when we test Document or >>>> CssXmlDocument, >>>> > because the optimization is below them. >>>> > So we have two options: >>>> > - moving DTDs and embedded resources into the Dom assembly >>>> > - merging all assemblies >>>> > Or maybe the tests are not accurate, and SvgDocuments should be used >>>> when >>>> > SVG DTD are referenced? >>>> > Pascal. >>>> > >>>> > jabber/gtalk: pa...@ja... >>>> > msn: pa...@cr... >>>> > >>>> > >>>> > >>>> > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr... >>>> > >>>> > wrote: >>>> >> >>>> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> >>>> wrote: >>>> >> > - merging assemblies (at least SharpVectorsBindings, >>>> SharpVectorCss, >>>> >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >>>> >> >>>> >> This is probably the most controversial change. One reason for the >>>> >> split was an idea that each assembly could be reused on its own (like >>>> >> by someone needing CSS support but not SVG). I don't think this has >>>> >> exactly been a huge success in the user community so from my point >>>> >> feel free to do whatever you find best :-) >>>> >> >>>> >> /niklas >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > Create and Deploy Rich Internet Apps outside the browser with >>>> > Adobe(R)AIR(TM) >>>> > software. With Adobe AIR, Ajax developers can use existing skills and >>>> code >>>> > to >>>> > build responsive, highly engaging applications that combine the power >>>> of >>>> > local >>>> > resources and data with the reach of the web. Download the Adobe AIR >>>> SDK and >>>> > Ajax docs to start building applications today- >>>> http://p.sf.net/sfu/adobe-com >>>> > _______________________________________________ >>>> > Svgdomcsharp-developers mailing list >>>> > Svg...@li... >>>> > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Bryan Livingston >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Create and Deploy Rich Internet Apps outside the browser with >>> Adobe(R)AIR(TM) >>> software. With Adobe AIR, Ajax developers can use existing skills and >>> code to >>> build responsive, highly engaging applications that combine the power of >>> local >>> resources and data with the reach of the web. Download the Adobe AIR SDK >>> and >>> Ajax docs to start building applications today- >>> http://p.sf.net/sfu/adobe-com >>> _______________________________________________ >>> Svgdomcsharp-developers mailing list >>> Svg...@li... >>> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >>> >>> >> > |
From: Pascal C. <pi...@gm...> - 2009-02-06 19:55:24
|
I had a sample with a very small float number (something like 1e-14) and it caused an error in the GDI. I fixed the problem by changing a string-to-number-to-string method, and that made me think that we should clearly differentiate what happens within SVG# from the renderer. On Fri, Feb 6, 2009 at 20:35, Cort Schaefer <cor...@gm...> wrote: > I don't see a problem with it off hand, without really putting a whole lot > of thought into it. I do agree with the W3 comment though about getting the > highest precision you can. I don't think I have come across this one in the > past though, and I push a lot of SVG through the code. :) > Cort > > On Thu, Feb 5, 2009 at 10:26 AM, Pascal Craponne <pi...@gm...> wrote: > >> Hi everyone, >> I experienced some problems today, with overflows on floating point >> calculations, with rounding errors, or overflows in GDI rendering. >> The W3 specification says: >> It is recommended that higher precision floating point storage and >> computation be performed on operations such as coordinate system >> transformations to provide the best possible precision and to prevent >> round-off errors. >> Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are >> required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) >> for intermediate calculations on certain numerical operations. >> Within the SVG DOM, a <number> is represented as a float or an >> SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> >> . >> so even if they speak about float in end, it's all left to user choice >> before. >> >> My suggestion is to: >> - use double in SVG DOM (it also has the effect of speeding up >> computations, since it's the native format) >> - use float in SVG renderer and let the renderer do the conversion by >> itself (and check the overflows there). >> >> Pascal. >> >> jabber/gtalk: pa...@ja... >> msn: pa...@cr... >> >> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code >> to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Svgdomcsharp-developers mailing list >> Svg...@li... >> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> >> > |
From: Pascal C. <pi...@gm...> - 2009-02-06 19:53:05
|
I fixed a matrix problem recently (related to a number parsing problem). Did you try using the latest SVN version? On Fri, Feb 6, 2009 at 20:32, Cort Schaefer <cor...@gm...> wrote: > Another issue that I have just lived with and hit me again today, is a > problem with the polygon element. When one is read in and I then obtain the > path for it -- the path is incorrect (scaled to small). I might be able > able to identify a test case, but have instructed those creating the > documents to simply them first so that we just don't have that element. > Cort > > > On Fri, Feb 6, 2009 at 11:14 AM, Pascal Craponne <pi...@gm...> wrote: > >> I don't go against the work previously done. I assume that if the DTD >> loading was left it's for a good reason.We could probably implement an >> option to disable schema loading, but I'm not sure it is the top priority >> anyway :) >> >> There is still some work to do to fix potential issues. I found several >> problems in string parsing and number to string conversion. These are maybe >> the next things to fix. >> >> A XAML renderer would also be a priority. >> Just as using a double-precision floating point values for internal >> computations. >> >> Cort, what kind of changes did you make to SVG#? >> >> Pascal. >> >> jabber/gtalk: pa...@ja... >> msn: pa...@cr... >> >> >> >> On Fri, Feb 6, 2009 at 19:05, Bryan Livingston <bry...@gm... >> > wrote: >> >>> What is the value of loading the DTDs? I cut out the DTD loading all >>> together in xamltune and it still ran fine for my test set of 8000 svg >>> files, just 2.5x faster. It was tricky to figure out but I can find >>> the line to change to do that if you'd like. >>> >>> Bryan >>> >>> On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> >>> wrote: >>> > I committed a version where the most common DTD files are embedded in >>> the >>> > assembly, so it is not necessary to download them anymore when loading >>> a >>> > document. >>> > This makes the point for merging all assemblies: currently it is >>> handled in >>> > ObjectModel assembly, since it is related to SVG. Anyway, during unit >>> tests, >>> > we still have very slow loading when we test Document or >>> CssXmlDocument, >>> > because the optimization is below them. >>> > So we have two options: >>> > - moving DTDs and embedded resources into the Dom assembly >>> > - merging all assemblies >>> > Or maybe the tests are not accurate, and SvgDocuments should be used >>> when >>> > SVG DTD are referenced? >>> > Pascal. >>> > >>> > jabber/gtalk: pa...@ja... >>> > msn: pa...@cr... >>> > >>> > >>> > >>> > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> >>> > wrote: >>> >> >>> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> >>> wrote: >>> >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >>> >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >>> >> >>> >> This is probably the most controversial change. One reason for the >>> >> split was an idea that each assembly could be reused on its own (like >>> >> by someone needing CSS support but not SVG). I don't think this has >>> >> exactly been a huge success in the user community so from my point >>> >> feel free to do whatever you find best :-) >>> >> >>> >> /niklas >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > Create and Deploy Rich Internet Apps outside the browser with >>> > Adobe(R)AIR(TM) >>> > software. With Adobe AIR, Ajax developers can use existing skills and >>> code >>> > to >>> > build responsive, highly engaging applications that combine the power >>> of >>> > local >>> > resources and data with the reach of the web. Download the Adobe AIR >>> SDK and >>> > Ajax docs to start building applications today- >>> http://p.sf.net/sfu/adobe-com >>> > _______________________________________________ >>> > Svgdomcsharp-developers mailing list >>> > Svg...@li... >>> > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >>> > >>> > >>> >>> >>> >>> -- >>> Bryan Livingston >>> >> >> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code >> to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Svgdomcsharp-developers mailing list >> Svg...@li... >> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> >> > |
From: Cort S. <cor...@gm...> - 2009-02-06 19:36:00
|
I don't see a problem with it off hand, without really putting a whole lot of thought into it. I do agree with the W3 comment though about getting the highest precision you can. I don't think I have come across this one in the past though, and I push a lot of SVG through the code. :) Cort On Thu, Feb 5, 2009 at 10:26 AM, Pascal Craponne <pi...@gm...> wrote: > Hi everyone, > I experienced some problems today, with overflows on floating point > calculations, with rounding errors, or overflows in GDI rendering. > The W3 specification says: > It is recommended that higher precision floating point storage and > computation be performed on operations such as coordinate system > transformations to provide the best possible precision and to prevent > round-off errors. > Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are > required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) > for intermediate calculations on certain numerical operations. > Within the SVG DOM, a <number> is represented as a float or an > SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> > . > so even if they speak about float in end, it's all left to user choice > before. > > My suggestion is to: > - use double in SVG DOM (it also has the effect of speeding up > computations, since it's the native format) > - use float in SVG renderer and let the renderer do the conversion by > itself (and check the overflows there). > > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
From: Cort S. <cor...@gm...> - 2009-02-06 19:32:31
|
Another issue that I have just lived with and hit me again today, is a problem with the polygon element. When one is read in and I then obtain the path for it -- the path is incorrect (scaled to small). I might be able able to identify a test case, but have instructed those creating the documents to simply them first so that we just don't have that element. Cort On Fri, Feb 6, 2009 at 11:14 AM, Pascal Craponne <pi...@gm...> wrote: > I don't go against the work previously done. I assume that if the DTD > loading was left it's for a good reason.We could probably implement an > option to disable schema loading, but I'm not sure it is the top priority > anyway :) > > There is still some work to do to fix potential issues. I found several > problems in string parsing and number to string conversion. These are maybe > the next things to fix. > > A XAML renderer would also be a priority. > Just as using a double-precision floating point values for internal > computations. > > Cort, what kind of changes did you make to SVG#? > > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > On Fri, Feb 6, 2009 at 19:05, Bryan Livingston <bry...@gm...>wrote: > >> What is the value of loading the DTDs? I cut out the DTD loading all >> together in xamltune and it still ran fine for my test set of 8000 svg >> files, just 2.5x faster. It was tricky to figure out but I can find >> the line to change to do that if you'd like. >> >> Bryan >> >> On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> wrote: >> > I committed a version where the most common DTD files are embedded in >> the >> > assembly, so it is not necessary to download them anymore when loading a >> > document. >> > This makes the point for merging all assemblies: currently it is handled >> in >> > ObjectModel assembly, since it is related to SVG. Anyway, during unit >> tests, >> > we still have very slow loading when we test Document or CssXmlDocument, >> > because the optimization is below them. >> > So we have two options: >> > - moving DTDs and embedded resources into the Dom assembly >> > - merging all assemblies >> > Or maybe the tests are not accurate, and SvgDocuments should be used >> when >> > SVG DTD are referenced? >> > Pascal. >> > >> > jabber/gtalk: pa...@ja... >> > msn: pa...@cr... >> > >> > >> > >> > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> >> > wrote: >> >> >> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> >> wrote: >> >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >> >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >> >> >> >> This is probably the most controversial change. One reason for the >> >> split was an idea that each assembly could be reused on its own (like >> >> by someone needing CSS support but not SVG). I don't think this has >> >> exactly been a huge success in the user community so from my point >> >> feel free to do whatever you find best :-) >> >> >> >> /niklas >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Create and Deploy Rich Internet Apps outside the browser with >> > Adobe(R)AIR(TM) >> > software. With Adobe AIR, Ajax developers can use existing skills and >> code >> > to >> > build responsive, highly engaging applications that combine the power of >> > local >> > resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> > Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> > _______________________________________________ >> > Svgdomcsharp-developers mailing list >> > Svg...@li... >> > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> > >> > >> >> >> >> -- >> Bryan Livingston >> > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
From: Cort S. <cor...@gm...> - 2009-02-06 19:30:16
|
Another comment -- just because the simple SVG files are all using common DTD, doesn't mean that there won't be others referenced that are not common -- i.e. when a document is exported from Adobe Illustrator, if they want to keep the Adobe specific information for their UI, it adds other references and a lot of other "stuff". :) Cort On Fri, Feb 6, 2009 at 11:14 AM, Pascal Craponne <pi...@gm...> wrote: > I don't go against the work previously done. I assume that if the DTD > loading was left it's for a good reason.We could probably implement an > option to disable schema loading, but I'm not sure it is the top priority > anyway :) > > There is still some work to do to fix potential issues. I found several > problems in string parsing and number to string conversion. These are maybe > the next things to fix. > > A XAML renderer would also be a priority. > Just as using a double-precision floating point values for internal > computations. > > Cort, what kind of changes did you make to SVG#? > > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > On Fri, Feb 6, 2009 at 19:05, Bryan Livingston <bry...@gm...>wrote: > >> What is the value of loading the DTDs? I cut out the DTD loading all >> together in xamltune and it still ran fine for my test set of 8000 svg >> files, just 2.5x faster. It was tricky to figure out but I can find >> the line to change to do that if you'd like. >> >> Bryan >> >> On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> wrote: >> > I committed a version where the most common DTD files are embedded in >> the >> > assembly, so it is not necessary to download them anymore when loading a >> > document. >> > This makes the point for merging all assemblies: currently it is handled >> in >> > ObjectModel assembly, since it is related to SVG. Anyway, during unit >> tests, >> > we still have very slow loading when we test Document or CssXmlDocument, >> > because the optimization is below them. >> > So we have two options: >> > - moving DTDs and embedded resources into the Dom assembly >> > - merging all assemblies >> > Or maybe the tests are not accurate, and SvgDocuments should be used >> when >> > SVG DTD are referenced? >> > Pascal. >> > >> > jabber/gtalk: pa...@ja... >> > msn: pa...@cr... >> > >> > >> > >> > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> >> > wrote: >> >> >> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> >> wrote: >> >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >> >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >> >> >> >> This is probably the most controversial change. One reason for the >> >> split was an idea that each assembly could be reused on its own (like >> >> by someone needing CSS support but not SVG). I don't think this has >> >> exactly been a huge success in the user community so from my point >> >> feel free to do whatever you find best :-) >> >> >> >> /niklas >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Create and Deploy Rich Internet Apps outside the browser with >> > Adobe(R)AIR(TM) >> > software. With Adobe AIR, Ajax developers can use existing skills and >> code >> > to >> > build responsive, highly engaging applications that combine the power of >> > local >> > resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> > Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> > _______________________________________________ >> > Svgdomcsharp-developers mailing list >> > Svg...@li... >> > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> > >> > >> >> >> >> -- >> Bryan Livingston >> > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
From: Cort S. <cor...@gm...> - 2009-02-06 19:28:33
|
I think we fixed some of the number parsing, as well as some performance issues. We did fix some problems with the DTD caching, which was a big part of performance. I don't know what I would remove the validated reader and just assume that the document is well formated -- that would potentially lead to other code having to do validation and/or error handling if that was not the case. I unfortunately got bit a few times on poorly formed SVG documents. I have not had a chance just yet to isolate my changes -- I did get the new code though, so that was step 1. Cort On Fri, Feb 6, 2009 at 11:14 AM, Pascal Craponne <pi...@gm...> wrote: > I don't go against the work previously done. I assume that if the DTD > loading was left it's for a good reason.We could probably implement an > option to disable schema loading, but I'm not sure it is the top priority > anyway :) > > There is still some work to do to fix potential issues. I found several > problems in string parsing and number to string conversion. These are maybe > the next things to fix. > > A XAML renderer would also be a priority. > Just as using a double-precision floating point values for internal > computations. > > Cort, what kind of changes did you make to SVG#? > > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > On Fri, Feb 6, 2009 at 19:05, Bryan Livingston <bry...@gm...>wrote: > >> What is the value of loading the DTDs? I cut out the DTD loading all >> together in xamltune and it still ran fine for my test set of 8000 svg >> files, just 2.5x faster. It was tricky to figure out but I can find >> the line to change to do that if you'd like. >> >> Bryan >> >> On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> wrote: >> > I committed a version where the most common DTD files are embedded in >> the >> > assembly, so it is not necessary to download them anymore when loading a >> > document. >> > This makes the point for merging all assemblies: currently it is handled >> in >> > ObjectModel assembly, since it is related to SVG. Anyway, during unit >> tests, >> > we still have very slow loading when we test Document or CssXmlDocument, >> > because the optimization is below them. >> > So we have two options: >> > - moving DTDs and embedded resources into the Dom assembly >> > - merging all assemblies >> > Or maybe the tests are not accurate, and SvgDocuments should be used >> when >> > SVG DTD are referenced? >> > Pascal. >> > >> > jabber/gtalk: pa...@ja... >> > msn: pa...@cr... >> > >> > >> > >> > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> >> > wrote: >> >> >> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> >> wrote: >> >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >> >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >> >> >> >> This is probably the most controversial change. One reason for the >> >> split was an idea that each assembly could be reused on its own (like >> >> by someone needing CSS support but not SVG). I don't think this has >> >> exactly been a huge success in the user community so from my point >> >> feel free to do whatever you find best :-) >> >> >> >> /niklas >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Create and Deploy Rich Internet Apps outside the browser with >> > Adobe(R)AIR(TM) >> > software. With Adobe AIR, Ajax developers can use existing skills and >> code >> > to >> > build responsive, highly engaging applications that combine the power of >> > local >> > resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> > Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> > _______________________________________________ >> > Svgdomcsharp-developers mailing list >> > Svg...@li... >> > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> > >> > >> >> >> >> -- >> Bryan Livingston >> > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
From: Pascal C. <pi...@gm...> - 2009-02-06 18:14:20
|
I don't go against the work previously done. I assume that if the DTD loading was left it's for a good reason.We could probably implement an option to disable schema loading, but I'm not sure it is the top priority anyway :) There is still some work to do to fix potential issues. I found several problems in string parsing and number to string conversion. These are maybe the next things to fix. A XAML renderer would also be a priority. Just as using a double-precision floating point values for internal computations. Cort, what kind of changes did you make to SVG#? Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... On Fri, Feb 6, 2009 at 19:05, Bryan Livingston <bry...@gm...>wrote: > What is the value of loading the DTDs? I cut out the DTD loading all > together in xamltune and it still ran fine for my test set of 8000 svg > files, just 2.5x faster. It was tricky to figure out but I can find > the line to change to do that if you'd like. > > Bryan > > On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> wrote: > > I committed a version where the most common DTD files are embedded in the > > assembly, so it is not necessary to download them anymore when loading a > > document. > > This makes the point for merging all assemblies: currently it is handled > in > > ObjectModel assembly, since it is related to SVG. Anyway, during unit > tests, > > we still have very slow loading when we test Document or CssXmlDocument, > > because the optimization is below them. > > So we have two options: > > - moving DTDs and embedded resources into the Dom assembly > > - merging all assemblies > > Or maybe the tests are not accurate, and SvgDocuments should be used when > > SVG DTD are referenced? > > Pascal. > > > > jabber/gtalk: pa...@ja... > > msn: pa...@cr... > > > > > > > > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> > > wrote: > >> > >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> > wrote: > >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > >> > >> This is probably the most controversial change. One reason for the > >> split was an idea that each assembly could be reused on its own (like > >> by someone needing CSS support but not SVG). I don't think this has > >> exactly been a huge success in the user community so from my point > >> feel free to do whatever you find best :-) > >> > >> /niklas > > > > > > > ------------------------------------------------------------------------------ > > Create and Deploy Rich Internet Apps outside the browser with > > Adobe(R)AIR(TM) > > software. With Adobe AIR, Ajax developers can use existing skills and > code > > to > > build responsive, highly engaging applications that combine the power of > > local > > resources and data with the reach of the web. Download the Adobe AIR SDK > and > > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > > _______________________________________________ > > Svgdomcsharp-developers mailing list > > Svg...@li... > > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > > > > > > > -- > Bryan Livingston > |
From: Bryan L. <bry...@gm...> - 2009-02-06 18:05:18
|
What is the value of loading the DTDs? I cut out the DTD loading all together in xamltune and it still ran fine for my test set of 8000 svg files, just 2.5x faster. It was tricky to figure out but I can find the line to change to do that if you'd like. Bryan On Fri, Feb 6, 2009 at 8:00 AM, Pascal Craponne <pi...@gm...> wrote: > I committed a version where the most common DTD files are embedded in the > assembly, so it is not necessary to download them anymore when loading a > document. > This makes the point for merging all assemblies: currently it is handled in > ObjectModel assembly, since it is related to SVG. Anyway, during unit tests, > we still have very slow loading when we test Document or CssXmlDocument, > because the optimization is below them. > So we have two options: > - moving DTDs and embedded resources into the Dom assembly > - merging all assemblies > Or maybe the tests are not accurate, and SvgDocuments should be used when > SVG DTD are referenced? > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...> > wrote: >> >> On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> wrote: >> > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >> > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >> >> This is probably the most controversial change. One reason for the >> split was an idea that each assembly could be reused on its own (like >> by someone needing CSS support but not SVG). I don't think this has >> exactly been a huge success in the user community so from my point >> feel free to do whatever you find best :-) >> >> /niklas > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > -- Bryan Livingston |
From: Pascal C. <pi...@gm...> - 2009-02-06 15:00:10
|
I committed a version where the most common DTD files are embedded in the assembly, so it is not necessary to download them anymore when loading a document. This makes the point for merging all assemblies: currently it is handled in ObjectModel assembly, since it is related to SVG. Anyway, during unit tests, we still have very slow loading when we test Document or CssXmlDocument, because the optimization is below them. So we have two options: - moving DTDs and embedded resources into the Dom assembly - merging all assemblies Or maybe the tests are not accurate, and SvgDocuments should be used when SVG DTD are referenced? Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... On Wed, Feb 4, 2009 at 20:10, Niklas Gustavsson <ni...@pr...>wrote: > On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> wrote: > > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > > This is probably the most controversial change. One reason for the > split was an idea that each assembly could be reused on its own (like > by someone needing CSS support but not SVG). I don't think this has > exactly been a huge success in the user community so from my point > feel free to do whatever you find best :-) > > /niklas > |
From: Pascal C. <pi...@gm...> - 2009-02-05 17:26:22
|
Hi everyone, I experienced some problems today, with overflows on floating point calculations, with rounding errors, or overflows in GDI rendering. The W3 specification says: It is recommended that higher precision floating point storage and computation be performed on operations such as coordinate system transformations to provide the best possible precision and to prevent round-off errors. Conforming High-Quality SVG Viewers<http://www.w3.org/TR/SVG11/conform.html#ConformingHighQualitySVGViewers> are required to use at least double-precision floating point (see [ICC32<http://www.color.org/ICC-1A_1999-04.PDF>]) for intermediate calculations on certain numerical operations. Within the SVG DOM, a <number> is represented as a float or an SVGAnimatedNumber<http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedNumber> . so even if they speak about float in end, it's all left to user choice before. My suggestion is to: - use double in SVG DOM (it also has the effect of speeding up computations, since it's the native format) - use float in SVG renderer and let the renderer do the conversion by itself (and check the overflows there). Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... |
From: Pascal C. <pi...@gm...> - 2009-02-04 22:15:03
|
Hi everyone, I added Cort Schaefer as project member. Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... ---------- Forwarded message ---------- From: Pascal Craponne <pi...@gm...> Date: Wed, Feb 4, 2009 at 22:39 Subject: Re: Revival! To: Cort Schaefer <cor...@gm...> Until now, I did a very few changes, so I presume you can replay most of your changes, especially if you can extract the patches for your repository, so we can try to apply them one by one, automatically or manually. I added you to the project. Thank you for your contribution. Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... On Wed, Feb 4, 2009 at 21:08, Cort Schaefer <cor...@gm...> wrote: > I am registered on SF as corts. I would be happy to be added to the > project as a contributor (developer). > I don't know that I can fit in immediately (i.e next day or so) getting my > diffs isolated as I think I will have to reformat the source of the project > as you have it and mine so that they are compatible and then use something > to compare the 2 trees. I might be able to ferret some of it out of our CVS > repository of it, but it would take a little time. > > Cort > > > On Wed, Feb 4, 2009 at 11:19 AM, Pascal Craponne <pi...@gm...> wrote: > >> Hi Cort, >> that sounds great. I've fixed some bugs today, and I'm now experiencing >> random rendering problems. I suspect that some matrix computing is wrong >> somewhere, but it's hard to tell where. >> I'd love to see you changes committed to the project. >> Are you a registered contributor? >> >> Pascal. >> >> jabber/gtalk: pa...@ja... >> msn: pa...@cr... >> >> >> >> On Wed, Feb 4, 2009 at 19:11, Cort Schaefer <cor...@gm...>wrote: >> >>> I have been using SVG# for quite some time to drive a few projects. We >>> have actually made a number of changes both to functionality as well as to >>> performance. I would be more than happy to share those back with the >>> project. >>> We had made several inquires to the project and never got any responses >>> back so we considered the project dead and later reformatted the source to >>> match our standards --- which will make trying to isolate the diffs >>> interesting. We had upgrade to VS2008 as well. >>> >>> Cort >>> >>> On Wed, Feb 4, 2009 at 6:19 AM, Pascal Craponne <pi...@gm...>wrote: >>> >>>> Hi everyone, >>>> The project is alive again, with me as main reanimator :) >>>> I already did a few changes: >>>> - switched from CVS to SVN >>>> - switched to Visual Studio 2008 (still targetting .NET 2.0, but using >>>> C# 3.0) >>>> >>>> My current job is to perform a few fixes (I'm working with wikipedia SVG >>>> flags database,where links can be found at >>>> http://en.wikipedia.org/wiki/ISO_3166-1).<http://en.wikipedia.org/wiki/ISO_3166-1> >>>> >>>> After this, I'd like to perform the following changes: >>>> - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >>>> SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >>>> - moving all unit tests to a separate assembly (for reasons I don't >>>> understand, some tests are in the main assemblies). >>>> - conforming assemblies settings so the classes namespaces match the >>>> path (ReSharper sends me a lot of warnings about this). >>>> - documenting (with a little help from GhostDoc). >>>> >>>> Any comments, suggestions? >>>> >>>> Thanks, >>>> Pascal. >>>> >>>> jabber/gtalk: pa...@ja... >>>> msn: pa...@cr... >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Create and Deploy Rich Internet Apps outside the browser with >>>> Adobe(R)AIR(TM) >>>> software. With Adobe AIR, Ajax developers can use existing skills and >>>> code to >>>> build responsive, highly engaging applications that combine the power of >>>> local >>>> resources and data with the reach of the web. Download the Adobe AIR SDK >>>> and >>>> Ajax docs to start building applications today- >>>> http://p.sf.net/sfu/adobe-com >>>> _______________________________________________ >>>> Svgdomcsharp-developers mailing list >>>> Svg...@li... >>>> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >>>> >>>> >>> >> > |
From: Niklas G. <ni...@pr...> - 2009-02-04 20:15:12
|
On Wed, Feb 4, 2009 at 2:19 PM, Pascal Craponne <pi...@gm...> wrote: > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). This is probably the most controversial change. One reason for the split was an idea that each assembly could be reused on its own (like by someone needing CSS support but not SVG). I don't think this has exactly been a huge success in the user community so from my point feel free to do whatever you find best :-) /niklas |
From: Bryan L. <bry...@gm...> - 2009-02-04 19:58:05
|
Hey there Pascal, Good to have you on board. Such a coincidence meeting you here after working together on the dbLinq project. I've been working with a fork of SharpVector at http://www.codeplex.com/XamlTune. They've got a xaml renderer to do svg->xaml conversions. Bryan On Wed, Feb 4, 2009 at 6:19 AM, Pascal Craponne <pi...@gm...> wrote: > Hi everyone, > The project is alive again, with me as main reanimator :) > I already did a few changes: > - switched from CVS to SVN > - switched to Visual Studio 2008 (still targetting .NET 2.0, but using C# > 3.0) > My current job is to perform a few fixes (I'm working with wikipedia SVG > flags database,where links can be found > at http://en.wikipedia.org/wiki/ISO_3166-1). > After this, I'd like to perform the following changes: > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > - moving all unit tests to a separate assembly (for reasons I don't > understand, some tests are in the main assemblies). > - conforming assemblies settings so the classes namespaces match the path > (ReSharper sends me a lot of warnings about this). > - documenting (with a little help from GhostDoc). > Any comments, suggestions? > Thanks, > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > -- Bryan Livingston |
From: Don D. <do...@do...> - 2009-02-04 18:56:22
|
Rumor has it (and if I had heard anything from any in MSFT, officially or unofficially I wouldn't repeat it, so take this for what it is worth .) that native SVG support is on the list for IE 9. Don Demsak .Net Solutions Mentor & Consultant Microsoft <http://mvp.support.microsoft.com/profile=F161139B-12C5-4855-867E-27147C3BFC 84> Most Valuable Professional Member <http://www.ineta.org/DesktopDefault.aspx?tabindex=2&tabid=14> of the INETA Speakers Bureau <http://www.donxml.com/> DonXml.com Email: <mailto:do...@do...> do...@do... IM: do...@do... <mailto:do...@ho...> (MSN) http://www.linkedin.com/in/donxml From: Pascal Craponne [mailto:pi...@gm...] Sent: Wednesday, February 04, 2009 12:23 PM To: svg...@li... Subject: New member: Bryan Livingston Hi everyone, Bryan Livingston joined the project. He is mainly interested in XAML, so I just hope to see a XamlRenderer one of these days :) Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... |
From: Cort S. <cor...@gm...> - 2009-02-04 18:35:06
|
I have been using SVG# for quite some time to drive a few projects. We have actually made a number of changes both to functionality as well as to performance. I would be more than happy to share those back with the project. We had made several inquires to the project and never got any responses back so we considered the project dead and later reformatted the source to match our standards --- which will make trying to isolate the diffs interesting. We had upgrade to VS2008 as well. Cort On Wed, Feb 4, 2009 at 6:19 AM, Pascal Craponne <pi...@gm...> wrote: > Hi everyone, > The project is alive again, with me as main reanimator :) > I already did a few changes: > - switched from CVS to SVN > - switched to Visual Studio 2008 (still targetting .NET 2.0, but using C# > 3.0) > > My current job is to perform a few fixes (I'm working with wikipedia SVG > flags database,where links can be found at > http://en.wikipedia.org/wiki/ISO_3166-1).<http://en.wikipedia.org/wiki/ISO_3166-1> > > After this, I'd like to perform the following changes: > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > - moving all unit tests to a separate assembly (for reasons I don't > understand, some tests are in the main assemblies). > - conforming assemblies settings so the classes namespaces match the path > (ReSharper sends me a lot of warnings about this). > - documenting (with a little help from GhostDoc). > > Any comments, suggestions? > > Thanks, > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > |
From: Pascal C. <pi...@gm...> - 2009-02-04 18:24:46
|
Hi Jeff, pleased to meet you, I saw you name in a large number of CVS commits :) Apparently a lot of developpers (well, at least two :)) collapsed the five assemblies mentioned below, this is why I think this is a requirement. I think of SVG# as a set of 3 assemblies: 1. The core 2. The tests (all tests: some unit tests are currently in the core and I don't understand why) 3. The GDI renderer Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... On Wed, Feb 4, 2009 at 18:41, Jeff Rafter <jef...@gm...> wrote: > Hi Pascal, > Sorry I didn't get a chance to reply earlier, but I think this is great and > am really excited to see the project coming alive. The reason that > everything was split into separate assemblies was to make it easy and quick > to determine where something would be. Apart from that the Bindings was used > separately by projects like the scripting interfaces (which iirc were not > completely finished with regards to timing). > > Please feel free to ask any questions you have (and include code samples > along the way). > > All the best, > Jeff Rafter > > On Feb 4, 2009, at 5:19 AM, Pascal Craponne wrote: > > Hi everyone, > The project is alive again, with me as main reanimator :) > I already did a few changes: > - switched from CVS to SVN > - switched to Visual Studio 2008 (still targetting .NET 2.0, but using C# > 3.0) > > My current job is to perform a few fixes (I'm working with wikipedia SVG > flags database,where links can be found at > http://en.wikipedia.org/wiki/ISO_3166-1).<http://en.wikipedia.org/wiki/ISO_3166-1> > > After this, I'd like to perform the following changes: > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > - moving all unit tests to a separate assembly (for reasons I don't > understand, some tests are in the main assemblies). > - conforming assemblies settings so the classes namespaces match the path > (ReSharper sends me a lot of warnings about this). > - documenting (with a little help from GhostDoc). > > Any comments, suggestions? > > Thanks, > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com_______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers > > > |
From: Pascal C. <pi...@gm...> - 2009-02-04 18:19:49
|
Hi Cort, that sounds great. I've fixed some bugs today, and I'm now experiencing random rendering problems. I suspect that some matrix computing is wrong somewhere, but it's hard to tell where. I'd love to see you changes committed to the project. Are you a registered contributor? Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... On Wed, Feb 4, 2009 at 19:11, Cort Schaefer <cor...@gm...> wrote: > I have been using SVG# for quite some time to drive a few projects. We > have actually made a number of changes both to functionality as well as to > performance. I would be more than happy to share those back with the > project. > We had made several inquires to the project and never got any responses > back so we considered the project dead and later reformatted the source to > match our standards --- which will make trying to isolate the diffs > interesting. We had upgrade to VS2008 as well. > > Cort > > On Wed, Feb 4, 2009 at 6:19 AM, Pascal Craponne <pi...@gm...> wrote: > >> Hi everyone, >> The project is alive again, with me as main reanimator :) >> I already did a few changes: >> - switched from CVS to SVN >> - switched to Visual Studio 2008 (still targetting .NET 2.0, but using C# >> 3.0) >> >> My current job is to perform a few fixes (I'm working with wikipedia SVG >> flags database,where links can be found at >> http://en.wikipedia.org/wiki/ISO_3166-1).<http://en.wikipedia.org/wiki/ISO_3166-1> >> >> After this, I'd like to perform the following changes: >> - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, >> SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). >> - moving all unit tests to a separate assembly (for reasons I don't >> understand, some tests are in the main assemblies). >> - conforming assemblies settings so the classes namespaces match the path >> (ReSharper sends me a lot of warnings about this). >> - documenting (with a little help from GhostDoc). >> >> Any comments, suggestions? >> >> Thanks, >> Pascal. >> >> jabber/gtalk: pa...@ja... >> msn: pa...@cr... >> >> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code >> to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> Ajax docs to start building applications today- >> http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Svgdomcsharp-developers mailing list >> Svg...@li... >> https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers >> >> > |
From: Jeff R. <jef...@gm...> - 2009-02-04 17:42:02
|
Hi Pascal, Sorry I didn't get a chance to reply earlier, but I think this is great and am really excited to see the project coming alive. The reason that everything was split into separate assemblies was to make it easy and quick to determine where something would be. Apart from that the Bindings was used separately by projects like the scripting interfaces (which iirc were not completely finished with regards to timing). Please feel free to ask any questions you have (and include code samples along the way). All the best, Jeff Rafter On Feb 4, 2009, at 5:19 AM, Pascal Craponne wrote: > Hi everyone, > > The project is alive again, with me as main reanimator :) > I already did a few changes: > - switched from CVS to SVN > - switched to Visual Studio 2008 (still targetting .NET 2.0, but > using C# 3.0) > > My current job is to perform a few fixes (I'm working with wikipedia > SVG flags database,where links can be found at http://en.wikipedia.org/wiki/ISO_3166-1) > . > > After this, I'd like to perform the following changes: > - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, > SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). > - moving all unit tests to a separate assembly (for reasons I don't > understand, some tests are in the main assemblies). > - conforming assemblies settings so the classes namespaces match the > path (ReSharper sends me a lot of warnings about this). > - documenting (with a little help from GhostDoc). > > Any comments, suggestions? > > Thanks, > Pascal. > > jabber/gtalk: pa...@ja... > msn: pa...@cr... > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills > and code to > build responsive, highly engaging applications that combine the > power of local > resources and data with the reach of the web. Download the Adobe AIR > SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com_______________________________________________ > Svgdomcsharp-developers mailing list > Svg...@li... > https://lists.sourceforge.net/lists/listinfo/svgdomcsharp-developers |
From: Pascal C. <pi...@gm...> - 2009-02-04 17:23:05
|
Hi everyone, Bryan Livingston joined the project. He is mainly interested in XAML, so I just hope to see a XamlRenderer one of these days :) Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... |
From: Pascal C. <pi...@gm...> - 2009-02-04 13:19:33
|
Hi everyone, The project is alive again, with me as main reanimator :) I already did a few changes: - switched from CVS to SVN - switched to Visual Studio 2008 (still targetting .NET 2.0, but using C# 3.0) My current job is to perform a few fixes (I'm working with wikipedia SVG flags database,where links can be found at http://en.wikipedia.org/wiki/ISO_3166-1).<http://en.wikipedia.org/wiki/ISO_3166-1> After this, I'd like to perform the following changes: - merging assemblies (at least SharpVectorsBindings, SharpVectorCss, SharpVectorDom, SharpVectorUtil and SharpVectorObjectModel). - moving all unit tests to a separate assembly (for reasons I don't understand, some tests are in the main assemblies). - conforming assemblies settings so the classes namespaces match the path (ReSharper sends me a lot of warnings about this). - documenting (with a little help from GhostDoc). Any comments, suggestions? Thanks, Pascal. jabber/gtalk: pa...@ja... msn: pa...@cr... |
From: Niklas G. <ni...@pr...> - 2007-05-31 08:54:43
|
Hey I'm no longer active in the project. You could check with the more recent commiters to see if anyone can help you get going. If not, and you have any patches, send them to me and I'll help you commit them (or make you a commiter). /niklas On 5/31/07, Mathavan M <mat...@ya...> wrote: > Hi Niklas, > > I am really interested in working this SVG#. I always liked XML and C#. I > was looking for some project like this where I can contribute something. > > About me : I am a software consultant. Working with BizTalk, C#, and VB.NET. > > Thanks, > Mathavan > > ________________________________ > New Yahoo! Mail is the ultimate force in competitive emailing. Find out > more at the Yahoo! Mail Championships. Plus: play games and win prizes. > > |
From: Niklas G. <ni...@pr...> - 2007-02-11 15:47:15
|
Curia Damiano wrote: > Hello, in these last months I=92m using your SharpVectors C# library. >=20 > I=92m done some small improvements to it (the latest version downloaded= =20 > from the web), and they are: >=20 > - in SvgDocument.doc, introduced a little modify to open the=20 > svgz files automatically (already sent to you); >=20 > - in SvgPolyElement.cs, corrected a bug in the dot.net runtime= =20 > to catch an ArgumentException when you try to draw a polygon or line=20 > when point1=3D=3Dpont2 (maybe caused by the IsoDraw-generated files of = my=20 > customer); >=20 > - in GraphicsWrapper.cs, corrected a bug in the dot.net runtim= e=20 > to catch an OutOfMemoryException when you try to draw a path (seems to = > happen when the path is in reality a straight line, but not completely = > sure) (also this maybe caused by the IsoDraw-generated files of my=20 > customer); >=20 > - in SvgDocument.cs and GdiRenderer.cs, introduced some=20 > modifies to handle the case when you are disconnected from the Internet= =20 > (you try the same to validate the svg xml dtd; anyway if you do=20 > renderer.XmlResolver=3Dnull, you have to handle the namespaces that=20 > becomes blank =96 try to add the line =93127.0.0.1 www.w3.org=20 > <http://www.w3.org/>=94 to your hosts file). >=20 > Is it possible to include my improvements in the shared sources? I'm forwarding this mail to the developers list, someone there should be = able to help you. > And I would like to know, do you think to release a next version of thi= s=20 > library? And if so, when do you think to relase it, approximately? Hopefully they will also be able to help you with these questions. /niklas |
From: Niklas G. <ni...@pr...> - 2007-01-16 21:54:33
|
Hey Florian, glad you like SVG# and it's been useful for you! I'm no longer involved=20 in the project so I'm CCing the dev list on this email, hopefully=20 someone there can help you. /niklas Florian Geyer wrote: > Hello Niklas, >=20 > I=92m an information science student from Germany and I enjoy using you= r=20 > sharp vector graphics project for a research project at my university. >=20 > I managed to render SVGs to a bitmap but I think I need your help for m= y=20 > further plans. >=20 > I want to display SVG based graphics in a zoomable user interface. To d= o=20 > this I need to =93draw=94 the SVG document or nodes onto a canvas. I wo= uld=20 > like to use the SVG Renderer in the Paint-Event of a Class. Because I=20 > want to zoom in on the graphics I don=92t want to use the Bitmap-Render= er=20 > and draw the Image. >=20 > e.g. >=20 > void Paint(Graphics g) >=20 > { >=20 > // draw lines and shapes >=20 > g.FillPath(Brush, Ellipse); =20 >=20 > // draw vectors from SVG here=85 >=20 > } >=20 > Can you tell me which classes and functions I have to use to achieve=20 > this? I would appreciate any help I can get. >=20 > Thank you, >=20 > Florian Geyer >=20 |