- Inkscape Devel - Inkscape Mailman

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