Re: [Inkscape-devel] Problem with the GTK file selector in KDE
OK, the difference between the 2004-04-10 05:00 (good) and the 2004-04-10 06:00 (bad) versions are in inkscape.cpp and in main.cpp. Downgrading inkscape.cpp in the 06 tree to the 05 version does not solve the problem, but downgrading main.cpp DOES.
I just replaced all atof() and strtod() with g_ascii_strtod() which is locale independent. Please try the CVS and see if this fixes your problem (Arpad, you have the developer access and thus can check the up-to-the-minute CVS, others will have to wait until tomorrow because anon CVS lags behind).
_________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
I am using win32 autobuild 27April.
Print command throws me out of Inkscape.
Print command in 0.38.1 works as expected.
regards, vellum
On Wed, 2004-04-28 at 00:20, vellum wrote:
I am using win32 autobuild 27April.
Print command throws me out of Inkscape.
Print command in 0.38.1 works as expected.
Hmmm, any more info on this. Can you get a stack trace or something similar? There has been a few changes, notably the adding of extension properties into the print subsystem. I think that is the biggest change there, so I'm a touch concerned.
--Ted
Ted, I did some chasing this morning.
The problem seems to occur when there is text in the file.
With autobuild 28 April A freehand scribble prints OK. But just add some text and print throws me out of Inkscape. With a new document, add slightest bit of text and print throws me out.
The same behaviour occurs with builds back to and including 18 April.
With builds up to and including 9 April print works properly for text and drawing.
I cannot pin it down any further as I do not have any builds within that time gap.
hope this helps.
vellum
On Wed, 2004-04-28 at 16:21, vellum wrote:
The problem seems to occur when there is text in the file.
Ah, yes. Carl, this is probably related to the text function that was added. I don't think that it was added into the other print drivers besides the Postscript one. Is it possible that we could make the default /src/extension/implementation/implementation.cpp one do the same rendering of the text that was done before? This way older print drivers won't need to reimplement this functionality.
--Ted
On Thu, 29 Apr 2004, Ted Gould wrote:
On Wed, 2004-04-28 at 16:21, vellum wrote:
The problem seems to occur when there is text in the file.
Ah, yes. Carl, this is probably related to the text function that was added. I don't think that it was added into the other print drivers besides the Postscript one. Is it possible that we could make the default /src/extension/implementation/implementation.cpp one do the same rendering of the text that was done before? This way older print drivers won't need to reimplement this functionality.
Hi Ted,
The problem is that sp_text_print() has to decide whether to print text by printing curves, or whether to call sp_print_text() (which in turn calls Extension::text()).
It decides this by doing sp_print_get_param for the "textToPath" parameter. If an extension does not know the parameter, it throws an exception. This is currently not caught, causing the silent exit.
The quick fix for this is:
Index: extension/internal/win32.cpp =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/extension/internal/win32.cpp,v retrieving revision 1.7 diff -u -r1.7 win32.cpp --- extension/internal/win32.cpp 15 Apr 2004 18:23:46 -0000 1.7 +++ extension/internal/win32.cpp 29 Apr 2004 14:06:35 -0000 @@ -483,6 +483,7 @@ "<spmodule>\n" "<name>Windows 32-bit Print</name>\n" "<id>" SP_MODULE_KEY_PRINT_WIN32 "</id>\n" + "<param name="textToPath" type="boolean">TRUE</param>\n" "<print/>\n" "</spmodule>", new PrintWin32());
I think you always want to do text-to-path for this extension, so this fix should be ok.
Do you think it's right that an exception is thrown if a particular extension doesn't understand some parameter? I'm not really very well up on the extension code.
Thanks
Carl
On Thu, 2004-04-29 at 07:13, Carl Hetherington wrote:
The problem is that sp_text_print() has to decide whether to print text by printing curves, or whether to call sp_print_text() (which in turn calls Extension::text()).
It decides this by doing sp_print_get_param for the "textToPath" parameter. If an extension does not know the parameter, it throws an exception. This is currently not caught, causing the silent exit.
<snip>
Do you think it's right that an exception is thrown if a particular extension doesn't understand some parameter? I'm not really very well up on the extension code.
I don't know - I'm kinda of the thought that you shouldn't use a parameter that you don't know exists in any situation other than an extreme one. So, I wanted to make the error very obvious. (and, in this case it seems to have worked :)
I think, perhaps, a better solution would be having another extension function which is 'bool text_to_path (void)' and then it can be implemented in the implementation class to always return true. Or, have a return value from the text function that says 'hey, don't use me'.
I really never intended parameters to be used generically, like for all print extensions. I've always thought of them as: this parameter goes to this extension. If it needs to be that global, probably putting it into the objects themselves is more proper, perhaps with a definition in the XML file to define whether the print extension supports text printing.
I don't know - thoughts? Should parameters be made more globally accessible?
--Ted
win32 autobuild 27 April. In the Fill and Stroke Proerties box the object markers do not have icons. Should they be there?
Also:
INK_mArrowTail3 is often not aligned with the underlying line when it is curved. Slight but quite noticeable. INK_mArrow4 empty circle is on the line. It would seem more consistent to have it straddling the line and locate cleanly at the beginning or end of the line. INK_mArrow4 and mArrow5 are not arrows.
Would it be possible/easy to make the markers fine tunable after placement?
vellum
participants (4)
-
bulia byak -
Carl Hetherington -
Ted Gould -
vellum