active document
by Johan Engelen
Hi all,
"SP_ACTIVE_DOCUMENT" or equivalently "inkscape_active_document" uses
the current active desktop to find out which document is active. So
SP_ACTIVE_DOCUMENT will not work if there is no GUI (cmdline Inkscape),
and will return NULL.
To allow one to call SP_ACTIVE_DOCUMENT to obtain the SPDocument, I am
proposing to 'fall back' to take the first listed document in the
Inkscape instance if desktop==NULL.
In inkscape.cpp:
SPDocument *
inkscape_active_document (void)
{
if (SP_ACTIVE_DESKTOP) {
return sp_desktop_document (SP_ACTIVE_DESKTOP);
} else if (!inkscape->document_set.empty()) {
return document_set.begin()->first;
}
return NULL;
}
I know we should move away from SP_ACTIVE_DOCUMENT and friends, but
let's do the proposed change for sake of getting functionality now
instead of over 5 years. ;-)
It is related to fixing r11804 [1] to work from the cmdline.
Cheers,
Johan
[1]
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11804#s...
10 years, 3 months
Changes in cairo >= 1.12.4 affect Inkscape stable and trunk
by ~suv
Cairo 1.12.4 introduced changes which affect Inkscape stable and trunk.
Later releases (1.12.6, 1.12.8) addressed some of them for now, but not
all: Outline view mode doesn't display any visible outlines at all [1],
even with latest cairo 1.12.8 (released today).
Tests with just released cairo 1.12.8 on OS X 10.7.4 (X11 and Quartz
cairo surface backends with Inkscape 0.48.3.1 and Inkscape 0.48+devel
r11861) gave me these results:
- not fixed: outline view mode still renders invisible
affects current stable 0.48.3.1 and trunk
- fixed (since 1.12.6): invisible auxiliary paths and handles
° path outlines (red/green), node handles (blue) in
Pen, Pencil and Node tool
° circle (grey/green) indicating distance to guide path in
Calligraphy tool hatch mode
° circle (orange) indicating brush size of Tweak tool (width)
° circle (orange) indicating spray area of Spray tool (width)
° possibly others I missed in my tests
affected current stable (0.48.3.1)
- AFAICT fixed (since 1.12.8): rendering artifacts with stroked curves
affected trunk [3]
In upstream bug 56099 [2], one of the cairo developers indicates that
Inkscape needs to change how certain handles and paths are rendered via
cairo:
> commit c565bad8901dbe66e1402cdc2418986e96e698e3
> Author: Chris Wilson <chris@...2923...>
> Date: Fri Oct 19 12:22:58 2012 +0100
>
> pen: Relax invisibility criteria from half-tolerance to quarter-tolerance
>
> Inkscape is one user who sets geometric tolerance to 1.25 pixels when
> stroking sub-pixel lines. Whilst we wait for inkscape to set sensible
> values for their tolerance, we have to allow through the current values
> in order to prevent the fine strokes from disappearing.
Is there something which can or ought to done on Inkscape's side to help
affected users of current Inkscape stable [4] (AFAIK currently Fedora
18, Mageia and ArchLinux, and probably soon other distros which plan to
update to latest cairo stable)?
Likely - I don't know any details about how cairo is used in Inkscape -
there will be different changes required for the stable release branch
(release of 0.48.4 is pending, and held up only by one blocker so far)
and current trunk.
V
[1] Bug #1074612 “No display in outline mode”
<https://bugs.launchpad.net/inkscape/+bug/1074612>
[2] Bug 56099 - path rendering problems in 1.12.4
<https://bugs.freedesktop.org/show_bug.cgi?id=56099>
[3] artifacts with stroked bézier curves
<http://lists.cairographics.org/archives/cairo/2012-September/023532.html>
<http://lists.cairographics.org/archives/cairo/attachments/20120928/194fcb...>
<http://dl.dropbox.com/u/65084033/irc/cairo-1.12.4-stroked-paths-rendering...>
[4] user comments
<https://plus.google.com/106604070261659014786/posts/Bru4nW8wSrh>
<https://plus.google.com/106604070261659014786/posts/3DpwXkBLRwv>
10 years, 3 months
Testing SpiroLive
by Jabiertxo Arraiza Cenoz
Hi SorinN.
How are your testing? I'm not enoft specific?
Thanks for your time compiling. I want to know if SpiroLive is mature to
propose to merge. ¿Whath do you think about?
Hi, Jabier.
10 years, 3 months
feComposite : how to deal with alpha ?
by pennec victor
Hi,
Some days ago, Jasper van de Gronde asked me if I still got problem with
negative values in feComposite.
He pointed that I forgot about the alpha value (becoming zero)
https://bugs.launchpad.net/inkscape/+bug/1044989
So I reworked my filters using his clever trick so that alpha won't reach 0
(except I used feColorMatrix instead of feComponentTransfer)
And once again I'm stuck.
I try to redo the exclusion filter in photoshop using feComposite
For two layers A (=sourceImage) and B (=backgroundImage) with opacities =
1, formula is supposed to be A+B - 2AB.
As feComposite (stupidly IMO) computes not only rgb channels but the alpha
too I need to get rid of the alpha channel (either in earlier or later
stages) until now I failed.
What I'd expected
rgb(1,0,0.5, x) exclusion rgb(0,1,0.5, y) should be rgb(1,1,0.5, 1)
r:1 + 0 - 2 (1*0) = 1
g:0 + 1 - 2 (0*1) = 1
b:0.5+0.5 - 2 (0.5*0.5) = 0.5
problem is the alpha coz
1 + 1 - 2(1*1) = 0
I tried the 2 following solutions
solution 1: dealing later with alpha => set alpha to 1 when everything is
done.
feComposite k=(-2;1;1;_)
followed by colorMatrix
1 0 0 0 0
0 1 0 0 0 <= identity for rgb
0 0 1 0 0
0 0 0 0 1 <= reset alpha to 1.0 whatever it could've been before
this doesn't work, the result is full black
solution 2: dealing earlier with alpha => set alpha so that it is 1 and not
0 after composition (=set it to 0 before the feComposite)
pass sourceimage through the following colormatrix to remove the alpha
1 0 0 0 0
0 1 0 0 0 <= identity for rgb
0 0 1 0 0
0 0 0 0 0 <= reset alpha to 0
run this + backgrounImage in feComposite k=(-2;1;1;_)
with this I'd expected the alpha to be ok because
0 + 1 - 2 (1*0) = 1.
but this doesn't work either (fully transparent ?)
Could anybody help ?
How do you deal with alpha when using feComposite ?
Does Inkscape (or svg) drop result of a filter stage if alpha is zero ? (in
solution 1)
10 years, 3 months
Clippath and Masks
by Jelle
Dear all,
I was wondering if it wouldn't be useful to change the way clippath and
masks are created. Now the object used to create the clippath, gets
transformed into a clippath and placed in the defs. However, very often
I'd have to create a copy of this very object, move it down in Z-order and
the use the original object to clip. Wouldn't it be easier to move a copy
of the orginal to the defs as clippath and leave the original where it is?
For masked area's it makes more sense to destroy the orignal, but even
there I feel maintaining the original could be useful as those shapes are
often used for dropshadows (at least that's what I use them for).
Releasing the clip or mask would then still be rendering the same result
as now, the only change is creating a new idea for the clippath by adding
"c_" or "m_" in front of the ID of the copy.
Jelle Mulder
10 years, 3 months
Something annoying with new sliders and filters
by Ivan Louette
While the new sliders could be smart they are also annoying when used on some filters like Gaussian Blur when a wide range of variation is allowed (this is the case for some filters also suited for high resolution images like for example the new custom filter "Drawing").
The problem is when you try to click on numerical values because then often the slider instantly increase up to the highest value (like if you drag it to this value) instead of giving you precise control on the numerics. And in these cases often if you type Ctrl+Z before the filter is completely applied Inkscape crashes.
It make working with some nice filters somewhat hasardous and I am sure discouraging for the beginners in this area.
ivan
10 years, 3 months
display scale factor
by unknown＠example.com
Recently, I wanted to use Inkscape to draw a floor plan for a large
house. For this, I needed to use a grid specified in feet and inches.
I found that in order to fit the whole drawing on the screen at once, I
had to set the zoom factor to 3% or less, which was inconvenient. It
seems that for some reason you cannot set a zoom factor of less than 1%,
so if the building were even three times larger, there would be no way
to view it all at once, if you used the correct units to draw it.
It seems that I'm not the only person having this problem:
http://inkscape-forum.andreas-s.net/topic/1209992
The suggested solution is to scale your drawing in "px" units, and then
apply a mental scale factor to get the real dimensions. Of course you
COULD do that, but why should you have to? Why can't Inkscape
accommodate whatever units, dimensions, and scales are appropriate for
the task at hand?
My first solution was as follows. The inch and foot units are defined in
the Inkscape config file "/usr/share/inkscape/ui/units.txt", or possibly
"/usr/share/inkscape/ui/units.xml". I'm not sure which of these files is
supposed to be normative; why are there two of them?
# name plural abbr type factor PRI description
inch inches in LINEAR 90.0 N Inches (90 px/in)
foot feet ft LINEAR 1080 N Feet (12 in/ft)
I added the following units, which are defined to be 1/360 of the usual
ones:
x-inch x-inches xin LINEAR 0.25 N X-Inches (0.25 px/xin)
x-foot x-feet xft LINEAR 3 N X-Feet (12 xin/xft)
Inkscape then recognizes these new units for the "Default units" and
"Page Size" options, and for the "Transform" dialog. It DOES NOT
recognize them for the object dimension boxes along the top of the
canvas, and when the drawing's default unit is set to "xft", the rulers
are graduated in "px" units.
I then tried adding the same definitions to the "units.xml" file:
<unit type="LINEAR" pri="n">
<name>x-inch</name>
<plural>x-inches</plural>
<abbr>xin</abbr>
<factor>0.25</factor>
<description>X-Inches (0.25 px/xin)</description>
</unit>
<unit type="LINEAR" pri="n">
<name>x-foot</name>
<plural>x-feet</plural>
<abbr>xft</abbr>
<factor>3</factor>
<description>X-Feet (12 xin/xft)</description>
</unit>
This did not appear to have any further effect.
It seems rather silly that for some purposes, the unit definitions would
be read at runtime from a config file, while for other purposes, they
would be compiled into the program binary, but that appears to be how it
currently works.
I suppose I could fix this so that all the unit definitions were read
from a single config file at runtime, and then define corresponding
metric x-units as 1/100 of the usual ones, but that would be kind of
pointless. People who want to draw cells, or integrated circuits, or
molecules, would have to define y-micrometres, y-nanometres, and
y-angstroms, as a million times bigger than the standard units, because
it turns out that the maximum zoom factor you can apply is 25600%, or
256. (It's pretty silly to have to write 256 as "25600%", but apparently
you do have to.)
There is a much better solution, which is illustrated by the attached
image "scale.png". This is intended as an addition to the current
"Document Properties/Page" config window. It specifies the scale at
which the drawing will be displayed on the physical screen, as a ratio
between real dimensions on the screen, and the declared dimensions of
the drawing.
This does not replace the current "Zoom" option in the "View" menu or
the box in the lower right corner of the main window. It is simply
multiplied together with that setting, so if the zoom factor is set to
"1:1" or "100%", the specified display scale factor is what you get. The
intention is that the display scale factor will be set once, to an
appropriate value for the drawing, while the zoom factor will be changed
frequently while working.
The display scale factor is specified as a ratio between two values,
each of which consists of a decimal number and a unit chosen from a
selection list. The available units are those read from the
units.{txt,xml} file, with the addition of "width" and "height". These
two units will refer to the physical screen dimensions, and the declared
page size for the drawing. You can therefore specify that the normal
display scale is such that the width of the drawing is the width of the
screen (or half that, or twice that). This is likely to be useful,
because often the X server does not have an accurate idea of the
physical screen dimensions, but it always knows the size in pixels.
It seems that this feature should be fairly simple to implement, for
someone familiar with the Inkscape code. It only requires four
additional widgets for the Document Properties window, for this setting
to be saved and read from the SVG file, and for the resulting value to
be multiplied with the existing zoom factor wherever that appears.
Note the following related feature request, rated as "Priority: High":
https://blueprints.launchpad.net/inkscape/+spec/real-units
Bob wants to draw a house plan in feet and inches, but still print
it on a letter-sized paper. (one idea: different layers can have
different scales: e.g. border layer is actual size, house layer is 1
in. = 8 ft.)
I would point out that the SVG specification does not prescribe any
particular ratio between "px" drawing units and actual physical lengths.
(It certainly DOES NOT specify that 90 px = 1 inch, as Inkscape
currently assumes [units.txt]; this ratio is only mentioned as "for
example".)
http://www.w3.org/TR/SVG/coords.html#Units
I suggest that for Inkscape, "px" be considered to be equivalent to the
specified "Default unit" from the Document Properties window. If the
default unit is metres, or whatever, then that's what "px" means, for
that document, but no other. I don't see how this is inconsistent with
the SVG specification.
Another related proposal is here:
http://sourceforge.net/mailarchive/message.php?msg_id=29861176
>> I think that if we are going to break compatibility, we go for one
>> release to do it. Basically, all of the new-style stuff including
>> custom doc coords would be a huge win to introduce all at once. I
>> would love to see a rotatable canvas in Inkscape, but I have no idea
>> how feasible it is with the current rendering/viewport stuff we have
>> in place.
>
> In principle it should be possible to change doc2dt and dt2doc
> matrices to any transform without any modifications to the display
> subsystem, but it might expose bugs - mainly hidden assumptions that
> doc2dt is always an Y flip + translation.
If the canvas can be rotated by an arbitrary angle (or "any transform
matrix" applied), then certainly another uniform scaling factor can be
applied at the same time.
Finally, I must comment on how strange it is that "units.txt" contains
the following definition:
# name plural abbr type factor PRI description
% % % DIMENSIONLESS 1.00 Y Percentage
It seems clear that since 100% = 100/100 = 1.0 , then 1% = 1/100 = 0.01
; this is what the conversion factor should be.
Only slightly less strange is this:
degree degrees deg RADIAL 1.00 Y Degrees
The natural base unit for rotations (if not radians) is one whole
rotation, the identity operation, analogous to multiplication by one.
These definitions necessarily imply that there must be inverse
conversion factors of "100" and "360" hard-wired into the Inkscape code
somewhere. But why should that be? The natural place for such conversion
factors is this same "units.txt" definition file; that's what it's FOR.
In this regard, it would be helpful if whatever piece of code is
responsible for reading these definitions were (trivially) extended to
handle ratios; then a degree could be defined as "1/360", rather than
"0.002777777".
Then, if someone wants to specify angles in milliradians, for some
reason, they can define that as "1/6283.185", rather than "0.05729578",
as is currently necessary.
http://en.wikipedia.org/wiki/Angle#Units
Similarly, if someone is working on some tiling problem and wants to
scale things by multiples of 1/64, rather than 1/100, they can call that
a "perfoo", and define it as "1/64", instead of "1.5625", as currently
necessary.
Another thing that would be useful for this file is to have some
notation for "the n-th root of x"; for example, "2\4" could mean "the
fourth root of two", which might otherwise be written as "2^(1/4)".
Currently, the "+" and "-" keys zoom the display by a factor of 2^(1/2)
(usually called "square root of two", 1.414214), while the up and down
arrows next to the zoom factor box change it by almost, but not quite,
2^(1/10) ("tenth root of two", 1.071773). If there were some convenient
notation for specifying geometric roots in the "units.txt" file, these
zoom factors might be made configurable, and they could also be used in
the "Transform" dialog for scaling objects.
-- Ian Bruce
10 years, 3 months
Problem export to png in spanish version
by Benjamin Núñez
Hi everybody
When I try export to png a file, and the name have spanish letters like "ñ"
or accent like in this word "camión" the name change in other form. For
example Cataluña change as Cataluña.
The other problem is, when I try import this file in the same folder
nothing happens. If I want export the file I need put this file in other
folder.
I´m not sure if this problem is because I use Windows.
I´m from Spain, sorry if my english not is good and I´m not engineer.
V. 0.48
Spanish version
Windows 7
--
Benjamín Núñez González
10 years, 3 months
Color names shown when hovering a swatch color
by Lucas Vieites
Hi,
I'm the translator for the Spanish version of Inkscape and I just got an
email from a user asking why the names of the colours in the swatches
weren't translated. I didn't know what he was talking about so I checked
and found out that when hovering over a color in the swatch at the bottom
of the Inkscape window a tooltip is shown in the status bar with the name
of the colour that's in the .gpl file.
Just out of curiosity: could it be a feature to add in the future, I mean
the translation of the colours?
Thanks in advance,
--
Lucas Vieites
lucas@...1852...
http://blog.codexion.com
http://www.linkedin.com/in/lucasvieites
10 years, 3 months
