- Inkscape Devel - Inkscape Mailman

Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
by Wolf Drechsel 08 Apr '10

08 Apr '10

Hello everybody, I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle. When running the osx-dmg.sh, I get the message: osascript: dmg_set_style.scpt: No such file or directory In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently. Could somebody be so kind and mail me the script - or - in the case - guide me to another solution of that problem. Yours, Wolf

6 21

Document versioning (was: Coordinate system fix)
by Krzysztof Kosiński 08 Apr '10

08 Apr '10

W dniu 6 kwietnia 2010 18:31 użytkownik bulia byak <buliabyak@...400...> napisał: > 2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>: >> W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak >> <buliabyak@...400...> napisał: >>> This sounds inevitable, but rather hairy. Why have both >>> inkscape:version and inkscape:document-version? Can you get what you >>> need with inkscape:version only? >> >> 1. Document version changes must be atomic, because the upgrade is >> conducted only one time for each type of defect. This means >> inkscape:document-version (or inkscape:document-format) can change >> several times between two releases. > > But why can't we just fix ALL the defects we find between 0.47 and > 0.48 and have just two states of upgrade for <=0.47 and for >=0.48? The upgrade procedure must run exactly once for any document. This means that if we introduce a change in the interpretation of XML between revision FOO and FOO+1, then FOO+1 must perform the upgrade on documents saved in FOO and earlier, but it must also be smart enough not to upgrade documents saved with FOO+1. That's true regardless of how many defects are fixed in each version or how many document formats there are. This means the version number must be accurate down to a single revision, which is a bad idea for reasons I've already mentioned. If we have only the bare version number (e.g. 0.47 or 0.48), then anything saved in FOO+1 or later cannot be opened until we make a stable release. It would be possible to have the document format version number equal to the Bazaar revision in which it was first introduced. However, this would complicate working on the backwards compatibility fixes in branches. I think a simple number increasing from 1 would be the best way to go. This is hairy, possibly tedious to implement, etc., but at the same it's the long-term solution. Regards, Krzysztof

6 18

Bug Hunt Update - 93/300
by Joshua A. Andler 07 Apr '10

07 Apr '10

Hey all, Here is the current Bug Hunt scoring. I'm starting the count as of 3/29. Following past traditions, here is how it works: Scoring: Low: 3 pts Med: 6 pts High: 9 pts Critical: 12 pts Double if over one year old. Only fixes to "true bugs" (i.e. no website/translation/docs/etc. bugs). This list contains fixes between 3/29 - 4/7 @ 2:22pm PST. Pts BugID Fixer Description ------------------------------------------------------------------------ 3 520532 Kosiński Single app for GUI and console mode on Windows 12 215020 Kosiński Win32 - DOS/Command window pops up when... 12 168557 Jon Cruz Fill & Stroke dialog randomly stops updating.. 9 544833 Jon Cruz Crash in SVG font editor on "New" 6 541956 Kosiński comandline option don't work on win xp 6 522327 Daniel_J Inkscape 0.47 fails to build with GCC 4.5 3 554109 Kosiński unwanted printout of PYTHONPATH (Win32) 12 167455 Kosiński WinXP2: Command line file names not current... 9 551433 Kosiński inkex.py not found for extensions in user's... 6 553911 Jon Cruz Inkscape hangs when selecting CJK fonts in... 6 556233 Jon Cruz 'Rows and Columns' dialog fails when used... 3 548918 Alvin Penner HPGL output scaling incorrect 6 512447 Alvin Penner save as in DXF format fails in 0.47 ------------------------------------------------------------------------

1 0

GSOC proposal - Improve GUI for transformation center
by Zhenfeng Zhao 07 Apr '10

07 Apr '10

Hello, I appreciate all suggestions and technical details from you as to the “transformation anchor” project. I have summarized them into a proposal in the following. There is plenty of information for the project goal and plan. Later discussion, confirmation on tasks, and further input may help me to keep in the right track in the implementation. So far, the project and its tasks seem clear enough to me. And, according to my experience, I can see that this project can be done. As well, if there is any time left (I guess there would be), I would like to work on adjusting origin of document coordinates, and allowing math operations for spin boxes. The beginning of April is often the busiest time for students in Canada. It will be much better in the summer (May to August). Last year, I completed a 10+ page proposal for Gimp in the last day. This year, I am slightly earlier, after talking in Inkscape mailing list for half a month. Your feedback will be welcome and important. Then, I will submit the proposal very soon, or I will revise it there. Thank you very much. Regards, Zhenfeng. GSOC proposal - Improve GUI for transformation centers >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PROJECT SUMMARY (a longer abstract) There are some existing issues with selecting and modifying the transformation center. This project focuses on improving and modifying GUI for transformation centers to solve existing issues and enhance precision and flexibility. In the three month GSOC period, first I will discuss with Inkscape designers and decide a GUI mockup as an implementation guide. With the further analysis and detailed plan, possible refactoring will be done. A control of precision of moving the transformation center will be implemented. Center coordinates would be set numerically. There will be a 9-button-matrix widget that is used to quickly move the center to 9 positions, and a separate tab in the Transform dialog, for adding XY fields using a couple spin-buttons for X and Y. Then, the linkage between the 9-button-widget and the spin-buttons can be done. Another relevant projects will be analyzed and implemented (i) adjust origin of coordinates of document, and (ii) allow math operations (sum, substraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. All implementations will be tested and ensure accuracy, flexibility, and robustness. All code produced will follow the Inkscape coding style. Documentation will be done during coding. BACKGROUND AND SKILLS I am interested in working on the "transformation-anchors" project in GSOC this year. Inkscape is one of my favorite open source software. I have similar work before, to have the default rotation center to be the geometric center of all shapes. Anchor coordinates are a part of the object (drawing) attributes. It can be adjusted, so that geometrical transformations, rotation, translation, scaling, and shearing, can be performed with the updated center. The following is a few points about my background. · Master student in Computer Science (GPA: 4.0/4.0) in Canada, thesis: medical image processing and 3D reconstruction. · Successfully completed GSOC 2009 for a Gimp project, Advanced GUI for brush dynamics. · Four years full-time work experience in programming and architecture · Played key roles in technology R&D and innovation in image processing, vector graphics, 3D modeling, and CAD I have developed vector-based graphics editors both from scratch and on existing large applications. One of them is for a leading manufacturing company in Canada. For example, a graphics editor uses customized XML formats, have OOP architecture design to deal with all shapes/primitives using object classes (e.g. rectangle, ellipse, closed-path with arcs and lines, curves), and allow SVG and DXF (Solidworks drawing file) import and export. I have used Inkscape and SVG at work for one year (e.g. for SVG work, and GUI and HCI design example). One of my contributions for this software is to replace the previous raster based image editor with vector based editor using custom XML format. Every year, hundreds of customers use it for industrial designing, including NASA, Boeing, Google, Microsoft, MIT, US Army, GE, GM, Lockheed Martin, and many more. The company can product near anything that is made using the software. Meanwhile, the R&D goal was to provide the software that reflects what products can be made. Therefore, it is high level quality software that provides flexibility and precision. A few highlights of my work: · Completed the release of version 3.1 within 1.5 months of hire, with minimal input · “accomplished tasks the first day that took half a month before; amazing” – President · “The good news is, you are on the top.” – Chairman, in a review for R&D team performance Besides this software, I have developed dozens of image and video editors. When I worked as Lead Developer with 2D-3D Video Inc. for two years, I worked on image processing, and video editing software, and 2D to 3D image/video conversion. I have led the development of 3D movie player on iPhone/iPod Touch, and LG 42-inch 3D TV. The technology is used to convert image or video and generate 3D viewing effects without 3D glasses required. Sample work: 3D face of Barrack Obama. It is converted to 3D photorealistic view using a single 2D still face photo. http://www.2d-3dvideo.com/3Dphotos/BarrackObama.wmv Other: http://www.2d-3dvideo.com/NewSite/SchoolPhoto.wmv http://www.2d-3dvideo.com/3Dphotos/Couple.wmv http://www.2d-3dvideo.com/3Dphotos/33framerotation24degree.wmv http://www.2d-3dvideo.com/IDcards/male130BG40deg.wmv In my Master thesis research, I have had two publications, and will have couple more soon. I have developed new algorithms and techniques in image segmentations, interpolations, 3D reconstruction, and missing structure generation. Since the work deals with different shapes, it has a vector graphics sense. I used XML to store and process 3D structure and wireframes. Technically, I am good in C++. I have done some work using the following. XML: I have used it for many projects, using C++, Python, C# and Java. Libraries used: .NET, DOM, JDOM, Minidom. It is used in my thesis and each of my jobs at work. SVG: I have written a SVG viewer before. GTK+: I have experience with it in the Gimp GSOC project. Git and SVN: I used it at work before. Bazaar: I tried it, and it is very similar with SVN and Git. PROBLEMS AND IMPLEMENTATION PLAN A well designed GUI and interaction of transformation anchor manipulation is very important for Inkscape. Currently, the rotation center (in an example of transformation) can be dragged freely. However, where it is dragged to cannot be precisely defined, except eye-balling roughly. There needs to be new UI facilities with an intuitive design that allows the precise adjustment of the center. This precision control is expected to be useful to many Inkscape users, such as Xfig users. In the Transform dialog, XY fields need to be added as a separate tab. A 9-button-matrix widget, which is intuitive and helpful to users, will be implemented to assist moving the center among nine locations easily with one click. To prevent errors or misleading, there should not be center of rotation and anchor as two different entities. A single tool should be used, which is marked by the cross. Then, all transformations should refer to it. Since this object exists in the code, a list of better UI facilities can be added to move it. As well, the cross can be automatically saved into SVG for each object. A simple test was done to confirm this. The center of rotation, marked as cross, can be moved to a different location. It is saved for the object, so that when closing and reopening this SVG file, the cross (center of rotation) stays where it is left. In the SVG, the fields or attributes of the path object shows: inkscape:transform-center-x="7.6874748" inkscape:transform-center-y="-3.2402241" / Another quick test was done for moving the transformation centers. - For rotate and skew, different centers will give different results. - For scale, moving the center gives the same results, with the same transform values. - Transform using handles is correct. A simple drag keeps the center as it was, and Shift+drag scales around the rotation center. Obviously, there is an issue in the consistency with scaling. It does not work correctly if scaling by numbers. Selector toolbar, or the mouse tool in the top left interface, uses the top right corner, while Transform scales around the geometric center. The correct way is to use rotation center for scaling, with X/Y in selector toolbar displaying the coordinates of the center. The above issues will be fixed. The UI needed for rotation center XY coordinates is a couple Gtk-Spin-Buttons for X and Y plus a unit selector, defaulting to the document units. Since there is already the unit selector for X, Y, Height and Width, it may be used without writing a new one. After the 9-button-widget is used to move the X/Y coordinates, the spinbuttons should be updated to reflect the selection of one of nine anchors. Hence, the linkage is required for the 9-button-widget and the spinbuttons. It was pointed out that there were two other relevant projects related to this one: - adjust origin of coordinates of document - allow math operations (sum, subtraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. I believe that it would be more beneficial if I work on this two during GSOC. The main focus of the project is on transformation centers, and the above two will be analyzed and planned, when transformation center tasks are half way through. I will propose another implementation plan for them, with a reasonable class structure design/rewrite. I will work on the two after completing the transformation center project. If there is no time to finish all of these in three months, I will try to make sure on-going work is easy to do. After the three months of work, I may be interested to continue contribution. At some point later, it may become clear what can be done, when unknowns are solved. It was suggested that the math operations can be taken from GIMP 2.7.0+. It can be done easily with my previous experience in Gimp contribution. Taking code from open source is something that I have done for many times, both for Master thesis and at-work programs. Recently, I took some open source code of spline interpolations into my thesis. Translating math operations into C++ is doable too. I do porting of different languages on daily bases. TASKS AND TIME TABLE Goal: Improve GUI for transformation centers for precision and flexibility 1. Communication. May 10 – May 20. Communication with the mentor. Code review on relevant source code, class structure. 2. Studying. May 21 – May 25. Study Inkscape development workflow, coding style, committing process. Study libraries required. 3. Reaserch. May 26 – June 6 Analysis of the architecture. Discuss and decide a GUI mockup as an implementation guide. Get familiar with sample SVG files and GUI mock-up that Pajarico has. Preparing a list of implementation. Intuitive GUI design. 4. Coding and implementing. June 7 – July 17 Possible refactoring. Precision of center moving. Fix the issues for scaling around different centers. Allow setting the center coordinates numerically Add 9-button-matrix widget Add XY fields in a separate tab of the Transform dialog Implement XY coordinates UI, a couple Gtk-Spin-Buttons for X and Y. Ensure the linkage between the 9-button-widget and the spinbuttons. Display coordinates and values, take XY input from users, and allow undo and redo 5. Second stage implementation. July 18 – July 31. Further analysis of two relevant projects: 1) adjust origin of coordinates of document 2) allow math operations (sum, substraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. Have another implementation plan for them, with a reasonable class structure design/rewrite. Implement them. 8. Overall debugging, code optimization and further improvements. August 1 - August 10. 9. Further optimization. August 11 - August 15. 10. Documentation and clean up. August 16 - August 20. REFERENCES AND LINKS: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/inkscape https://bugs.launchpad.net/inkscape http://wiki.inkscape.org/wiki/index.php/InkscapeInvariants http://inkscape.org/bzr.php Note: I am also interested in a few other interesting projects: - Power Stroke - Modulated width stroke LPE. - xar-to-svg converter - Converter for Xara Xtreme to Inkscape - KML SVG translation - For use of Inkscape with Google Earth or Maps >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1 0

Problem of chatting in IRC
by Zhenfeng Zhao 07 Apr '10

07 Apr '10

Hi, I have a question about chatting in IRC. In windows, it did not work for me. So, I just tried XChat in Linux. Now I can see other people chatting in the channel. But I cannot send messages there. I have changed it to utf-8. #inkscape :Cannot send to channel Charset changed to: utf-8 Still, it shows: <ZZF_> hello * #inkscape :Cannot send to channel Also, some more messages below... Can anyone told me how to fix it, in order to chatting in the channal? Thank you. <ChrisMorgan> That is probably all you need, but if you need more, you could create a rectangle the size of the whole thing and apply it as a clipping mask. <ChrisMorgan> (Then everything else would need to be in a group) <kn100> so in other words there's no way to hide overflow at the design stage without changing how i work with the tool? * troy_s has quit (Quit: Leaving.) * vlada has quit (Remote host closed the connection) * Justicejr (~Justicejr@...2337...) has joined #inkscape <ZZF_> hello * #inkscape :Cannot send to channel Regards, Zhenfeng.

2 1

Coordinate system fix
by Krzysztof Kosiński 07 Apr '10

07 Apr '10

Hello In revision 9288 I fixed the inverted coordinate system bug, starting from a patch by Thomas Holder. https://bugs.launchpad.net/inkscape/+bug/170049 While this is a rather invasive change, fixing bugs caused by removing the coordinate inversion is simple (often it boils down to tweaking a single line of code), so I think we'll manage to fix any remaining regressions before the release. Regards, Krzysztof

16 52

Re: [Inkscape-devel] GSoC: KML <-> SVG Translation
by sjatkins＠...2336... 06 Apr '10

06 Apr '10

Oh dear, I really am no good at mailing lists. I accidentally emailed this to Krzysztof instead of the mailing list. Sorry! On 06 April 2010 at 17:49 "Krzysztof Kosiński" <tweenk.pl@...400...> wrote: > 2010/4/5 sjatkins@...2336... <sjatkins@...2336...>: > > Then, develop a command-line app that will actually do the conversion. I'll > > be > > using C++. I haven't decided on an XML library yet - any suggestions? > > You should use libxml2 and libxslt - that's what Inkscape uses. > However, it might be better to write an internal extension rather than > a separate command line application. Look at src/extension/internal/. > You can also consider using XSLT. Thanks, that's really helpful - I wasn't sure where in the codebase to look. Making it an internal extension does sound much better than an external application. I'm not very familiar with XSLT, and it's probably better to stick with C++ as I know it better. > > Once the command-line program is working, I'll start on giving it a GUI. I > > can't > > seem to find anything about what UI library Inkscape itself uses - can > > anybody > > tell me? > > It uses GTK+ and gtkmm. Again, look at existing input extensions - the > extension system should satisfy your GUI needs. You just put the > parameters you need in an .inx file and the GUI is created > automatically. > > Regards, Krzysztof I think I might not need to add a GUI if I do this as a extension, but if I do I'll use the extension system like you suggest. ~Sam

1 0

GSoC: KML <-> SVG Translation
by sjatkins＠...2336... 06 Apr '10

06 Apr '10

Hi everyone, I'm interested in applying to create an KML - SVG converter. KML and SVG are similar enough that it makes sense for there to be a way to convert from one to the other. My plan would be: >From now until the end of week 1 or 2: Study both formats and work-out the equivalents between KML and SVG. I know there are features of KML - namely, placemark descriptions, which will not convert directly to SVG. There are probably other features too. I'll try to deal with these in any time I have remaining at the end. I'll also need to work out a way to convert the coordinates systems, and deal with sizing the image - using the KML coordinates, the image would be very small, in a very large document. Then, develop a command-line app that will actually do the conversion. I'll be using C++. I haven't decided on an XML library yet - any suggestions? * Plan the structure of the program. * Focussing first on KML -> SVG, gradually add tags to convert, and check they work correctly. * Once KML -> SVG works, add SVG -> KML. Should be a case of reversing the existing conversion functions. * Write some usage documentation. Once the command-line program is working, I'll start on giving it a GUI. I can't seem to find anything about what UI library Inkscape itself uses - can anybody tell me? It would be better to use the same one, to make maintenance easier. The GUI will send commands to the command-line program, to keep the two separate, and so that Inkscape itself can use the command-line one at some point if needed. * Design the UI. * Implement it. * Write some user documentation. Deliverables: * A command line program that can convert SVG to KML, and back, successfully. * (Probably) A GUI to go with the command-line program. If I get time: * Allow importing/exporting as KML from within Inkscape. * Find ways of handling 'placemark' KML elements, and any others that do not convert easily to SVG, so that a user can convert to SVG, edit, and convert back, without losing anything. Possibly by including hidden elements in the SVG, or using comments. ----------------------- Is this a decent plan? Is there anything I've missed? ~Samuel Atkins

3 2

Remove Inkview?
by Krzysztof Kosiński 06 Apr '10

06 Apr '10

Hello https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/278001 Inkview is large (8MB) and doesn't do much. Does anybody use it? I think it should be removed. This would reduce the size of binary packages as well as installed size somewhat. Regards, Krzysztof

11 12

Question on Frost - is this a known issue?
by Jason Smith 05 Apr '10

05 Apr '10

I am new to Inkscape, but have been involved in some open source projects (mainly Java-ish stuff). I downloaded the latest Windows release and tried it out. I am wondering if this is a known issue, since it is so badly broken. (Inkscape April 3 drop, Windows Vista) I am trying to use a Wacom Bamboo tablet. Inkscape looks like it recognizes the tablet, but I can't seem to get it to work with the caligraphy tool. My tablet works with 0.47, after some fiddling. Additionally, there are two GUIs for setting up input hardware now. The old one looks like 0.47, and the new one looks very cool, but for the life of me I can't figure out how to make it work. And keep in mind, it could be user error - I am new to Inkscape. But I am thinking that a Wacom Bamboo tablet should "just work" with a drawing application... Sooooo... are the hardware input dialogs still "in-work"? If not, I'll be happy to provide details and screen shots. I just don't want to clutter your bug tracking system before checking. Thanks! Jason Smith

4 4