- Inkscape Devel - Inkscape Mailman

TSL errors for LP
by Brynn 20 Nov '15

20 Nov '15

Hi Friends, I'm having trouble connecting to Launchpad today. (1 success out of 8 tries :-( ) The error says "Secure Connection Failed" with option to report it to Mozilla. Info: https://support.mozilla.org/en-US/kb/tls-error-reports "If you experience this problem, contact the owners of the website and ask them to update their TLS version to a version that is still current and still secure." Has this already been reported to LP? If not, how can I do that? There doesn't appear to be any way to allow the connection to go through anyway, but I'm still investigating. Maybe have to use IE? Thanks for your help :-) brynn

2 2

Union PathVector
by Jabier Arraiza 20 Nov '15

20 Nov '15

Hi to all. I want to make a pathvector joined with itself like Inkscape do whith only a path selected, with subpats and in non-zero fill rule. I look to Krzysztof code with boolops but it handle it with diferent pathvectors, not with the same. If anybody can point me on a direction, his help are welcome. All the best, Jabier.

2 1

Offset LPE
by Jabiertxo Arraiza Cenoz 18 Nov '15

18 Nov '15

Hi to all. I just finish a LPE called "Offset" based on Liam and Krzysztof work. The branch give better results than actual offset LPE, more similar to Liam JoinType LPE than a Offset one. Anyway, the LPE could be improved working on Geom/PathStroke and Krzysztof boolops code. As a fast improvements things to do: Boolops: Commented in previous mail, I have problems with fill-rule options on AminusB function. Also if we can handle overlaping curves, I could simplify the LPE. PathStroke: Handle strange results specialy on very big width of stroke Tavmjong, you remember our conversation about extrapolated arcs in Toronto? ¿Need a refresh? ¿Could you explain to Liam in a math point of view, to know if he want to make the proposal for the SVG working group? lp:~inkscape.dev/inkscape/offset All the best, Jabier.

1 0

Vertical text & 'text-orientation'
by Tavmjong Bah 18 Nov '15

18 Nov '15

Hi, I've implemented the CSS 3 'text-orientation' property which controls how glyphs are rendered in vertical text. This property replaces the 'glyph-orientation-vertical' property which Inkscape never implemented and is deprecated in SVG 2. While doing this work I also corrected some other layout issues with vertical text and with multi-line text. As this work is rather invasive I've pushed my changes to a new branch which can be checked out via: bzr branch lp:~inkscape.dev/inkscape/writing_modes Please test this branch! Here is a list of the most important changes: * Latin characters in vertical text will be drawn by default sideways. This is the default direction in both SVG 1.1 and in CSS 3 Writing Modes. Currently Inkscape draws the glyphs upright. * Punctuation characters in CJK vertical text will be orientated correctly. * The Text Toolbar can be used to set 'text-orientation' which controls how characters are orientated in vertical text (it has no effect on horizontal text). The three choices are 'mixed' where the glyphs are drawn in their Unicode defined natural orientation, 'upright' where all glyphs are drawn upright, and 'sideways' where all glyphs are drawn sideways. * The new CSS 3 values for 'writing-mode' will be recognized. The values written out are still the SVG 1.1 values except for the new 'vertical-lr' value which has no equivalent SVG 1.1 value (and is required for Mongolian). A new button appears on the Text Toolbar to select this value. (The SVG 1.1 values are deprecated but must still be recognized by SVG renderers.) * Fonts without vertical metrics will have a vertical advance of 1em. The CSS specification explicitly does not define what advance to use but the SVG 1.1 spec suggests 1em and the W3C Japanese text document specified an advance of 1em. * In laying out multi-line text, any 'leading' value from the font is ignored. CSS dictates that the font-size corresponds to the em height of a font which is defined as 'ascent' + 'descent'. The change to ignore the "internal" font 'leading' may make small visual changes in how multi-line text appears. * In flowed text, Inkscape has been using a "scaled" value of 'ascent' to position the first line. This has been changed to follow the correct CSS prescription of using the value of 'half-leading' + normal 'ascent' for horizontal text (to find the alphabetic baseline) and 'half -leading' + half em width for vertical text (to find the center baseline). (The 'leading' in this case is the extra space needed between lines as dictated by the 'line-height' property. It is not the 'internal' font 'leading'.) Tav

3 6

Offset LPE
by Jabier Arraiza 16 Nov '15

16 Nov '15

Hi to all. Im on Offset LPE using Liam and Krzysztof work. I have two questions, First: Using "PathIntersectionGraph" to make boolean operation "getAminusB", givea unwanted result, to me, maybe because fillrule work as evenodd. I remember read in list the fill rule work is not ended on new boolops, I'm wrong Krzysztof? Second: If I'm brong with first, I need to try "manual" erase the unwanted data, for example in the middle of a infinite sign path. To do this I run the function: "self_crossings" but this function give me points not self crossed in the path, also, give me, for each real crossing, one of the times not the two that have a self crossing. Maybe Im wrong in th concept of selfcrosing... Thanks in advance for the help, all the best, Jabier.

1 0

How to make extension that is called on every edit of the document ?
by Stuart Axon 16 Nov '15

16 Nov '15

Hi, I'd like to make an extension that keeps track of changes (and can also make changes from external sources) in a drawing - is there a way to get a call every time an edit happens ? (I guess ideally the callback would include information about what was changed). S++

1 0

swiss publishing days 2015 in Bern: slides, including those from Libre Graphics talks, available for download
by "Christoph Schäfer" 15 Nov '15

15 Nov '15

Hi all, The slides of the talks during the "swiss publishing days 2015" in Bern are now online: http://swiss-publishing-week.ch/winterthur_n.php?t=Teilnehmer-Seite&read_gr… The most interesting talk with respect to Libre Graphics, was the one by Beat Kipfer (http://swiss-publishing-week.ch/dynpg/upload/imgfile1855.pdf) on Scribus, GIMP and Inkscape. He erred in several aspects, as those who can read German will certainly discover, but I was there and corrected the errors on the spot. Most importantly, though, Beat praised all three projects for their reliability and their longevity. According to Beat, they are worthy competitors to Adobe CC. It was also remarkable that one participant stood up during the Q&A session, and said (in German, of course): "I'm still an Adobe customer, but I'm about to leave the company's products, because their priority seems to be to find ways to suck their customers dry without even bothering to fix existing bugs. We should applaud and support the efforts of the Open Source community, because without them, there wouldn't be any competetion at all". The audience reacted with a long applause (and if you know the Swiss, this was a truly amazing reaction). The slides of the presentation by Holger Everding (FreeColour) and I on the advantages of a vendor-neutral and CIELAB-based colour standard are also there: http://swiss-publishing-week.ch/dynpg/upload/imgfile1973.pdf, as are the slides of my talk on open file formats (http://swiss-publishing-week.ch/dynpg/upload/imgfile1858.pdf). Please don't bother downloading the latter, because I only used the slides as a visual introduction to what I said and demonstrated with real files (e.g. showing the content of an ORA file in Ark). Christoph

1 0

couple of patches in need of testing: window icon, and auto font-refresh
by insaner 14 Nov '15

14 Nov '15

Hi all, I have a couple of patches I would like some testing done on, especially if you are a non-linux user (I can only do linux testing here) and/or a dev that can tell me any issues with the code that I am not seeing. window/task bar icon missing when installed in non-standard location https://bugs.launchpad.net/inkscape/+bug/1516238 font dialog doesn't refresh to show newly installed fonts https://bugs.launchpad.net/inkscape/+bug/168960 The patch to be tested for the font-refresh bug is: https://bugs.launchpad.net/inkscape/+bug/168960/comments/9 And if you can tell me how to get the fontlist to refresh in a non-linux (fontconfig) system, that would help me fix that issue for others too. -- View this message in context: http://inkscape.13.x6.nabble.com/couple-of-patches-in-need-of-testing-windo… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

SPKnot, KnotHolderEntity, and KnotHolder
by Papoj Thamjaroenporn 12 Nov '15

12 Nov '15

Dear Inkscape-devel, Can someone explain to me the relationships between SPKnot, KnotHolderEntity, and KnotHolder? The code seems a bit confusing to me in terms of how they are related to each other. What I have collected so far: SPKnot is a like a UI element. It has properties like style and color and signals when events are triggered. KnotHolderEntity is like the manager of SPKnot, allocating and storing pointer to SPKnot to allow SPKnot object to outlive the scope of the entity. It also manages connections between signals that SPKnot emits and receivers for those signals. KnotHolder aggregates KnotHolderEntity, with a few functions that iterate through the list of these entities to do certain things like handling events and knot update by calling methods that have been implemented in SPKnot already. My questions are: Why is SPKnot named with the SP prefix? From SPObject documentation, all SPObject is supposed to be representable as a node in SVG. There is no notion of “knot” in SVG 2 as far as I know, and the class didn't even inherit SPObject. In terms of Model-View-Controller design pattern, I see SPKnot as the Model and KnotHolderEntity as the Controller, handling the Model creation and events handling. But instead, event handling resides partly in SPKnot itself and partly in KnotHolder, which confuses me in terms of the design of these classes. Is the main purpose of KnotHolder really just for aggregating KnotHolderEntity in a list? I might be missing something, but I don’t see why we can’t move handler methods all into KnotHolderEntity, following MVP pattern. Knot events are handled individually after all. What are these PatternKnotHolderEntityXY / Angle / Scale? They seem to do something specific to patterns but instead of seeing their implementations in their own classes, I see declarations and methods about them implemented in KnotHolder and KnotHolderEntity instead. Can we factor these out somewhere, like how LPETangentToCurve defines their own KnotHolderEntities in their own source file? Overall, I’m skeptical most about the implementation of KnotHolder. It can be much simpler — just an aggregator of KnotHolderEntities. Right now, it seems to have unrelated functionalities that obscure the purpose of the class. I’d love any additional documentation about this if anyone can point me to it. I don’t see much on the generated Doxygen doc and in the source files. Thank you. Regards, _______________________ Papoj "Hua" Thamjaroenporn papoj@...3117... <mailto:papoj@...3117...>

2 1

Spary tool and transparent area ?
by Ivan Louette 10 Nov '15

10 Nov '15

Is there a way to spray only over transparent area ? (i. e. inverting "Spray only over non transparent area") ivan

1 0

Any Inkscape gurus here got any game / animation experience?
by Philip Rhoades 09 Nov '15

09 Nov '15

People, I am going to develop an Open Source interactive game for designing the neural architecture of a VERY simple alien organism - for research purposes. I am thinking that Inkscape is a sort of (more complicated) version of the interface that that would be required. During the game, after a bit of design, the alien organism should animate to some extent (depending how good the design is) because of the nerves interacting with the muscles and other cell organelles - which all correspond to SVG objects - is this a sensible method of proceeding? Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil@...1587...

5 6

Board Meeting @ Friday Oct 2nd, 2015
by Bryce Harrington 09 Nov '15

09 Nov '15

Hi all, We'll be holding an Inkscape Committee meeting this Friday the 2nd of October, on #inkscape-devel, at 1900 UTC (Noon PDT / 9pm CEST) http://wiki.inkscape.org/wiki/index.php/Board_Meetings All in the Inkscape community are welcome to attend. Our agenda is open for any new business. Thanks, Bryce ----- Forwarded message from Tavmjong Bah <tavmjong@...8...> ----- Date: Mon, 28 Sep 2015 17:28:13 +0200 From: Tavmjong Bah <tavmjong@...8...> To: Bryce Harrington <bryce@...961...>, inkscape-board(a)lists.sourceforge.net Subject: Re: [Inkscape-board] Proposal for board meeting An IRC meeting is an excellent idea. Any day at noon PDT (9 PM CEST) is OK with me. Thursdays I have an SVG WG meeting at 1:30 PM PDT (10:30 CEST). My agenda items would be: C++11 Hackfest 2016 Paid development Tav On Sun, 2015-09-27 at 12:20 -0700, Bryce Harrington wrote: > Hi guys, > > Now that our board is re-manned, I'm thinking it'd make sense to call > a > meeting on IRC. I don't have anything major to discuss myself, but > I'll bet the rest of you have some good ideas to float. > > How does some time first week of October sound? Thursday Oct 1st? > Or > would the weekend be better? I seem to recall that before we met at > noon pacific time; would such a time be impossible for anyone? > > http://wiki.inkscape.org/wiki/index.php/Board_Meetings > > As far as agenda goes, I don't have anything to suggest - this past > year > we've accomplished so much! I figure we can just play it by ear, and > leave the agenda to "opens". > > Bryce > > > > > > --------------------------------------------------------------------- > --------- > _______________________________________________ > Inkscape-board mailing list > Inkscape-board(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-board ----- End forwarded message -----

6 15

Measure and Spray tool
by Jabiertxo Arraiza Cenoz 08 Nov '15

08 Nov '15

Hi to all, the spray tool and measure tool improvements are now in trunk, thanks to Nathan Hurst and Mc- for the fast reviews and to all people involved on it. Bug report it! Regards, Jabier. https://www.youtube.com/user/jabiertxof/videos

3 2

Screen tearing on Inkscape (OS X)
by Papoj Thamjaroenporn 08 Nov '15

08 Nov '15

Dear Inkscape-devel, I recently picked up Inkscape again, and there is this screen tearing <https://en.wikipedia.org/wiki/Screen_tearing> issue I have seen on OS X, and I am wondering what the causes are and how I may be able to contribute. As far as I understand, screen tearing seems to be an issue specific to GTK2. This happens when I scroll or zoom the canvas, where screen refresh rate is not synced with canvas rendering. This happens either on X-based version (I tried using the official Inkscape app) or Quartz-based version (I tried by compiling the trunk using Quartz variants). I also found that ~suv has this exciting development on native OS X integration with GTK3. The artifacts I have seen are exactly like in this screen recording <https://inkscape.org/en/gallery/item/4556/> of Inkscape with GTK2 that ~suv posted. So, am I correct to say that GTK3 somehow eliminates this problem, even without native OS X integration? How does it do so? If we stay with GTK2 as of now, is there a way to fix the tearing issue? Regards, _______________________ Papoj "Hua" Thamjaroenporn papoj@...3117...

2 2

Re: [Inkscape-devel] Board Meeting @ Friday Nov 6th, 2015
by Bryce Harrington 06 Nov '15

06 Nov '15

Reminder that the meeting is tomorrow at Noon Pacific time. Check your times since daylight savings is in effect. Last month's meeting log is posted here for reference: https://inkscape.org/en/gallery/item/6701/ Bryce On Thu, Oct 29, 2015 at 08:27:15PM -0700, Bryce Harrington wrote: > Hi all, > > Last month's meeting went well, and we decided to have another in early > November at a similar time and place. > > We'll be holding an Inkscape Committee meeting on Friday the 6th of > November, on #inkscape-devel, at 1900 UTC (Noon PDT / 9pm CEST) > > http://wiki.inkscape.org/wiki/index.php/Board_Meetings > > Agenda is: > > * Code of Conduct & Privacy Policy > * Funded development > * GSoC 2016 > * Fiscal Sponsorship Agreement (FSA) > * Hackfest 2016 > * Budget 2016 > * Other business > > Bryce > > ------------------------------------------------------------------------------ > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Notifying users of nonfatal errors, general interface?
by mathog 05 Nov '15

05 Nov '15

Hi, All, I posted about this back on 2015-03-26 with the title Example of Inkscape handling corrupt input file but there were apparently no responses. So once again, is there an interface in Inkscape where code can push a message for a nonfatal event such that: 1. In GUI usage - a pop up appears with the message. 2. Command line/filter usage - message is sent to stderr Usage example: SVG -> EMF export cannot handle opacity because the output format does not support it. The code currently just drops the opacity property which of course results in output visually different from the original (although all the same elements are there). End users keep tripping over this, example: https://bugs.launchpad.net/inkscape/+bug/1513262 So I would like a warning message to appear. Ideally this would show up in the code as something really simple like this: if(errors_found){ inkscape_display_message(my_message): } and then this function/method would go on and never has to do anything else related to that message. If there is already a function/method corresponding to "inkscape_display_message", what is it called? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Suppressing specific Unknown Attribute '__alloc_size__' warnings
by Papoj Thamjaroenporn 05 Nov '15

05 Nov '15

Dear Inkscape-devel, I became tired of seeing these same warning messages over and over again whenever I compile and debug the code: /opt/local/include/gc/gc.h:804:23: warning: unknown attribute '__alloc_size__' ignored [-Wunknown-attributes] GC_API GC_ATTR_MALLOC GC_ATTR_ALLOC_SIZE(1) void * GC_CALL For the record, I compile Inkscape 0.91(trunk) with XQuartz backend using latest clang from Xcode. Someone also has seen <https://answers.launchpad.net/inkscape/+question/256081> this before (I’m glad the instructions I posted on the mailing list a year earlier were useful :-)), and the thing about warnings was ignored because the issue there was about getting the code to run. It seems that clang has removed alloc_size attribute <https://github.com/neovim/neovim/issues/429> a while ago. But these warnings would pop up about gazillion times per compiling session, from gc.h, so I am wondering if I can suppress this warning specifically. I’m not familiar with how to add a suppression in autoconf. Do I just do the following in configure step? ../trunk/configure --prefix=YOUR_BUILD_DIRECTORY --disable-static --enable-shared CC="clang" CXX="clang++" CXXFLAGS="-std=c++11 -stdlib=libc++ -I/opt/local/include -Wno-unknown-attributes" CPPFLAGS="-I/opt/local/include -U__STRICT_ANSI__ -Wno-unknown-attributes" If I re-configure the build, do I have to run "make install" again before "make -j 4"? I’m also not sure if globally suppressing this kind of warning is recommended. I have not seen this kind of warning other than this, and I couldn’t even find its definition on the official Clang documentation <http://clang.llvm.org/docs/UsersManual.html>. If this is not recommended, does anyone know how I can specifically suppress this particular warning? Regards, _______________________ Papoj "Hua" Thamjaroenporn papoj@...3117...

4 5

Absolute path to image
by my369 04 Nov '15

04 Nov '15

Hello. I have noticed sucha feature in inkscape, every time I press the "Extract Image.." path for all images will change to absolute. It's either something I do not know, or it is a bug.

2 1

question about nodes display
by Brynn 02 Nov '15

02 Nov '15

Hi Friends, I sent this message earlier, but the attachment has apparently put it over the size limit. So it's waiting for a moderator, for now. But perhaps could be answered without the PNG. So just in case, here's the message, and if the screenshot is needed, I'll try to figure some way to send it. Original message below: This is something I noticed a long, long time ago, and never really questioned. But now I'm writing a tutorial about node editing, and it seems a good time to find out. When more than 1 node are all stacked up, precisely on top of each other -- if it's an even number of nodes, then they appear to be smaller than a regular node. (see in the top aqua circle in the attached ne12.png) It's what you see if you use "Break path at selected nodes". But if there are an odd number of nodes all stacked up, it looks just like a regular node. So there's no visible clue -- you only know how many nodes might be there, if you happen to select them (by dragging a selection box around), or if you already know, or happen to remember what's there. I'm curious why it's made that way, and whether it might be helpful if any number of stacked up nodes can look like the even number of stacked up nodes (just a smaller node). Well, I would find it helpful anyway, and wonder if others might as well. I'd appreciate if anyone can explain. Thank you very much, brynn

3 5

question about nodes display
by Brynn 01 Nov '15

01 Nov '15

Hi Friends, This is something I noticed a long, long time ago, and never really questioned. But now I'm writing a tutorial about node editing, and it seems a good time to find out. When more than 1 node are all stacked up, precisely on top of each other -- if it's an even number of nodes, then they appear to be smaller than a regular node. (see in the top aqua circle in the attached ne12.png) It's what you see if you use "Break path at selected nodes". But if there are an odd number of nodes all stacked up, it looks just like a regular node. So there's no visible clue -- you only know how many nodes might be there, if you happen to select them (by dragging a selection box around), or if you already know, or happen to remember what's there. I'm curious why it's made that way, and whether it might be helpful if any number of stacked up nodes can look like the even number of stacked up nodes (just a smaller node). Well, I would find it helpful anyway, and wonder if others might as well. I'd appreciate if anyone can explain. Thank you very much, brynn

1 0

Spray Tool V
by Jabiertxo Arraiza Cenoz 01 Nov '15

01 Nov '15

Hi again, another video to the list. Sorry for the multiple steps, but my initial objetive increase in each video. Next time I try to reduce the number of videos to one or maybe 2. https://www.youtube.com/watch?v=Zn3vzf-yA_w Whith this improvement, now the Spray tool get the trace dialog options if in "pick" mode. Cheers, Jabier.

1 0

Re: [Inkscape-devel] Spray Tool Improvements III
by Jabier Arraiza 30 Oct '15

30 Oct '15

Hi Ivan, put reply on list. First one is not posibol to put them "exactly" because is based on a random algoritm of the tool. Second one: Great idea!!! I try to implement. Thanks for the feedback! El jue, 29-10-2015 a las 12:15 +0100, ivan louette escribió: > Then what do you think of the two following ideas : > > 1° spraying exactly contiguous squares or quadranglesto simulate > bitmaps ? > > 2° spraying objects which increase or decrease in size based on the > darkness or lightness of the background colors ? > > Le 29/10/15 11:23, Jabier Arraiza a écrit : > > Yes Ivan!!! > > > > El jue, 29-10-2015 a las 09:14 +0100, ivan louette escribió: > > > Can you spray over a bitmap image and acquire its colors like > > > this is > > > possible with clones ? > > > > > > Le 28/10/15 21:10, Jabier Arraiza a écrit : > > > > Thanks Ivan, this allow a lot of posibilities, because the > > > > color > > > > that > > > > change is only the fill, the stroke retains original color, so > > > > you > > > > can > > > > do things like this: > > > > http://i.imgur.com/wn7n95Z.png?1 > > > > > > > > Regards, Jabier. > > > > > > > > > > > > El mié, 28-10-2015 a las 20:53 +0100, ivan louette escribió: > > > > > Amazing ! I easily imaginate it combinated with some svg > > > > > filter > > > > > to > > > > > simulate organic cellular textures ! > > > > > > > > > > ivan > > > > > > > > > > Le 28/10/15 19:31, Jabier Arraiza a écrit : > > > > > > Hi again, my last video about new features to the spray > > > > > > tool: > > > > > > https://www.youtube.com/watch?v=aTdKu7mAZE8 > > > > > > > > > > > > Thanks to Gabriel Grosso for the idea and to Mc for his > > > > > > help on > > > > > > review. > > > > > > > > > > > > Cheers, Jabier. > > > > > > > > > > > > > > > > > > --------------------------------------------------------- > > > > > > ---- > > > > > > ---- > > > > > > ------------- > > > > > > _______________________________________________ > > > > > > Inkscape-devel mailing list > > > > > > Inkscape-devel(a)lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > > > > ----------------------------------------------------------- > > > > > ---- > > > > > ---- > > > > > ----------- > > > > > _______________________________________________ > > > > > Inkscape-devel mailing list > > > > > Inkscape-devel(a)lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

3 5

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 113, Issue 19
by Jelle 30 Oct '15

30 Oct '15

Great work guys! The spray tool improvements make it a lot more useful, but the text improvements are a bit of a breakthrough. Thanks for all the great effort. > 1. New branch SprayTool Improvements > 9. Vertical text & 'text-orientation' Cheers, Jelle

2 1

Recent changes that would result in object reordering???
by mathog 29 Oct '15

29 Oct '15

I fixed a bug today and found that the emf round trip test no longer worked. (This has nothing to do with the bug I was working on, which just changed a couple of scale factors related to dashed lines.) The round trip test works like this (sorry about the wrap): $INK --file=/usr/local/src/libUEMF/dist/test_libuemf_ref.emf --export-emf=/tmp/test1.emf $INK --file=/tmp/test1.emf --export-emf=/tmp/test2.emf $INK --file=/tmp/test2.emf --export-emf=/tmp/test3.emf $READEMF /tmp/test1.emf > /tmp/test1_emf.txt $READEMF /tmp/test2.emf > /tmp/test2_emf.txt $READEMF /tmp/test3.emf > /tmp/test3_emf.txt afterwards "diff" of any of pair of the test*_emf.txt pairs would show only the one line associated with the name change. Not anymore though. Now they differ from each other a lot. When the emf files produced are viewed in inkscape they appear to be the same. However, the text dumps of the EMF files are wildly different, apparently because the object order is no longer the same. That is, the input stage is seeing the objects in one order, and the output stage is seeing them in another. The reordering seems to be repeatable, that is, if test1.emf is loaded and saved as test9.emf, then the text dump of that is the same as test2.emf (other than the file name field.) The same test with WMF is still stable, but that is a much, much simpler and smaller test file. What has changed in Inkscape that would be causing this? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 3

Code of Conduct review
by Krzysztof Kosiński 29 Oct '15

29 Oct '15

Hello I think the CoC can be considerably improved. I think it's too wordy in a few places. Here is my proposed revised text. Inkscape online communities are intended to be a friendly, inclusive spaces for users to collaborate on the further development of Inkscape, share and discuss their creations, inspire each other and interact in constructive ways. To that end, we have established a set of guidelines that we believe will help foster such an environment. Anyone willing to follow these guidelines is welcome. In your interactions with others, please do your best to: - Be respectful. There's always a human very much like you at the other end. Always treat them respectfully and be kind to them, even if you disagree with them. - Be responsible. Everyone makes mistakes from time to time; own up to them and be willing to work on fixing them. If someone has been harmed or offended, listen carefully and work to right the wrong. - Don't take criticism personally. Remember that criticizing an idea (e.g. a technical proposal or an user interface blueprint) is different from criticizing the person that proposed it. Do not become overly attached to your contributions and do not demand preferential treatment for them because of your standing in the community. Ideas should stand on the merit of their supporting arguments, not on the merit of their originators. - Use neutral language. Avoid words that others are likely to find offensive or excluding. - Forgive. If someone wronged you and apologized, do not keep demanding special punishment. Don't hold a grudge or seek to settle scores. Be willing to let things slide if it benefits the community. - Give credit where it is due. Never try to pass off others' work as your own. - Disclose and address conflicts of interest. You should be aware when you are conflicted due to employment or other projects you are involved in, and abstain or delegate decisions that may be seen to be self-interested. When in doubt, ask for a second opinion. - Step down considerately. When you leave a responsible position in the Inkscape project, do so in a way that minimizes disruption to the community. Tell people you are leaving and take the proper steps to ensure that others can pick up where you left off. The following actions and behaviours are deemed unacceptable: - Harassment of other users, including but not limited to threats of any kind, insults, discriminatory language and jokes, unwelcome sexual attention, posting personally identifying information ("doxing"). - Deliberate disruption: trolling, spamming, flaming, baiting, attention seeking, distribution of malware, any kind of attacks against Inkscape computing infrastructure or that of its parent organizations. - Distribution of illegal or pornographic material in Inkscape communities. - Advocating or encouraging any of the above. If you believe a member of an Inkscape community is in breach of the above code, report it to the appropriate moderators (contact info here), even if you are not among the directly affected parties. Violations of the code can be met with disciplinary action, ranging from a private warning to complete, permanent expulsion. If you feel you have been unfairly accused or penalised, you may contact Inkscape's board (link to governance section here). Decisions of the board are final. Summary of changes: I removed some text that I felt was repetitive and split the code into 2 sections with desirable and undesirable behaviors. I also added 2 points: "Forgive" and "Give credit where it is due", which I think are pretty important, and a paragraph at the end about disciplinary action. Best regards, Krzysztof

5 11