January 2008 - Inkscape Devel

feImage filter progress
by Felipe Sanches 24 Jan '08

24 Jan '08

feImage renderer is working properly for images. Getting graphics from other svg elements is still not implemented Nicholas, could you work on the UI for this filter primitive, please? If you wish to do so, I suppose that it could be easier to construct it completely and just leave the svg element settings hidden, so that, as soon as we have the renderer working for svg elements too we can simply .show() this half of the feImage settings UI The reason why the renderer still does not work for svg elements is because I don't know how to get the NRPixBlock from an element given its id attribute. Maybe somebody here could help me on this? Juca

4 9

BUG HUNT - Dec 29 Scoreboard
by Bryce Harrington 24 Jan '08

24 Jan '08

Over a quarter of the way to our goal! Pts BugID Assignee Description ------------------------------------------------------------------------ 3 171593 Diederik Snapping menu items and shortcuts 3 168912 Johan Engelen axonometric grid angle changes with... 12 168588 Johan Engelen assertion failed, file sp-conn-end.cpp 3 171783 Bulia Byak rclk on palette should change outline color 3 171710 JonCruz Sum color dragging color inother 3 171292 --- Transparency reduced pdf export 9 168865 Johan Engelen Crashes applying "Path along path" effect... 3 171803 Johan Engelen Angled Guidelines! 12 168570 Johan Engelen Crash when recreating grid using 'redo' 9 178004 Max Albert assert when saving as plain svg 3 170374 --- perspective/warp transformation envelope 6 168574 --- Grid setup truncate significant figures 12 178803 theAdib Save As... -> filetype "PDF via Cairo" crashes 9 178312 Diederik Global 'Enable snapping' option non-functional 9 177891 Johan Engelen feGaussianBlur crashes when setting fill paint 9 174475 Niko Kiirala feImage renderer crashes on non-external image 12 167416 Diederik Shrinking a pattern causes lock-up 9 172778 Johan Engelen Grid settings not respected when reopening doc 6 167640 Bryce Escaped HTML chars - tooltips show incorrectly ------------------------------------------------------------------------ 135 Goal: 500 http://people.ubuntu.com/~brian/project-graphs/inkscape/plots/inkscape-mont… Note: Points are not given for bugs fixed as invalid, dupe, or worksforme, and only for issues that require code changes to fix (not website, translation, or documentation changes). Note: Scoring for bugs is based on their Importance: Crit=12, High=9, Med=6, Low=3, Undecided=3, Wishlist=3.

4 15

inkview can't show text blur and the cause of it
by Lingtao Pan 24 Jan '08

24 Jan '08

Hi, all: Inkview in front revision can't show text blur correctly. I traced the problem and find that in main() sp_document_ensure_up_to_date (ss.doc); should be put before ss.view = sp_svg_view_widget_new (ss.doc); not after. Otherwise the 'layout' member of SPText will have wrong value. And consequently, the 'item_bbox' will not be set correctly. By the way, I'm from China, and have been using Inkscape for more than one year. Usually, I use inkscape to design slides, and use inkview to show them.

2 2

Inkscape.org Drupal theme mockups needed
by Bryce Harrington 24 Jan '08

24 Jan '08

Hi all, The next item on our infrastructure todo list has been to move the website over to Drupal. Inc is about ready to turn on the code, so next we'll need a Drupal-ified website theme. It's amazing that despite three facelifts since Inkscape started, we've essentially kept the same underlying PHP bones of our website. Unfortunately, as we've grown they've exhibited some problems: 1. Contributors must know SVN to add to or update the website 2. New content must be created in PHP 3. To roll out changes you need an SSH account on inkscape.org 4. Our news/rss setup is limited in features and breaks often 5. Due to the above, the site's content has gotten pretty stale I'm very hopeful about our change, and think we'll be able to solve these issues well. In the year since we picked Drupal as the successor, I've been using Drupal to run my own personal website, and am finding it to be both easy to use, and very flexible and powerful. So the plan going forward is: A. Set up a demo site for folks to learn Drupal B. Test out Drupal's localization capabilities C. Start work on building up the site's content D. Design a new theme for the website E. Once we're ready/happy, cut over to the new site We will be targeting the new Drupal 6.0 (currently in beta). Localization - one of our most critical requirements - has been a top focus for Drupal 6.0 development, so I'm sure it will meet our needs, but we need to test it thoroughly, to ensure our translators will be comfortable using it. Regarding the content, I don't have any huge plans. As far as I'm concerned, we could move all the content into the wiki and manage it there. However, I've really enjoyed working in Drupal, and suspect that once people gain comfortability with it, they'll naturally want to build up content in it. But at this point, the news blog is my principle concern. Now, for the website theme and look and feel, this is a good opportunity for us to explore some new ideas (even including sticking with our current look and feel, just Drupalifying it to fit Drupal's new capabilities). What we're looking for at this point are mockups that work with Drupal 6.0. If you're feeling creative, and wish to learn about making Drupal 6.0 themes, why not give it a shot? Information on creating Drupal 6.0 themes is available here: Theme Guide: http://drupal.org/node/171179 (under development) Porting Themes: http://drupal.org/update/theme When you have a theme ready to propose, package it into a tarball and email it to Inc: inc@...1773... Inc will add it to the demo site so folks can try it out as they work on content. Later on in a few months, right before we make the site switch, we'll hold a vote to select the best theme to be our default. Depending on if we get enough contributions, we can include the 2nd and 3rd place submissions as alternate themes. Bryce

3 2

Native File Dialogs for Windows are finally ready!!!
by Joel Holdsworth 24 Jan '08

24 Jan '08

Hi All, I'm happy to announce, after all this time, that my native file dialogs for windows are now ready. I cannot believe how long it's taken to get them right, but they're working properly now - without needing any extra dependencies in the end. With the exception of the preview pane, the end result looks pretty unremarkable, but then that's the point of a native dialog! - I certainly wouldn't have believed the lengths it would be necessary to go to implement this. I might not have embarked on the project if I'd know, but it's done now. I guess it's too late to add this patch to the .46 release, but my NativeWin32FileDialogs branch is ready to be merged at an appropriate time. Take a look, if you're interested, or take a look at the attached screenshot. The only reason we might want to merge before .46 is that the patch will at the very least close these three bugs. #167795 "Windows fails to enforce Security Policies for drives access" #166158 "WIndows Shortcuts not visible in file dialogs" #166814 "Win32: Open/Save dlgs cannot cope with multi-monitor setups" Thanks Joel

6 17

Re: [Inkscape-devel] cannot compile r17091
by Guillermo Espertino 24 Jan '08

24 Jan '08

I'm trying to compile r17131 and have problems with tar-pax I'm using Ubuntu Gutsy and it compiled correctly before 17091. Since that I couldn't compile anymore. First I had automake 1.9, but I didn't even start (it asked for other version of automake). I removed 1.9 and installed 1.8.5 and it apparently started, but it returned this when running autogen.sh: ============================================================================= When you report a trouble about building SVN version of inkscape, Please report following information about distro and tools version, too. --1. distribution------------------------------------------------------------ Debian GNU/Linux release lenny/sid --2. tools------------------------------------------------------------------- /usr/bin/m4: m4 (GNU M4) 1.4.10 /usr/bin/autoconf: autoconf (GNU Autoconf) 2.61 /usr/bin/autoheader: autoheader (GNU Autoconf) 2.61 /usr/bin/automake: automake (GNU automake) 1.8.5 /usr/bin/automake-1.7: automake (GNU automake) 1.7.9 /usr/bin/automake-1.8: automake (GNU automake) 1.8.5 automake-1.9: not found /usr/bin/aclocal: aclocal (GNU automake) 1.8.5 /usr/bin/aclocal-1.7: aclocal (GNU automake) 1.7.9 /usr/bin/aclocal-1.8: aclocal (GNU automake) 1.8.5 aclocal-1.9: not found /usr/bin/intltoolize: intltoolize (GNU intltool) 0.36.2 /usr/bin/gettextize: /usr/bin/gettextize (GNU gettext-tools) 0.16.1 --3. environment variables--------------------------------------------------- LD_LIBRARY_PATH=/usr/lib WINDOWPATH=7 GDM_LANG=es_AR.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=es_AR.UTF-8 ============================================================================= I am testing that you have the required versions of autoconf, automake, glib-gettextize and intltoolize. This test is not foolproof and if anything goes wrong, there may be guidance in the file HACKING.txt checking for autoconf >= 2.52 ... yes (version 2.61) checking for automake >= 1.7 ... yes (version 1.8.5) checking for glib-gettextize >= 2.0.0 ... yes (version 2.14.1) checking for intltool >= 0.17 ... yes (version 0.36.2) Running aclocal ... Running autoheader ... Running automake --copy --force --add-missing ... configure.ac:12: option `tar-pax' not recognized Please fix the error conditions and try again. ------------------ If I try to run make clean before running autogen.sh, it complains about tar-pax too. Any advise to workaround this? Regards, Gez.

5 5

about screen licensing issues
by Felipe Sanches 23 Jan '08

23 Jan '08

I have seen on the winner about screen metadata that it is marked as "proprietary". I can see no citation about free content licensing on its page at devianART and I also notice that there was no requirement for free content licensing on the contest rules. This could lead to problems on packaging for debian and other gnu/linux distributions that have strict rules about licensing. I think that we should add this requirement on the next contest. We should also verify which license does needcoffee intend to use on his work (same is true for the #2) and update the SVG metadata. Juca

6 12

Batch export feature request
by Brian Vanderburg II 22 Jan '08

22 Jan '08

Simple request, I think it would be nice to support 'relative' exports when doing a batch export such that the 'inkscape:export-filename' paramters is relative to the location of the saved document. I <g id="item1" inkscape:export-filename="../images/item1.png" ...> and the file is saved as c:\documents and settings\allen\my documents\gfx\svgs\test1.svg, then it would save it as c:\documents and settings\allen\my documents\gfx\images\item1.png. But if I move the document or save elsewhere, it will export relative to that new location. In this case the export-filename could perhaps be in a 'universal' format that would work no matter what system it is on unix or windows path seperators don't matter. Just an idea. Brian Vanderburg II

1 0

zh_CN - Translation Patch in Launchpad
by ryan lerch 22 Jan '08

22 Jan '08

A zh_CN translation update for inkscape has been submitted to Launchpad. I was not sure if the translators that have SVN access check the bug tracker... https://bugs.launchpad.net/inkscape/+bug/184734 cheers, ryanlerch

2 1

translatable about screen
by Felipe Sanches 22 Jan '08

22 Jan '08

Today I was wondering about how to make the about screen more easily translatable. I figured out that the main problem is that text and effects applied to it are stored as curves. Maybe if we could use raw text and apply filters to it, then translators would have an easier task. This made me try to implement the mirrored reflex effect that we can see in the 0.45 about screen using filters. This is what I came up with: (1) feImage xlink:href=#(gradientrect) (2) feDisplacementMap input=SourceGraphic and displacement map=(1) <-- makes the mirrored reflex (3) feComposite input1=(2) input2=SourceGraphic <-- adds the original image to it apply a linear gradient to the rect whose id is gradientrect This gradient must be setup so that it mirrors the source graphic when applied to feDisplMap We probably would need to have an additional primitive on this stack, in order to alter opacity in the reflex Unfortunately, we don't have feImage working yet. Maybe there is another way of implementing this. And it also remains the problem of having to depend on system available fonts Anyway, this is just brainstorm :-D This also brings to discussion the general question about tools to make easily translatable drawings using SVG. Juca

2 1