- Inkscape Devel - Inkscape Mailman

Difficulty rendering Arabic text (re-send)
by Adam Baker 26 Feb '12

26 Feb '12

This is a repost of my earlier message, since the Arabic characters in the pasted SVG weren't encoded properly. -- Hello, I believe this may be a bug, but I will leave that judgment to more capable people. In rendering paragraphs of Arabic text, I have come across situations where the text simply does not join together. In fact, it's possible through editing to toggle the text back and forth between appropriately joined and entirely unjoined. I haven't been able to identify the conditions under which this occurs. The attached SVG file is a minimal example. In Inkscape 0.48.2, Windows Vista, the letters are all completely unjoined. But, if the final space is removed from the text, the letters join properly. On the other hand, some longer blocks of text do render properly. I am at a loss. Any thoughts are appreciated, or if it looks like this is a bug, that would be good to know as well. Thanks, Adam

1 0

IRC meeting
by Josh Andler 25 Feb '12

25 Feb '12

A big thanks to everyone who participated! It was great to see and some good stuff got covered. Cheers, Josh

1 0

Minutes of the Inkscape team IRC meeting, 25/02
by Krzysztof Kosiński 25 Feb '12

25 Feb '12

This is a rough record of the main subjects of discussion. Copied with slight changes from http://piratepad.net/inkscape The agenda turned out to be too long for a single meeting, and several points were left untouched. 1. Inkscape 0.48.3.1 packaging Need people (2 or 3) to create an installer on win32 and OSX. How about UweSch ? Tweenk is making a package on a VM (for win). Quite slow need 1h. Discussion about tool (btool, MSYS..) "we have 2 ways forward, fix our autotools scripts to work with MSYS (should be doable since they have recently updated their Perl port) or move to a different build system" Resume: ScislaC and Tweenk will see about building the Win32 packages. They need to figure out if the project could invest in virtualized OS copies so they can knock specific builds out (like OSX). If Michael W. doesn't have time/resources, su_v could provide 32bit Intel (Leopard) and 64bit Intel (Lion) packages (no Universal packages) Unit testing: we need to get our unit tests cleaned up and all passing. Then a continuous build system can take care of that whole one-os-breaks-the-others issue. Breaking OS often stems from #ifdef or package issues, so is not solved by unit testing. Unit testing + continuous build systems on multiple OS's catches #ifdef breakage, etc. 2. Inkscape 0.49 2.1 - Remaining refactoring goals Cairo and render caching : still some bugs to fix Gradient rendering: kuribas offers to chip in to help fix the banding. Idea is to add it as an option in exporting. Needs to be implemented in Cairo. disadvantages: speed, filesize, consistency between outputs, shouldn't be done partially (only on gradients f.e.) proposal (Tweenk): implement a GEGL renderer as an alternative to the Cairo renderer for use in export (running 16 bit engine under the hood) 2.1.1 - Handling of svg:switch not as a kind of group, but as a "transparent" element that is effectively replaced by the best choice in the SP tree (ScislaC): we need to be a solid test ground for SVG2 ... switch helps make it happen. (Tweenk): there is an asymmetry between the "base path" and "path parameters": the "base path" is stored in the svg:path that represents the result, while all other path parameters are stored in, IIRC, inkscape:liveeffect (Tweenk): the primary use case for switch in Inkscape would be to put 2 elements in it where the first is an inkscape-specific XML element while the second is an SVG fallback browser implementation is not at par yet - this isn't usable on the web for now. Some playing/testing with Firefox: (Tweenk): looks like FF works as I intended only if I put the SVG element first, and the Inkscape-specific XML second link: https://developer.mozilla.org/en/SVG/Element/switch (Tweenk): if I put Inkscape XML in a foreignObject it works properly (MenTaLguY): foreignObject is probably the technically correct thing anyway (Tweenk): there would be two elements in the <switch>, a <inkscape:something> inside <foreignObject> that would contain flowframe info and a <g> that would contain SVG 1.1 text (...and ScislaC nods) 2.1.2 - SVG 1.1 fallback for flowtext (probably depends on the above) see above - 2.1.1 2.1.3 - UI & Document coordinates the problem in short: where do you set the (0,0) point and what direction? Currently: (Inkscape standard): bottom left corner = (0,0) and up is positive versus (SVG standard): top left corner = (0,0) and down is positive. Current fix breaks a few things stored in desktop coordinates: grids, 3D boxes and guides, rows and columns, view coordinates, ... (JonCruz): "I'd say we need to have a wiki page to start listing what can be affected, and the use cases we care about" Changes shouldn't alter the SVG, but be purely interface (preferrably the document origin should be configurable on a per document basis) 3D box: fix or remove and then rewrite, if a new one is written, keep in mind http://dev.w3.org/csswg/css3-transforms/ wiki page to summarize broken areas, general use cases, etc. for guiding the coord fixes: http://wiki.inkscape.org/wiki/index.php/UI_and_Document_coordinates 2.1.4 - Markers matching stroke by default (user preference vs current default behavior) See SVG2 below. 2.1.5 - Better architecture for Live Path Eeffects (LPE; similar to SVG 2.0 vector effects) 2.1.6 - User visible version numbering suggestion of switching to a different scheme after 0.49 is released 1.0 conditions: fix most annoying problems: flowtext, coords, marker coloring discussion background: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31650 and take 2: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36540 2.2 - Status 0.49 should contain the coords fix (but it should be forward compatible with origin being placed in another spot) Flowtext fallback is too complicated and there's already too much new stuff in 0.49 Lack of mipmapping / downscaling in Cairo: critical bug WIKI page is needed to work on this: http://wiki.inkscape.org/wiki/index.php/Mipmapping 2.3 - Release Plan 3. - GSOC 2012 3.1 - Focus / Goals Pick coders who have better chances of sticking around and delivering instead of those who promise super-features Focus on completing all selected projects successfully with benefit to the project rather than on adding flashy new stuff Preference on structural type projects over features 3.3 - Mentoring Available mentors: Johan E. (dutch, english, german), Tweenk (english, polish) (can also be a student), Tav (English, W. African Pidgin), JonCruz (english) Available mentors should be pinged: JazzyNico, pygmee, steren. i guess we can manage some "french team" Not available: Jasper vd G. Available as admin: simmie 3.4 - Getting new students JonCruz mentioned something about African students - African countries have a lot of open source activity, but most of it is in French-speaking countries (language barrier) -> JazzyNico, pygmee and (Steren -if available) can speak French : need to find available african too but we can have help from some organization for this :) For GSoC purposes, 2Geom should be part of Inkscape - interesting potential projects with concrete deliverables; relates to point 8 (to be discussed in the future) Strictly enforce two patches rule Have IRC meetings with mentors/students as part of our process (Johan: I meant this as part of our *selection* process) 4. SVG2 and CSS3 - not discussed thoroughly due to lack of time. 4.1 - Implementation strategies 4.1 .1 - Fallback support for older versions of the spec and inkscape 4.1 .2 - Specific features (markers inheriting properties for example) 4.2 - Low hanging fruit Marker color matching stroke. Named colors. CSS3 2d transforms (duplicates current attributes) 4.3 - Most important features to our userbase 4.3.1 - Helping Tavmjong with the Mesh branch 4.4 - Initial Vector Effects support (non-destructive boolean ops might be a good target) - relates to Live Path Effects 4.5 Pushing for wanted features in SVG2. - multipage support 8. What we need in upstream libraries (including 2geom) 2geom: coders better documentation of mathematics behind path operations more unit tests port existing tests to Google Test Framework? provide skeleton test example libgdl: named icons in dock item labels there's a bug in the code that we currently have imported into our codebase that makes 64 bit architectures crash: https://bugs.launchpad.net/inkscape/+bug/933058/comments/10 cairo: bitmap downscaling / mipmapping libcroco: ability to work with other XML tree implementations this is provided by our in-tree cr-sel-eng (selection engine) modification 11. Platform specific issues (and responsibilities) - see point 1 12. Regular IRC Meetings (monthly is ideal, quarterly would be as a good minimum) general consensus on 1 or 2 times per month. suggestion to let timeslots alternate (f.e. 8AM and 8PM UTC) to accomodate ppl worldwide Various points: * do we need more focus on 'polish' instead of new features? see Bruce Perens' keynote on Linux.conf.au http://www.youtube.com/watch?v=Uoum-DHO7S8 * long-winded discussion about preferences system * this discussion then spilled over into the embed/link debate Participants (list might be incomplete): jazzynico, Johan Engelen (johan_e), Jon A. Cruz, Jurgentje, Kris, Nikita Kitaev, parasidasaeidae, pygmee, ScislaC, simarilius, su_v, Tavmjong, Tweenk, yemanjalisa

2 1

Re: [Inkscape-devel] Powerstroke cusps
by Valerie 25 Feb '12

25 Feb '12

> Hi all, > I've been working on cusps on powerstroked paths. And I've obtained a > first success. The attached picture shows a comparison between how > powerstroke strokes thick cusps, and how Inkscape does it normally (I > suppose according to SVG spec). I think the powerstroke solution is more > artistically pleasing, what do you think? :-) That looks Fantastic! The powerstroke version, of course! I can't wait to try it out! :D

1 0

Difficulty rendering Arabic text
by Adam Baker 25 Feb '12

25 Feb '12

Hello, I believe this may be a bug, but I will leave that judgment to more capable people. In rendering paragraphs of Arabic text, I have come across situations where the text simply does not join together. In fact, it's possible through editing to toggle the text back and forth between appropriately joined and entirely unjoined. I haven't been able to identify the conditions under which this occurs. The SVG file below is a minimal example. In Inkscape 0.48.2, Windows Vista, the letters are all completely unjoined. But, if the final space is removed from the text, the letters join properly. On the other hand, some longer blocks of text do render properly. I am at a loss. Any thoughts are appreciated, or if it looks like this is a bug, that would be good to know as well. Thanks, Adam <?xml version="1.0" encoding="utf-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" width="744.09448819" height="1052.3622047" version="1.1"> <flowRoot xml:space="preserve" style="font-size:16px;direction:rtl;writing-mode:lr-tb;font-family:Times New Roman">‏<flowRegion><rect width="745" height="283.57144" x="-1.4285715" y="1.6478958" /></flowRegion><flowPara>سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام </flowPara></flowRoot> </svg>

1 0

2/25 IRC Meeting Agenda (draft)
by Josh Andler 25 Feb '12

25 Feb '12

Hey all, I just wanted to send out a draft agenda for the upcoming irc meeting and also seek feedback about what others would like to add to the list. I will send out a finalized version a couple hours before the meeting time. Just a reminder, the meeting is scheduled for UTC 2/25 0800. *Inkscape 0.48.3.1 packaging *Inkscape 0.49 **Status **Release Plan *GSOC 2012 **Focus **Goals **Mentoring **Getting new students *SVG2 **Implementation strategies **Low hanging fruit **Most important features to our userbase *CSS3 *Javascript *Membership changes on the Inkscape Board *What we need in upstream libraries (including 2geom) *Old/unfinished code **Lessons learned **Cleanup *Release schedule moving forward **Fixed schedule **Schedule timing **Developer needs **Translator needs *Platform specific junk (OSX, Windows, etc... and yes, it's junk and unless people are going to contribute code, we won't stay focused on it too long) Cheers, Josh

3 3

02/25 IRC Meeting Agenda
by Josh Andler 25 Feb '12

25 Feb '12

Hey all, Here is a slightly modified agenda for the irc meeting in ~2 hours. Sorry that the formatting is probably not ideal, it's my first shot as this is the first official meeting that I can remember in the past 8 years. Just a reminder, the meeting is scheduled for UTC 02/25 0800. *Inkscape 0.48.3.1 packaging *Inkscape 0.49 -Remaining refactoring goals --Handling of svg:switch not as a kind of group, but as a "transparent" element that is effectively replaced by the best choice in the SP tree --SVG 1.1 fallback for flowtext (probably depends on the above) --UI & Document coordinates --Markers matching stroke by default (user preference vs current default behavior) --Better architecture for LPEs (similar to SVG 2.0 vector effects) --User visible version numbering -Status -Release Plan *GSOC 2012 -Focus -Goals -Mentoring -Getting new students *SVG2 -Implementation strategies --Fallback support for older versions of the spec and inkscape specific features (markers inheriting properties for example) -Low hanging fruit -Most important features to our userbase --Helping Tavmjong with the Mesh branch -Initial Vector Effects support (non-destructive boolean ops might be a good target) *CSS3 support *Javascript support *Membership changes on the Inkscape Board *What we need in upstream libraries (including 2geom) *Old/unfinished code -Lessons learned -Cleanup *Release schedule moving forward -Fixed schedule -Schedule timing -Developer needs -Translator needs *Platform specific issues (and responsibilities) *Regular IRC Meetings (monthly is ideal, quarterly would be as a good minimum) Looking forward to seeing whoever shows up. I want to have these meeting be painless, but this initial one might be a little more in-depth given that it's our first and we probably have a bit to share/discuss and document. I will try to keep us focused if we stray. Cheers, Josh

1 0

Disappearance of rendering and regression tests.
by Tavmjong Bah 24 Feb '12

24 Feb '12

Hi, At one point we had automatic rendering and regression testing. I can't seem to find any information about this. The links are all broken. Can someone point to a current source of the tests? Thanks, Tav

2 1

Gradually replacing UniConvertor + refactoring
by Alexandre Prokoudine 24 Feb '12

24 Feb '12

Hi, Speaking of refactoring, I think it's time we consider replacing some of our UniConvertor-based importers. The one I particularly have in mind is CDR. Thus far support for some file formats via UC was a low-hanging fruit. However the project isn't progressing (http://bit.ly/pRwyJV) in a way that would provide us an increasingly good support for some of them, especially CDR. Yet users keep complaining (and rightfully so). Last year we (re-lab) started working with LibreOffice team. The first project we did together was reading binary Visio files which resulted in libvisio (http://bit.ly/rh0TGd) that's now available to everyone with release of LibreOffice 3.5 a week ago. Then we started working on CDR (again), and now there is libcdr available (http://bit.ly/zJFr7l). With release of v0.0.3 the library is now feature-wise on par with UniConvertor and even surpasses it in terms of supported objects, properties and a certain part of API that is of interest for us. I'm talking about API that allows building previews of pages and importing just the pages that the user needs (something like what we have in the PDF/PS importer). Pages used to be one of the selling points for Corel DRAW, since Adobe Illustrator got its artboards only in CS4. So no wonder that there's quite a lot of legacy CDR files around that have multiple pages. And we cannot sensibly read those. The very same API was added to libvisio. So what I'm wondering about is whether we can abstract part of the importing preview dialog and rebuild existing importers around it: redo both PDF/PS/EPS (probably little work), use libcdr instead of UC, add Visio importer (libvisio). If we ever go for Assimp for importing 3D projections of 3D files, that would come in handy too. It would probably also make sense adding a possibility to import pages as either layers or new documents (the way GIMP does it for e,g, PDF). What do you think? P.S. As for libcdr and libvisio, both are well maintained project (as they are part of LibreOffice). Currently we are working on support for gradients and text in CDR (both missing in UniConvertor). If anyone's interested, it's best to fetch code from Git, as it's moving forward very fast. $ git clone git://anongit.freedesktop.org/libreoffice/libcdr Alexandre Prokoudine http://libregraphicsworld.org

2 3

Inkscape slowing down
by LucaDC 23 Feb '12

23 Feb '12

I've not been using Inkscape for a while lately. Yesterday I made a new drawing and noted a considerable slowdown while moving objects. After some investigation, I found that this is mainly due to bounding box update, i.e. while an object (or a group of objects, but a single one is enough) is moved, its bounding box is drawn as a dashed rectangle around it; when I start moving, the rectangle stays in its original position for a while (and moving is ok), then if I stop moving or after a while it gets updated in the new position and this takes ages! I can't work with such a slow update. I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered pretty old a system, but I run all the software I need on it without any problem. I feel that it should be fairly enough for an application like Inkscape (I never use filters or other graphical features, only technical drawing); and it was, up to few weeks ago. I suspect that the bounding box is continuously recalculated but this is not needed as the object cannot change while moving it; also, calculating the bounding box for a single object should not be heavy at all. So, should I start worrying for Inkscape requiring too much resources for me in the near future (or even present) or can this be simply considered a bug? I can easily trigger it by opening a new document, drawing a couple of circles and a couple of rectangles, selecting all four objects and start duplicating them with the spacebar: after a few duplications my CPU usage goes very high and moving objects becomes a pain. It seems related to how many objects are present in the drawing, which is a nonsense because moving a single object should not depend on anything else but the object itself (I tried with all snappings disabled too, of course). Thanks and regards Luca -- View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

12 33

helper/util folder
by Johan Engelen 20 Feb '12

20 Feb '12

Hi all, We have two helper directories: src/helper and src/util. I think we should merge the two. Which name do we want to keep? Note we have for example src/helper/units.h and src/util/units.h, argh! If anyone is looking for a GSoC project: a unification of the units system would be nice. If I remember correctly, we have 4 (!) separate pieces of unit calculation code... Ciao, Johan

5 8

Debian Squeeze build issue
by Nicolas Dufour 18 Feb '12

18 Feb '12

Hi again, I've just found out that Inkscape no longer compiles on Debian Squeeze (Crunch Bang Linux variant, with back-ports), Inkscape trunk revision 10990. It fails on the first file with the following message: ----- CXX arc-context.o In file included from /usr/include/glibmm-2.4/glibmm/balancedtree.h:29, from /usr/include/glibmm-2.4/glibmm.h:83, from ./io/inkscapestream.h:14, from ./xml/repr.h:24, from display/canvas-grid.h:15, from sp-namedview.h:26, from arc-context.cpp:30: /usr/include/glib-2.0/glib/gtree.h:28:2: error: #error "Only <glib.h> can be included directly." ----- Last time it compiled correctly was with revision 10962 (I use it on a rather slow netbook that is not updated it as regularly as my other computers or VMs...) Squeeze uses libgk2-2.20.1 and libglib2-2.24.2 . Maybe it's too old for the trunk? Regards, -- Nicolas

6 14

Inkscape 0.48.3
by Ted Gould 17 Feb '12

17 Feb '12

Happy to announce the 0.48.3 release of Inkscape being out the door. Of course this is only the source release, binaries will be along shortly. You can find the LP milestone here: https://launchpad.net/inkscape/0.48.x/0.48.3 Which reports 68 bugs as Fix Released, from 18 different assignees. Both impressive numbers. There are files on that page but also at SourceForge here: http://sourceforge.net/projects/inkscape/files/inkscape/0.48.3/ For the paranoid I've also included hashes of the files on my system, love you paranoids! == MD5 == 9038961369c4f8b63e900ca4bfa4da61 inkscape-0.48.3.tar.bz2 4b88d6220b491e94366c2365b90d36cc inkscape-0.48.3.tar.bz2.asc 4623e6be4d4553d7c871b26454de88db inkscape-0.48.3.tar.gz c97bb53225556cf704ca1d2cad4b654f inkscape-0.48.3.tar.gz.asc 2669679a121def72577184c8691f4209 inkscape-0.48.3.zip cedf6bc858ff63d54c0659eaabd2ddba inkscape-0.48.3.zip.asc == SHA1 == 7de7f5cb28d7407a891f02a3cfcfbff962bc3f9f inkscape-0.48.3.tar.bz2 531349ebbcbde497b419b86b14b8f4588e5f592b inkscape-0.48.3.tar.bz2.asc 937c1376bb0d9c00b22b88525826257d67ce237b inkscape-0.48.3.tar.gz e90e00e75a1af5ec0ef9736ebcff843e5def9a5b inkscape-0.48.3.tar.gz.asc 048e65843d61a70858966068a1c98f3e3a8667b6 inkscape-0.48.3.zip eb65f197135c48acfa274f3a16a93761c30b3562 inkscape-0.48.3.zip.asc --Ted

6 7

does devlibs need libgcc_s_dw2-1.dll ?
by alvinpenner 17 Feb '12

17 Feb '12

I was updating my devlibs from rev 24 to rev 27, on Windows XP, tdm-gcc-4.5.1. After recompiling Inkscape the compiler gave me an error message saying it could not find libgcc_s_dw2-1.dll. I could not find this in devlibs or mingw32 so I copied a version from a Gimp 2.0 installation and it appears to work. Will this file need to be in devlibs or is this a peculiarity of my machine? tia, Alvin -- View this message in context: http://inkscape.13.n6.nabble.com/does-devlibs-need-libgcc-s-dw2-1-dll-tp436… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

8 35

btool compile error on windows
by Susan Spencer 17 Feb '12

17 Feb '12

In compiling Inkscape for Windows vista Home SP2, in response to the 'btool' command, I received this error message: make error line 0 ： cannot open the file 'C:\devlibs\lib\pkgconfig\gtkmm-2.4.pc' Adding the DEVLIBS_PATH fixed this problem, ran btool again, but received similar message for mingw, adding the MINGW_PATH environment variable fixed this problem as well. How to: In Control Panel/System/Advanced System Settings/Advanced Tab/Environment Variables: 1. click New, type DEVLIBS_PATH in Variable Name, C:\<path>\devlibs in Variable Value, click OK ...(individual paths may vary) 2. click New, type MINGW_PATH in Variable Name, C:\mingw32 in Variable Value, click OK 3. click OK, close control panel, etc. 4. run btool again 5. play skyrim while it grinds - susan

2 3

Re: [Inkscape-devel] Powerstroke requests
by Valerie 17 Feb '12

17 Feb '12

Alright, I've made a bug report: https://bugs.launchpad.net/inkscape/+bug/933928 Now that you mention it, you're right, the bug also shows up with Pattern along Path and such. While we're on the topic of powerstroke, I'd like to suggest having multiple styles of powerstroke available from the drop-down, which means users wouldn't need to open the LPE dialogue at all. This means different end styles, different cusp node styles etc. I'm at a loss as to how they'd be named though. Maybe we can at least have a "rounded" (rounded edges, rounded for cusp nodes) and a "sharp" shape (everything sharp, a bit like for thin calligraphic strokes). Thanks for the tip by the way! I'm going for a different style, but it's useful. Date: Thu, 16 Feb 2012 20:51:07 +0100 From: Johan Engelen <jbc.engelen@...2592...> Subject: Re: [Inkscape-devel] Powerstroke requests To: inkscape-devel(a)lists.sourceforge.net Message-ID: <4F3D5E2B.2050701@...2592...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 26-1-2012 16:59, Valerie wrote: > Weird behavior to report: > 1. Make a powerstroke (example: triangle in) > 2. Make a duplicate (ctrl+D) > 3. Move some of the nodes of the second powerstroke > 4. Modify the width of the second powerstroke > > Behavior: the width of the first powerstroke gets modified as well. > > This does not happen if you select and move the second > powerstroke with F1 before modifying its width. > This does not happen with ctrl+C. This is a more general bug that duplicating does not fork LPEs. There is a setting for forking behaviour for gradients, so I will have to add it for LPEs too. Perhaps if I forget about it too long, you can add a bug report about it and assign it to me... > I was trying to trying to do easy eyelashes by making one > powerstroke the shape I wanted, duplicating it, moving the end > slightly and modifying the width slightly (to have a bit of variety). > I was also trying to do some sketchy effects with the same > method. You can also do eyelashes with the stitch sub-paths effect (and paste an eyelash shape as stitch path). But then you cannot do width variations... perhaps a good addition to stitch sub-paths LPE... Cheers, Johan*******************

1 0

Re: [Inkscape-devel] Powerstroke requests
by Valerie 16 Feb '12

16 Feb '12

Weird behavior to report: 1. Make a powerstroke (example: triangle in) 2. Make a duplicate (ctrl+D) 3. Move some of the nodes of the second powerstroke 4. Modify the width of the second powerstroke Behavior: the width of the first powerstroke gets modified as well. This does not happen if you select and move the second powerstroke with F1 before modifying its width. This does not happen with ctrl+C. I was trying to trying to do easy eyelashes by making one powerstroke the shape I wanted, duplicating it, moving the end slightly and modifying the width slightly (to have a bit of variety). I was also trying to do some sketchy effects with the same method. Any clue?

2 1

Windows version messed up in lcms.h and color-profile.cpp
by LucaDC 16 Feb '12

16 Feb '12

Even after a clean build, I get these errors (rev 10983, Windows XP): Make error line 289: problem compiling: In file included from src/color-profile.cpp:30:0: c:\devlibs/include/lcms.h:196:0: warning: "ZeroMemory" redefined [enabled by default] c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/winbase.h:1348:0: note: this is the location of the previous definition c:\devlibs/include/lcms.h:197:0: warning: "CopyMemory" redefined [enabled by default] c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/winbase.h:1346:0: note: this is the location of the previous definition c:\devlibs/include/lcms.h:212:0: warning: "LOWORD" redefined [enabled by default] c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/windef.h:131:0: note: this is the location of the previous definition c:\devlibs/include/lcms.h:213:0: warning: "HIWORD" redefined [enabled by default] c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/windef.h:132:0: note: this is the location of the previous definition In file included from src/color-profile.cpp:30:0: c:\devlibs/include/lcms.h: In function 'void* _cmsMalloc(size_t)': c:\devlibs/include/lcms.h:1410:16: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] src/color-profile.cpp: In static member function 'static std::vector<Glib::ustring> Inkscape::ColorProfile::getBaseProfileDirs()': src/color-profile.cpp:824:55: error: invalid conversion from 'cmsUInt32Number* {aka unsigned int*}' to 'PDWORD {aka long unsigned int*}' [-fpermissive] c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/icm.h:319:13: error: initializing argument 3 of 'BOOL GetColorDirectoryW(PCWSTR, PWSTR, PDWORD)' [-fpermissive] Regards. Luca -- View this message in context: http://inkscape.13.n6.nabble.com/Windows-version-messed-up-in-lcms-h-and-co… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 5

sp-conn-end.cpp specialist in the room?
by Kris De Gussem 16 Feb '12

16 Feb '12

Hi all During another round of cppcheck, I stumbled upon some weird code in sp-conn-end.cpp. Can someone have a look at line 77 to 85? This block of code does not seem right (why is for-loop variable i used again as for loop variable in a sub loop?): ------------- for (Geom::CrossingSet::const_iterator i = cross.begin(); i != cross.end(); i++) { const Geom::Crossings& cr = *i; for (Geom::Crossings::const_iterator i = cr.begin(); i != cr.end(); i++) { ------------- Regards K.

2 1

Problem with the following SVG
by Gerben Wierda 14 Feb '12

14 Feb '12

The following SVG can be correctly exported to a bitmap, but it cannot correctly be printed on Windows and not correctly translated to PDF on either Windows or Mac.

2 2

UI related
by Josh Andler 14 Feb '12

14 Feb '12

Hey all, As mentioned in the past regarding wanting better UIs for Filters and LPEs, here's another vector app that is based around things operating in "nodes" to take a look at. http://beta.nodebox.net/ And here's some basics from their documentation about: http://beta.nodebox.net/documentation/tutorial/getting-started.html I'm not saying that their overall UI is desirable, but I think there's something that can be learned from pieces of it. Cheers, Josh

1 0

Google Summer of Code
by Josh Andler 14 Feb '12

14 Feb '12

Hey All, Any volunteers for possible mentors? When/if we apply later this month, it would be good to know how many potential students we could handle. Cheers, Josh

3 3

My involvement with the project
by Josh Andler 13 Feb '12

13 Feb '12

This is related to the discussion over the past couple days. I have decided that I will fulfill my commitments surrounding releasing 0.49.0 and GSoC 2012. However, I will most likely be less active on the mailing list, and less involved in general until those commitments have been fulfilled. I will reassess how I feel about continued involvement with the project at the time that those commitments have been fulfilled. For the time being I will remain on the board, but will likely step down later this year in favor of "new" blood getting in there. Cheers, Josh

2 1

Ubuntu LTS feature freeze deadline
by Alex Valavanis 13 Feb '12

13 Feb '12

Hi All, Just a quick reminder that Ubuntu 12.04 LTS hits its feature freeze deadline on Thursday 16 Feb. It will be pretty difficult to update the Inkscape package after that deadline, so it would be great if we can push ahead with the 0.48.3 source tarball in the next day or two. I can quickly submit an updated package for review as soon as this is done. Thanks, Alex

2 2

Problem with the following SVG
by Gerben Wierda 13 Feb '12

13 Feb '12

The following SVG can be correctly exported to a bitmap, but it cannot correctly be printed on Windows and not correctly translated to PDF on either Windows or Mac. (I did not see it coming through with the attachment, so here is the SVG attachment in plain text) <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" version="1.1" width="43.82cm" height="51.92cm" viewBox="0 0 4382 5192" preserveAspectRatio="none" id="svg2" inkscape:version="0.48.2 r9819" sodipodi:docname="Total view for [rs6sv054_k0bbbd01] Oracle RDBMS (Artifact).svg"> <metadata id="metadata1049"> <rdf:RDF> <cc:Work rdf:about=""> <dc:format>image/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> <dc:title></dc:title> </cc:Work> </rdf:RDF> </metadata> <defs id="defs1047" /> <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="1217" inkscape:window-height="1292" id="namedview1045" showgrid="false" inkscape:zoom="0.5" inkscape:cx="838.10578" inkscape:cy="790.69214" inkscape:window-x="0" inkscape:window-y="0" inkscape:window-maximized="0" inkscape:current-layer="svg2" /> <g id="g22" transform="translate(5.6444446,-705.55559)"> <defs id="defs24"> <pattern id="pattern6" patternUnits="userSpaceOnUse" x="90.00" y="870.00" width="540.00" height="180.00" patternTransform="translate(0.000000,0.000000) scale(1.000000,1.000000) translate(-90.000000,-870.000000)"> <g style="fill-opacity:1.00;stroke:none;" id="g27"> <rect style="fill:#b4ff00" x="0.00" y="0.00" width="180.00" height="180.00" id="rect29" /> <rect style="fill:#b4b400" x="180.00" y="0.00" width="180.00" height="180.00" id="rect31" /> <rect style="fill:#ffff00" x="360.00" y="0.00" width="180.00" height="180.00" id="rect33" /> </g> </pattern> </defs> <g style="fill:url(#pattern6);stroke:#000000;stroke-width:2.6500001" id="g35"> <path style="fill-rule:nonzero;stroke-linejoin:bevel" d="m 630,915 0,135 -540,0 0,-180 495,0 45,45 -45,0 0,-45 z" id="path37" inkscape:connector-curvature="0" /> </g> </g> </svg>

2 1