Minutes of the Inkscape team IRC meeting, 25/02
by Krzysztof Kosiński
This is a rough record of the main subjects of discussion. Copied with
slight changes from http://piratepad.net/inkscape
The agenda turned out to be too long for a single meeting, and several
points were left untouched.
1. Inkscape 0.48.3.1 packaging
Need people (2 or 3) to create an installer on win32 and OSX.
How about UweSch ?
Tweenk is making a package on a VM (for win). Quite slow need 1h.
Discussion about tool (btool, MSYS..) "we have 2 ways forward, fix our
autotools scripts to work with MSYS (should be doable since they have
recently updated their Perl port) or move to a different build system"
Resume: ScislaC and Tweenk will see about building the Win32
packages. They need to figure out if the project could invest in
virtualized OS copies so they can knock specific builds out (like
OSX).
If Michael W. doesn't have time/resources, su_v could provide
32bit Intel (Leopard) and 64bit Intel (Lion) packages (no Universal
packages)
Unit testing:
we need to get our unit tests cleaned up and all passing. Then a
continuous build system can take care of that whole
one-os-breaks-the-others issue.
Breaking OS often stems from #ifdef or package issues, so is not
solved by unit testing.
Unit testing + continuous build systems on multiple OS's catches
#ifdef breakage, etc.
2. Inkscape 0.49
2.1 - Remaining refactoring goals
Cairo and render caching : still some bugs to fix
Gradient rendering: kuribas offers to chip in to help fix the banding.
Idea is to add it as an option in exporting. Needs to be implemented
in Cairo.
disadvantages: speed, filesize, consistency between outputs,
shouldn't be done partially (only on gradients f.e.)
proposal (Tweenk): implement a GEGL renderer as an alternative to
the Cairo renderer for use in export (running 16 bit engine under the
hood)
2.1.1 - Handling of svg:switch not as a kind of group, but as a
"transparent" element that is effectively replaced by the best choice
in the SP tree
(ScislaC): we need to be a solid test ground for SVG2 ... switch
helps make it happen.
(Tweenk): there is an asymmetry between the "base path" and "path
parameters": the "base path" is stored in the svg:path that represents
the result, while all other path parameters are stored in, IIRC,
inkscape:liveeffect
(Tweenk): the primary use case for switch in Inkscape would be to
put 2 elements in it where the first is an inkscape-specific XML
element while the second is an SVG fallback
browser implementation is not at par yet - this isn't usable on
the web for now.
Some playing/testing with Firefox:
(Tweenk): looks like FF works as I intended only if I put the SVG
element first, and the Inkscape-specific XML second
link: https://developer.mozilla.org/en/SVG/Element/switch
(Tweenk): if I put Inkscape XML in a foreignObject it works properly
(MenTaLguY): foreignObject is probably the technically correct thing anyway
(Tweenk): there would be two elements in the <switch>, a
<inkscape:something> inside <foreignObject> that would contain
flowframe info and a <g> that would contain SVG 1.1 text (...and
ScislaC nods)
2.1.2 - SVG 1.1 fallback for flowtext (probably depends on the above)
see above - 2.1.1
2.1.3 - UI & Document coordinates
the problem in short: where do you set the (0,0) point and what direction?
Currently: (Inkscape standard): bottom left corner = (0,0) and up
is positive versus (SVG standard): top left corner = (0,0) and down is
positive.
Current fix breaks a few things stored in desktop coordinates:
grids, 3D boxes and guides, rows and columns, view coordinates, ...
(JonCruz): "I'd say we need to have a wiki page to start listing
what can be affected, and the use cases we care about"
Changes shouldn't alter the SVG, but be purely interface
(preferrably the document origin should be configurable on a per
document basis)
3D box: fix or remove and then rewrite, if a new one is written,
keep in mind http://dev.w3.org/csswg/css3-transforms/
wiki page to summarize broken areas, general use cases, etc. for
guiding the coord fixes:
http://wiki.inkscape.org/wiki/index.php/UI_and_Document_coordinates
2.1.4 - Markers matching stroke by default (user preference vs current
default behavior)
See SVG2 below.
2.1.5 - Better architecture for Live Path Eeffects (LPE; similar to
SVG 2.0 vector effects)
2.1.6 - User visible version numbering
suggestion of switching to a different scheme after 0.49 is released
1.0 conditions: fix most annoying problems: flowtext, coords,
marker coloring
discussion background:
http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31650 and
take 2: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36540
2.2 - Status
0.49 should contain the coords fix (but it should be forward
compatible with origin being placed in another spot)
Flowtext fallback is too complicated and there's already too much
new stuff in 0.49
Lack of mipmapping / downscaling in Cairo: critical bug
WIKI page is needed to work on this:
http://wiki.inkscape.org/wiki/index.php/Mipmapping
2.3 - Release Plan
3. - GSOC 2012
3.1 - Focus / Goals
Pick coders who have better chances of sticking around and
delivering instead of those who promise super-features
Focus on completing all selected projects successfully with
benefit to the project rather than on adding flashy new stuff
Preference on structural type projects over features
3.3 - Mentoring
Available mentors: Johan E. (dutch, english, german), Tweenk
(english, polish) (can also be a student), Tav (English, W. African
Pidgin), JonCruz (english)
Available mentors should be pinged: JazzyNico, pygmee, steren. i
guess we can manage some "french team"
Not available: Jasper vd G.
Available as admin: simmie
3.4 - Getting new students
JonCruz mentioned something about African students - African
countries have a lot of open source activity, but most of it is in
French-speaking countries (language barrier) -> JazzyNico, pygmee and
(Steren -if available) can speak French : need to find available
african too but we can have help from some organization for this :)
For GSoC purposes, 2Geom should be part of Inkscape - interesting
potential projects with concrete deliverables; relates to point 8 (to
be discussed in the future)
Strictly enforce two patches rule
Have IRC meetings with mentors/students as part of our process
(Johan: I meant this as part of our *selection* process)
4. SVG2 and CSS3 - not discussed thoroughly due to lack of time.
4.1 - Implementation strategies
4.1 .1 - Fallback support for older versions of the spec and inkscape
4.1 .2 - Specific features (markers inheriting properties for example)
4.2 - Low hanging fruit
Marker color matching stroke.
Named colors.
CSS3 2d transforms (duplicates current attributes)
4.3 - Most important features to our userbase
4.3.1 - Helping Tavmjong with the Mesh branch
4.4 - Initial Vector Effects support (non-destructive boolean ops might be
a good target)
- relates to Live Path Effects
4.5 Pushing for wanted features in SVG2.
- multipage support
8. What we need in upstream libraries (including 2geom)
2geom:
coders
better documentation of mathematics behind path operations
more unit tests
port existing tests to Google Test Framework?
provide skeleton test example
libgdl:
named icons in dock item labels
there's a bug in the code that we currently have imported into our
codebase that makes 64 bit architectures crash:
https://bugs.launchpad.net/inkscape/+bug/933058/comments/10
cairo:
bitmap downscaling / mipmapping
libcroco:
ability to work with other XML tree implementations
this is provided by our in-tree cr-sel-eng (selection engine) modification
11. Platform specific issues (and responsibilities)
- see point 1
12. Regular IRC Meetings (monthly is ideal, quarterly would be as a
good minimum)
general consensus on 1 or 2 times per month.
suggestion to let timeslots alternate (f.e. 8AM and 8PM UTC) to
accomodate ppl worldwide
Various points:
* do we need more focus on 'polish' instead of new features? see Bruce
Perens' keynote on Linux.conf.au
http://www.youtube.com/watch?v=Uoum-DHO7S8
* long-winded discussion about preferences system
* this discussion then spilled over into the embed/link debate
Participants (list might be incomplete):
jazzynico, Johan Engelen (johan_e), Jon A. Cruz, Jurgentje, Kris,
Nikita Kitaev, parasidasaeidae, pygmee, ScislaC, simarilius, su_v,
Tavmjong, Tweenk, yemanjalisa
11 years, 9 months
Re: [Inkscape-devel] Powerstroke cusps
by Valerie
> Hi all,
> I've been working on cusps on powerstroked paths. And I've obtained a
> first success. The attached picture shows a comparison between how
> powerstroke strokes thick cusps, and how Inkscape does it normally (I
> suppose according to SVG spec). I think the powerstroke solution is more
> artistically pleasing, what do you think? :-)
That looks Fantastic! The powerstroke version, of course! I can't wait to
try it out! :D
11 years, 9 months
Difficulty rendering Arabic text
by Adam Baker
Hello,
I believe this may be a bug, but I will leave that judgment to more
capable people.
In rendering paragraphs of Arabic text, I have come across situations
where the text simply does not join together. In fact, it's possible
through editing to toggle the text back and forth between appropriately
joined and entirely unjoined. I haven't been able to identify the
conditions under which this occurs.
The SVG file below is a minimal example. In Inkscape 0.48.2, Windows
Vista, the letters are all completely unjoined. But, if the final space
is removed from the text, the letters join properly.
On the other hand, some longer blocks of text do render properly.
I am at a loss. Any thoughts are appreciated, or if it looks like this
is a bug, that would be good to know as well.
Thanks,
Adam
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" width="744.09448819"
height="1052.3622047" version="1.1">
<flowRoot xml:space="preserve"
style="font-size:16px;direction:rtl;writing-mode:lr-tb;font-family:Times
New Roman"><flowRegion><rect width="745" height="283.57144"
x="-1.4285715" y="1.6478958" /></flowRegion><flowPara>سلام سلام سلام
سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام
سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام
سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام سلام
سلام سلام سلام سلام سلام </flowPara></flowRoot>
</svg>
11 years, 9 months
2/25 IRC Meeting Agenda (draft)
by Josh Andler
Hey all,
I just wanted to send out a draft agenda for the upcoming irc meeting
and also seek feedback about what others would like to add to the
list. I will send out a finalized version a couple hours before the
meeting time. Just a reminder, the meeting is scheduled for UTC 2/25
0800.
*Inkscape 0.48.3.1 packaging
*Inkscape 0.49
**Status
**Release Plan
*GSOC 2012
**Focus
**Goals
**Mentoring
**Getting new students
*SVG2
**Implementation strategies
**Low hanging fruit
**Most important features to our userbase
*CSS3
*Javascript
*Membership changes on the Inkscape Board
*What we need in upstream libraries (including 2geom)
*Old/unfinished code
**Lessons learned
**Cleanup
*Release schedule moving forward
**Fixed schedule
**Schedule timing
**Developer needs
**Translator needs
*Platform specific junk (OSX, Windows, etc... and yes, it's junk and
unless people are going to contribute code, we won't stay focused on
it too long)
Cheers,
Josh
11 years, 9 months
02/25 IRC Meeting Agenda
by Josh Andler
Hey all,
Here is a slightly modified agenda for the irc meeting in ~2 hours.
Sorry that the formatting is probably not ideal, it's my first shot as
this is the first official meeting that I can remember in the past 8
years. Just a reminder, the meeting is scheduled for UTC 02/25 0800.
*Inkscape 0.48.3.1 packaging
*Inkscape 0.49
-Remaining refactoring goals
--Handling of svg:switch not as a kind of group, but as a
"transparent" element that is effectively replaced by the best choice
in the SP tree
--SVG 1.1 fallback for flowtext (probably depends on the above)
--UI & Document coordinates
--Markers matching stroke by default (user preference vs current
default behavior)
--Better architecture for LPEs (similar to SVG 2.0 vector effects)
--User visible version numbering
-Status
-Release Plan
*GSOC 2012
-Focus
-Goals
-Mentoring
-Getting new students
*SVG2
-Implementation strategies
--Fallback support for older versions of the spec and inkscape
specific features (markers inheriting properties for example)
-Low hanging fruit
-Most important features to our userbase
--Helping Tavmjong with the Mesh branch
-Initial Vector Effects support (non-destructive boolean ops might be
a good target)
*CSS3 support
*Javascript support
*Membership changes on the Inkscape Board
*What we need in upstream libraries (including 2geom)
*Old/unfinished code
-Lessons learned
-Cleanup
*Release schedule moving forward
-Fixed schedule
-Schedule timing
-Developer needs
-Translator needs
*Platform specific issues (and responsibilities)
*Regular IRC Meetings (monthly is ideal, quarterly would be as a good minimum)
Looking forward to seeing whoever shows up. I want to have these
meeting be painless, but this initial one might be a little more
in-depth given that it's our first and we probably have a bit to
share/discuss and document. I will try to keep us focused if we stray.
Cheers,
Josh
11 years, 9 months
Disappearance of rendering and regression tests.
by Tavmjong Bah
Hi,
At one point we had automatic rendering and regression testing. I can't
seem to find any information about this. The links are all broken. Can
someone point to a current source of the tests?
Thanks,
Tav
11 years, 9 months
Gradually replacing UniConvertor + refactoring
by Alexandre Prokoudine
Hi,
Speaking of refactoring, I think it's time we consider replacing some
of our UniConvertor-based importers. The one I particularly have in
mind is CDR.
Thus far support for some file formats via UC was a low-hanging fruit.
However the project isn't progressing (http://bit.ly/pRwyJV) in a way
that would provide us an increasingly good support for some of them,
especially CDR. Yet users keep complaining (and rightfully so).
Last year we (re-lab) started working with LibreOffice team. The first
project we did together was reading binary Visio files which resulted
in libvisio (http://bit.ly/rh0TGd) that's now available to everyone
with release of LibreOffice 3.5 a week ago.
Then we started working on CDR (again), and now there is libcdr
available (http://bit.ly/zJFr7l). With release of v0.0.3 the library
is now feature-wise on par with UniConvertor and even surpasses it in
terms of supported objects, properties and a certain part of API that
is of interest for us. I'm talking about API that allows building
previews of pages and importing just the pages that the user needs
(something like what we have in the PDF/PS importer).
Pages used to be one of the selling points for Corel DRAW, since Adobe
Illustrator got its artboards only in CS4. So no wonder that there's
quite a lot of legacy CDR files around that have multiple pages. And
we cannot sensibly read those.
The very same API was added to libvisio.
So what I'm wondering about is whether we can abstract part of the
importing preview dialog and rebuild existing importers around it:
redo both PDF/PS/EPS (probably little work), use libcdr instead of UC,
add Visio importer (libvisio). If we ever go for Assimp for importing
3D projections of 3D files, that would come in handy too.
It would probably also make sense adding a possibility to import pages
as either layers or new documents (the way GIMP does it for e,g, PDF).
What do you think?
P.S. As for libcdr and libvisio, both are well maintained project (as
they are part of LibreOffice). Currently we are working on support for
gradients and text in CDR (both missing in UniConvertor). If anyone's
interested, it's best to fetch code from Git, as it's moving forward
very fast.
$ git clone git://anongit.freedesktop.org/libreoffice/libcdr
Alexandre Prokoudine
http://libregraphicsworld.org
11 years, 9 months
Inkscape slowing down
by LucaDC
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
moving objects.
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
slow update.
I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered
pretty old a system, but I run all the software I need on it without any
problem. I feel that it should be fairly enough for an application like
Inkscape (I never use filters or other graphical features, only technical
drawing); and it was, up to few weeks ago.
I suspect that the bounding box is continuously recalculated but this is not
needed as the object cannot change while moving it; also, calculating the
bounding box for a single object should not be heavy at all.
So, should I start worrying for Inkscape requiring too much resources for me
in the near future (or even present) or can this be simply considered a bug?
I can easily trigger it by opening a new document, drawing a couple of
circles and a couple of rectangles, selecting all four objects and start
duplicating them with the spacebar: after a few duplications my CPU usage
goes very high and moving objects becomes a pain. It seems related to how
many objects are present in the drawing, which is a nonsense because moving
a single object should not depend on anything else but the object itself (I
tried with all snappings disabled too, of course).
Thanks and regards
Luca
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
11 years, 9 months
helper/util folder
by Johan Engelen
Hi all,
We have two helper directories: src/helper and src/util. I think we
should merge the two. Which name do we want to keep?
Note we have for example src/helper/units.h and src/util/units.h, argh!
If anyone is looking for a GSoC project: a unification of the units
system would be nice. If I remember correctly, we have 4 (!) separate
pieces of unit calculation code...
Ciao,
Johan
11 years, 9 months
Debian Squeeze build issue
by Nicolas Dufour
Hi again,
I've just found out that Inkscape no longer compiles on Debian Squeeze (Crunch Bang Linux variant, with back-ports), Inkscape trunk revision 10990. It fails on the first file with the following message:
-----
CXX arc-context.o
In file included from /usr/include/glibmm-2.4/glibmm/balancedtree.h:29,
from /usr/include/glibmm-2.4/glibmm.h:83,
from ./io/inkscapestream.h:14,
from ./xml/repr.h:24,
from display/canvas-grid.h:15,
from sp-namedview.h:26,
from arc-context.cpp:30:
/usr/include/glib-2.0/glib/gtree.h:28:2: error: #error "Only <glib.h> can be included directly."
-----
Last time it compiled correctly was with revision 10962 (I use it on a rather slow netbook that is not updated it as regularly as my other computers or VMs...)
Squeeze uses libgk2-2.20.1 and libglib2-2.24.2 . Maybe it's too old for the trunk?
Regards,
--
Nicolas
11 years, 9 months
