- Inkscape Devel - Inkscape Mailman

clone breakage
by MenTaLguY 23 Jan '05

23 Jan '05

Argh. Clones appear broken in latest CVS. For the moment, I'm assuming it was me, as I did a relatively large repr-related commit recently. I'm a bit puzzled though; the work I did was almost entirely reorganizing code around rather than changing algorithms, and clones were one thing I tested with the new code. Maybe I was lucky and hit a particular corner case that still worked... I'll experiment more. FWIW, so far as I can tell everything still functions correctly up through sp_use_build, at least. I'll continue to narrow things down, but if anyone has any ideas that would help. Also, the one set of algorithms I _did_ change were the implementation sp_repr_position/sp_repr_set_position (the guts are now in xml/simple-node.cpp). If someone could review my changes to make sure I didn't do anything stupid there, that'd be much appreciated. -mental

1 2

Italian translation
by Dariusz Stojek 23 Jan '05

23 Jan '05

In atachement italian translation in it.po I will finish it (translations) soon, because I'm using Inkscape for vector graphic design in our school, and the language people understand is only italian :-) darek

3 2

Re: [Inkscape-user] converting svg to eps via commandline
by Ted Gould 23 Jan '05

23 Jan '05

On Sun, 2005-01-23 at 19:01 +0100, Steffen Glückselig wrote: > I'd like to convert a bunch of my svgs to eps-format automatically via the > commandline. I noticed that there is no option like the one for exporting > png but I found > > ------ > -p PRINTER, --print=PRINTER > > Print document(s) to the specified printer using `lpr -P PRINTER'. > Alternatively, use `| COMMAND' to specify a different command to pipe to, > or use `> FILENAME' to write the PostScript output to a file instead of > printing. Remember to do appropriate quoting for your shell, e.g. > > inkscape --print='| ps2pdf - mydoc.pdf' mydoc.svg > ------ > > in the man-page which seems to come close. What do I have to do to get eps > on a windows-system? Well, internally the difference between printing or saving postscript and saving as EPS is a matter of how the bounding box is placed. It is something that could be done by hand somewhat easily. It would be a really cool feature if someone implemented a command line option to the Extensions system to allow for batch conversion between any supported formats. It would be an easier enhancement for someone who wanted to get familiar with the codebase. There wouldn't be any GUI programming, or using lots of the codebase that would be required. I would be happy to help anyone that wanted to do this, it is an oft requested feature. --Ted

1 0

Re: [Inkscape-devel] Re: Jimmac evaluates Inkscape, +1 Insightful.
by Ashwin Bharambe 23 Jan '05

23 Jan '05

> Actually the main problem is that icons have to be redrawn for small > sizes. It doesn't matter when or with what you do the scaling, SVGs > generally just don't scale well to 16x16 type sizes. Jimmac seems these > days to draw icons by hand in the Gimp for small sizes, and then provide > an SVG as well for larger sizes. Precisely. Loading times should be a non-issue, completely. (I will be surprised if profiling shows icon loading as even a significant portion of the startup time.) The fact is vectors loose crispness at smaller scales. Ashwin

1 0

Ruler units revisited
by Aaron Spike 23 Jan '05

23 Jan '05

In reference to: http://sourceforge.net/mailarchive/forum.php?thread_id=6260553&forum_id=360… With the latest autopackage working on my machine again, I finally had a chance to play with the new units code. Thank you all it is super. And now I think I have nailed down what my trouble was all along. Would someone please try the following and confirm that I am not crazy. create a new document change document preferences default units to inches (notice ruler units change) save document and close inkscape. open inkscape open recent the document look at rulers (not inches) open recent the document look at rulers (now inches again) Thanks, Aaron Spike

3 2

XForms for extensions and UI
by Jon A. Cruz 23 Jan '05

23 Jan '05

I've been kickout out the possiblity of implementing some basic XForms or XForms-ish implementation for our UI, including for the extension & scripting support. Among other things, I think it would shift things around and get them more useable than just putting in .glade file and libglade parsing. It's a bit similar to XUL, but with a focus that I think is more appropriate for our needs. Anyway, I came across this article that gives a quick overview of some things, and how it might benefit us. I think it would be good if everyone could at least skim it. ---------------------------------------- The Secret Life of XForms http://www.devx.com/xml/Article/17714/0/page/1 "XForms recently reached the W3C's Candidate Recommendation status—and you need to know about it—because XForms isn't a form description language, it's a language for describing applications in a platform-independent way. Best of all, it integrates easily with technologies you already know, such as XHTML, XPath, SVG, and CSS. " ---------------------------------------- Read it through, and then think of how this could be taking our 'verbs' approach a step further, and also give extensions and scripts a nice way to get and use UI without having to resort to the evils of Gtk::Socket and such.

1 0

Roadmap updated
by Bryce Harrington 23 Jan '05

23 Jan '05

With Scislac's help, the Roadmap's been updated: http://inkscape.org/cgi-bin/wiki.pl?Roadmap Basically, we've just moved all the milestones forward one release, so that 0.41 can be released fairly soon (it'll be mostly just bug fixing). I've also outlined more of the work in the Gtkmm section for 0.42. Please everyone take a moment to look through the roadmap and check that the things you plan to work on in 2005 are listed in there, and add them (with your name), if not. Also, PLEASE consider volunteering for some of the Gtkmm tasks by listing your name next to some tasks. Remember that the current gtkmm code is going to be integrated into the main codebase as soon as 0.41 hits the shelves, and there's a lot to do so the more help, the sooner we'll get through it. Gtkmm is not hard to learn if you know C++. I estimate at least two more weeks before we're ready to freeze for 0.41, so expect the Gtkmm work to become the project's focus by the end of Feb. I suspect it may take 2-4 months of work to complete, although given a lot of participation we could probably cut that in half. Bryce

1 0

new screenshot
by bulia byak 22 Jan '05

22 Jan '05

See a new and beautiful screenshot at the top of http://inkscape.org/screenshots/index.php Send us your new and beautiful screenshots, too! :)

1 0

Transparency support for postscript output
by Ashwin Bharambe 22 Jan '05

22 Jan '05

Hi all, I am assuming that postscript not having transparency natively would be the reason for inkscape not supporting transparency in EPS or postscript outputs. What would be required to implement support for this? Ashwin

9 14

Re: [Inkscape-devel] button sizes?
by Andreas Nilsson 22 Jan '05

22 Jan '05

David Christian Berg wrote: >Alors: >When I designed my icon theme, I noticed exactly the same problem as >Andreas did. Designing icons to use the space of 16*16 in the menu will >be clipped in the tool-option-bar. >I don't agree that this means, that the buttons have to become larger. A >svg will look rather crisp at any size and gnome is going svg, for sure. >It just means, that the rendering of the icons is kinda screwed. >The size on canvas should not matter at all! That's what svg is for. >Find the object you want to draw, take it's width or height, whatever is >bigger, and scale it proportionally to fit either the 16px of the Menu >or the I think 20 px of the tool-option bar. That's how it should work. >Right now I have to design a 24pt*24pt icon to fit the menubar. Since it >actually is 16px*16px one might think that maybe scaling up a 16pt*16pt >object would give very crisp results, but it doesn't. At the same time, >the node-editing icons created in 20pt*20pt allow you to draw single >pixels, which are 1pt*1pt. >So as I said, all this is kinda screwed, but it doesn't count as a >reason for increasing the button size. > >David > > So youre saying that there might be another reason for the clipping? The clipping is my main concern, and I thought that the size was the problem. If that is not, I apoligy for my request to make the buttons larger, especally if people find it a problem with normal-sized icons. - Andreas

7 8