Nem feledve, hogy Windows és Macintosh platformokon is erős felhasználói bázissal rendelkezik, mégis kimondhatjuk, hogy az Inkscape a Linux operációs rendszer saját vektorgrafikus szerkesztőjévé vált. Itt az új verzió.

Csak néhány a legfontosabb változások közül:

• új távolság- és szögmérő eszköz;
• többszálú feldolgozás, az SVG szűrők gyorsabb megjelenítése;
• félkövér és dőlt változatokon túli betűváltozatok támogatása;
• Corel DRAW, EMF és WMF állományok beolvasása — jelentősen továbbfejlesztve;
• Microsoft Visio diagramok és jelek importálása;
• valós lapméretekhez használt mértékegységek;
• szimbólumkönyvtárak az újrafelhasználható rajzelemekhez;
• Cairo-alapú megjelenítés és .PNG export.

Egy rövid kis videó az új vagy továbbfejlesztett szolgáltatásokról, melyek a kedvenceink:

Néhány használhatósági fejlesztés, ami megkönnyíti majd az életünket:

• A rétegek fogd és vidd módszerrel átméretezhetőek.
• A szerkesztőmód fogantyúméretei beállíthatóak, mely a csomópontok mozgatásánál vagy a lekerekített sarkú téglalapoknál lesz szembetűnő (Szerkesztés -> Preferences -> Input/Output -> Input Devices -> Handle size).
• Gyorsbillentyűk átkonfigurálhatóak a Preferences (Tulajdonságok) párbeszédablakban.
• Mint más illusztrációs programokban, a rajzvászon a Space billentyű lenyomásával továbbcsúsztatható, elmozdítható (panning).
• A Felosztás halmazművelet használható síkidomok és útvonalak között is.
• A kijelölt objektum kitöltéséhez vagy körvonalához hasonló tárgyak kijelölése.

Néhány kevésbé szembetűnő funkció, mint az SVG-szűrők élő előnézettel rendelkező finombeállításai:

És még folytathatnánk. Az Inkscape 0.91 az előző verzióhoz képest nagy előrelépésnek látszik. Hogy belássunk a színfalak mögé, megkérdeztük Bryce Harrington-t és Tavmjong Bah-ot az Inkscape fejlesztésének vezetőit.

Inkscape 0.91 sok szempontból hosszú várandósság után született. Többen kértek benneteket régebben, hogy rövidítsétek a kiadási ciklusokat. Mire számíthatunk a jövőben?

Tavmjong: A 0.91-es megjelenése egy meghatározó változással járt — a program grafikus megjelenítése a Cairo függvénykönyvtárra váltott. Olyan ez, mintha egy kasznin belül motort cserélnénk. Sok idegességgel jár, amíg mi is kitapasztaljuk az összes hibalehetőséget. Ezek közül a legnagyobb a bitképek nagyításánál jelentkezett, mely a Cairo-ban jó ideig nem volt megfelelően kidolgozva. Amíg ez megvalósult, átbütyköltünk “néhány dolgot” az Inkscape saját kódbázisában — ez sem egy kis dolog.

Bryce: Ahogy mondod, számos oka volt, amiért ez a kiadás olyan sokáig tartott. S még van sok tényező, amit meg kell oldani, hogy legközelebb gyorsabban menjen. Ki is emelnék ezek közül néhányat:

Ha van egy jól meghatározott ütemterved, vissza kell fogni magad, nehogy túlságosan sok nagy változtatást vigyél egy menetben a munkádba. Vagy úgy dolgozol, hogy egy fejlesztés áthömpölyög sok kisebb kiadáson — bár közben nem jól használható –, vagy az rendesen megcsinálod, s csak akkor jelenteted meg.

Mi szeretjük visszatartani magunkat, nehogy úgy menjen ki egy verzió, hogy nem használható. Amikor bejelentünk egy nagy változtatást, időt fog jelenteni, amíg minden a helyére kerül. Ha sokat akarunk változtatni, mindet meg kell várni, míg elkészül.

Szükség van néhány fejlesztésre a munkafolyamatunkban, ami leegyszerűsíti a megjelentetési fázist. Például most, hogy össze tudj hozni egy új csomagot, úgy kell összefogdosni egy tucat állományt, mivel különféle fordítókat használunk, létrejön egy csomó össze nem illő konfigurációs állomány. Oké, ezeket egységesíteni kéne, szkriptelni a megvalósítási folyamatot, s ez töredékére csökkentené a rabszolgamunkát.

A jövőben egy-egy nagyobb változtatást kisebb, könnyebben kezelhető, önmagában is használható lépésre kell felbontanunk.

Az Inkscape 0.41-es verziója óta, ami 2006-ban jelent meg, volt némi teljesítménynövekedés. Az Inkscape ennek ellenére nem kezeli elég jól a nagyméretű dokumentumokat, sok objektummal és csomóponttal. Tudsz erre valamilyen megoldást? Talán az SVG szab ilyen korlátokat — ahogy néhány fejlesztő állítja?

Tavmjong: Nem gondolnám, hogy az SVG lenne ebben a ludas. A mi kódunk nem elég hatékony. Tegyél csak egy PRINT utasítást az egyik függvénybe véletlenszerűen, aztán nézd meg, hányszor hívják meg, miközben végigcsinál egy olyan egyszerű műveletet, mint egy csomópont elmozdítása. Túl sok esemény van, amit közben kezelünk. A kódunkból hiányzik a megfelelő dokumentáció, sok helyen nehezen követhető a folyamat.

Bryce: A teljesítményelemzés szerint nem szabad addig kidolgozni a megoldást, amíg nem értjük a problémát, emiatt én nem adnék erre még konkrét választ. Könnyebb itt-ott javítgatni a kódot, míg a felhasználói élmény elég alacsony szinten marad — de legalább működik.

Szükség van egy csomó terheléses vizsgálatra: nagy fájlok betöltésére, zoomolásra, színátmenetek változtatására. Vannak eszközök, amik ilyen esetekben a teljesítményt vizsgálják, beazonosítva az optimalizálási lehetőségeket. Ez egy csomó unalmas rabszolgamunkával jár, de nagy lehetőség annak, akit ez érdekel 😉

További kemény munka egyszerűsíteni a program logikáját, átállni hatékonyabb algoritmusokra, stb. Aztán meg kell vizsgálni, hogy ezek a változtatások összesítve nem okoznak-e inkább visszaesést az eredeti állapothoz képest.

Félretéve ezeket a bonyolult folyamatokat, vessünk egy pillantást a megjelenítő algoritmusokra, a renderelésre. Egyre több megbeszélésünkben előkerült a Cairo grafikus könyvtár, mint lehetőség, ha már más nem adódik. Ebben az irányban indultunk el…

Évek óta érezhető a nyomás, hogy az Inkscape legyen képes helytállni a professzionális nyomdai munkákban — CMYK színrendszer használata, direkt színek, nyomdai PDF. A Cairo-ra való átállással sokan úgy vélik, ennek az utolsó esélye úszott el. A Scribus nem ezt használja, hanem saját függvénykönyvtárat fejlesztett, mely viszont annak dokumentumrendszerére épül. Hogy látjátok ezt?

Tavmjong: Nem gondolom, hogy a Cairo rossz architektúra lenne erre a feladatra, de még sok minden hiányzik belőle. Kéne valaki, aki a nyomdai irányba kezdi fejleszteni.

Bryce: Jó eséllyel lehetne erre valamilyen támogatásos rendszert kitalálni, hogy valaki foglalkozzon is ezzel.

A következő állomás a 0.92-es verzió. Sok érdekes újítást látunk. Mi a legfontosabb?

Bryce: Nekem személyesen az, hogy meghatározzuk az ütemtervet, aztán elkezdjünk megalapozni egy adománygyűjtést a program fejlesztésére. Ezután kezdődhet az új verzió létrehozása. Egyelőre az előbbi még jobban lefoglal.

Tavmjong: Az én kedvencem viszont az SVG 2 specifikációjának automatiusan alakzatba folyó szövege.

Hogyan működik a fejlesztési és döntéshozatali rendszer manapság a projekten belül?

IDÁIG SIKERÜLT FORDÍTANI………………………………………………………………………………

Akinek van ideje, kedve, folytathatja a kommentekben…

Tavmjong: Mostly, the people doing the work decide. We’ve always had a very open policy to checking in code. We haven’t had any time where a major piece of code has been checked in that the community has balked at.

Bryce: Make a proposal, get it peer-reviewed, and when the consensus is in favor, then bang out the code, and land it, when you feel it’s ready.

I believe that the people doing the work deserve the decision making power. Given that release work and board stuff consumes nearly all my available freetime, this means I pretty much defer feature idea decisions to other folk that are actually touching the code.

I facilitate and break logjams here and there when asked, but the project seems to be pretty good at reaching consensus collaboratively and making decisions collectively. Aside from perhaps nailing these decisions down into a roadmap, I see no reason to change how things are done.

In big projects like Inkscape, there’s usually some internal work going on. What are the biggest under-the-hood changes lately and what still needs doing? How do these changes affect the “front-end”, the user-visible part?

Tavmjong: There has been some code clean-up. For example, I reworked the style handling code to make it easier to maintain. I’ve also added a lot of SVG 2 things which for the moment are hidden (see next question).

Tav, for the past several years you’ve been actively involved with the development of SVG 2. What do you think are the most user-visible benefits of this that one could lay his/her hands on in 0.91 or, possibly, 0.92?

Tavmjong: In 0.91, there is very little user-visible benefits as the SVG 2 features that are supported in rendering are not exposed to the GUI (CSS blend modes, stroke behind fill, arrowheads that automatically point the right way, markers that automatically match stroke color, etc.).

Before adding these new things to the GUI either one of two things need to happen: 1) there must be widespread browser support for the feature or 2) we need to provide an SVG 1.1 fallback for it. We don’t have at the moment a framework for providing SVG 1.1 fallbacks.

Does it affect features like extra blending modes too? There’s a quite a lot of people dying for soft light etc. support.

Rendering support for all 16 CSS blending modes is there using the ‘mix-blend-mode’ property. Additional blending modes are also supported in filters. None of this is exposed via the GUI.

What’s the deal with gradient meshes, and why was this feature disabled for 0.91?

Meshes are not turned on for a variety of reasons: the specification is not 100% stable (there was a recent “bike-shedding” type change decided by the SVG working group which hasn’t made it into the spec or into Inkscape), no browsers support meshes yet, and the GUI is not 100% functional and stable.

I do plan on enabling meshes in trunk so they can get more attention but whether they stay enabled in 0.92 will have to be seen. I am currently working on adding “auto-smoothing” to meshes and will present a proposal for this at the SVG meeting in Sydney next month.

SVG and CSS are being developed in sync by the respective W3C working groups for the past several years. How well is Inkscape doing with regards to supporting this recent trend?

Tavmjong: Yes, a lot of what was in SVG is being moved into specs that can be shared between SVG and CSS (transforms, blending, filter effects, etc.). This is usually a good thing as it means that the browsers are more likely to support things in SVG if they need to code it for CSS/HTML.

It brings new things to SVG such as HSL colors since SVG 2 references the latest CSS color spec. It can be problematic in some case as a problem that could easily be solved within the SVG working group must now be passed by the CSS working group which isn’t always easy or quick (e.g. changing ‘image-rendering’ so that it better reflects how authors want there bitmaps scaled).

In some cases, there is nothing to be done on Inkscape’s side as the CSS spec is basically identical to what was in SVG 1.1 (e.g. basic filter effects). In other cases we need to adapt our code (e.g. add HSL color support).

Tav, here’s a vanity question 🙂 Do you think your involvement with the SVG working group helps shaping SVG into a better standard for illustrators?

Yes. For example, I’ve done all the work putting mesh gradients and hatched fills into the spec as well as CSS based wrapped text.

I should mention that Inkscape has supported this work by paying for some of my travel to SVG working group meetings.

Last year the Inkscape Board announced that the project is now encouraging paid development. Has anyone approached the Board so far to have a go? Or was it postponed until after 0.91 is out?

Bryce: Certainly our top focus has been the v0.91 release, but I’m hoping we can get moving on the funded development projects. We have three projects in mind so far: GSList removal, box blur support for faster blurring, and more SVG 2 features support. We need to allocate some initial funds and then set up fund raising. After that we’ll be looking for applicants.

Tavmjong: We really need to get our funded development projects going. The Inkscape developers community is not very large and it would really benefit by having people being able to work on Inkscape as part of their paid work.

---

You can download Inkscape 0.91 for Windows and Mac, from an Ubuntu repository, and, of course, as a source code archive.