- Inkscape Devel - Inkscape Mailman

RE: [Inkscape-devel] news + features
by bulia byak 26 Jan '04

26 Jan '04

>Are there any more announcements? I add most features/fixes I do to the release notes. Review the release notes to see if there's anything that you like that wasn't on the front page yet. (And add anything missing to the release notes as well.) _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

new preview?
by bulia byak 26 Jan '04

26 Jan '04

Anyone would object if I remove this command? What it does is basically runs an SVG viewer on the current file. The idea behind this is unclear to me. If you want a parallel view of your file, "New view" would be just fine. So I think "New preview" is confusing and useless. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

news + features
by Jonathan Phillips 26 Jan '04

26 Jan '04

Does anyone have any news/announcements that they would like on the main page. I'm going to add prior to our release: - inkscape-user mailing list announcement Are there any more announcements? Jon -- Jonathan Phillips <jon@...15...>

1 0

remove/apply transformations?
by bulia byak 26 Jan '04

26 Jan '04

Another confusing concept. SVG allows to store transformations (moves, rotates, etc) both "natively" (in the object's own coordinates) and as a transform= attribute that is applied "after the fact". Of the many commands that move/rotate objects, some (most) write the new coordinates directly into the object, but some just add a transform= attribute without changing anything else in the object. I see no apparent logic behind this difference in behavior. Now, the "remove transformations" command simply erases the transform= attribute if it is present. Recent Sodipodi adds "apply transformations" which writes the transform= into the object and then removes it (i.e. no visible change). I think this mess is very confusing and serves no useful purpose. To an artist, "remove transformations" works as a weird sort of undo whose results are generally unpredictable, and "apply transformations" does nothing at all. So I propose: - remove the "remove transformations" command. - fix the remaining commands that add transform= so that they always "apply" their transformations to the objects at once. (In particular, scaling a text object must affect its font size; transforming a group must write transformations into the group's members instead of adding transform= to the entire group.) I may have missed something, so please argue. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

[Fwd: [Sodipodi-list] Writing SVG code for editing with Sodipodi]
by Jonathan Phillips 26 Jan '04

26 Jan '04

Looks like the UNITS problem! Arg! It seems like there are all these containers of ideas and badly implemented ideas that are TODO that still hang over us still in INKSCAPE. I say we evaluate, disable, and remove any of this unimplemented or crappy code from the project. It will probably make our life easier in the long run. The units problem is horrible. Our printing system and export system are pretty bad too. ARG! Jon -----Forwarded Message----- From: Pierre Abbat <phma@...177...> To: sodipodi-list(a)lists.sourceforge.net Subject: [Sodipodi-list] Writing SVG code for editing with Sodipodi Date: Sun, 25 Jan 2004 11:22:47 -0500 I wrote a two-line program that generated a lemniscate and pasted the code into a <path> element in a Sodipodi file. Since the width and height are in millimeters I thought the coordinates would be in millimeters. They weren't. The lemniscate was too small. I then edited it so that it looked like M-87.4619707139396mm 42.4024048078213mm M-88.2947592858927mm 41.4518786277521mm M-89.1006524188368mm 40.4508497187474mm and tried again. The lemniscate went flat. I removed the millimeters and scaled it and put it in the middle of the 300*300mm square. The center is now at 531.4961,531.4961. What unit is Sodipodi using, and how do I tell it that the coordinates are in millimeters? phma -- Jonathan Phillips <jon@...15...>

2 1

export background
by bulia byak 26 Jan '04

26 Jan '04

Now the page color, settable in the document options dialog and saved with the document, is also used as the background color when exporting anything from this document. By default this color is white and 100% transparent, so the default export has transparent background as before. However you can set it e.g. to white 0% transparent and have white background in PNG without having to add any background objects. For this to be possible I added inkscape:pageopacity attribute to the namedview. Now the page color is split into the pagecolor and inkscape:pageopacity attributes - ugly but at least partially compatible with Sodipodi. By the way, Sodipodi now has an extra color picker right on the Export dialog for the same purpose (setting background color for export). I think simply using page color is more natural and convenient. Especially given that, in the typical Sodipodi fashion, that picker's color is not saved/restored anywhere... I'm also thinking about saving export dpi in the namedview as well, so that each document would remember its last dpi setting. I think it's logical. Other improvements today: font list in the text dialog is autoscrolled to always show selected font; text object description shows font in the statusbar; currentColor and userSpaceOnUse fixes ported from Sodipodi; and many other bugfixes. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

1 0

Proposal: "inkscape-user@" mailing list
by Bryce Harrington 26 Jan '04

26 Jan '04

For the purposes of assisting users following the 0.37 release, we should create an inkscape-user@ mailing list at this time. The purpose of this list would be to serve as a place for users to share tips and tricks and help each other learn how to make effective use of the tool. Having a place to build a user community will be adventageous, as many users may find devel lists overwhelming. If this sounds good, I'll set it up, and we can push membership in it as part of the 0.37 announce. Bryce

1 1

RE: [Inkscape-devel] Win32 - Bug in Markers?
by bulia byak 26 Jan '04

26 Jan '04

>Can someone check please? > >The line markers are not working with the freehand line or bezier curve >tools. I get the messages 'start_marker' marker is '<nil>', >'mid_marker'...... and 'end_marker'........is nil, as soon as I start. The >end cap choices are working. For me, nothing works at all in today's CVS. When I click any marker button, Inkscape crashes. >This is the first time I have used this so I do not know if it is recent >behaviour. Yes, I think Bryce added it recently. I hope it gets resolved for the release. Are the preferences problems resolved? I recently tested it on Windows 98 and it seems to work OK. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 2

Inkscape on Windows
by Ryan Pavlik 25 Jan '04

25 Jan '04

Hello developers! I am not a member of the list, I just sent this in to alert you of a potential installer problem. I have GTK 2.2.4-2 (from the Gimp web site) installed, which is the official version for Windows. However, when I try to install Inkscape, it quits the installer, asking me to install GTK2. I will continue to try to override this setting in the installer, as the official GTK should work fine... Ryan (any replies please copy to me, since I am off list)

1 0

sodipodi:type namespace
by MenTaLguY 25 Jan '04

25 Jan '04

I realized one other place where we need to be careful about not polluting sodipodi's namespace -- sodipodi:type. Currently, we only have one "type" of our own, SPOffset, but we can expect to add more. I think the best way to approach this is to prefix any types we introduce ourselves with inkscape: -- e.g. now the sodipodi:type for SPOffset will be "inkscape:offset". I think it's important we get these issues sorted out before the release. As a result, I've changed the sodipodi:type used in HEAD -- if you have existing documents using SPOffsets, you'll need to fix their sodipodi:type from the XML editor. -mental

1 0