- Inkscape Devel - Inkscape Mailman

View option: skeleton-only mode?
by Valerie 04 Jul '08

04 Jul '08

It's great that the easy pattern-along-path functionality is already being implemented! Now is it possible to implement a view mode that turns all the LPE effects off and only show skeletons? The reasoning is the same as with outline mode: rendering speed. Some complex shapes may be quite complicated and take a long time to re-render every time, especially if one is only seeking to edit the skeleton. In fact, skeleton-only could be an option of outline mode. The biggest conflict is with Spiro lines, since users treat those as "normal" lines and not LPEs, thus probably don't want them to suddenly disappear. I'm not sure what can be done about this, save either making an exception for it (preference option?), or eventually implementing "native" Spiro splines despite them not being part of the native svg specifications.

1 0

Status update, take 2
by Maximilian Albert 03 Jul '08

03 Jul '08

Hi all, here is finally an update on my recent work. Note that this refers to the status of the project about two weeks ago. Most of what I have done in the meantime is not finished yet and, alas, was further delayed by my missing internet connection during last week and the serious build problems I have encountered afterwards (see different thread). As far as this work-in-progress is concerned, I'll outline it in a separate email to keep this one at a moderate length. Here is what's new: - A couple of new LPEs: * circle through 3 points * angle bisector * parallel to a line (it only uses start and end point of the path) * rotate copies (similar to tiled clones) * offset (in progress, see next email) - The pen context can now be put into a new internal state in which it waits for a specified number of mouse clicks, then creates a path from these clicks (by default only polylines are allowed but this is configurable) and either applies a new LPE of given type to the newly created path or passes the new path as a parameter to an existing LPE. This infrastructure is currently planned to only be used under the hood. Its full potential will become clear when we have a better UI for the new geometric LPEs. At the moment you can give it a try in two ways. Either apply the "mirror reflect" LPE to a path - it then waits for two mouse clicks which specify the mirroring line and only applies the LPE after these have occcurred. Or press Shift+C/B/A in pen tool, which activates one of the three LPEs "Circle through 3 points", "perpendicular bisector" or "angle bisector". Each of these waits for mouse clicks and then applies the LPE to a new path created from these (you will notice that you can only create polylines, which is reasonable for these kinds of constructions). - LPEPerspectivePath has a new handle to control the offset of the path (it's not ideal yet but better than tweaking the values manually). - LPEs can now choose to display or hide the original path. Boilerplate code for setting this option as well as for creating custom knotholder handles were added to lpe-skeleton.(h|cpp). - For each PointParam of a LPE, a knotholder handle is now automatically created (a separate status bar tip can be provided, otherwise the tooltip is reused). This made the clumsy "edit on-canvas" button in the LPE dialog obsolete. If you want to see it in action, "Lattice Deformation" is probably the LPE where the benefits of automatic handles are most visible. :) - Each LPE can now display custom helper paths (similar to how the original path is displayed in node context). Just like handles for PointParams, these helper paths are automatically created for PathParam parameters. Again, "Lattice Deformation" is a good illustration. It displays a (very rudimentary) grid joining the lattice points. In the course of implementing custom helper paths, the framework also was reworked to make live updating of paths faster, among other things (though this can probably still be optimized). Known bug: The helper paths are not live-updated during dragging, and sometimes old ones don't vanish. This used to work properly, but it needed to be switched off due to the "green fish problem" which occurred last week (sorry for the hassle with it, BTW). It will be sorted out soon. More soon. Cheers, Max

4 3

Hackontest dev's
by unknown＠example.com 03 Jul '08

03 Jul '08

Hi all, If you are interested in participating in Hackontest, please register yourself at www.hackontest.org and click on the "agree to implement" button next to projects you'd like to work on. IMPORTANT: At the moment, there are no project proposals in Inkscape with at least 4 developers, which means we are out of the running! So, even if you are not 100% sure you can make it, please sign up for it; or at the very least, make a vote :) There may even be funds to get a developer over from the States, so if you want to see a beatiful and nice city in Europe... this holds especially for the developers out there with Inkscape "Hero" status!! Thanks a bunch, Cheers! Johan

2 1

GSoC Unit test suite update
by Jasper van de Gronde 03 Jul '08

03 Jul '08

The utest tests are now converted to CxxTest tests and you can build all the CxxTests on Windows. To build (and execute) them on Linux you still just do "make check", to use them on Windows build the linkcxxtests target and then execute cxxtests.exe (which is put in the build directory). You should execute it from the inkscape directory, as it needs a lot of dll's, unless you have the right dll's available in your path. Unfortunately the new CxxTest tests do not build under Linux yet. (With a bit of luck this will be remedied within one or two days, I'm currently doing a test build of Inkscape with some changes to add helper/units-test.h to make check.) I also made some new tests from scratch in CxxTest format. The test file for svg-path was committed some time ago and there are some tests for svg-affine and svg-length now as well (the latter doesn't have a lot of tests yet though). The test executable generates three types of output: 1. Its progress is written to stdout 2. A log is kept in text format 3. A log is kept in xml format The last two are put in the same directory as the cxxtests executable. Finally, the results of the tests themselves: - Two of the existing CxxTest tests (AttributesTest::testAttributes and DirUtilTest::testBase) fail on my system(s). - A test converted from the utest framework also fails (BezierUtilsTest::testBezierPt1). - Some of the new tests fail, but fortunately not in ways that would cause problems (for example, the current transform writing code outputs rotations and skews as a matrix instead of a rotate or skewX/Y, not wrong, but not very consistent/user-friendly either). Jasper

1 0

Vote for new functionality at www.hackontest.org
by unknown＠example.com 03 Jul '08

03 Jul '08

Hello all, A 24-hour contest to program new functionality into an opensource program? => www.hackontest.org Inkscape has registered for participation in Hackontest.org! http://www.hackontest.org/index.php?action=Root-projectDetail(97) This means we need your votes to find out which new functionality you'd like to see us code as quick as we can. Also, we need a lot of votes just to let the Hackontest organization know Inkscape makes you happy ;-) Cheers, Johan Engelen

1 0

Google Summer of Code(TM) 2008 Midterm Survey Approaches
by Aaron Spike 03 Jul '08

03 Jul '08

Attention all GSoC students and mentors, This is a reminder that midterm evaluation surveys open July 7th. Information about the surveys can be found at the links below. http://groups.google.com/group/google-summer-of-code-announce/web/midterm-s… http://groups.google.com/group/google-summer-of-code-announce/web/student-s… http://groups.google.com/group/google-summer-of-code-announce/web/midterm-m… I would ask that everyone involved reply to this thread so that Bryce and I can see that you are all awake and mindful of the survey deadline. This should give me a few extra days to track down awol participants. Remember these surveys are used to decide who receives t-shirts and money. If you are signed up as a mentor but not actively mentoring anyone, read the fine print you may still be eligible for a t-shirt if you complete the survey. Aaron Spike

7 7

Re: [Inkscape-devel] Import form openclipart
by Jakub Klawiter 02 Jul '08

02 Jul '08

Hello! :/ strange my gmail sent this message to pvt e-mail not to list probably. I'f i'm wrong excuse me for the dupe. > This is a bug on OCAL's side. We tried to find someone to fix it on > their side and we failed. It is very possible that I don't understand the real problem, but from my (user) point of view there are bug on both sides, as I wrote on previous message. Inkscape is importing *only one*, and always *only first* image uploaded to OCAL. And this is IMO a bug in Inkscape. If OCAL supports more than one version of image, and many of them can be SVG files, Inkscape should ask user which one (s)he want's to import. It is possible that somebody will upload a set called: "John Example" and inside you will find files: John Example (SVG) John Example Monochrome (SVG) John Example Manga Style (SVG) Rasterized John Example (PNG) Inkscape should ask what version of Mr. Example you want to import. You can say, ppl should not upload various version of picture into one "set". Maybe, but they probably will if they can, and IMO Inkscape and OCAL should work with this, because *software should be for users* not vice versa. Other bug in OCAL is that it can show thumbnail only if PNG file is first. Yes it is a bug in OCAL which maybe will be killed (a bug) someday. -- Pozdrawiam, Jakub. Milion osób dziennie pobiera Firefoksa... pobierz i Ty! www.firefox.pl

3 4

Startup crash (perhaps related to modified CFLAGS)?
by Maximilian Albert 02 Jul '08

02 Jul '08

Hi all, for a while now I have been compiling Inkscape with empty CFLAGS/CXXFLAGS, which greatly speeds up the build. Since last week, however, Inkscape consistently crashes for me during startup. I first thought this was caused by one of the recent SVN commits, but bisecting the history I was unable to identify any malicious commit because a single revision sometimes worked and sometimes didn't. It's still strange that the problem only seems to occur with revisions that are not older than one or two weeks. I have a separate SVN checkout on my hard drive which uses unchanged CFLAGS/CXXFLAGS (which I use when I need full debugging information). This one works without problems. Has anyone else seen similar crashes in the past, perhaps related to modified CFLAGS? I'd be very glad if someone could point me to a solution because development is severely slowed down with the increased compile times, and I've already spent several days just trying to recompile Inksacpe and finding that the crash is still there. Many thanks in advance, Max P.S.: Of course I tried 'make clean' but that didn't help. :(( Backtraces are worthless, too, since they read like this: #0 0xb74db9d7 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #1 0x00000000 in ?? () (as I said, debugging symbols are stripped off in these builds)

1 2

Re: [Inkscape-devel] OSX native compile error
by Matt Peterson 01 Jul '08

01 Jul '08

I don't know if it helps but because the menus are rendered by the OS I can get to the font dialog, and the font preview in that dialog renders just fine. Nothing in the actual interface does though. -- Matthew Peterson Programmer Christa McAuliffe Space Education Center On Sat, Jun 28, 2008 at 1:38 AM, jiho <jo.irisson@...400...> wrote: > > On 2008-June-27 , at 20:45 , Matt Peterson wrote: > > Installed versions of pango and cairo are (copied straight from macports): >> pango @1.16.5_0 >> pango @1.20.2_0+no_x11 >> pango @1.20.3_0+no_x11 (active) >> cairo @1.6.4_0+no_x11 >> cairo @1.6.4_1+macosx+no_x11 (active) >> As you can see, both of the active versions for cairo and pango have X11 >> disabled. I followed the instructions from >> http://www.inkscape.org/wiki/index.php/CompilingMacOsX >> under the "Compiling Inkscape with native GTK using MacPorts >> [experimental]" heading to the best of my ability. >> > > then I am not sure what to tell you. I haven't been trying this for a > while. I just remember hitting that problem before and finally solving > it.... but I don't remember precisely how unfortunately :( > If you look into pango options (in pango's code or in macports : port edit > pango) there is (was at least) a switch to specify rendering via cairo > instead fo freetype. The result is that fonts are smoother than in the X11 > version but that works. > I won't be able to check this more before 2 or 3 weeks. Keep me in copy of > your messages until then please. It is great that you work on this. > > > JiHO > --- > http://jo.irisson.free.fr/ > > >

1 0

Fwd: OSX native compile error
by Matt Peterson 01 Jul '08

01 Jul '08

Installed versions of pango and cairo are (copied straight from macports): pango @1.16.5_0 pango @1.20.2_0+no_x11 pango @1.20.3_0+no_x11 (active) cairo @1.6.4_0+no_x11 cairo @1.6.4_1+macosx+no_x11 (active) As you can see, both of the active versions for cairo and pango have X11 disabled. I followed the instructions from http://www.inkscape.org/wiki/index.php/CompilingMacOsX under the "Compiling Inkscape with native GTK using MacPorts [experimental]" heading to the best of my ability. -- Matthew Peterson Programmer Christa McAuliffe Space Education Center On Fri, Jun 27, 2008 at 1:22 AM, jiho <jo.irisson@...400...> wrote: > On Sun, Jun 22, 2008 at 12:02 AM, Bob Jamison <rwjj@...127...> wrote: > > I asked around, and nobody knew. What I would suggest, is that you > > try visiting irc.gnome.org, in the "#gtk+" channel. Since the native > OSX > > gtk port is still in development, this might be something that they > > would need > > to see. At any rate, that is where the experts in this area lurk. > > Matt Peterson wrote: > >> Putting that line into Inkscape didn't seem to help, although inkscape > >> is getting the change. I think it might be a problem with pango. The > >> errors I am getting are: > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GDEF table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GSUB table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GPOS table 28333 > >> > >> (inkscape:19764): Gtk-CRITICAL **: gtk_widget_show_all: assertion > >> `GTK_IS_WIDGET (widget)' failed > >> > >> (inkscape:19764): Gtk-CRITICAL **: gtk_box_pack_start: assertion > >> `GTK_IS_WIDGET (child)' failed > >> > >> (inkscape:19764): Gtk-CRITICAL **: gtk_widget_show_all: assertion > >> `GTK_IS_WIDGET (widget)' failed > >> > >> (inkscape:19764): GLib-GObject-CRITICAL **: g_object_ref: assertion > >> `object->ref_count > 0' failed > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GDEF table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GSUB table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GPOS table 28333 > >> > >> (inkscape:19764): GLib-GObject-CRITICAL **: g_object_ref: assertion > >> `object->ref_count > 0' failed > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GDEF table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GSUB table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GPOS table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GDEF table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GSUB table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GPOS table 28333 > >> > >> ** (inkscape:19764): CRITICAL **: gdouble > >> sp_document_height(SPDocument*): assertion `document->root != NULL' > failed > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GDEF table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GSUB table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: Error loading GPOS table 28333 > >> > >> (inkscape:19764): Pango-WARNING **: shaping failure, expect ugly > >> output. shape-engine='BasicEngineFc', font='Lucida Grande 12', text=' ' > >> > >> (inkscape:19764): Pango-WARNING **: shaping failure, expect ugly > >> output. shape-engine='BasicEngineFc', font='Lucida Grande 6.34765625', > >> text='5' > >> > >> (inkscape:19764): Pango-WARNING **: shaping failure, expect ugly > >> output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans Mono > >> 12.5', text='?' > >> > >> (inkscape:19764): Pango-WARNING **: shaping failure, expect ugly > >> output. shape-engine='BasicEngineFc', font='Lucida Grande 15', > >> text='No objects selected. Click, Shift+click, or drag around objects > >> to select.' > >> > >> Seems to me that pango isn't reading the font files right. > > These issues are indeed caused by Pango and the problem does not come > from note having bitstream vera sans (BTW, switching to Deja Vu sans > as the default would be a wise move since most new distros are using > this new version of the Bitstream fonts). > > If I remember well, the problem, for me, was that Pango was build by > MacPorts with an X environement in mind while, obviously, the rest is > X-free (no pun intended). So look for a no_x11 variant of Pango, or > something similar. Basically it must remove dependencies on X and > freetype and use Cairo to render the fonts. When Cairo is compiled > natively, it ultimately removes any dependency on X11. > The other possible issue is that font stuff changed recently in Cairo > and Pango and that some environement variables names related to fonts > may be different between the two. Which versions does MacPorts gives > you on your G4 on 10.4? > > I'll look a bit more into this when I am on my main machine. > > JiHO > http://jo.irisson.free.fr/ >

1 0