- Inkscape Devel - Inkscape Mailman

Last minute file naughiness
by Jon A. Cruz 07 Feb '05

07 Feb '05

Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now. The one I am concerned about is in repr-io.cpp, in sp_repr_read_file I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.

6 25

line-height
by bulia byak 06 Feb '05

06 Feb '05

Peter: Please don't touch line-height property which I added to style.cpp. Reasons: 1. CSS2 says: "User agents must ignore a declaration with an unknown property." This means even if it is an invalid property, it will do no harm. It will just be ignored. 2. In SVG 1.1, line height is just given a fixed value equal to font-size. Our specifying a different value will have no effect whatsoever on compliant renderers. 3. SVG 1.2 indeed does not mention line-height for flowtext (as I wrote here some time ago). But it also proposes NO OTHER mechanism for controlling inter-line spacing. So I'm inclined to think that this is just an omission in the standard. If you're so worried by it, you can go to the W3C SVG list and raise this issue there. I'm reasonably sure that when made aware of the omission, the authors will reuse line-height as this is the most natural approach. 4. Without a way to control line spacing, flowtext is pretty much useless. So, if we cannot use line-height nor any other mechanism for that, I see no reason to continue working on flowtext. In other words, the choice we have is between completing the draft spec where it's most obviously incomplete, or just giving up and not having flowtext at all.

1 0

inkscape.svg vs plain.svg
by unknown＠example.com 06 Feb '05

06 Feb '05

Hi, I have been going through the openclipart.org flag collection yesterday, cleaning up metadata etc. There is a couple of issues I would like to bring up which I noticed in this process. The first thing is that images saved in sodipodi.svg/inkscape svg do not always render correctly with librsvg. I filed a bug with librsvg on this, but the reply I got is that this is caused by sodipodi/inkscape svg not being fully SVG compliant. Saving the flags with prolems as plain.svg made them all render correctly. Now the question is wether I should file these flags towards Inkscape as bugs, I assume so, as I think if we generate a file with .svg it should render nicely in all other SVG renderers? For some testfiles all the pirate flags in openclipart 0.10 misrender until resaved as plain svg. librsvg bug with some details here: http://bugzilla.gnome.org/show_bug.cgi?id=166385 The second thing which I have brought up with Jon Cruz and Bryce already is that there is some difference in metadata handling between svg_annotate/svg_validate and Inkscape. Inkscape do not recognize keywords set by svg_annotate and svg_validate do not recognize titles set by Inkscape for instance. Apart from these items, keep up the great work, Inkscape is really rocking! Christian

2 2

Bug 1114714
by Jon A. Cruz 06 Feb '05

06 Feb '05

To try to see if bug 1114714 is fixed, can someone on Win32 add some asserts and test things? Just go into src/dialogs/export.cpp and before each call to *_set_text add warnings just before each? if (!g_utf8_validate(variableAboutToCallSetWith, -1, NULL)) { g_warning( "variableAboutToCallSetWith IS NOT UTF-8" ); } Then try some file/directories with umlauts in them? Thanks.

1 0

0.41pre1 tarball is up
by Kees Cook 06 Feb '05

06 Feb '05

Ted and are both having harddrive and filesystem problems tonight, it seems. I've managed to get the 0.41pre1 tarball up on sourceforge, emulating the prior prerelease notes, etc. -- Kees Cook @outflux.net

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 06 Feb '05

06 Feb '05

They were actually listed under libinkpre_a_SOURCES. Just removing them from there fixed the issue. Thanks for the help on this! Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Saturday, February 05, 2005 1:27 PM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies On Sat, 5 Feb 2005, Montgomery, Steven S wrote: > I've went ahead and included the extern lines: however, that's a > different issue than what we were having. The undefined reference we > have is to functions we wrote in inkboard.cpp. Here they are from the > most recent attempt: > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xa7a): In function > `sp_inkBMsg_ObjectAddedChild': > dialogs/InkboardMsg.cpp:436: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xc92): In function > `sp_inkBMsg_ObjectRemovedChild': > dialogs/InkboardMsg.cpp:519: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xe4d): In function > `sp_inkBMsg_ObjectChanged': > dialogs/InkboardMsg.cpp:624: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa97): In function > `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:228: undefined reference to > `connect_and_auth(char*, char*, char*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xacf):dialogs/inkboard > -connect.cpp:238: undefined reference to `setRecipient(char const*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0x138f): In function > `sp_inkboardConnect_dialog_inkboardShareUser(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:393: undefined reference to > `send_connect_request_to_user(char const*, char*)' > > I suspect you didn't get that error when you checked out of the CVS. > Line 8 of inkboard.cpp should be #include "dialogs/InkboardMsg.h" > instead of #include "dialogs/InkboardMsg.cpp". I hesitate to upload > that change since we've been following the convention of only committing > changes after we ensure that it at least compiles. > > For a reason I don't fully understand, including that .cpp somehow > informs the linker of where our new functions are defined. Well, by including the .cpp you essentially are pasting the contents of that file in, so it's getting the full definition of all the functions. However, having multiple definitions of functions in your binary will cause trouble later, so we should solve the problem more directly... Try this. Move your two main files to the inkpost.a section, i.e.: libinkpost_a_SOURCES = \ ... inkboard.cpp inkboard.h \ This forces those objects to be compiled last in the link chain, so if link ordering is the issue, this might fix it. Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

g_file_test
by Kees Cook 06 Feb '05

06 Feb '05

I've been playing with Jon Cruz's updates to the profile_path and mkdir stuff. Short story: it works. Long story: g_file_test isn't utf sane. *bang head* So, the test for the directory fails, but making it works just fine. -- Kees Cook @outflux.net

5 8

[0.41] Fix link: Move functions from splivarot.cpp to xml/
by Peter Moulder 06 Feb '05

06 Feb '05

A couple of utility functions in splivarot.cpp have become used by xml/repr-util.cpp. The attached patch moves these two functions (LCA and AncetreFils) to new files xml/repr-sorting.{cpp,h} in xml/libspxml.a. This is appropriate for cleanliness, and also fixes a link problem with `make check'. Since we're in hard freeze, I haven't renamed these functions. (N.B. Remember to do `cvs add -ko xml/repr-sorting.{cpp,h}' after applying this patch.) The patch (like the gc one, I should have mentioned in the previous message) is from the src directory. pjrm.

2 2

[0/5]: patches for clean "make check"
by Kees Cook 05 Feb '05

05 Feb '05

Following this email are five patch sets (whose apply order matters). This is a full roll-up of changes Peter and I worked on last night with some additional updates to get "make check" to fully pass. 1/5: compile cleanups only This is makefile goo for getting "make check" to compile correctly. 2/5: test code changes only This is test-code changes only. No core code changes are needed to make these tests pass "make check". 3/5: core code changes for repr-action-test compiling This is a change to the way core code is layed out in the tree, to help compile repr-action-test more easily. The functions are unchanged. 4/5: core code changes for repr-action-test behavior This changes when an undo session is released, down in simple-session. This lets repr-action-test pass its tests. The only caller to sp_repr_rollback is sp_document_cancel. sp_document_cancel isn't easily callable, since the three calls to it currently would only happen during repr tree breakage in the XML editor. I think this is safe. 5/5: win32 file list updates This is just a final sync of all the above file changes, as seen by the win32 file list building tools. "make check" finished, but "make distcheck" does not, as streamtest depends on files local to its directory, which is against build rules for "distcheck". I will fix it later, since I made it relocatable in patch #2. -- Kees Cook @outflux.net

4 4

[4/5]: core code changes for repr-action-test behavior
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

3 2