- Inkscape Devel - Inkscape Mailman

Save as.../Export etc.
by Alexandre Prokoudine 10 Jan '05

10 Jan '05

Hi, Bryce told me that some dialogs need redesigning and "Export to bitmap" is one of them. After some serious thinking I came to conclusion that redesigning "Export to bitmap" is not enough. The issue is actually with Save as.../Export dialogs themselves. IMO, there are some inconviniences that need to be fixed. Let's look at these functions through the user case glass. Designer A has done a nice sketch. Though he likes it, he wants to make another version. He saves it under some other name and keeps working on the new file. Designer B has done several sketches. Now he wants to send them to his customer in some easy to view file format. He needs to save copy of each original file in a different file format in the same directory, where originals are. Now let's look closer. In the first case he wants to go to "File - Save as..." and specify name of the new file in the same directory, without changing file extension. The only reason to "save as" into, e.g. AI is when he was told that the new version has to be done in AI from ground up -- and only if his $VECTOR_GRAPHICS_EDITOR supports direct editing of AI files. I wonder how smooth Inkscape is at editing AI/EPS/EPSI/POV/PS instead of native SVG :) In the second case he wants to go to "File - Export as..." and: 1) specify name of the new file; 2) specify its extension; 3) specify export parameters. I don't even doubt that Inkscape will have export parameters dialog for EPS and PostScript (and TIFF as soon as someone writes it). Users are not supposed to see "Export to EPS", "Export to TIFF" etc. menu items in "File", don't you agree? ;) The GIMP model I'm talking about is quite nice, but its has a PITA drawback -- The GIMP doesn't remeber the last directory it went to. If you find a way to work around it, we will need the following: 1. Add "Export as..." menu item to "Files". 2. Add "Export to" dialog in a GIMP style with - a file name entry box; - a combobox to switch between directories from gtk bookmarks; - a hidable large "Specify directory" file panel; - a hidable "Choose export format" panel. 3. Move current "Export to bitmap" dialog to a new dialog "PNG export settings" which will appear, if a user chooses PNG as export format. Adding export settings to other file formats will be easier then. Guys at Novell have good points in their DesignWiki (http://primates.ximian.com/~glesage/wiki/doku.php?id=gimp:png_export). I really like their idea, so I suggest: 4. Add "Fast export" (or "Save for Web") menu item to save a PNG to the same directory, where the sketch is, or to a "fast export" directory specified in Inkscape's preferences. It will make decision on saving region from the selection context: - export the whole page, if nothing is selected; - export current selection, whatever is selected. Honestly, I don't remember myself ever saving a "special" region -- only current selection or the whole page. If I want something to be absent in exported bitmap, I either don't select or move it away out of the page. But my use case may be different from yours. I can imagine a situation when a designer needs to export "slices" from his design. I really hope that this proposal makes some sense to you :) Alexandre

6 8

inkscape rpm second patch (fwd)
by Bryce Harrington 10 Jan '05

10 Jan '05

Could someone apply this patch if still needed? Bryce ---------- Forwarded message ---------- Date: Thu, 30 Dec 2004 07:43:58 -0500 From: D. Scott Barninger <barninger@...639...> To: Bryce Harrington <bryce@...260...> Subject: inkscape rpm second patch Bryce, Here is a second patch against the 1.14 CVS spec file. It adds build choices for both SuSE 9.2 and Fedora Core 3. Regards, Scott

1 0

problems
by David Christian Berg 09 Jan '05

09 Jan '05

I had a cvs version of Inkscape running, and it would not have working flowtext... so that is problem number one. Number two is, that after downgrading to the Debian package my guides were at the wrong spot due to the change of units. Both really annoying... Also I've noticed that quite often I just can't grab objects, to move them, but have to use the keyboard first, and then, after moving them a little, I can move them with the mouse. I've no idea, how to reproduce this, but it bothers me a lot, so maybe someone else has experienced this? Another point, I noticed, when creating the icons, is that the scaling mechanism works kinda weird with objects with strokes... when you try to set a specific size, it will not work via snapping to guides nor via the tooloptions bar. Just try on very small scales... because that is where you'll notice. That's it for now... I'll be writing another mail soon, I guess. After some feedback I'm also in for doing the needed bug reports. David

2 2

autopackages now statically linked
by Mike Hearn 09 Jan '05

09 Jan '05

Hi guys, I'm now statically linking the GTKmm stack as well as Boehm GC into the Inkscape nightly autopackages, and will do so for the next release. So we should have no more problems with them blowing up on people with mixed/broken distro setups. I also added dep checks for libxml2 and libxslt. thanks -mike

1 0

Broken string trimming
by Jon A. Cruz 09 Jan '05

09 Jan '05

I just saw this in the jabber logs (01:20:33) *bryce:* to delete the first N chars off the start of a string s, is it ok to do s += N? The answer, for most of our stuff, is a big resounding "NO!" Remember, when multibyte encodings come into play, doing something like that is liable to break things mid-sequence and corrupt data. Or to get the wrong count and trim fewer characters that you'd expect. In most places our code is using the 'standard' GTK+ encoding of UTF-8. That's multibyte, with from 1 to 6 bytes per character. Of course, if you're at the point where raw data is entering the app via some means other than UI widgets, the bytes will be in whatever the local encoding is. So just remember, characters no longer match bytes one-for-one. Sometimes they'll happen to align, but other times not.

5 7

Draw Icons
by David Christian Berg 09 Jan '05

09 Jan '05

For all those of you who like a more Adobe-ish look for the drawing tool icons: Attached is a icon set that covers the drawing tools. The groups are named correctly, so you only need to delete the icons in the icons.svg and insert the attached file (you might have to ungroup the inserted file afterwards) Enjoy! David

7 8

0.41 About Artwork
by Andy Fitzsimon 09 Jan '05

09 Jan '05

attached is a png snapshot .. you can grab the svg from the url below (56 warning ) http://andy.fitzsimon.com.au/about41.svg let the controversy begin :-) This style was pretty trendy in 2004. its a hybrid of the distressed/metro-sexual looks. And I'm embarrassed to admit I think I have a pair of jeans & shirt somewhere with the same 2second mongrel print-work on it. So... why did I slaughter the comfort of your eyes ? Because Inkscape makes it so easy ! Thanks to the calligraphy pen, inset/outset and simplify commands this style is more easy to emulate with Inkscape than any other vector illustration program. There are starving indie-punk kids out there right now making their band t-shirts with this stuff. And they are paying ( or at least their universities are ) for the proprietary software their art is made with. Anyway i thought id just throw this around as an idea. let me know if it gets approval note: I'm happy to create a completely different about page. I understand there are several conferences coming up and it might be useful to have our next release looking as professional as possible.

4 3

version numbers: 0.41, 0.42, Gtkmm, and 0.50
by Derek P. Moore 08 Jan '05

08 Jan '05

I've been helping Bryce recently with the experimental Gtkmm codebase. Today I was thinking about all the work involved, what it means, and version numbering... A top-level UI replacement in Gtkmm is a pretty big change in the architecture of Inkscape; and though creating it isn't terribly difficult, tying the existing application (the canvas/viewport, tool and feature implementations, etc.) and all its functionality into the hollow shell of the Gtkmm UI will present more of a challenge. And it may take longer than we hope (a quarter of a year, maybe). If 0.4* stayed stable for a while, that might be nice. We could probably use more than one stable release before the work of transitioning Inkscape to the new top-level GUI is up to snuff with what we've got now in the 0.4 tree. There's going to be a lot of things to hunt down and tear out of Inkscape to make way for The New Way(tm)... And I imagine it's going to be fairly tedious hooking everything up. But I think we can wrangle two codebases at once, as they're not all that radically different. And many development communities are familiar with the concepts of separate "stable" and "development" trees. The people working a lot on 0.4 can keep working a lot there. In about a month or so, we'll probably be ready for 10% of your coding time to help move your bits to the development tree. Once everything is moved over to the new shell, and is stable and ready for general users, we could then tag and release the development tree as 0.50. I could see us getting well into 0.45 before 0.50 is ready to replace the old codebase. But I also imagine that the 0.5 codebase could become stable and interesting enough early on in the process to attract new developers and alpha/beta users. I just thought going about the next major release this way might give us developers more room to breathe, instead of trying to cram all this work between 0.41 and 0.42 (although that approach might be more "exciting" :). Any thoughts? Derek

9 25

oops: metadata bug
by Kees Cook 08 Jan '05

08 Jan '05

Since the "svg:" prefix change, there was another bug with metadata where every time you opened an SVG, it would add another empty "metadata" tag. I've fixed this now, but please check your files. icons.svg, for example, had like 40 extra metadata's in it. ;) -- Kees Cook @outflux.net

5 6

ANNOUNCE: Scribus 1.2.1
by Plinnell 08 Jan '05

08 Jan '05

The Scribus Team is pleased to announce the release of Scribus 1.2.1 - Open Source Desktop Publishing. The Scribus team urges all users and distros to use this latest release. This release also marks the first public offering of commercial support by members of the Scribus Team. This support is primarily intended for printers, publishers and other interested parties in receiving expert implementation and migration support. Building on the first stable 1.2 version released in August 2004, 1.2.1 intergrates new import/export features, python scripter additions and rendering speed improvements : * A new OpenOffice.org importer. The new importer imports OO Writer files,complete with OO.org Writer styles retained. The OpenOffice.org Draw importer inserts Draw files onto the page as native Scribus objects. * Substantial improvements in the Python Scripter, including added functionality and enhanced error handling. * Numerous improvements to SVG import/exporter. *Over 100 bug reports and user feature requests have been squashed. *The 1.2.1 release also adds updated English documentation, along with a new easy to navigate help browser. *The Scribus GUI is now translated into 30 languages Downloads: Mirrored: http://sourceforge.net/project/showfiles.php?group_id=125235 http://www.scribus.org.uk/downloads/1.2.1/scribus-1.2.1.tar.bz2 md5sum: 002cb629e817722f4123df7a41fc824b size 6436083 bytes GPG signature for source tarball: http://www.scribus.org.uk/downloads/1.2.1/scribus-1.2.1.tar.sig Template package: http://www.scribus.org.uk/downloads/1.2.1/scribus-temp-all-1.2.1.tar.bz2 md5sum: 19d102ff16c295e29bb7a051c66c2c58 size 1435895 bytes Scribus home page : http://www.scribus.net Document Site: http://docs.scribus.net Features http://bugs.scribus.net Enjoy!

1 0