Libre Graphics Day miniconf - Call for Participation
by unknown＠example.com
Libre Graphics Day is a one day miniconf at linux.conf.au
in Wellington, New Zealand on Monday 18th January, 2010.
This is a broad call to participate!
Do you develop, use, document, or train with Free Software Graphix
tools? Tools such as GIMP, Inkscape, Scribus, Blender, Krita, Sk1,
Fontforge and Fontmatrix. Are you involved in the testing and
development of the sub-systems and libraries on which these apps
depend?Submit proposal now!
* The X Window system
* GEGL, Hugin, Oyranos
* I/O devices and drivers; tablets, mice, keyboards, monitors,printers
* Colour and Font Management
* Cross-platform tools - developing for multiple platforms
* Open Standards and file format interoperability: PDF, SVG, PNG etc
* Open Content: clip art, fonts, creative commons, etc
Perhaps you can share expertise in the 'How' of Libre Graphics? Could
you talk about Design techniques and workflow? Pre-press, or Themes and
Skins for open source web frameworks. What about Digital asset
management? What about the Why? Communication strategy and effective
marketing using graphic design. Open Source publishing? What about
Digital Art just for Art's sake? Perhaps you have other ideas that
relate to Libre Graphics?
Please participate in our miniconf!
We're calling for presentations related to Free Software in the Graphics
domain, and aim to provide an environment for cross-project
collaboration to build understanding of shared problems, and work
towards shared solutions. Most of all, we just wanna have fun, and bring
some of the Libre Graphics Love to the southern hemisphere.
Submit a Proposal
-----------------
To submit a proposal for participating in the LGD miniconf at
linux.conf.au 2010 go to
http://www.libregraphicsday.org/submit-proposal
Call for Participation closes Friday 25th September!
Libre Graphics Day
------------------
For the past four years Libre Graphics Meetings (LGM) have allowed
developers, users and supporters of free graphical applications of all
kinds to get together to discover, share and collaborate. However,
scheduling has not made it easy for those not close enough to attend.
This miniconf will bring the LGM experience to those almost literally on
the far side of the globe from LGM 2010.
Not only will this serve the developers working on graphical
applications, drivers and technology who make up a portion of the core
linux.conf.au audience, but it will also bring in many users, artists,
graphic designers and potential open source users. Developers of
different projects will be able to learn from and collaborate with other
projects, while also gaining insight on some of the uses artistic end
users discover. Users will have a chance to gain insight into the open
source development process while at the same time giving them an
opportunity to provide feedback and input directly to the developers of
projects they might use.
Miniconfs at linux.conf.au are unable to accept sponsorship. However, if
you wish to support linux.conf.au, the conference sponsorship team would
love to hear from you. For more info see
http://www.lca2010.org.nz/sponsors/why_sponsor
libre graphics meeting
----------------------
The fifth edition of the Libre Graphics Meeting (LGM) will take place in
Brussels, Belgium. In May 2010, users and developers of Free, Libre and
Open Source creative software gather in the European capital for the
collective sharing of creativity, innovation and ideas.
The Libre Graphics Meeting exists to unite and accelerate the efforts
behind Free, Libre and Open Source creative software. Since 2006, this
annual meeting has been the premiere conference where developers, users
and supporters of projects such as GIMP, Inkscape, Blender, Krita,
Scribus, Hugin, the Open Clipart Library, and the Open Font Library
gather to work on interoperability, shared standards, and new ideas.
Work at prior LGMs has pushed the state of the art in important areas
such as color management, cross-application sharing of assets, and
common formats.
Face-to-face meetings and opportunities for collaboration are important
to developers and users alike; in the form of tutorials, talks,
workshops, and birds-of-a-feather (BOF) the event offers many formal and
informal opportunities to interact.
About linux.conf.au
-------------------
linux.conf.au is one of the world's best conferences for free and open
source software! The coming linux.conf.au, LCA2010, will be held at the
Wellington Convention Centre in Wellington, New Zealand from Monday 18th
January to Saturday 23rd January 2010. LCA2010 is fun, informal and
seriously technical, bringing together Free and Open Source developers,
users and community champions from around the world. LCA2010 is the
second time linux.conf.au has been held in New Zealand, with the first
being Dunedin in 2006. linux.conf.au is made possible by the generous
support of our Conference Sponsors
About Linux Australia
---------------------
Linux Australia is the peak body for Linux User Groups (LUGs) around
Australia, and as such represents approximately 5000 Australian Linux
users and developers. Linux Australia facilitates the organisation of
this international Free Software conference in a different Australasian
city each year.
13 years, 8 months
DVCS Discussion & Vote
by Joshua A. Andler
I guess the question at this point is what does git have over bzr? To me
it seems like there is more benefit to bzr than git for our project. So,
if you want to discuss, go for it... Let's vote otherwise.
Josh: BZR
13 years, 8 months
Fwd: [Bug 238796] Re: Display mode toggle needs update to all 3 modes
by the Adib
Again, pls. review and commit the patch. Thx, Adib.
Is there any new TODO list for the 0.47 release?
---------- Forwarded message ----------
From: theAdib <theAdib@...1439...>
Date: Sun, Sep 13, 2009 at 2:25 AM
Subject: [Bug 238796] Re: Display mode toggle needs update to all 3 modes
To: theAdib@...1439...
attached patch cycles through all 3 display modes normal->without
filters->outline
pls test.
HTH, Adib.
** Changed in: inkscape
Status: Confirmed => In Progress
** Changed in: inkscape
Assignee: MenTaLguY (mental) => theAdib (theadib)
** Attachment added: "BUG238796_display_toggle.patch"
http://launchpadlibrarian.net/31734073/BUG238796_display_toggle.patch
--
Display mode toggle needs update to all 3 modes
https://bugs.launchpad.net/bugs/238796
You received this bug notification because you are a bug assignee.
13 years, 8 months
Re: [Inkscape-devel] DVCS Discussion & Vote
by JiHO
> > Tidying history is helpful. It enables people to go off on
> > experimental tangent branches knowing that they can bring order out of
> > chaos when they're ready. It also means that we don't have to have
> > patches merged that break inkscape. It's good to keep a clean history,
> > and you can use bisect to find problems in that case.
>
> Uhm, I don't see how changing the number of revisions would effect how
> the patch applies in any case. Neither would which changing which
> revision the branch started on.
I don't think Max was saying that, when you are on a personal branch,
you might commit something that you later discover breaks Inkscape.
Git allows you to reorganize/rework your commits before they are
pushed, so that each of your commits leaves Inkscape working. That
way, when you merge back in trunk, all revisions are valid. This
seemed like the goal of the svn trunk at some point: always have the
development version working because some people use that for actual
work.
> I assure you that I go on experimental tangent branches regularly,
> that's simply the kind of person that I am. The histories there are
> still important even though you'd never see them unless you started
> really delving into the revision history to see each commit. When I
> merge it into main is when I write a more useful message about what
> really changed, as most people only look at the history of trunk anyway.
I am not sure whether this is specific to git or a general behaviour,
but in git, when you merge back a branch, you see its full history in
the trunk, not just the merge commit. For example, let say your
history is something like (best viewed with a fixed width font):
master: A--B-------C-------D--
\ /
branch: \--A'---B'--/
A,B,C are commits on the master (=trunk); A',B' are commits on the
branch; D is your merge commit. After the merge, "git log" on the
trunk will show:
D
B'
C
A'
B
A
You get all the commits, in chronological order, *including* those on
the branch. So you don't "only look at the history of the trunk". Of
course git keeps a memory of what was on the branch and what was on
the master but you still see everything from the master. This is a
reason why it is sometimes interesting to rework your branch history
before a merge. I don't know whether this is a feature or a drawback,
but this is the way (I think) it works.
JiHO
---
http://maururu.net
13 years, 8 months
Re: [Inkscape-devel] DVCS Discussion & Vote
by Ted Gould
On Wed, 2009-09-16 at 08:27 -0500, Aaron Spike wrote:
> Ted Gould wrote:
> > On Tue, 2009-09-15 at 21:31 -0400, bulia byak wrote:
> >> Instead of a vote, I have a question: Ted, what was the piece of
> >> software with which you did that horrendous hole in our SVN history,
> >> erasing many past revisions of many files? Was it bzr? If so how can
> >> we be sure this never happens again? Sorry to bring it up again but I
> >> run into this "black hole" quite often when I do research in our code
> >> and it's really a sore spot.
> >
> > It was bzr-svn.
>
> I thought we had seen problems with SVK. Hadn't heard about bzr-svn
> problems. It does make quite a bit of sense that DVCS -> VCS would be a
> lossy operation. Another reason to switch.
We had some problems with the way that SVK does things as well. But,
that wasn't the issue that Bulia was referring to :)
I was able to work with the bzr-svn developers to get the necessary
fixes in so that it would import the Inkscape repository even with the
SVK-isms in it.
--Ted
13 years, 8 months
Re: [Inkscape-devel] SPAM-LOW: Re: DVCS Discussion & Vote
by Ted Gould
On Tue, 2009-09-15 at 05:12 -0700, joel@...1709... wrote:
>
> > You can do most of that with the bzr-rebase plugin, but I'd
> recommend
> > against it. Honestly, the only reason I've seen to reorder commits
> is
> > to lie and say you never make mistakes, or to clean up a
> visualization
> > to make it look better. I don't think either of those are good
> reasons
> > to "change history." I'm kinda a historian on that point, it seems
> like
> > history is history -- leave it alone :)
>
> Tidying history is helpful. It enables people to go off on
> experimental tangent branches knowing that they can bring order out of
> chaos when they're ready. It also means that we don't have to have
> patches merged that break inkscape. It's good to keep a clean history,
> and you can use bisect to find problems in that case.
Uhm, I don't see how changing the number of revisions would effect how
the patch applies in any case. Neither would which changing which
revision the branch started on.
I assure you that I go on experimental tangent branches regularly,
that's simply the kind of person that I am. The histories there are
still important even though you'd never see them unless you started
really delving into the revision history to see each commit. When I
merge it into main is when I write a more useful message about what
really changed, as most people only look at the history of trunk anyway.
--Ted
13 years, 8 months
Re: [Inkscape-devel] Inkscape-devel Digest, Vol 40, Issue 22
by Ashmi Shah
I did my research. I stand corrected. The new operating system from
Microsoft after Vista is not called System 7. They call it Windows 7.
We are very interested in learning whether InkScape and GIMP will provide
appropriate vector and raster information to our Windows compatible printer
type driver for job processing on different types of machines.
Thanks in advance.
Ashmi
Solustan, Inc.
On Mon, Sep 14, 2009 at 4:43 AM, <
inkscape-devel-request(a)lists.sourceforge.net> wrote:
> Send Inkscape-devel mailing list submissions to
> inkscape-devel(a)lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> or, via email, send a message with subject or body 'help' to
> inkscape-devel-request(a)lists.sourceforge.net
>
> You can reach the person managing the list at
> inkscape-devel-owner(a)lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Inkscape-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Since release is nearing, let's talk 0.48 and beyond...
> (Alexandre Prokoudine)
> 2. Re: Since release is nearing, let's talk 0.48 and beyond...
> (Joshua A. Andler)
> 3. Re: *sigh* icons (Jon A. Cruz)
> 4. Re: *sigh* icons (Alexandre Prokoudine)
> 5. Re: Since release is nearing, let's talk 0.48 and beyond...
> (Valerie)
> 6. Re: Does inkscape use windows GDI for printing? (Tobias Jakobs)
> 7. Re: *sigh* icons (Jon A. Cruz)
> 8. Re: Current TODO for 0.47 discussion (~suv)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Sep 2009 10:45:08 +0400
> From: Alexandre Prokoudine <alexandre.prokoudine@...400...>
> Subject: Re: [Inkscape-devel] Since release is nearing, let's talk
> 0.48 and beyond...
> To: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net>
> Message-ID:
> <733f2c730909132345s5f7695a4wa054b2a0fb2bbda9@...401...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Sep 14, 2009 at 10:38 AM, Joshua A. Andler wrote:
>
> > The point releases have a place... we should have had a couple for 0.46
> > honestly. If you would like to point fingers, I am willing to take the
> > blame for it as I was a release warden for it and for this release.
>
> No fingers, no blame. The long 0.46/0.47 development cycles got quite
> a few important contributors burnt out. We need to learn to deal with
> it, IMO.
>
> > P.S. Move continents all you want Alexandre, I'll nag you wherever you
> > go. ;)
>
> That goes without saying :)
>
> P.S. Thank you for posting 0.47 screenshots btw!
>
> Alexandre
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 13 Sep 2009 23:49:24 -0700
> From: "Joshua A. Andler" <scislac@...400...>
> Subject: Re: [Inkscape-devel] Since release is nearing, let's talk
> 0.48 and beyond...
> To: Krzysztof Kosi?ski <tweenk.pl@...400...>
> Cc: inkscape-devel(a)lists.sourceforge.net, bulia byak
> <buliabyak@...400...>
> Message-ID: <1252910964.4270.114.camel@...2139...>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, 2009-09-13 at 18:08 -0700, Krzysztof Kosi?ski wrote:
> > I vote for bzr
>
> Noted
>
> > > Additionally, if we could get cairo work in a
> > > branch (under said DVCS) during this cycle, it would be excellent to
> > > possibly get something to drop in for the 0.49 dev cycle
> > Is there any plan on how we're going to do this? Do we write a new C++
> > library that is similar to libnr but nicer to work with and uses Cairo
> and
> > 2Geom internally, or rip out rendering code from libnr and replace it
> with
> > Cairo operations?
>
> bulia, can you please comment on what you think would be the best course
> of action given your experiments/testing? I know you've been going it
> along in this department for quite a while which is why I proposed
> getting a branch going... I'm sure others would love to help make it
> happen.
>
> Cheers,
> Josh
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Sep 2009 00:01:19 -0700
> From: "Jon A. Cruz" <jon@...18...>
> Subject: Re: [Inkscape-devel] *sigh* icons
> To: Alexandre Prokoudine <alexandre.prokoudine@...400...>
> Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net>
> Message-ID: <D546B4A6-63EB-4C61-8B72-5B06258E73F6@...18...>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Sep 13, 2009, at 11:38 PM, Alexandre Prokoudine wrote:
>
> > On Mon, Sep 14, 2009 at 10:04 AM, Ted Gould wrote:
> >
> >> The icon specification provides for things like fall back icons and
> >> for
> >> icon themes providing their own set of fallbacks. So most icon
> >> themes
> >> that ship today are actually a base set, with a fallback to a more
> >> complete set that is similar. Also, many applications ship with a
> >> default set of icons that the theme can override. Sure, in those
> >> cases
> >> GIMP and Inkscape wouldn't match, but that's no worse than we have
> >> today.
> >
> > But what we have *today* is Inkscape *always* using its default
> > theme :)
> >
>
> No.
>
> If external icons with the given names are present in the directory
> set, then those will override the internal ones.
>
13 years, 8 months
*sigh* icons
by Alexandre Prokoudine
Hi,
Could anybody please explain how one could get Tango icons back? The
last thing I heard is that one should be using Tango icons on system
level to get them in Inkscape. Well, I switched to Tango theme in
GNOME prefs and I still see the default icon theme. I don't mean to
ask for a new feature this close to releasing, but for future - just
how difficult would it be to add a simple switcher in Preferences and
get rid of this brain damage forever? :)
Alexandre
13 years, 8 months
Does inkscape use windows GDI for printing?
by Ashmi Shah
(1) Our company builds Windows compatible user level drivers for XP, Vista,
and System 7 versions. These drivers accepts vector information from
programs like Corel Draw and control the following:
- Engraving machines
- CNC milling machines
- Vinyl cutting machines
- Generates G codes for most popular CNC controllers
-Torch cutting machines
- Waterjet cutting machines
- CO2 laser cutting and rastering machines
Basically, we convert vectors to motion control commands in many different
ways.
Also, we could similarly use GIMP to accept the information and generate
raster control commands for laser machines.
Generally, programs like Corel Draw, AutoCAD, Illustrator, and others work
with Windows GDI architecture. GDI passes the vector and raster information
to our driver and we control machines.
The potential is literally thousands of copies of Inkscape and GIMP all over
the world.
We need to unfill all the shapes, designs, and text in Corel Draw, for
example, and make sure that the line widths are hairline (0.001 inch, I
believe). The definition of hairline varies with different programs.
However, it should be such that GDI is told to interpret the information as
vectors.
Can our users use Inkscape and GIMP in place of Corel Draws of the world to
provide proper info to GDI and in turn to our drivers?
We noticed that the version 0.46 of inkscape was able to print to a
HPLaserjet type laser printer. Most programs can work with our driver if
they can print to laser printer.
What do we need to do to make this happen?
(2) Does Inkscape work with the following operating systems?
- Windows XP
- Windows Vista 32 bit
- Windows Vista 64 bit
- System 7 32 bit
- System 7 64 bit
(3) This question was first presented to the launchpad inskscape question
#82515. It was suggested that we should ask the same question to the
developers at this address. We are available for phone discussions, if
necessary, during the working hours.
Ashmi Shah
Solustan, Inc.
www.solustan.com
781-449-7666
--
ashmi
13 years, 8 months
Re: [Inkscape-devel] Since release is nearing, let's talk 0.48 and beyond...
by Valerie
On Sun, 2009-09-13 at 23:09 -0500, Ted Gould wrote:
> On Sat, 2009-09-12 at 23:16 -0700, Joshua A. Andler wrote:
> > One thing that Debian is considering is fixed dates for freezes.
> > So they'd do a freeze on a fixed schedule, and then
> > release when it's ready. I'm curious if this might work for us
> > long term, certainly with a DVCS we'd have more flexibility there.
>
> Interesting approach... I think that this may work for us
> too after 0.49 since it may be a little unpredictable with
> the library changes.
It'd probably be a good idea after 0.49, yes, after major tasks such
as library change is complete.
Open source projects often push back the release date so that
they can stabilize all the features they have added during
the development cycle (and even then, some don't make it on time
anyway).
To the user, the choice is pretty simple though:
- In 6 months, you get to access Feature A, and 6 months after
that, you get to access Feature B, or:
- You get to access Features A and B in 1 year.
Those 6 months with "just" Feature A isn't pointless,
it may mean hours of work saved, or that the user could accomplish
things that he couldn't have otherwise. For some users, the
absence of a crucial feature can be just as crippling as a bug.
Good thing for the Development version, though that's not a
solution for everybody.
13 years, 8 months
