- Inkscape Devel - Inkscape Mailman

ill2svg.xslt
by Bryce Harrington 23 Apr '05

23 Apr '05

----- Forwarded message from Holger Will <holger@...792...> ----- Date: Tue, 19 Apr 2005 21:45:34 +0200 From: Holger Will <holger@...792...> To: clipart-list <clipart@...626...> Subject: Re: [Clipart] Image portability Christopher Schmidt wrote: >On Tue, Apr 19, 2005 at 09:09:51PM +0300, Nicu Buculei wrote: > > >>Linda Kim wrote: >>however, the file size is still a problem, i think 0.5MB is huge for an >>image like >>http://openclipart.org/clipart//food/desserts/ice_cream_cone_linda_kim_01.s… >>(i would expect something 10-20 times smaller) >> >> > >A completely reasonable expectation: after doing just a simple removal >of a lot of data that was encoded in CDATA elements, the image size is >reduced by a factor of 20, which results in the SVG available at >http://crschmidt.net/tmp/icecream.svg . > >(This URL is not permanent: it may dissapear at some point in the >future.) > >This image is only 21kb, as opposed to 450. > >Key to creating decent SVG from Adobe is to just check the content by >hand: it's really easy to pull out a lot of stuff most of the time, in >my experience. > > ive just written a simple xslt stylesheet to do the job, you can find it here: http://www.treebuilder.de/svg/ill2svg.xslt hope you find it usefull Holger _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart ----- End forwarded message -----

4 4

Re: [Inkscape-devel] Effects Tarball
by aaron＠...749... 23 Apr '05

23 Apr '05

bulia byak wrote: > On 4/17/05, bulia byak <buliabyak@...400...> wrote: >>On 4/17/05, aaron@...749... <aaron@...749...> wrote: >>>http://www.ekips.org/comp/inkscape/inx/InkexEffects.png >> >>That's quite impressive. Do these extensions have GUIs of their own? >>If so can you include one of them into the screenshot as well? > > Oh, and by the way, shouldn't we put these extensions into CVS so that > they are available to all? Can you send me an archive of all the > files? Or do you want to do this when you are finished with them? Thanks. These effects all use Ted's autogui functionality. Autogui isn't fully functional yet, so I don't know if it should be put in a screenshot. If you want to put these effects into CVS it is fine by me. I will continue tweaking these and adding more effects as ideas come to me. As long as CVS gets a fresh copy occasionlly, I think it would be great. Here is a direct link to the archive on my website. http://www.ekips.org/comp/inkscape/inx/inkex_latest.tar.gz There are, however, probably a few reasons to hold off. I haven't figured out how to write an inx file that works on Windows and Linux. So as they are the effects only work on Linux. I'm not sure exactly what is required for the scripts to run, at least Python and PyXML. If extensions are by definition optional, you might not want to include them directly. Aaron Spike

9 21

Re: [s4-p18] Re: Mail à destination des développeurs d'Inkscape
by Nicolas Aupetit 23 Apr '05

23 Apr '05

Greetings to all the Inkscape development community ! We are a team of 7 students from a Grande Ecole of engineering in France (Ecole Nationale Supérieure des Télécommunications de Bretagne). As part of a school project, we are to develop a software which converts SVG files to PostScript. After looking for and testing different solutions, we figured out that Inkscape was our favorite to do this job. Nevertheless, Inkscape does not come up to all our expectations. Therefore, we would like to do some improvements which could benefit the whole community of Inkscape users. First of all, we wish to improve the management of fonts in the conversion process. In addition, we intend to add backup for transparency and superimposing in the export to PS (likely the way of Adobe Illustrator). Eventually, if not short of time then, we could focus on enhancing the Inkscape command-line interface (in the idea of processing many files in a row (batch process)). Now, here we go : if anyone around has already worked on these issues, and is ready to communicate with us, so that we might start on a firm and good foundation, we are more ready than ever to listen to everything you've got : information, advice, tips, whatever. You can contact us on the email address : s4-p18@...796... Best regards, -- Nicolas Aupetit, for the svg2ps team from the ENST Bretagne

2 2

[Warning: OT] library to create svg files
by Joakim Hove 22 Apr '05

22 Apr '05

Dear inkscape developers, I have an application, which produce some figures. I have considered using svg (partly to learn), but instead of actually coding the necessary svg strings directly in the source of my application, I would like to employ a somewhat higher level library. I.e. instead of fprintf(svg_stream , "<path id=\"%s\" fill=\"%s\" ....>\n",id,fill_type); I would like to do (using a hypothetical svg library): svg_path(svg_object , id , fill_type); Now, my question is whether Inkscape has (i.e. is built on) a library which somehow provides this functionality; or if you have another library to recommend which would provide this kind of functionality. As you can see from the code snippets above my language of choice(?) is C, so it must be something which can be linked from C. Best Regards Joakim Hove -- Joakim Hove hove AT ift uib no / Tlf: +47 (55 5)8 27 90 / Stabburveien 18 Fax: +47 (55 5)8 94 40 / N-5231 Paradis http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04

3 2

Re: [Inkscape-devel] Extensions Package
by Ted Gould 22 Apr '05

22 Apr '05

Okay, from both Bryce's and Bulia's e-mail I don't think that I was entirely clear. I was only thinking about extensions that are distributed from inkscpae.org, I could definitely see others providing extension packages or collections of their own. (I expect KPT to start shipping Inkscape extensions any time now) I understand Bulia's argument of this being a little too early, I think that if we take that approach we should definitely decided when is mature enough. Release 0.43? When there are 100 extensions? Though, I could definitely see waiting until we have more. So, I guess that's the approach that I'm going to suggest, put everything we have in the Inkscape package today, and we'll split them out at a prespecified time. --Ted On Wed, 2005-04-20 at 14:59 -0300, bulia byak wrote: > (Note that gmail is currently spamblocked by sf lists, so this message > likely won't make it to the list, but Ted and Bryce will see it) > > On 4/20/05, Ted Gould <ted@...11...> wrote: > > We've talked about before, and Aaron and I have recently talked about > > it, should we package extensions? I'd like put some ideas and questions > > forward so that people can rip them apart and we'll end up with > > something good :) > > I'm strongly of the opinion that we must include the extensions we > have so far into Inkscape. Maybe later when there are too many of > them, or when there are some complex or large ones, we may consider > breaking them out. Right now they are just starting to appear, so > including them with the program itself is the only way we can let them > survive. Separating them would pretty much kill them, as few people > will bother downloading them separately. > > > -- Dependencies. The dependency checking in Inkscape will always be a > > toy when compared to dpkg and rpm. And, we don't want to require every > > package in Debian just to install Inkscape. > > This is all irrelevant on Windows which has no dependency checking at > all. It's already difficult to make them work on Windows, by > separating them we'll pretty much make this impossible for an average > user. > > > -- Versioning. It might be more reasonable to have effects on a > > different release schedule if there were a larger collection of authors. > > Something more like OpenClipart's monthly release. > > Few people care about versioning. Most just use whatever version came > with the program. If nothing came with it, well, they will use > nothing. If they DO care, they can always download the freshest > version of the extension they are interested in. > > > -- Modularity. If we ever expect for people to be able to ship > > extensions for Inkscape from outside the project umbrella the tools to > > do so need to be good, and packing some of our own extensions externally > > would force use to make them reasonable. > > It's possible to make these tools good without this. And, as I said, > _right now_ extensions are just too weak and immature to let them go > on their own. > > > -- Simple. Releases are a pain, more releases need to be justified. > > A very important reason - simplicity _for the user_ is a priority. > > > -- Complete Solution. Have you ever seen a public forum where someone > > posts a new program, and then 90% of the questions are "What theme did > > you use in the screenshots?" Multiple places to get extensions means > > that everyone won't have the same set. > > Yes. > > Another reason to package extensions is the Effects menu. If there are > no extensions in the default package, it will either be empty or will > have to be disabled. Both options are bad. > > So as a very minimum, I think we must ship everything we have in the > Windows package (also with Python). But I think the same reasoning > applies to all platforms. >

2 1

Re: [Inkscape-devel] LaTeX Export
by Jose Hevia 22 Apr '05

22 Apr '05

For me,this 'd be essential,given the BAD memory management in kpdf, xpdf, gpdf,I'm looking for something that lets me put simple figures, rectangles, arrows and text ,from latex to generate decent documents, and I want to use Inkscape for that. > Wow, this'll be a handy extension - how are things going with it? > > Bryce > > On Wed, Apr 20, 2005 at 07:54:00AM -0400, Michael Forbes wrote: > > The init.cpp issue was the problem and now it works (not fully, but at > > least I can "Save as"). > > > > -Michael Forbes > > > > On Tue, 19 Apr 2005, Ted Gould wrote: > > > > >On Tue, 2005-04-19 at 20:38 -0400, Michael Forbes wrote: > > >>I am trying to develop a barebones LaTeX export extension. I have wrote > > >>the > > >>code mostly based of the PovRay export and included the .h and cpp file > > >>in > > >>src/extension/internal/Makefile_insert. libinternal.a includes the > > >>extension > > >>but the main program does not. Can anyone help me with this? > > > > > >I guess, what do you mean by the main program not including it? For the > > >internal extensions their init function must be called in init.cpp -- > > >could you not have put that call in? Are you saying that the code isn't > > >getting linked in? > > > > > > --Ted > > > > > >PS - LaTeX export would be pretty cool, neat feature. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Refactoring in action
by Jon A. Cruz 22 Apr '05

22 Apr '05

Just thought I'd toss out this note "Refactoring in action" or "How I implemented an RFE in under an hour" This morning I changed things so that the CMYK color slider mode now has values that range form 0 through 100 instead of 0 through 255. In and of itself that was no big deal, and the ammount of code change needed was minimal. What is interesting, however, are the principles that came into play in doing it. ------------------------ I addressed RFE 994177 "CMYK 0 - 100 not 0 - 255". The first thing was to see if it was needed. Having worked with various media places and artist before, this was a simple one to see the utility of. Not earth-shattering or anything, but something that would make artist and designers working in print a little more comfortable. So, yes, it should be done at some point. Next question was how much effort would it take. Since I'm in the middle of addressing color issues in general, a lot was fresh in my mind. Then looking into the code I saw it was in very good shape, and prime for reuse. So the level of effort needed should be low. Now came the fun part. As I went into the code, it was pretty clean and easy to understand. More importantly, it already was setup to mainly separate the UI presentation from the underlying data model itself. In this case, the sliders would need to change depending on the 'mode'. But... the slider widgets were not played with directly, but instead were attached to instances of GtkAdjustment. It turns out that GtkAdjustment is pretty much a 'model' class to represent ranging data in an abstract way. So... my next step was to look at what needed changing. I first was going to set things up to change the sliders manually when the mode was switched. However, as I moved forward I realized that things were almost clean, and only needed to get set. I just added a 'range limit' member to track which limit the range was using. Now the really good news was that the functionality I needed to hack on was already moved out to a pair of common functions (get1 and set255). And instead of needing to change those to take a parameter, I just needed to make the code respect the limit already a member of the 'model' class being used (GtkAdjustment). I no longer needed to keep a parameter, and so didn't need ot pass it in or have different functions to do different values. I did rename those two, just to make things a little clearer on their use. But that was just a minor tweak to make things easier to read down the road. I did a little find/grep magic to check where things were used and clean them up, but I was done fairly early. Building and testing took up more of the time. Here is a quick summary of the files I changed: src/widgets/sp-color-scales.h 1.8 src/widgets/sp-color-scales.cpp 1.13 src/widgets/sp-color-slider.cpp 1.10 src/widgets/sp-color-wheel-selector.cpp 1.9 sp-color-scales.h: * renamed get1() to getScaled() * renamed set255() to setScaled() * added _rangeLimit (this actually can go away now) sp-color-scales.cpp: * set default range limit * use rangelimit in constructing adjustments * changed get1() and set255() to meet the GtkAdjustment limit instead of hardcoded values * set the range limit when switching modes sp-color-slider.cpp: * only the get1/set255 function renaming sp-color-wheel-selector.cpp: * changed _adjustmentChanged to meet the GtkAdjustment limit instead of a hardcoded value. ======================= Summary: Things went very fast because of a few things: * The code was fairly clean and easy to understand to begin with. * Common functionality was pulled out and centralized into common functions instead of being repeated in-line. (fix it in one place, and it was fixed everywhere) * There was a nice separation of UI and data model. Functional logic dealt with the data model, while the UI was just a slave to it. (in this case there was the RGBA color value and the GtkAdjustment models in play) Those combined to make it quite easy to change the UI without negatively impacting the functionality of Inkscape itself. The more we can allow for this type of refactoring, the better Inkscape can be. So I'd like to encourage everyone to try to keep principles like this in mind. Oh, and a big thanks also goes out to all the developers who were in that code before me.

3 2

Effects Tarball
by unknown＠example.com 22 Apr '05

22 Apr '05

I created a few more effects today. A path randomizer that randomly nudges path nodes and control points within a specified radius. A path segment straightener that straightens bezier path segments in two different ways. And a random tree generator. The tree generator uses a really simple little Turtle class that draws with SVG path data instead of pixels. Very basic but I think it should be enough to make an Inkscape effect out of just about any of those fun little fractal routines done in LOGO. A tarball of effects is available to try out: http://www.ekips.org/comp/inkscape/extending.php Aaron Spike

4 5

Aaron's effects screenshot
by Ted Gould 22 Apr '05

22 Apr '05

Hey all, Aaron made a screenshot of his effects, everyone should take a look. Very cool stuff! http://www.ekips.org/comp/inkscape/inx/InkexEffects.png --Ted

5 7

Re: [Inkscape-devel] screwy export
by bulia byak 21 Apr '05

21 Apr '05

On 4/21/05, John Taber <jtaber@...480...> wrote: > On Thursday 21 April 2005 07:17, bulia byak wrote: > > If by adjusting you mean scaling, just scale with Ctrl, or click the > > lock toggle in the selector controls. > okay but where is this lock or selector controls? I can't find it anywhere - > not under doc prefs, selecting. I think it should be under object properties > - that's the first place we looked for it. No. It's not a property of an object. It's a property of the tool which you use for scaling. Therefore, it's in the tool controls bar. It's the horizontal bar just above canvas. Use the button with the lock icon. > > > 2) clipping out what you want and pasting it into a new drawing - > > > then exporting it. > > There's no need to do this unless you want to hide all other objects > > except those you are exporting. Just select something and export > > consider that we use svg maps - a river runs the length of the drawing but we > are only clipping out an area that contains part of the river - that means > clipping the river object (assuming it's something like a bezier line) So do you want to hide all other objects when exporting the river or not? If not, just select the river and do export. If yes, you can do this from command line with the --export-id-only option (see man inkscape). > Okay, I understand what you are saying about the canvas and that we only need > to worry about the actual svg elements, but we want to take the above clipped > section, draw some stuff on it, resize, and export to a bitmap to put in a > report, where one bitmap export might be the whole clipped area, one might be > a zoomed in detail look. Does this make more sense of what the problem is ? I don't see what the problem is. Select an object and export it, this will clip your drawing by this object. If you want to export a detail, draw a transparent rect over it and export that rect. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Available export formats
by Lucas Vieites 21 Apr '05

21 Apr '05

Hi, I'm in need of knowing the available export or interchange formats for Inkscape. I normally use Inkscape to create graphics for the web, but now I created a design for a publicity flyer and the printer (the guys who are going to print the flyers) only work with CorelDraw 10. How can I export the svg to a format Corel understands. I've been googling a bit and I know newer versions of Corel import svg directly (at least version 12) but I'm stuck on this one. Can anybody help me? Thanks a lot in advance, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

2 2

screwy export
by Jon Phillips 21 Apr '05

21 Apr '05

When I use export, it seems screwy with the DPI. I expect that if I change the DPI to 72, and then change the size of the exported image, the DPI should stay the same. It is really wacky and unlike other graphics apps for the DPI to change when I change the image size, and vice-versa. Actually, most apps, like gimp, etc have locks to constrain dpi and proportions (see attached screenshot). Anyhow, export use to work well for me to do exporting for web, but now is strange. Is this a problem for anyone else? Yes, I understand the logic that the size changes because there are then more pixels per inch, but I don't agree in how it acts. Once someone sets dpi in this, then the exported image should stay the same size and just have a higher DPI, but same size. Thoughts on this? Am I wrong here? Am I smoking something? Whats the deal?? Jon -- 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)

3 7

Extensions Package
by Ted Gould 20 Apr '05

20 Apr '05

We've talked about before, and Aaron and I have recently talked about it, should we package extensions? I'd like put some ideas and questions forward so that people can rip them apart and we'll end up with something good :) The basic idea is that we may want to start shipping extensions packages somehow separately from the core Inkscape package. There are several reasons for this: -- Dependencies. The dependency checking in Inkscape will always be a toy when compared to dpkg and rpm. And, we don't want to require every package in Debian just to install Inkscape. -- Versioning. It might be more reasonable to have effects on a different release schedule if there were a larger collection of authors. Something more like OpenClipart's monthly release. -- Modularity. If we ever expect for people to be able to ship extensions for Inkscape from outside the project umbrella the tools to do so need to be good, and packing some of our own extensions externally would force use to make them reasonable. Reasons to just throw everything into the Inkscape tarball and live with it: -- Simple. Releases are a pain, more releases need to be justified. -- Complete Solution. Have you ever seen a public forum where someone posts a new program, and then 90% of the questions are "What theme did you use in the screenshots?" Multiple places to get extensions means that everyone won't have the same set. I think, that there is compelling reasons to start a new package for extensions, which brings the next points: how should it work? -- Granularity. Should each extension be it's own package? Should they be grouped by functionality (input/output/effect)? Should they be grouped by common dependencies (inkscape-extensions-{python,perl,pstoedit}) -- Versioning. I'm kinda thinking that we should just do <inkscape major>.<inkscape minor>.<extension release> That way extensions could be released independent of Inkscape, but still, you know what version of Inkscape they are tied to. Okay, I think that was verbose enough for now, if you made it this far I'm impressed. --Ted

2 1

Supporting <style> elements
by Bob Jamison 20 Apr '05

20 Apr '05

Hi, all, Last night, user <giordano> came onto the channel and showed an SVG file exported from Visio, which did not render properly on Inkscape. Turns out that the file has a separation of style specification into <style> and class="" references like this: <style type="text/css"> <![CDATA[ .st1 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.72} .st2 {fill:#ffffff;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.72} ...etc.... and later referenced like: <rect v:rectContext="foreign" x="0" y="892.83" width="2327.33" height="807.957" class="st1"/> I know that this is exactly the missing CSS functionality that we have on the roadmap, but is it really that hard to implement? I made a quickie Java class that loads up the css definitions into a HashMap, and later when the class="" tags use the refs, replaces the class="" with style="". So that line would look like this now: <rect v:rectContext="foreign" x="0" y="892.83" width="2327.33" height="807.957" style="fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.72"/> Could we not, in the interim before we integrate full libcroco functionality, parse the <style type="text/css"> element into a std::map<std::string, std::string> and do the same substitution at load-time? I attached the Java source to show how simple this method would be. Bob import java.io.File; import java.util.StringTokenizer; import java.util.HashMap; import java.util.Iterator; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import javax.xml.transform.Result; import javax.xml.transform.Source; import javax.xml.transform.Transformer; import javax.xml.transform.TransformerFactory; import javax.xml.transform.TransformerConfigurationException; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.Node; import org.w3c.dom.NodeList; import org.xml.sax.SAXException; class VisioFilter { HashMap<String, String> styles; void error(String msg) { System.out.println("VisioFilter:" + msg); } String getElementText(Element elem) { StringBuffer buf = new StringBuffer(); NodeList nl = elem.getChildNodes(); for (int i=0 ; i<nl.getLength() ; i++) { Node n = nl.item(i); int type = n.getNodeType(); if (type == Node.TEXT_NODE || type == Node.CDATA_SECTION_NODE) { buf.append(n.getNodeValue()); } } return buf.toString(); } boolean processStyleElement(String str) { StringTokenizer bigSt = new StringTokenizer(str, "\n\r"); while (bigSt.hasMoreTokens()) { String line = bigSt.nextToken(); //System.out.println("line:"+line); StringTokenizer st = new StringTokenizer(line, "{}"); if (!st.hasMoreTokens()) continue; String name = st.nextToken(); name = name.trim(); if (!name.startsWith(".")) continue; name=name.substring(1); if (!st.hasMoreTokens()) continue; String style = st.nextToken(); styles.put(name, style); } /* for (Iterator<String> iter = styles.keySet().iterator() ; iter.hasNext() ; ) { String key = iter.next(); System.out.println("name:'"+key + "' style:'"+styles.get(key)+"'"); } */ return true; } void substituteClassAttribute(Element elem) { String className = elem.getAttribute("class"); if (className!=null && className.length()>0) { //System.out.println("found class:"+className); String style = styles.get(className); if (style!=null) { elem.removeAttribute("class"); elem.setAttribute("style", style); //System.out.println("replaced with:"+style); } } NodeList nl = elem.getChildNodes(); for (int i=0 ; i< nl.getLength() ; i++) { Node n = nl.item(i); if (n.getNodeType() != Node.ELEMENT_NODE) continue; Element childElem = (Element)n; substituteClassAttribute(childElem); } } public boolean processFile(String inFile, String outFile) { System.out.println("############### PARSING"); DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = null; try { db = dbf.newDocumentBuilder(); } catch (ParserConfigurationException pce) { error("processFile:" + pce); return false; } File inf = new File(inFile); Document doc = null; try { doc = db.parse(inf); } catch (Exception se)//saxexception + ioexception { error("processFile:" + se); return false; } NodeList nl = doc.getElementsByTagName("style"); if (nl.getLength() < 1) { error("no style elements"); return false; } for (int i=0 ; i<nl.getLength() ; i++) { Node n = nl.item(i); if (n.getNodeType() != Node.ELEMENT_NODE) continue; Element elem = (Element)n; String type = elem.getAttribute("type"); if (type == null || !"text/css".equals(type)) continue; String val = getElementText(elem); processStyleElement(val); } System.out.println("############### PROCESSING"); substituteClassAttribute(doc.getDocumentElement()); System.out.println("############### WRITING"); File outf = new File(outFile); TransformerFactory tf = TransformerFactory.newInstance(); Source source = new DOMSource(doc); Result result = new StreamResult(outf); Transformer trans; try { trans = tf.newTransformer(); trans.transform(source, result); } catch (Exception tce) { error("processFile:" + tce); return false; } return true; } public VisioFilter() { styles = new HashMap<String, String>(); } public static void main(String argv[]) { if (argv.length!=2) { System.out.println("usage: VisioFilter infile outfile"); return; } String inFile = argv[0]; String outFile = argv[1]; VisioFilter vf = new VisioFilter(); vf.processFile(inFile, outFile); } }//end class

1 1

Re: [Inkscape-devel] Effects Tarball
by Alexandre Prokoudine 20 Apr '05

20 Apr '05

On 4/20/05, bulia byak <buliabyak@...400...> wrote: > On 4/20/05, Alexandre Prokoudine <alexandre.prokoudine@...400... > wrote: > > btw, is it possible to add a "_" to "Effects" (e.g. "E_ffects") so > > that this menu was selectable from keyboard at once? > > No because "f" is already taken for _File. And "e" for _Edit. You can > only use "c" or "s". Well :) I don't insist on _f :) It's just it should be there, no matter what exactly unique character is used. Alexandre

1 0

More warnings with gcc4.0
by Bob Jamison 20 Apr '05

20 Apr '05

Playing more with the current pre-release of gcc4.0, I found some more warnings due to its greater strictness. Here are the warnings I got with CVS today. 'make clean ; make > /dev/null' is great for getting this listing. People might want to look at their files. I can clean up some of these tomorrow. Actually, this is not very many! Bob dropper-context.cpp: In function 'void sp_dropper_c32_color_copy_hex(guint32)': dropper-context.cpp:216: warning: unused variable 'pick' file.cpp: In function 'void file_import(SPDocument*, const gchar*, Inkscape::Extension::Extension*)': file.cpp:752: warning: unused variable 'repr' select-context.cpp: In function 'gint sp_select_context_item_handler(SPEventContext*, SPItem*, GdkEvent*)': select-context.cpp:276: warning: unused variable 'selection' sp-item.cpp: In function 'SPItem* sp_item_first_item_child(SPObject*)': sp-item.cpp:1277: warning: control reaches end of non-void function sp-pattern.cpp: In function 'void sp_pat_fill(SPPainter*, NRPixBlock*)': sp-pattern.cpp:909: warning: operation on 'px_x' may be undefined sp-pattern.cpp:940: warning: operation on 'px_x' may be undefined dialogs/stroke-style.cpp: In function 'void sp_stroke_style_any_toggled(GtkToggleButton*, SPWidget*)': dialogs/stroke-style.cpp:1704: warning: unused variable 'items' display/canvas-arena.cpp: In function 'void sp_canvas_arena_class_init(SPCanvasArenaClass*)': display/canvas-arena.cpp:91: warning: invalid access to non-static data member 'SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:91: warning: (perhaps the 'offsetof' macro was used incorrectly) display/sp-canvas.cpp: In function 'void sp_canvas_item_class_init(SPCanvasItemClass*)': display/sp-canvas.cpp:110: warning: invalid access to non-static data member 'SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:110: warning: (perhaps the 'offsetof' macro was used incorrectly) libnrtype/Layout-TNG-Output.cpp: In function 'const char* Inkscape::Text::weight_to_text(PangoWeight)': libnrtype/Layout-TNG-Output.cpp:214: warning: enumeration value 'PANGO_WEIGHT_SEMIBOLD' not handled in switch livarot/float-line.cpp: In member function 'void FloatLigne::Affiche()': livarot/float-line.cpp:518: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t' livarot/float-line.cpp:524: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t' widgets/sp-color-wheel.cpp: In function 'void sp_color_wheel_set_color(SPColorWheel*, const SPColor*)': widgets/sp-color-wheel.cpp:229: warning: operation on 'sat' may be undefined

3 3

[dtl_s_t_m] Desktop Developers Converence (fwd)
by Bryce Harrington 20 Apr '05

20 Apr '05

FYI. I'm hoping to be at this conference, and it'd be cool to meet up with other developers there. Bryce ---------- Forwarded message ---------- Date: Mon, 18 Apr 2005 09:45:16 -0700 From: Tom Hanrahan <hanrahat@...1...> To: dtl_s_t_m@...790... Cc: Andrew J. Hutton <ajh@...791...> Subject: [dtl_s_t_m] Desktop Developers Converence As many of you know, a desktop conference will be held this year, July 17, 18, in Ottawa. I'm writing to ask for your help in publicizing the event, and in particular, to request that look within your organizations for developers interested in submitting papers for the conference. Paper proposals are now being accepted. The deadline is May 1. You can learn more about the conference (including how to submit papers) at: http://www.desktopcon.org/2005/ Let me know if you have any questions. Also let me know if you are aware of any other organizations worth approaching with invitations to participate. Thanks, -- Tom

1 0

Re: Inkscape on our covermount CD
by Bryce Harrington 19 Apr '05

19 Apr '05

Hello Mr. Breyer, We have collected a set of packages for your magazine distribution: http://www.bryceharrington.com/InkscapeBild/ I have faxed a signed copy of the Explanation of License to you separately; a copy of this along with the actual license is also provided at the above URL. The System Requirements are also attached and available at the above URL. We are providing you with three packages: 1. The Inkscape Executable for Windows 2. The Inkscape Source Code 3. The Open Clip Art Library (optional) Let me know if you have any questions. Thanks, Bryce On Thu, Apr 14, 2005 at 06:44:41PM +0200, Konstantin Breyer wrote: > D ear Sir or Madam, > your Software Inkscape on our covermount CD: COMPUTERBILD, Europe's biggest > PC magazine, is going to attach a CD/DVD-ROM to one of its next issues. We > would like to record your software free of charge on this CD/DVD-ROM. The > software versions on the CD/DVD-ROM will be explained in the magazine and > will possibly also be presented and explained on our internet page > "www.computerbild.de". Thus, your product will be presented to more than 4 > millions of readers (MA 2004 I) and many enthusiastic users of the internet > - for that reason your software will get a high amount of attention. > > > > Join in. For the sake of good order, please fax the signed license agreement > (please delete inapplicable terms) back to us (+49/40/34 724 710) and e-mail > me the system requirement sheet. > > > > Kind regards, > > > > Mit freundlichen Gr??en > > Konstantin Breyer > Axel Springer AG > Redaktion COMPUTERBILD > Leitender Redakteur Software > > Telefon +49 (0) 40 - 34 72 34 52 > Mobil +49 (0) 151 - 12 70 88 23 > > Telefax +49 (0) 40 - 34 72 47 10 > E-Mail kbr@...787... <mailto:kbr@...787...> > Internet <http://www.computerbild.de/> http://www.computerbild.de > > Besucheradresse: > Caffamacherreihe 1 > 20350 Hamburg > > Diese E-Mail und eventuelle Anlagen k?nnen vertrauliche und/oder rechtlich > gesch?tzte Informationen enthalten. Wenn Sie nicht der richtige Adressat > sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte > sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren > sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. > > This e-mail and any attachments may contain confidential and/or privileged > information. If you are not the intended recipient (or have received this > e-mail in error) please notify the sender immediately and destroy this > e-mail. Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. >

4 5

Re: [Inkscape-devel] "COMPUTERBILD"?
by unknown＠example.com 19 Apr '05

19 Apr '05

Quoting Thorsten Wilms <t_w_@...123...>: > On Thu, Apr 14, 2005 at 05:56:48PM -0700, Bryce Harrington wrote: > > > > I've been emailed by someone from a magazine called > "ComputerBild", that > > is said to be popular in Europe. Could someone confirm for me > that it > > exists? > > Yes. It's a spinoff of Bild, a german newspaper with huge > headlines and full of gossip. > It's very well known and targeted at those who don't know better > ;-) Ah, Bild... Hmm, so do they want to interview you? I wonder whether it might not be wise to involve the German-speakers among us, to give them replies auf Deutsch. Avoid being misquoted AND mistranslated. ^_- (my own German abilities are pretty weak though) -mental

13 34

Re: [Inkscape-devel] Command line extension options
by Carl Hetherington 19 Apr '05

19 Apr '05

On Tue, 19 Apr 2005, bulia byak wrote: > On 4/19/05, Carl Hetherington <lists@...169...> wrote: >> OK, this is in CVS. Comments welcome. > > Wow, that was fast. > > Comments: > > -T, --text-to-path Convert text to paths when > exporting to EPS > -B, --page-bounding-box Set the bounding box of exported > EPS files to the page > > Since these apply to export only, better call them > --export-text-to-path and --export-bbox-page. (They can also be used > later for export to other vector formats.) > > Please update the release notes (section "Loading, saving, export") > > Please update the man page OK, all done. Cheers Carl

1 0

Printing issues
by John Taber 19 Apr '05

19 Apr '05

I've found 2 major issues with printing (v .41): 1) getting it to print on my fedora system - lp or lpr won't work - the bigger problem is that users shouldn't even have to mess with lp or lpr 2) it won't print a zoomed image - just the original size 3) while we're at it - how about a way to save the zoomed image size to replace the actual size Gimp offers a much better print dialog box, addressing all of the above issues, can we capitalize on that ?

4 4

Adobe buys Macromedia
by bulia byak 19 Apr '05

19 Apr '05

http://www.adobe.com/aboutadobe/invrelations/adobeandmacromedia.html I think it's good news for us. There will be people scared or disgusted by the forming monopoly and looking for alternatives. Also, it seems likely that Freehand will be either discontinued or at least downplayed so as to not hurt Illustrator, which means a lot of users will have to migrate. All this gives us a certain opportunity.

7 6

Re: [Inkscape-devel] Command line extension options
by Carl Hetherington 19 Apr '05

19 Apr '05

On Tue, 19 Apr 2005, bulia byak wrote: > On 4/19/05, Carl Hetherington <lists@...169...> wrote: >> It'd be nice if you could pass in options to the EPS exporter on the >> command line. In other words, I'd like to be able to do >> >> inkscape -p '> file.eps' file.svg > > Actually this is printing, not exporting. It's not quite the same. In > my plans is adding a separate PS export option with all the suboptions > (bbox, convert to path, and PS/EPS switch). If you can do it for me, > it would be fantastic :) OK, this is in CVS. Comments welcome. Cheers Carl

1 0

Command line extension options
by Carl Hetherington 19 Apr '05

19 Apr '05

Hi all, Long time no see! It'd be nice if you could pass in options to the EPS exporter on the command line. In other words, I'd like to be able to do inkscape -p '> file.eps' file.svg like I can now, but to be able to specify that I don't want text converted to path. What's the best way to go about this? I'm sure I could add a specific command line option, but it seems that perhaps there should be a more generic way of passing options to extensions. Any ideas? Cheers Carl

2 1

Win-Build with GTK-Wimp
by David Christian Berg 18 Apr '05

18 Apr '05

Hey guys, today I'll be leaving for Lyon, where I will hold a course on design and public relations. I thought I'd be really cool to have Inkscape as a small giveaway, but frankly unlike gimp the win builds have the standard gtk-theme included, which doesn't really rule that much. What would be cool is to have it build with GTK-Wimp (and my icon theme) I'm not sure, how big of a job that is, but if it's easy to do, I'd really appreciate someone doing this within the next week, so that I can already distribute it. Thanx! David

3 6