IRC meeting for hackfest planning and fundraising
by Bryce Harrington
When: Tomorrow, Monday Sept 15th at 12 noon (3pm eastern)
Where: #inkscape-devel on Freenode IRC
Who: Inkscape team; Karen Sandler
Karen and I will be discussing plans/ideas for an upcoming Inkscape
hackfest. The principal topic we want to discuss is the
fundraising/budgeting side of things, but other aspects are within
scope.
All are welcomed to attend, but this will mostly be interesting to
people wishing to help out in organizing the hackfest and/or
fundraisers.
Bryce
9 years, 2 months
Merging Policy
by Tavmjong Bah
Hi,
The merge of the latest features from Liam into the Experimental branch
raises the question of best practices for merging. In particular, I am
not sure that merging multiple features at one time is a good idea.
Other projects seem to divide commits into the smallest possible pieces.
I think that this is good practice as it better documents what is being
committed, allows for better reviews, and makes it easier to cherry-pick
from one branch to another.
In particular, the commit message:
"Merge in ponyscape features by Theo and worked on my LiamW"
doesn't give any information about what are the purpose of the changes.
It takes reading the code and/or searching the web to find this
information. (See: http://liamwhite1.deviantart.com/journal/ )
As far as I can tell, the commit:
1. Adds the new LPE's:
* Attach path
* Bounding box
* Ellipse
* Fill between many
* Fill between strokes
* Joint type
* Taper stroke
2. A tagging system.
3. Objects dialog.
4. Multi-path manipulator
5. Filter effects chooser.
I think these should have been committed separately with a line or two
explaining what each does. Also, each LPE should be a separate commit.
As an additional question: is the experimental branch going to become
0.92? I think there have been too many changes to the experimental
branch to try to merge it with trunk.
Tav
9 years, 2 months
Units in Inkscape
by Tavmjong Bah
Units in Inkscape
=================
Introduction
-----------
The recent debate about units in Inkscape highlights the fact that we do
not have a clearly defined approach on how to handle units in Inkscape.
Units are not as straight-forward as one should think they are. This
essay attempts to resolve this problem.
Historical View
---------------
Part of the problem with units in SVG and CSS in general is why they are
there in the first place. In the early days it was assumed that one
would want to display drawings on a screen at full scale. In other
words, a "one inch square" would be display on a screen as a physical
one inch square. This required that displays be queryable as to what
there true DPI was. Display manufactures rarely provided the means to
query the DPI of the display, and when they did, they often returned
incorrect results. Thus, the use of "real" units never became popular
and in reality is usually not what one wanted. Eventually, after long
arguments, the CSS working group dictated that one inch would be fixed
to 96 pixels regardless of screen resolution (ironically, with so called
"Retina" displays, there is once again interest in scaling drawings
based on DPI).
A Philosophy
------------
Absolute units should not be used inside an SVG file with one exception:
The 'root' width and height may have units, which with a proper
'viewBox' determines an appropriate scale for a drawing. (This sets the
'real' world value of the SVG 'user unit.) This reflect the opinion of
the majority of the SVG working group.
It should be noted that the relative units 'em', 'ex', and '%' can be
useful in some cases.
Inkscape & Units
----------------
Inkscape should not write out absolute units other than in the root SVG
element. Inkscape must, however, be able to interpret units from
non-Inkscape produced files according to the CSS defined value of 96
pixels (initial user-units) per inch.
The use of units in the Inkscape GUI is for ease of authoring only. The
actual values should be stored as 'user-units'.
Changing the "Inkscape GUI unit" should not introduce any 'transforms'
on elements (as seems to being done now) nor should changing the SVG
root 'width'/'height units or the 'viewBox'.
The GUI should reflect the chosen Inkscape GUI unit scaled to take into
account the SVG root 'width'/'height' and 'viewBox'.
For example:
<svg width="100mm" height="100mm" viewBox="0 0 100 100">
describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
one mm.
If the Inkscape property inkscape:document-units="mm" then the GUI would
show a width of '25.4' for a rectangle 25.4 'user-units' wide. If
inkscape:document-units="in", the GUI would show '1.0'.
To implement this, one either needs to find the proper scaling from
examining the SVG root 'width'/'height' and 'viewBox' properties or
create a new Inkscape property that fixes this scale (in which case
changing the 'width'/'height' would change the 'viewBox' and vice
versa).
Tav
9 years, 2 months
Re: [Inkscape-devel] Units in Inkscape
by mathog
On 11-Sep-2014 10:23, Nathan Hurst wrote:
> Ok, that's another vote for using double precision everywhere. That
> gets us 14-15 digits, which should be enough for anybody.
Adding more digits to the numerical representation does not in itself
provide numerical stability, it just makes it easier to sweep the
problem under the carpet of "looking at a smallish number of digits".
Conversely, at least with respect to this units question, numerical
stability, which for the purposes of this conversation means when a diff
of two SVG's shows no changes, can be achieved if the lengths and
coordinates inside the document are never changed, instead only one
transform (or its equivalent) at the top level is. Then an end user
could flip endlessly between different document units and never corrupt
the numerical representations in the drawing. The only change that
would show up, if no other changes were made, would be the values for
that one transform.
This assumes that the code did this:
"we are currently using mm, user wants inches, REPLACE document unit
transform
with the pixels to inch transform"
If instead it did:
"we are currently using mm, user wants inches, MULTIPLY document
transform
by mm to inches conversion"
then the single unit transform itself might not be numerically stable.
(It could be if all of the units scaling factors have terminating binary
representations with precision to spare, and the same is true for all
combinations of their products.)
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 2 months
Inkscape devel very slow
by Javier García
Hi,
I'm running inkscape devel on ubuntu 14.04 and it is going very slow
even in smal documents.. what should I do? If you need some info about
my computer/operative system I will be pleased to give you.
Javi
9 years, 2 months
problem in po/cs.po while compiling rev 13546 on Windows XP.
by alvinpenner
while synching with the trunk I got some error messages related to .po files,
but I neglected to write them down.
after compiling I get the messages below, related to po/cs.po
Cheers,
Alvin
..................................................................
============ cmd ============
strip build\inkscape-console.exe
=============================
##### Target : i18n
##### compile gettext .po files to .mo
--- i18n / msgfmt
============ cmd ============
msgfmt po/am.po -o build/locale/am/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/ar.po -o build/locale/ar/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/az.po -o build/locale/az/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/be.po -o build/locale/be/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/bg.po -o build/locale/bg/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/bn.po -o build/locale/bn/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/bn_BD.po -o build/locale/bn_BD/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/br.po -o build/locale/br/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/ca.po -o build/locale/ca/LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/ca@...3150... -o build/locale/ca@...1971.../LC_MESSAGES/inkscape.mo
=============================
============ cmd ============
msgfmt po/cs.po -o build/locale/cs/LC_MESSAGES/inkscape.mo
=============================
Make error line 421: <msgfmt> problem: po/cs.po: warning: Charset missing in
header.
Message conversion to user's charset will not work.
po/cs.po:12:2: syntax error
po/cs.po:12: keyword "TREE" unknown
po/cs.po:18: keyword "MERGE" unknown
po/cs.po:145: missing `msgstr' section
po/cs.po:146:2: syntax error
po/cs.po:146: keyword "TREE" unknown
po/cs.po:150: keyword "MERGE" unknown
po/cs.po:197: missing `msgstr' section
po/cs.po:198:2: syntax error
po/cs.po:198: keyword "TREE" unknown
po/cs.po:202: keyword "MERGE" unknown
po/cs.po:243: missing `msgstr' section
po/cs.po:244:2: syntax error
po/cs.po:244: keyword "TREE" unknown
po/cs.po:248: keyword "MERGE" unknown
po/cs.po:403: missing `msgstr' section
po/cs.po:404:2: syntax error
po/cs.po:404: keyword "TREE" unknown
po/cs.po:408: keyword "MERGE" unknown
po/cs.po:1925: missing `msgstr' section
msgfmt: too many errors, aborting
--
View this message in context: http://inkscape.13.x6.nabble.com/problem-in-po-cs-po-while-compiling-rev-...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9 years, 3 months
Re: [Inkscape-devel] Inkscape 0.48.5 Released
by Jon A. Cruz
On Jul 19, 2014 9:20 AM, Partha Bagchi <partha1b@...400...> wrote:
>
> I would think that any build (Mac/Windows/Linux) uses external libraries since Inkscape depends on gtk+ and friends. Only difference, on Linux it comes with the OS and so the user does not have to do the legwork while for the other 2 OSes, one has to build the dependencies.
>
Kinda, sorta on Mac. Some libraries do come with the system but may be optionally included with the distributed program. Others require a developer to explicitly include them. Also, the standard for applications on OSX is for each app to include its own copies of external libs, but infernally as part of the application bundle itself.
For the end user on a Mac no extra legwork is needed as all external libs are internal in the "application binary". It's also common to end up with multiple app versions side-by-side by simply changing the name on one app package before copying the next into the Applications folder.
9 years, 3 months
Please check r13544 or later for problems at unit change
by mathog
One of the changes I introduced at revision 13544 was a modification of
scaleChildItemsRec()
so that it no longer recurses into groups to apply scaling changes
associated with a change of units. This was breaking EMF import of
clipped objects. That happened because during the recursion the
coordinates of the clipped objects were changed directly, not by a
transform. Since the clipping object (in defs) was not similarly scaled
this broke the clip. See for instance:
https://bugs.launchpad.net/inkscape/+bug/1348417
In the changed version the scaling change is applied as a transform at
the group level, and all the coordinates within that group are not
directly modified, so the clipping object and clipped objects are still
at the same scale and they continue to work together. Since EMF import
of clipped objects always works like (pseudocode):
<g (clip reference)>
clipped objects
</g>
applying the transform at the group level fixes the problem in that
context.
I suspect that scaleChildItemsRec() is still going to cause problems for
any SVG object other than a group that looks something like
(pseudocode):
<(not a group)
(a clip or mask ref)
x=100
y=100
(other stuff)
>
when the document units are changed because it will change the 100's to
something else, and not modify the referenced clipping object. I have
not confirmed this though.
In any case, would the people who worked on document units please see if
my changes at revision 13544 break anything when the document units are
changed? I did some preliminary testing and it looked OK, but I don't
really know what test cases to use to explore all the edge cases.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 3 months
Re: [Inkscape-devel] Please check r13544 or later for problems at unit change
by mathog
On 07-Sep-2014 02:45, alvinpenner wrote:
> two comments: the pre-existing bug has been reported at Bug 307656 and
> Bug
> 1366434. It appears to be related specifically to the rectangle tool
> F4.
> However there are two new regressions which are not related to F4.
>
> First one: rev 13544 has broken one of the fixes for Bug 1240455,
> comment
> 24:
> https://bugs.launchpad.net/inkscape/+bug/1240455/comments/24
>
> using Extensions->Render->Grids->Grid and using the default spacing of
> 10
> px.
> - case 1 : open Inkscape with default units of px, draw default Grid
> - case 2 : open Inkscape, change units to mm, draw default Grid
>
> the expectation is that these two grids will look the same relative to
> the
> page size. Rev 13534 shows the expected behavior, rev 13546 does not.
>
> Second one:
> - open Inkscape, draw two objects, a rectangle and a star, or ellipse
> - select both of them
> - change document units
> - the expectation is that the shapes should not change size
> - Rev 13534 shows the expected behavior, rev 13546 does not.
I will revert that change in a little bit. Actually I'm going to add a
parameter to the call, so that it can work one way (so that it works
like it does now) for a call from EMF import, and as it did before when
called from elsewhere (only one other place that I know of.) This is a
short term hack until the actual problem is sorted.
And I think the actual problem is in those parts of Inkscape which fail
when the scale is applied to a top group. It is perfectly valid SVG to
do:
<g
(scale to whatever conversion one wants)>
(bunch of objects in completely arbitrary units.
</g>
All transform operations up the stack must be applied to an object. If
some part of Inkscape only shows units properly when the top level scale
is not present, then it is not correctly applying those transforms. How
is it not that part of Inkscape that is broken?
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 3 months
Old Website will be Decommissioned
by Martin Owens
Dear Inkscape Devels,
This is a warning that the old inkscape website currently at
dev.inkscape.org will be decommissioned by November.
Please make sure that any important information has been moved to the
new django-cms website by then and let me know as soon as possible if
you need help making this happen.
Best Regards, Martin Owens
9 years, 3 months
