- Inkscape Devel - Inkscape Mailman

Fwd: SVGT 1.2 Implementation 'Test Fest' announced
by Alexandre Prokoudine 07 Jul '08

07 Jul '08

FYI ---------- Forwarded message ---------- From: Andrew Emmons <andrew.emmons at quickoffice.com> Date: Mon, Jul 7, 2008 at 2:24 PM Subject: SVGT 1.2 Implementation 'Test Fest' announced To: "www-svg@...157..." <www-svg at w3.org> Hello, The SVG Working Group will be holding a final 'Test Fest' for SVGT 1.2 implementations from September 29th to October 2nd. During this event, SVGT 1.2 implementations will be tested against a final test suite for the purpose of producing an implementation report. This report is critical in moving SVGT 1.2 to the 'Proposed Recommendation' track and should demonstrate that at least two interoperable and independent implementations exist for each feature of the specification. Details on the W3C process can be found here[1]. If you are an implementer and wish to join the 'Test Fest', please respond, privately if you wish, to this e-mail. Details for the meeting are still being worked out – specifically the location. It will be held somewhere in North America. Regards, Andrew [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfr Andrew Emmons Engineering Director, SVG Business Unit Co-Chair, W3C SVG Working Group Quickoffice, BitFlash Division www.bitflash.com, www.quickoffice.com

1 0

Trouble compiling a 0.46+devel release: lib2geom errors
by heathenx 05 Jul '08

05 Jul '08

I set up a virgin Ubuntu Hardy VM a couple of days ago so that I could use it as an Inkscape build environment for any of the 0.46+devel revisions. I'm only interested in compiling one of the recent SVN snapshots every once in a while just to check out some new features. I have only been able to compile revision 19107. I cannot get a more recent revision to compile due to lib2geom errors during the "make" command. I went out and found lib2geom and compiled it with cmake, make, sudo make install. No errors so I think it's good. I understand that the dev's are working on the latest and greatest stuff and probably shouldn't be distracted by people like me who have little understanding in compiling Inkscape in the first place but I feel like I'm so close. Is the lib2geom library very experimental at this time?...likely preventing me from compiling cleanly? Thank-you, heathenx

2 1

Unit tests for 2geom?
by Jasper van de Gronde 05 Jul '08

05 Jul '08

I'm converting the relevant (existing) libnr tests to 2geom as part of my GSoC project, now my question is where to put them? So far I've just put them in the 2geom directory of my local working copy and adjusted the build file in the same way as for the unit tests in the svg/ and libnr/ subdirectories for example. I imagine, however, that it might be better to add them to 2geom directly.

2 3

Color Export
by Cédric GEMY 05 Jul '08

05 Jul '08

I made somes test with scribus Team, and some troube as been revealed in CMYK handling in Inkscape export. If you have a pure black shape and export it in several format (AI, EPS, PS, PNG), only the AI export preserve the pure black. All the other result in a rich black (around C80%, M80%, 80%Y, K100%), which gives a 320 inking factor and we should not have more than 280 % in the worst case. Can someone confirm this. I tested on Mac OS, and can do the test with linuxes, but not under windows. pygmee

2 1

Discrepancies between 2geom's rotate and Inkscape's (libnr's) rotate
by Jasper van de Gronde 05 Jul '08

05 Jul '08

While converting some of Inkscape's libnr tests I found the following discrepancies between the two rotate classes: - Rotate(.234).inverse() != Rotate(-.234) in 2geom but not in libnr - Rotate(.234)*Rotate(0) != Rotate(.234) (idem.) - Rotate(0)*Rotate(.234) != Rotate(.234) (idem.) - b * Geom::Rotate::from_degrees(90.) != Geom::rot90(b) (idem.) My guess is that at least the first three have to do with how the rotation vectors are normalized. To me the most logical thing to do would be to eliminate the (in principle unnecessary) normalizations when computing the inverse of a rotation or when composing two rotations.

2 1

Changes to 2geom directory
by unknown＠example.com 04 Jul '08

04 Jul '08

Hi all, Thanks Jon for fixing the compile I apparently broke on Linux by updating 2geom, I am sorry. I just added a file saying not to change any code in Inkscape's 2geom copy. It is because we try to keep this directory a direct copy of 2geom's files. It is a lot of hassle to apply changes back and forth otherwise. If you really want to change Inkscape's 2geom code, please apply it to 2geom's SVN as well; otherwise your changes may very well be destroyed by the next update of Inkscape's 2geom copy. Another possibility is to commit your change to lib2geom first, then copy to Inkscape and commit the copy to inkscape. Thanks a lot, Johan

2 1

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