inkscape git mirror?
by MenTaLguY
I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this.
-mental
15 years, 3 months
Odd size of imported bitmaps
by Dan H.
Hello,
I've imported a 400x400 pixel TIFF image into an inkscape drawing, and
it comes out as 112.89 x 112.89 mm, which translates to a resolution of
roughly 90 dpi.
Where does this number come from? Shouldn't inkscape honour the dpi
information that is embedded in the TIFF image?
Alternatively, for images that don't have a "built-in" resolution,
inkscape should ask for a "native" size of the image or use a changeable
default resolution.
Also I noticed that some imported images have width and height xml
attributes while others don't. All this came to my attention when I
worked with a SVG file with 20 imported images of about 10MB each (TIFF
uncompressed) which bogged down my computer. I tried substitutung the
TIFFs with scaled-down (by .25) working copies, which worked fine for
those images that had width and height attributes (the others came out a
fourth of the size),
I'm just wondering how Inkscape arrives at the "native" size of an
image, and I wanted to know if others agreed with my notion that in a
vector drawing program the resolution of imported bitmaps was of high
importance.
It would also be nice if Inkscape could somehow reload image properties
if the original bitmap had changed (by scaling or cropping, for instance).
Thanks,
--Dan
16 years
Latest news on LGM 2007 Montreal
by Louis Desjardins
Dear Inkscape team!
I'd like to post a few info here for the benefits of all travellers to LGM.
1. I know the website of LGM is outdated. I expect things to be
straightened up in the coming days. :)
2. Meanwhile, the Create wiki has been updated :
http://create.freedesktop.org/wiki/index.php/Conference
3. Visa. Please review the VISA info as it might apply to some of you
when travelling to Canada.
4. Rooms. We have dealt a LGM special price on rooms at the Student
Residences of the uni hosting the LGM. All info is on the wiki. What has
guided me is to allow LGM participants and especially the devel teams to
be together most of the time (remember we only have 3 days), have
internet access and enough room to organize meetings. All that into a
calm environment. The residences are on the site of the LGM at less than
5 minutes from the main auditorium. Arrival date : May 3 (Conference
starts on May 4). We may be able to arrange things if you want to arrive
earlier. Please let me know.
And we also want to avoid getting people lost in the city (Montreal is a
North American city, quite extended...) and taking up most of their time
getting from their hotel to the LGM site and back. I have made a
reservation on 50 Single rooms + 5 Cosy Suites (with large bed) and
there are lots more room there if needed. On each other floor of the
residence people have access to a Salon that can hold a good 10 to 12
people meeting and we also have access to another 3 large rooms for
meetings with more than 20 persons at a time.
5. Sponsorship. I am deeply concerned by sponsorship. We have to be able
to help people get to the LGM. So far, I am still waiting on
confirmation but sponsors have shown clear interest in helping us again
this year. It's a matter of time until we know for sure the exact amount
we going to get from the sponsors. Please stay tuned. I will post the
info as soon as I have something to say.
6. LGM speakers. I would appreciate that people interested in making a
talk at LGM show up on the Create wiki. Some people have contacted me
early by e-mail. Please fill the wiki as well. This is the only sure way
to help me put the schedule together. Also, if you know someone that
would be a good speaker, don't hesitate to propose his/her name. And
don't forget the subject suggestions as well.
7. LGM Brochure (see wiki for details) : we'd like to have each project
described. Cédric Gemy should be able to take care of Inkscape's
description and maybe more. At the same time, if anyone on this list has
images created with Inkscape that we could use to show what the program
can do, please contact me off list. We don't need that many images but
since we're distributed in the graphic designers magazine, the higher
the level the better the effect, imo.
8. If anyone has a question or comment or suggestion, please don't
hesitate to get back to me.
Hope to see you again at LGM2 and of course meet new people!
Louis Desjardins
LGM 2007 organizer
--
Louis Desjardins
Mardigrafe inc.
T 514 934 1353
F 514 934 3698
http://www.mardigrafe.com
16 years, 6 months
NEW: flood fill
by John Bintz
Inkscape now has a very rudimentary flood fill tool. It works by
performing a bitmap-based flood fill on a rendered version of the
visible canvas, then tracing the resulting fill using potrace and
placing the traced path on the canvas. You can access it by the paint
bucket icon in the toolbar. It places the rendered path onto the
current layer, so you can have a layer on top (in my case, "Inks") and
select the layer below ("Colors") and do the fills so that they always
appear below the inks.
This tool is in a very basic state, and there are issues with rendering
accuracy and memory usage. Some improvements that I can see being done are:
* If the [Ctrl] key is held down, clicking on an object changes the fill
color to the current fill color, and [Shift]-[Ctrl] changes the stroke
color to the current stroke color
* A way to either manually or dynamically increase the resolution of the
rendered version so that the accuracy of the flood fill is better
Try it and let me know what you think.
Thanks,
John
16 years, 6 months
0.45.1?
by bulia byak
I think it's time to start working on 0.45.1 - there are lots of
patches in the queue.
However the most frequently reported problem is still not fixed: it
does not work on OSX 10.3.9. Is there anyone on Mac who could look
into this and report if this is fixable at all?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
16 years, 6 months
NEW: cairo rendering in outline mode
by bulia byak
I was curious if cairo is in fact slower or faster than our current
renderer. I didn't feel like converting us totally to cairo yet, but
we have outline mode which is much simpler and perfect for tests like
this. So in about 3 hours (of which 2 hours were spent figuring out a
known bug in cairo) I converted our outline mode rendering to cairo.
The result of this experiment, after I adjusted the tolerance of cairo
to match our outline mode quality, is near parity. That is, cairo is
about as fast as our own renderer, at least for outline mode (i.e.
lots of paths but no gradients or transparency). However this claim
needs to be qualified:
- It is only true for the latest version of cairo (tested with
1.3.14). Versions 1.2.x are noticeably slower.
- This uses image backend to render to a memory buffer, and therefore
cannot use any hardware acceleration. Using hardware-accelerated
backends will require much more drastic changes in Inkscape's
architecture.
- Even with image backend, currently cairo is used _only_ for path
rendering, each path going to its own temp buffer, and these buffers
are later composed together just as they were before. I suspect that
if this is optimized by allowing a single cairo context draw all of
the paths in the drawing into a single buffer, performance will
improve noticeably.
In any case, since this does not make for any speed regression, and
since it fixes at least one bug that our native renderer had in
outline mode, I committed this. Please test outline mode thoroughly
and report if you find any problems. If everything works fine I'll
remove the old outline mode code and will look into doing some further
optimizations.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
16 years, 6 months
Fwd: git on win32
by David Douard
Sorry, I forgot to CC to mailing list
---------- Forwarded message ----------
From: David Douard <david.douard@...400...>
Date: 27 févr. 2007 09:06
Subject: Re: [Inkscape-devel] git on win32
To: "Jon A. Cruz" <jon@...18...>
Another solution might me to use Mercurial. It is very similar (in goals and
day to day use) to git. It is written in Python.
This is the tool we now use at Logilab for all of our projects (for a year
now; we used to use CVS).
Mercurial is incredibly fast (git also I guess). And once you have tasted
disctributed SCM, well, you just can't imaging how you could have do without
it for years...
Seriously, give it a try. Note that the first impression might me
disappointing, but once this step is done, what a pleasure... I used to be a
big SVN fan (I still find SVN a noce tool, but...), but mercurial (ang git
which really is very similar) is an incredible tool for every day work.
This big drawback (for git and mercurial) is the lack of "tortoise" tool on
win32 platform.
http://www.selenic.com/mercurial/wiki/
Note also that there is "all-in-one" mercurial package for win32 .
http://mercurial.berkwood.com/
David
2007/2/27, Jon A. Cruz <jon@...18...>:
>
> On Feb 26, 2007, at 1:58 PM, MenTaLguY wrote:
>
>
> ...and however much of cygwin is necessary to make them all work.
>
>
> -mental
>
>
> Unfortunately I've found that cygwin makes many things significantly
> slower.
>
> My other reservation would just be that git was made to solve certain
> problems that we're not hitting on Inkscape. That point, though, is just
> something I've not looked into.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
16 years, 6 months
Inkscape Project Status
by Bryce Harrington
Just to give some visibility into some of the work bubbling away these
days:
Cairo renderer: Bulia has taken point on investigation of conversion to
Cairo. Some tough problems have been uncovered but we're gaining a
clearer picture of what needs done. Presently this looks like it will
require an all at once brute force approach, rather than incremental
refactoring. If so, we'll need to reach a decision on how to
undertake that while minimizing disruption to SVN HEAD users.
Build system: There is definitely a concensus that our current build
system sucks. Options include CMAKE, Bob's buildtool, or just a
cleaned up automake. We really need to have interested parties mind
meld and find a single solution.
Version control system: Mental has been experimenting with git and
trying to get it to operate with svn. This study is still very early
on, but if it works out well, one day we may begin encouraging
developers to use git.
Bug tracking: I have been experimenting with use of Mantis with the
goal of replacing our SF bug tracker. It looks good, but the
principle issue is how to migrate the bugs and their history from SF
to Mantis. I'm also interested in seeing if it can be combined well
with Drupal, maybe along with Pootle. Any drupalheads out there?
Manual: We've got a good unofficial non-free manual/book and several
[semi-]official incomplete free manuals. There is discussion about if
efforts can be combined to produce a good official free manual.
Anyway, I've probably missed something, but I think that covers the
pending changes that are percolating. Most of these would benefit from
discussion, so we can make sure there is a rough concensus favoring the
change - so if you have concerns about any of these changes, now's a
good chance to bring 'em up.
Bryce
16 years, 6 months
