- Inkscape Devel - Inkscape Mailman

gtk theme and GTK2_RC_FILES
by jiho 29 May '07

29 May '07

Hello everybody, I am trying to add a default GTK theme to Inkscape (on OS X but the issue is probably generic enough). So I added the theme to an Inkscape specific directory and pointed the variable GTK2_RC_FILES to it and the theme is used. Fine. But I also want Inkscape to honor ~/.gtkrc-2.0 when it exists, so that the user can override the default gtk theme we'll ship if he/she likes to. GTK2_RC_FILES looks much like nay PATH variable with path element separated by semicolons, so I used: export GTK2_RC_FILES="/etc/gtk-2.0/gtkrc/:$TOP/themes/Default/ gtk-2.0/gtkrc:$HOME/.gtkrc-2.0" where $TOP is an Inkscape specific dir and $HOME/.gtkrc-2.0 points to a theme in $HOME/.themes which works and is used by Inkscape when GTK2_RC_FILES is not set. From the little I could find about GTK2_RC_FILES it looks like the order is inverted compared to PATH: the last argument prevails (and I've tried the other way around with the same result anyway). However, this does not use the theme defined in ~/.gtkrc-2.0, it still uses the theme in Inkscape's directory. So I could add a check for the existence of ~/.gtkrc-2.0 and define export GTK2_RC_FILES only if it does not exist but I was looking for a more generic solution and for the correct way to use GTK2_RC_FILES. Is someone knowledgeable enough with GTK to point me in the right direction? How do the Windows folks do: is it possible to override the default GTK theme on windows? Thanks in advance. JiHO --- http://jo.irisson.free.fr/

1 0

Re: [Inkscape-devel] [Inkscape-translator] Is this mailing list alive?
by Alexandre Prokoudine 28 May '07

28 May '07

2007/5/28, Leandro Regueiro wrote: > Sorry, but the last months I haven't received messages from this list, > is this mailing list alive? The list is having fun taking rest after 0.45 release while developers have fun adding new circles of hell (new rocking features) for us ;-) Alexandre

1 0

Undo Extrude trashes fill settings and deletes unrelated objects?
by Sak 28 May '07

28 May '07

Hey everyone, While working today I came across something that I wanted to run past you all to see about filing a bug. Forgive me, but I always hesitate to clutter bug databases without at least posting to see if anyone else can confirm an issue I'm running into. Here are the steps to reproduce. Given the attached extrudesample.svg file. Create a polygon or star. (I used the default setting for a star, but it also happens if you create a square, circle or any other object). Apply: Effects -> Generate from Path -> Extrude (Again default settings in the dialog that opens). Select Edit -> Undo (Ctrl-z). Notice how the highlight, blur, or other fill effects all disappear when you undo? If you redo the Extrude effect again they all reappear. I can reproduce this consistently on Inkscape 0.45, on Ubuntu 7.04. In this sample file there appear to be a couple of different things happening. Objects that have a gradient applied to them are deleted from the drawing. Objects that have a blur effect are retained, but the blur is removed from the object. The bug also doesn't seem to care if the objects are grouped, or not, or even if they're on separate layers. Notice the items in the reflection are on a layer named "reflection." Anyway, thanks for taking a look. If someone knows of a bug that already exists for this issue, I'll be happy to include this sample file for testing if one isn't already attached to the bug. Or I can file a new bug, but I wanted to run it by you all first to see what your thoughts are. Thanks, Sak.

1 1

Re: [Inkscape-devel] [Inkscape-user] Equivalent to Illustrator's Gradient Mesh?
by MenTaLguY 26 May '07

26 May '07

[CC:ing the -devel rather than the -user list] Hi Chris, Thanks for following up on this! > I'm not sure what to do about folding, where the triangles overlay > each other. Its hard to forbid it (but see below). The combination of non-full-scene antialiasing (as in many popular rasterizers like cairo) with self-overlapping shape presents some *extremely* difficult rendering problems with respect to alpha, to the point where I'd say it rules out any scheme permitting folding[1]. So, as far as the other scheme goes: > <colorGrid xml:id="foo" gridUnits="userSpaceOnUse"> > <dot dcolor="#27D" dopacity="0.5" x="12.7" y="3.5"/> > <dot dcolor="rgb(123, 254, 37)" dopacity="1" x="8.4" y="17.2"/> > <dot dcolor="#F0D" dopacity="0" x="3.2" y="14.1"/> > </colorGrid> How about: <mesh xml:id="foo" meshUnits="userSpaceOnUse"> <vertex vertex-color="#27D" vertex-opacity="0.5" x="12.7" y="3.5"/> <vertex vertex-color="rgb(123, 254, 37)" vertex-opacity="1" x="8.4" y="17.2"/> <vertex vertex-color="#F0D" vertex-opacity="0" x="3.2" y="14.1"/> </mesh> > This approach has some advantages: > - the xml is way shorter > - there is never any folding > - its simpler to author > - no messing about with ID and IDref to construct a linked data structure > - no chance of getting any of the links wrong > - adding a new point or deleting a point is stable and causes a local > change; the mesh is never in an invalid state > - animating x and y never produces overlap I consider all of these to be extremely desirable properties. I'd also add: - it has a very obvious user interaction model The interaction model offered by simply placing colored vertexes, letting the triangulation fall out naturally, is a LOT better than e.g. manipulating coons patches (as in Illustrator), which I've always found incredibly twiddly and tiresome to do. In Inkscape specifically, implicitly triangulated meshes could be handled by a very simple extension of the existing UI we have for gradients, where gradient stops are simply nodes on the canvas. > disadvantages > - implementation has to perform the triangulation. Although its not > very hard or computationally intensive. It's probably more of a people issue than a technical -- having developers on hand with the requisite experience. I've found it's harder than I'd expected to get people who are good with computational geometry stuff in general. But Delaunay triangulation is pretty well-understood and well-documented; by way of contrast, the boolean operations required by SVG vector effects represent a _much_ higher implementation burden than triangulation would. > - if you want overlaps/folding, or to hook up coincident points in a > particular way to get sharp transitions, you can't have it. Those effects should usually be possible to reproduce using multiple meshes (subject to some caveats with non-FSAA rendering again[2]). > - animating x and y of a vertex may be slower than in the explicit > case, because the triangles may re-form That shouldn't be too big a deal, so long as a triangulation method suited to incremental triangulation is used. In terms of existing vector tools, meshes are also much rarer in animation tools than in static tools. > And its possible to start with this vertex-only form, triangulate, and > write out the verbose, explicit form. I'm not sure I see a much value in permitting both forms, in SVG itself. More important to me is the fact that (assuming we specify Goraud interpolation for the colors) the triangulated form of either is directly translatable to a Type 4 shading in PS/PDF. So, yeah, I'd have to say that I'm very interested in giving the Delaunay approach a try. -mental [1] Usually the individual triangles of a mesh can be composed with each other using an alpha-saturating operation to eliminate seams between them, but this fails if they overlap and are semi-transparent, since the alpha will not accumulate as expected [2] Seams are unavoidable in cases where the edges of separate meshes are precisely congruent

4 7

LPE atop SVG vector effects
by MenTaLguY 26 May '07

26 May '07

Since I still can't get to the Wiki to document this, after talking to the SVG WG chair and studying the LPE proposal in more detail, here's what I think the live path effect stuff should look like: <svg:defs>  <path d="..." id="foo" inkscape:collect="always" /> </svg:defs> ...  <svg:switch sodipodi:type="livePathEffect">  <inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect"> <inkscape:vePath> <inkscape:vePathRef xlink:href="#foo" /> </inkscape:vePath>  <inkscape:extensionEffect name="org.inkscape.ext.jumble"> <inkscape:param name="spacing" value="10" /> <inkscape:param name="increment" value="0.5" /> </inkscape:extensionEffect>  <inkscape:veFill /> <inkscape:veStroke /> <inkscape:veMarker /> </inkscape:vectorEffect>  <svg:path d="..." /> </svg:switch> Bear in mind that it's not necessary to implement ALL features of vector effects upfront, merely the small subset used here. Vector effects are documented here: http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html -mental

4 8

Re: [Inkscape-devel] [Inkscape-user] Equivalent to Illustrator's Gradient Mesh?
by MenTaLguY 26 May '07

26 May '07

On Fri, 2007-05-25 at 23:47 -0400, Doug Schepers wrote: > Photorealism (or something akin to it) seems to be one use case. More generally, approximating arbitrary functions from 2d points to points in the rgba space, whether they're photos or some sort of scientific plot (c.f. Dr. Hoffmann's use case). > Bulia, your example seemed to have more in common with filters than it > did a gradient/affine transformation, Hmm, how so? -mental

1 0

Scaling & Viewbox
by jtaber 25 May '07

25 May '07

I cannot see a way for Inkscape to handle the viewbox element in order to scale coordinates, ie. setting lat long coordinates. Am I missing something or is there a good workaround ? I'm trying to develop a way to import/export kml files, keeping the lat long settings within Inkscape.

2 1

Proposed gradient editor
by Stathis Sideris 25 May '07

25 May '07

Hello everybody, I am writing to propose an enhancement on the way stops are defined and edited in the gradient editor on Inkscape. Sorry for cross-posting to the user and devel lists, but I would like feedback from both crowds. The idea is that the stops of the gradient are shown as circles on a larger gradient preview area, with the X axis representing the offset of the stop and the Y axis representing the alpha of a particular stop. Also, note that the circles contain the colour that corresponds to the particular stop. Please see the attached diagrams. Despite being a programmer myself, I won't be able to implement this feature right now, mainly due to my limited C++ ability and lack of familiarity with the Inkscape codebase. Hopefully someone will like it enough to give it a go. It would be great to see what people think. Stathis

2 1

PDF to SVG conversion with libpoppler and cairo
by Dave Barton 24 May '07

24 May '07

Hi, I noticed that one of the SoC'ers is working on integrating libpoppler with Inkscape for PDF import - I have investigated this briefly and written a quick-and-actually-not-too-dirty PDF to SVG converter with libpoppler and cairo. It is available at <http://seis.bris.ac.uk/~db9052/pdf2svg.tgz>. It is a *very* simple program that opens a PDF file with poppler and renders it to a cairo surface that is connected to an SVG file. Very simple and very effective and you might want to think about integrating it with Inkscape as is. It has worked on everything I've tried it on, though it has the nasty habbit of slicing large bitmaps up into small chunks. It doesn't produce the most streamlined SVG files either... Try it out and let me know. Dave -- =========================================== David Barton Email: davebarton@...1739... Web: www.cityinthesky.co.uk ===========================================

2 1

SoC blogging
by Niko Kiirala 24 May '07

24 May '07

I've put up a blog about my summer project. I'm planning to post there frequently about what I've been working on: http://fedev.blogspot.com/ Unlike this Finnish SoC project I'm working in, GSoC doesn't require writing this kind of documentary. Seems like Gail Banaszkiewicz put up a blog already, how about the rest of SoC:ers here? And yes, consolidating these blogs somewhere sounds like a good idea. Planet Inkscape maybe? (as it comes back up...) -- Niko Kiirala niko@...1267... http://niko.kiirala.com/

5 5