RE: [Inkscape-devel] more on win32 locale
I applied your first three patches, thanks.
- When drawing a polygon (the star) numbers in the points element are
locale dependent, strange the star is drawn correctly. 2. The root document with and height are also locale dendent.
Yes, and probably other places, too. What we need to do is just search for "printf" and see if the output of it goes into SVG, and if so, replace them (some printfs print debug messages on screen, you can leave them alone). Now that you know what to do, it should be easy :)
cvs diff sp-polygon.cpp (in directory C:\projekte\inkscape\src)
Please resend this patch in diff -u format as were the previous ones.
_________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
bulia byak wrote:
I applied your first three patches, thanks.
- When drawing a polygon (the star) numbers in the points element are
locale dependent, strange the star is drawn correctly. 2. The root document with and height are also locale dendent.
Yes, and probably other places, too. What we need to do is just search for "printf" and see if the output of it goes into SVG, and if so, replace them (some printfs print debug messages on screen, you can leave them alone). Now that you know what to do, it should be easy :)
I think that they were all cleaned up in /xml and /svg, and now it is mostly the special shapes that have sprintf()'s left.
Mental's use of <sstream> works nicely. I have used that elsewhere to format floats free from locale worries.
Look at how /svg/svg-path.cpp , line 631 uses Inkscape::SVGOStringStream. It is small and simple.
Bob
bulia byak wrote:
I applied your first three patches, thanks.
You are my boy ;-)
Please resend this patch in diff -u format as were the previous ones.
see attached file
Adib.
--- sp-polygon.cpp 2004-03-27 11:07:45.000000000 +0100 +++ sp-polygon.adib.cpp 2004-03-26 18:39:11.000000000 +0100 @@ -17,8 +17,9 @@ #include <stdlib.h> #include "attributes.h" #include "sp-polygon.h" #include "helper/sp-intl.h" +#include "stringstream.h"
static void sp_polygon_class_init (SPPolygonClass *klass); static void sp_polygon_init (SPPolygon *polygon);
@@ -95,33 +96,28 @@ */ static gchar * sp_svg_write_polygon (const ArtBpath * bpath) { - GString *result; + Inkscape::SVGOStringStream os; int i; - char *res; g_return_val_if_fail (bpath != NULL, NULL);
- result = g_string_sized_new (40); - for (i = 0; bpath[i].code != ART_END; i++){ switch (bpath [i].code){ case ART_LINETO: case ART_MOVETO: case ART_MOVETO_OPEN: - g_string_sprintfa (result, "%g,%g ", bpath [i].x3, bpath [i].y3); + os << bpath [i].x3 << "," << bpath [i].y3 << " "; break;
case ART_CURVETO: default: g_assert_not_reached (); } } - res = result->str; - g_string_free (result, FALSE); - - return res; + + return g_strdup (os.str().c_str()); }
static SPRepr * sp_polygon_write (SPObject *object, SPRepr *repr, guint flags)
In the "Elements and Principles of Design" tutorial", the Principles of Design graphics are all absent. Should this be so?
vellum using Win32 auto-build 27 March 2004.
On Fri, 26 Mar 2004, bulia byak wrote:
I applied your first three patches, thanks.
- When drawing a polygon (the star) numbers in the points element are
locale dependent, strange the star is drawn correctly. 2. The root document with and height are also locale dendent.
Yes, and probably other places, too. What we need to do is just search for "printf" and see if the output of it goes into SVG, and if so, replace them (some printfs print debug messages on screen, you can leave them alone). Now that you know what to do, it should be easy :)
The printfs that print debug messages should probably be replaced with g_message() or g_warning() calls, as appropriate.
Bryce
Bryce Harrington wrote:
On Fri, 26 Mar 2004, bulia byak wrote:
I applied your first three patches, thanks.
- When drawing a polygon (the star) numbers in the points element are
locale dependent, strange the star is drawn correctly. 2. The root document with and height are also locale dendent.
Yes, and probably other places, too. What we need to do is just search for "printf" and see if the output of it goes into SVG, and if so, replace them (some printfs print debug messages on screen, you can leave them alone). Now that you know what to do, it should be easy :)
The printfs that print debug messages should probably be replaced with g_message() or g_warning() calls, as appropriate.
Bryce
Bryce,
I was thinking, wouldn't it be nice if Inkscape had its own debug output console, like many apps have? This is almost unnecessary on Unix, but important on platforms that do not have pty-like consoles.
How about adding a couple of methods to the Inkscape class (since all code pieces in Inkscape should have it as their parent), like inkscape->error("format", ...) and inkscape->warning("format", ...); .
We could use this to redirect the debug output to either the same Glib g_message() and g_error() output we have now, or to a separate Gui. A simple text console similar to Mozilla's Java Console would be excellent. We could redirect many types of informational messages to it. And it would be in a format that users could easily email to us in case of problems.
This might be a good task for a new contributor to Inkscape.
Bob
Bob
On Sun, 2004-03-28 at 00:24, Bob Jamison wrote:
We could use this to redirect the debug output to either the same Glib g_message() and g_error() output we have now, or to a separate Gui.
There's really no reason to do so; glib already provides hooks to redirect the g_message() and g_error() output elsewhere (e.g. to such a GUI console).
http://developer.gnome.org/doc/API/2.0/glib/glib-Message-Logging.html#g-log-...
-mental
On Sat, 27 Mar 2004, Bob Jamison wrote:
Bryce,
I was thinking, wouldn't it be nice if Inkscape had its own debug output console, like many apps have? This is almost unnecessary on Unix, but important on platforms that do not have pty-like consoles.
Not a bad idea.
How about adding a couple of methods to the Inkscape class (since all code pieces in Inkscape should have it as their parent), like inkscape->error("format", ...) and inkscape->warning("format", ...); .
Could we be certain that all of the places we'd want to emit errors would have visibility to the inkscape class definition? I.e., are there any sub-libraries that we'd want to emit debug info but not be tied too tightly to Inkscape? How would this work for Inkview?
We could use this to redirect the debug output to either the same Glib g_message() and g_error() output we have now, or to a separate Gui. A simple text console similar to Mozilla's Java Console would be excellent. We could redirect many types of informational messages to it. And it would be in a format that users could easily email to us in case of problems.
*Nod* Do you have examples of how other apps have done it, or do you think the Mozilla approach is completely representative?
Bryce
Hi people,
I cannot get special characters using Win32-2000 autobuild 27 March.
Each time I try I get a small empty rectangle instead of the character.
I am also getting the error message shown in the attached file.
I am sure that I used to be able to get special characters. Any help?
vellum
participants (6)
-
Adib Taraben -
Bob Jamison -
Bryce Harrington -
bulia byak -
MenTaLguY -
vellum