Multilingual SVG
by Jabiertxo Arraiza Cenoz
Hi All.
I want to improve switch work, to find a way to handle multilenguage
SVG's.
I try to explain whats in my mind to be improved with your thoughts.
*current document is the default document.
*When add a new lang, all contents is cloned/copied into a switch into
his target lang.
*I think clones are paths, ellipses, stars.... and copies are text
elements and groups
*Default document is moved to the default lang in switch.
*Currently inkscape show the switch in current system lang, this
behabiour is good for a viewer but we need a switcher for diferent
langs, so the user pick the lenguage to use and inkscape reloads with
this lang.
Waiting to start, J.
8 years
Hackfest Q&A on git
by Bryce Harrington
On the last day of the hackfest, we discussed git over lunch. A few
folks on IRC had questions about what we talked about, and I figured
there'd be wider interest so am writing this up.
What is motivating us to switch? Is bzr going away?
Development of bzr has stopped. A couple years ago Canonical reassigned
all the bzr devs to other projects, leaving just a skeleton staff to do
bug maintenance (same was done with Launchpad). There had been a time
when Canonical pushed bzr as the Cat's Meow, but I think the realization
has sunk in that git has won the larger hearts and minds war.
bzr is not going away though, near as I can tell. There's no urgency to
move to something else; we can stay with it indefinitely if we want.
But it's a dead end tool. As we recruit new developers we will find
more often they have git experience but not bzr; eventually bzr will be
a detriment to attracting new talent that will prefer to invest their
skills in git. And there's no guarantee Canonical won't pull the plug
on it at some point, regardless.
There are also tons of tools, web applications, and so on being
developed for git. What exists for bzr is in process of bitrotting away
(e.g. I tried to install the rebase plugin last night but it's several
bzr revisions out of date, and did not work.)
Isn't git hard to learn? bzr seems so natural...
git has a reputation for having a high learning curve, and it's
legitimately earned. But most all of us have at least had a little
exposure to git, and there are plenty of good tutorials out there.
git was a struggle for me to learn, so I won't sugar coat it and say
it'll be easy. But I will say if you haven't yet mastered git, then
it's an important software development skill you're going to want to
have beyond Inkscape anyway, since pretty much all other projects use
it.
What about Launchpad and its bzr integration?
One of the reasons we picked bzr was because of its integration with the
bug tracker, and yes that's pretty cool and something we'll lose making
the transition. The good news is that unlike when we switched to bzr,
there are now a number of good web apps and services (github clones, et
al). So we'll have a wealth of options to consider when we get to this
point.
Where will we host the repository? github? freedesktop?
One nice thing with git is that we will have 100% freedom in deciding
where to host the official repo. We can even consider self-hosting it
(e.g. on our website vm). We have lots and lots of options, and plenty
of time to deliberate and decide on a plan.
Can it import our history? tags?
Yep. Lots of projects have preceeded us in bzr->git conversions and
there's a rich set of well tested converter tools available.
Can we still do PPA recipe builds on Launchpad?
Sure can. Launchpad may only host bzr but it has a very good git
importer. So we'd set up LP to import our git branch to a bzr tracking
branch on LP and then it's business as normal.
Can we convert to git ASAP?
I know some people are anxious to move us over to git, and so am I, but
we need to pace ourselves. Changing VCS is going to be disruptive to
everyone, and it will take time before everyone's up to speed with it.
As a project there are other changes which are more pressing, which we
need to give priority to. If we rush into git, we're likely to make
mistakes or at least cause unnecessary frustrations. Planned well, we
can make the transition relatively smooth, and ensure there are
tutorials and tips available as needed.
Bryce
8 years
Re: [Inkscape-devel] Hackfest build-systems discussion]
by Ken Moffat
Whoops, replied to Bryce instead of to all. Let's try sending it to
the list.
On Sun, May 03, 2015 at 03:00:30AM +0100, Ken Moffat wrote:
> On Sat, May 02, 2015 at 06:34:57PM -0700, Bryce Harrington wrote:
> > On Sat, May 02, 2015 at 11:39:34PM +0100, Ken Moffat wrote:
> > > On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington wrote:
> > > > On Wed, Apr 29, 2015 at 02:51:15AM +0100, Ken Moffat wrote:
> > > Yes, cmake -L appears to know what it is doing (noted some things I
>
> > > Building seemed to be going well, until
> > >
> > > [ 65%] Building CXX object
> > > src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o
> > > /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32:
> > > fatal error: gtkspell/gtkspell.h: No such file or directory
> > > compilation terminated.
> > >
> > > And when I look back at the cmake output it says:
> > > -- checking for module 'gtkspell-2.0'
> > > -- package 'gtkspell-2.0' not found
> >
> > What it's doing at that point is shelling out to pkg-config to see if
> > gtkspell is installed.
> >
> > pkg-config --cflags --libs gtkspell-2.0
> >
> > Run ^ that on your commandline and see what it says. If you don't have
> > it installed, install it. :-)
> >
> I know I don't have it installed. If it is now required, I assumed
> cmake would tell me.
>
At this point, I'm looking at r14094. If you will accept that, for
the moment, using ./autogen.sh and configure is still a valid
comparison, then gtkspell is optional. With autogen.sh and
configure I've managed to build it - no sign of gtkspell (nor the
coreldraw, vision, whatever) stuff.
Some hours later, after copious swearing (is that required or does it
only seem to help ? ;-), I think I've found where the problem is.
With the following patch, I can cmake, build and DESTDIR install
inkscape and the man pages, without any additional -D magic. I will
note that inkview did not get installed.
I would have thought that the set line I deleted would have done the
right thing, but for me it didn't.
If this is acceptable, do you need a SoB or equivalent ?
ĸen
--- inkscape/CMakeScripts/DefineDependsandFlags.cmake.orig 2015-05-03 22:06:01.598985260 +0100
+++ inkscape/CMakeScripts/DefineDependsandFlags.cmake 2015-05-03 22:08:03.313995015 +0100
@@ -290,8 +290,9 @@
list(APPEND INKSCAPE_INCS_SYS ${GTKSPELL_INCLUDE_DIR})
list(APPEND INKSCAPE_LIBS ${GTKSPELL_LIBRARIES})
add_definitions(${GTKSPELL_DEFINITIONS})
+ else()
+ set(WITH_GTKSPELL OFF)
endif()
- set(WITH_GTKSPELL ${GTKSPELL_FOUND})
endif()
#find_package(OpenSSL)
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
8 years
cmake next steps
by Bryce Harrington
Several of us now are able to successfully build Inkscape using cmake
only. This is still relatively new, but we need to broaden this to
everyone and make sure it works universally.
Do a 'make distclean' in your repo, update to latest bzr, and then:
$ cmake .
$ make -j8
Hopefully this "just works". If not, read on for troubleshooting tips.
CMakeCache.txt is a listing of all configurable parameters and all
computed values. For settables, you can force them via:
$ cmake -D<VARIABLE>=<VALUE>
If the build craps out during build or linking due to some missing bit
or other, reviewing this file can indicate if it has misdetected an
include or library path or whatnot.
CMakeList.txt is the top level build script, and generally the place to
start for debugging problems. This also is where all configurable
option parameters should be defined.
There is also a src/CMakeList.txt where the source files and header
files are itemized. This also sets up rules for compiling and linking
the executable and its libraries. Similar CMakeList.txt files are
placed in other directories with source.
The CMakeScripts/ directory holds various helper functions. In this
directory is a Modules subdirectory; this is where the logic is held
that finds where various dependencies have their include and library
files located. If you get errors about dependency headers not found
during build, or during linking it can't find definitions of symbols
then there could be an error in one of the Module Find*.cmake files.
CMakeScripts/DefineDependsandFlags.cmake is another important file; this
is where the include path and library options are worked out. This file
is essentially the "glue" that utilizes all the Modules, and propagates
settings up to the top level script.
Beyond this, there is a wealth of cmake tips and examples on the web, so
google will be your friend.
------------------------------------------------------------------------
So what development needs done?
While the cmake scripts work, they're a bit hacky and in need of some
cleanup. Below is a laundry list. I'd encourage everyone to tackle a
task or two, to get some cmake familiarity if nothing else. Once this
work is all done, we can wrap up 0.92 and start the release process.
0. Cleanup definitions. In CMakeLists.txt there are a sequence of
add_definitions() to set some environment variable definitions.
Some of these may not be strictly needed, others could be moved to
DefineDependsandFlags.cmake or to the respective Modules files.
1. Win32. Someone needs to try this against our supported win32
platforms, and fill in the missing logic that is specific to Win32.
2. More files. A lot is missing from the build... tests, man files,
icons, locale. If it's not clear how to do the logic for this
stuff, refer to another cmake-based project.
3. More Modules. In DefineDependsandFlags.cmake we just brute force
several libraries (to pick a few examples: pangocairo, gthread,
gomp, gslcblas...) These need to have proper Find<Library>.cmake
scripts made. Generally these are pretty easy - just make it
wrapperize pkgconfig. FindGtkSpell.cmake has a simple example.
Google "cmake <library>" before you do any work though; sometimes
someone has already done the logic and you can just copy.
4. Update Modules. Several of our modules were taken from cmake or
elsewhere, a long time ago, and they've improved upstream since
then. Snag newer versions, test, and add to our codebase. If we
have local changes consider pushing those upstream.
5. Add more configuration options. Review what we offer in automake
and make sure the equivalents are defined in CMakeLists.txt
6. Verify that uninstall works
7. Fix dist. In CMakeLists.txt it adds a custom svn command; this
needs replaced with the equivalent bzr. And in general run
'make dist' and hack on it until it produces a proper tarball.
8. Identify other issues needing resolved. I notice FIXME's peppered
here and there in various files. We'll want to tackle those or at
least plan those tasks for later on.
Bryce
8 years, 1 month
Hackfest build-systems discussion
by Alex Valavanis
Summary: We propose making CMake our recommended build system for
Inkscape 0.92 onwards and removing our Autotools support in 0.93. We
will also consider moving to Waf in future if it seems beneficial.
Any comments are warmly welcomed, particularly from Windows and OS X
users.
----
Hi All,
At the Hackfest, we have discussed some options for improving our
build systems and would like to invite your comments.
== Present situation ==
At the moment, we provide both Autotools (autoconf, automake etc) and
CMake, but our main focus has been on Autotools. This is causing a
significant maintenance challenge for the following reasons:
1. The syntax of the Autotools configuration files is rather complex
and uses a mixture of the M4 Macro processing language, and bash
scripting which is hard to understand/edit/debug
2. Numerous configuration files are needed to support both build
systems. This adds a significant maintenance burden whenever e.g.,
files are added/removed or package version numbers change
3. The Autotools configuration is pretty slow, and parallelisation
overheads are quite high
4. The CMake builds tend to be fairly neglected, and are not very
actively maintained.
== Proposal ==
We would like to focus on a single build system. CMake is more widely
understood than Autotools and it should be easier for more people to
manage our conditional build configuration.
As a first step, we could focus on improving the CMake build and
recommending this as our default option for the next Inkscape release
(0.92). We could then remove our Autotools build system entirely from
Inkscape 0.93 onwards.
Another potential option for future releases is the Waf system, which
offers very good wildcard handling and potentially even simpler build
configuration. However, I think it would make sense to stabilise our
existing CMake build before we start moving to anything new
== Portability ==
We need to determine whether the CMake builds work well on OS X and
Windows systems. Any comments from users of those systems would be
greatly appreciated.
Best wishes,
Alex
8 years, 1 month
New Intiative FreieFarbe/FreeColour announces Open Colours Systems Collection 1.0
by "Christoph Schäfer"
I'm pleased to introduce a new member to the Libre Graphics Community: the German initiative FreieFarbe / FreeColour.
Please take note of their initial announcement below.
Christoph
===============
Announcement: Project FreieFarbe / FreeColour has been launched and Open Colour Systems Collection 1.0 has been released
Websites: www.freiefarbe.de and www.freecolour.org
FreieFarbe / FreeColour is a loose association of (until now) German-speaking colour professionals of all stripes, from designers to software developers. FreieFarbe / FreeColour intends to promote colour communication, and its interests aren't primarily commercial.
==Liberating Colour==
The founders of FreieFarbe / FreeColour are convinced that currently available proprietary and aggressively protected colour systems, like Pantone, NCS et al., aren't the best solutions to handle colour.
Hence FreieFarbe's / FreeColour's dedication to promote and work on the following objectives:
- Making colour literally and metaphorically calculable;
- Making existing and future colour system comparable;
- Simplifying colour communication;
- Overcoming excessive licensing, copyright and trademark protections for colours by providing better and open alternatives;
- Creating an online resource pool with the necessary knowledge for consistent colour workflows;
- Making the "mystery" that is colour comprehensible.
In other words: It wants to *liberate colour from its proprietary chains*.
FreieFarbe / FreeColour is open to everyone who is interested in contributing and willing to share personal or professional knowledge with a wider public.
==The Future: CIE L*a*b* and HLC==
One step to liberate colours is the universal adaption of the CIE L*a*b* colour model, and this includes end users. Since CIE L*a*b* isn't very intuitive, FreieFarbe / FreeColour also promotes the use of the HLC (Hue, Lightness, Chroma) colour definition, which is easier to handle than pure L*a*b*. From a user point of view, it's similar to HSV in the RGB colour model, but much more reliable and flexible.
==Open Colour Systems Collection (OCSC) 1.0 Available for Download==
As of today, one of the founding members of FreieFarbe / FreeColour, Holger Everding, CEO and owner of dtp studio oldenburg, a German company specialised in colour software, has made available a collection of more than 350 commercial colour systems under a Creative Commons licence: The Open Colour Systems Collection (OCSC) 1.0. These colour palettes can be freely distributed with all Libre Graphics programmes.
Please note that the digital colour values in these palettes aren't necessarily identical with the official ones provided by the respective colour vendors. Instead, they are based on a sophisticated spectrometric measuring procedure of the official physical colour references (fans, swatches etc.). Thus, they are potentially even more "correct" than the official vendors' palette files. Also note that, for obvious reasons, the "big" colour systems (Pantone, RAL, NCS etc.) are not included, but it's more than a start. The colour systems cover all kinds of use cases: print, foils, paint, varnish, textiles and many more.
Regarding the licence, dtp studio decided to use a rather restrictive CC version: CC BY-ND 4.0. The simple reason for this choice is that users across programmes and platforms need to be assured that they are working with the same colour values when using a specific palette. In other words: It's an important part of the "colour communication" objective.
The colour palettes in dtp studio's proprietary software products were originally in the company's proprietary BCS binary format. These BCS palettes were accompanied by plain text and image files, which are being read by the respective programmes at runtime.
By contrast, the Open Colour Systems Collection is available in Swatchbooker's SBZ format. FreieFarbe / FreeColour and dtp studio are aware of the fact that the SBZ format isn't widely supported yet, but it seemed to be the only format that was fit for purpose:
- It allows for storing CIE L*a*b* values (since all Open Colour Systems Collection files use this colour model);
- It allows for storing metadata, including: description, copyright and licensing information, as well as metadata translation (the descriptions of the palettes are currently being stored in English and German in each file);
- There exists a reference implementation in the form of Swatchbooker;
- Since SBZ files are ZIP archives, it was possible to add a preview (a photograph of the real world colour fans or swatch) to most of them.
FreieFarbe / FreeColour and dtp studio would be pleased to cooperate with the Libre Graphics Community on improvements to the SBZ format, its eventual standardisation, or the development of better alternatives. Both would also be glad to explore future fields of cooperation with respect to the objectives mentioned above, including code development.
On behalf of FreieFarbe / FreeColour and dtp studio oldenburg
Holger Everding
8 years, 1 month
FreeHand
by Jabier Arraiza (Marker)
Hi
Any one cold give suport to freehand is a common program in my city.
I see about two people. They also do this on LGM "Document Liberation
Project: One year after" I think our visio import for symbols is using
it.
They say freehand suport is incomplete, but looks like now is better
than no one.
Im not familiar whith that part of inkscape and think my work could be
better inverted in other places like do nothing ;)
Regards, J.
El sáb, 02-05-2015 a las 14:23 +0000, noreply@...1881... escribió:
> ------------------------------------------------------------
> revno: 14093
> committer: ~suv <suv-sf@...58...>
> branch nick: inkscape
> timestamp: Sat 2015-05-02 16:23:11 +0200
> message:
> cmake: add support for librevenge-based input formats (WPG, Visio, CDR)
> added:
> CMakeScripts/Modules/FindLibCDR.cmake
> CMakeScripts/Modules/FindLibRevenge.cmake
> CMakeScripts/Modules/FindLibVisio.cmake
> modified:
> CMakeLists.txt
> CMakeScripts/DefineDependsandFlags.cmake
> CMakeScripts/Modules/FindLibWPG.cmake
> config.h.cmake
>
>
> --
> lp:inkscape
> https://code.launchpad.net/~inkscape.dev/inkscape/trunk
>
> You are subscribed to branch lp:inkscape.
> To unsubscribe from this branch go to https://code.launchpad.net/~inkscape.dev/inkscape/trunk/+edit-subscription
8 years, 1 month
