- Inkscape Devel - Inkscape Mailman

no xmlns crash
by Aaron and Sarah Spike 05 Feb '05

05 Feb '05

I have some files created by hand and some generated by batik that crash on loading. From what I can tell the crash is caused because my files don't have xmlns="http://www.w3.org/2000/svg" in the svg tag. The files cause no trouble with the adobe plugin. Requiring the namespace declaration is great. Inkscape should reject improperly formed files with out crashing right? Aaron Spike

5 5

Re: win32 GTK
by Bob Jamison 05 Feb '05

05 Feb '05

Actually, I was considering something radically different.. If it is possible, it would be good if we could build the entire tree from source ourselves with the cross-compiler (or maybe mingw). Then we could have any configuration we want, and not need to beg & borrow dll's from other people. Does this sound like an idea? Bob Kees Cook wrote: >Hey Bob. I was looking at the GTK packaged for Gimp, Ethereal, and >Gaim, and was thinking about trying to switch to it (after the 0.41 >release). Have you looked at this at all? It looks like it may fix a >number of weird problems we've had. > > >

3 2

Coming Hard Freeze tonight
by Bryce Harrington 04 Feb '05

04 Feb '05

It sounds like we're about ready for going into the final Hard Freeze, so I'd like to propose we do so in 12 hours from now: 11pm PST 2/4. During the Hard Freeze, no changes to CVS should be made without review and approval. Work should be limited to critical bug fixes, packaging, and release-related activity only. I think it was effective to have a pair of reviewer/approvers to keep an eye on the codebase for the hard freeze period in the 0.40 release. Last time, mental and bulia performed this function. For this release, I'd like to ask bulia and kees to perform this function. I know mental has been extremely busy with work, so I suspect he'd like to conserve what Inkscape time he has for finishing up his own work. Kees has been extremely active in bug fixing this release, so I think he'd be an excellent person for this role. (Maybe we can make this a rotating position for future releases.) Bryce

4 8

honoring presserveAspectRatio
by Edward Flick 04 Feb '05

04 Feb '05

Hello everyone, Is the freeze tonight going to mean that there will be no more added features until 1.0? Or just a feature freeze for 4.1? Also, I have just posted a suggestion on the list that the preserveAspectRatio attribute be added/honored. I wouldn't mind doing this myself, although I am new to the project and could use a couple of pointers on where I should make the necessary changes. Would anyone be interested in this? Ed

2 1

Italian translation
by Luca Bruno 04 Feb '05

04 Feb '05

Hi all, here you can find the updated Italian Translation of Inkscape. It is complete and with updated pot (today's CVS). Please upload it in time for 0.41. Ciao, Luc@ [CC'ed Arpad Biro as in previous private emails] -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S. | luca.br(AT)uno.it `. `'` | GPG Key ID: 3BFB9FB3 on keyserver.linux.it `- http://www.debian.org | Proud Debian GNU/Linux User -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Assicurazione auto Zuritel. Fai un preventivo gratuito e scopri il risparmio e molto di pi�! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3175&d=4-2

2 1

Some suggestions for the fill and stroke dialog
by Andreas Nilsson 04 Feb '05

04 Feb '05

Dear Inkscape developers. The current fill and stroke dialog is a big dialog that takes up 1/4 of my screen and has lots dirrerent of stuff in it. I'll try explain some of it's problems trough a short user case. --- Joakim is a graphic designer. He makes a lot of illustrations for different clients and is under a constant time pressure. He is currently working on a project where the AD has decided that they will use flat colors and stokes of varying width. 1. Joakim has the fill and stoke dialog up most of the time. It is space consuming and he has to move it constantly or hide it in order to see his artwork. 2. He has to do a huge amount of clicks because he moves between fill style and fill color all the time. 3. He is working in RBG color space, but has the ability to choose CMYK, even if the document is not in that color space. This confuses him. 4. He do not use dash pattern at all for this project. This only takes up space for him. 5. The markers are hard to overview (this is not really important for Joakim right now, but it might be in his next project). --- I have thought about these problems for a while and come up with a quick mockup with some ideas. http://ramnet.se/~nisse/diverse/temp/new_dialogs_mockup.png What I have done in this mockup is: - Splitted up the current dialog into smaller dialogs for better customization to suit an artists current workflow. - The font size is set to small to make the dialogs a bit narrower. - All dialogs are equally wide to make them easy to line up. - If the document is in the cmyk color space, it only shows the cmyk color settings. - I guessed most people uses the stroke width more than the other settings in this dialog and put the more rarely used options in an expander. - The markers are in their own dialog as well, and structured in a way that makes them easier to overlook. Names could be displayed when the mouse hoover over a marker. BTW. I know this looks a lot like Adobe Illustrator. And yes, I am very accustomed to the interface of that program, and am a bit inspired by it. But hopefully this can spur some discussion on how to better handle the color and stroke dialog/dialogs - Andreas Nilsson

10 11

[Fwd: Re: [office] [Fwd: clarification: OpenDocument and SVG]]
by Jon Phillips 04 Feb '05

04 Feb '05

Check it out! Progress on getting on w3.org's svg pages... Jon -------- Original Message -------- Subject: Re: [office] [Fwd: clarification: OpenDocument and SVG] Date: Fri, 4 Feb 2005 08:39:35 -0800 From: Chris Lilley <chris@...157...> Reply-To: Chris Lilley <chris@...157...> Organization: W3C To: Jon Phillips <jon@...235...> References: <4200ABF1.3010700@...677...> <4200C4A8.1030306@...678...> <4207e7a9.832074890@...689...> <1107368323.42011983e384f@...660...> <420139A2.3010603@...235...> <4201F976.8060306@...678...> <6610279990.20050203052414@...157...> <42033698.2050504@...235...> On Friday, February 4, 2005, 12:47:20 AM, Jon wrote: JP> Chris Lilley wrote: >> On Thursday, February 3, 2005, 2:14:14 AM, Michael wrote: >> >> MB> I believe that we will be able to resolve this issue in a way that is >> MB> beneficial to both the OpenDocument and SVG specs and agree that we >> MB> should keep the communication channels open. Who in the SVG group could >> MB> be the primary contact for the OpenDocument TC? Is it you? >> >> Jon Phillips is not a member of the SVG WG. I am the chair of that WG, >> so the contact can be through me. The issue is going to be discussed at >> todays telcon (in 40 minutes time ...) but its possible that we will need >> more time, and more communication between the two groups, to resolve >> this successfully. I gather there is a hard deadline of this Friday for >> comments? >> >> >> MB> I'd also like to thank Mental for bringing this topic to the attention >> MB> of our two working groups. >> >> Yes, a very timely alert - thanks! >> JP> Chris, could Inkscape (www.inkscape.org) and Open Clip Art Library JP> (www.openclipart.org) please get mentioned on the SVG portion of the W3C site. JP> We have been begging you guys for this off and on for a while. Please can we get JP> on some of your guys' pages as an SVG-based tool and a repository for SVG, JP> respectively. The implementation database is supposed to be run by an external SVG organization, as of a year ago. However, they do not seem to have done anything yet. This is irritating for implementors (and for myself, as people keep asking me to add stuff and i can't). I am meeting with those guys in 10 days time and will asked them about progress on this. if they haven't done it by then, i will get the database hosted somewhere else (like svg.org) which is where we syndicate our SVG news from. The idea (was) that implementors could update their own entries as they released new versions, so it would always be up to date but viewable from a central location. -- Chris Lilley mailto:chris@...157... Chair, W3C SVG Working Group Member, W3C Technical Architecture Group -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

2 1

Article about Cairo
by Bob Jamison 04 Feb '05

04 Feb '05

Here is another item of interest: http://www.osnews.com/story.php?news_id=9609 Bob

1 0

input "preedit" handling disabled
by Kees Cook 04 Feb '05

04 Feb '05

While investigating bug 1086769, I discovered that inkscape's on-canvas text editing does not handle (some?) multi-byte character entry. Here's what I did... I installed "scim-chinese" and "scim-gtk2-immodule" which gives me an "SCIM" input module (right-click on text-entry widget to select SCIM). Then, you can hit ctrl-space to switch to chinese-char-entry mode, which lets you type a letter (say, "a") and then select (with numbers) which character you want. In the text widgets, this works great. On the canvas, inkscape would do VERY weird things: it would add the "preedit" character to the _end_ of the string instead of at the cursor position, and then when the final char was selected, it would overwrite the char AT the cursor position. Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it. This just means that the "predit" char isn't visible until you're done typing it in. What's weird is that other Input Modules (like, say "IPA") will show their preedit letters and inkscape seems to handle it correctly (type "a" "e" with the IPA IM, to see a merged "ae" character). Even with preedit disabled, this works on the canvas. So... I'm not sure why preediting is there at all, and I've disabled it. Can anyone find any reduced functionality as a result of this? Currently this _fixes_ chinese input (at least with SCIM), so I'd like to leave it like this until I can better understand the IM system. -- Kees Cook @outflux.net

3 3

Re: [Inkscape-devel] Some suggestions for the fill and stroke dialog
by bulia byak 04 Feb '05

04 Feb '05

On Fri, 04 Feb 2005 12:11:06 +0100, David Christian Berg <david@...407...> wrote: > > - a current color indicator (like the one in the "color selector" in > > your mockup), except that it must not be in any dialog, but at the > > bottom of the main toolbar, on on the left of the horizontal palette > > Hmm, from Adobe I'm used to having it under the main toolbar, an it's > make sense to be there, but with the current layout it would be too > small. It doesn't need to be that big. Just a square with a border. Our main toolbar is wide enough for it I think. > So maybe I'd just put two buttons in front of the color-selection > bar/palette at the bottom.I think that would make a lot of sense. Possible, too. > > With these, 90% of reasons to open fill&stroke will be eliminated, and > > its size won't matter much anymore. > > Well, you'll still have to have a dialog to change the colors (opening > via double click) If our default palette has some common colors, changing them will be unfrequent. > and you'll have to have a dialog for stroke stuff. Also unfrequent with the exception of stroke width. > Concerning the CMYK vs RGB argument, Andreas gave: I think it should be > a drop down, because you've gotta be able to define RGB colors, even > when you're in a CMYK document, but the standard of the drop down has to > be set by document prefs. I don't care "what kind of document is this". Inkscape is a design tool, not prepress tool. I want the color mode which is the most convenient for me to THINK IN, and most often this is either HSV or wheel. If after I create my design I need to convert it to CMYK for some reason, I can use other tools for that. The CMYKness of a document must not affect my design process. The fact that in Adobe products it DOES affect it, is one of the main problems I have with those products. > > With palette, you click to change fill, shift+click to change stroke > > (same as the dropper tool now). Again, using fill&stroke for this will > > be much less frequent, so there's no need to break it up. > > (There also should always be one empty color field to add new colors Not empty, but a "duplicate color" command in the right-click menu of the swatches. > and > you'll have to be able to drag colors within the pallete. Yes > Furthermore: > have a Inkscape setting to have _no_ colors in the palette at startup. > That's the way I'm working, predefined colors (other than black and > white) are unnecessary for me and hinder the workflow, while other > people might want to have them.) Yes, though new users should see a complete enough palette by default > Point is that maybe this should be a document setting, Right now it is more of an Inkscape setting, because the color selector remembers the tab you used last. And I like it this way. It's not like length units which indeed may be different per document; colors are just colors everywhere. > Hmm, disagreed. Put the other stroke stuff into an expander like in the > mock-up, so that you can hide and show it easily, when you need it. In > general I don't like the idea being able to do the same thing at > multiple places. Exactly, this is what we need - one "quick" way to do something and one "complete" way to do the same. Like the quick layer selector and the layer dialog. I see absolutely no problem with this. Changing stroke width is such a common operation that it MUST be in the window interface somewhere. > I'm not yet sure, how the selector in the mock-up is supposed to work. > Wouldn't it make sense if it had tabs at the top for switching between > start, join and end markers? Yeah, probably, details need to be worked out, what I like however is the two-dimensional table instead of drop-down menu. > Or maybe you should just have a Markers > dialogue without any lines shown in the preview and you drag them and > drop them into the stroke-style dialogue as start, join or end > marker.... I think that would make a lot of sense, because that way you > can easily use any marker anywhere. As opposed to what? Can't you now use them anywhere? > > SVGs version 1.1 documents cannot use CMYK at all, so this is > > irrelevant. The CMYK selector is just a convenience. And then, even if > > I have a CMYK document of some kind, why on earth can't I use HSV or > > RGB to find a color I want, and have it converted to CMYK by the > > program? > > It's true, but for some reason graphic programs usually distinguish a > little stronger between the color spaces. I really hate that. I think the reason is that most of those programs are just old, and were initially paper-oriented, and thus keep sticking to their old superstitions even though they are mostly irrelevant today. > > Separating markers does make sense, though maybe not into a dialog but > > into a new tab in fill&stroke. > > hmm, that make me think of something. why not put everything in separate > tabs? Like [stroke weight], [caps and joins] (including miter limit -- > miter limit needs a spinbox!), [pattern] (this might as well get more > options like in Corel, where you can define your own pattern styles) and > [markers]. Possible too, but only if we use icons only, not words, for tab headers, otherwise they won't fit. > Hmmpff, the quick layer selection?? Maybe it's a good idea, once there > is another layer/objects dialogue, but as is right now, I haven't yet > managed to make layers part of my workflow. I only notice them, when for > some strange reason I can't move one object behind another. I use layers all the time and I really cannot imagine how I lived without them. Yes, there are some operations that are difficult and clumsy with the quick layer selector, but for many simple common operations it is very convenient and natural, indeed more natural than the layer dialogs in other apps.

2 2