• Lataa versio 1.3.9
  • Windowsille ja Mac OS X:lle
  • Debian-repo ja useimmille RPM:ää käyttäville distroille

Kehityksen pääpainona oli vakaus. Versiosta 1.3.8 on korjattu 70 bugia. Joukossa on myös muutama uusi ominaisuus koskien:

• käännösympäristöä
• leikekirjaa
• resursseja ja resurssien hallintaa
• tiedostojen tuontia
• typografiaa
• dokumentaatiota

Kauniin typografisen värin saavuttaminen ei enää ole julmetun kovan kikkailun takana. Poissa ovat myös valkoiset polut, joita kynä kyllästymisen saapuessa alkoi seurata. Kehityshaaran seuraavaksi julkaistavassa versiossa 1.3.5 (kulkee tällä hetkellä nimellä 1.3.5svn) voidaan ottaa käyttöön välien ja merkkien leveyden muutokset.

Ideana on, että merkkien ja välien leveyttä muuttamalla voidaan etsiä paras rivin katkaisukohta niin, että kappaleista muodostuu tasaisia kokonaisuuksia. Vaikkei leveyden muutoksilla löydettäisi uutta katkaisukohtaa, voidaan rivi siitä huolimatta täyttää tasaisemmin. Käytännössä tämä tapahtuu niin, että käyttäjä antaa kappaletyylille tai tekstikehykselle marginaalit ja ihannearvot, joiden puitteissa leveyttä muutellaan.

Alla olevassa kuvassa vasemmassa tekstipalstassa on teksti sijoitettuna ilman korjailuja. Oikeassa palstassa on otettu käyttöön merkkien ja välien leveyden muutokset, tavutus sekä optinen tasaus.

Leveyksiä muuteltaesssa on kohtuus hyvä pitää mielessä. Tarkoitus ei ole alkaa muuttaa fontin ulkoasua vaan pysyä rajoissa, joita silmä ei huomaa. Näitä aiheita käsittelee mm. Markus Itkosen kirja Typografian käsikirja, josta lisää jossain tulevassa blogikirjoituksessa.

Kehityshaaran versioitten kanssa leikkiminen on vaarallista puuhaa, jos aikoo saada jotain aikaankin. Suosituksia ja vinkkejä kehitysversion kanssa touhuamisesta löytyy blogikirjoituksesta Scribus 1.3.3.12 saapuu kesäksi.

Kehityshaaraa en vielä ole edes alkanut kääntää. Syynä tähän on ollut halu hallita liiallista innostusta kyseistä haaraa kohtaan, koska se ei todellakaan ole vielä valmis päivittäiseen käyttöön. Jos uskallusta riittää eikä aikataulut paina päälle, toki arvostamme testaushalukkuuttanne. Eihän niistä bugeista muuten päästä eroon ellei joku niitä meille ilmoita. Päivittäisessä käytössä pysykää vielä 1.3.3.x-haaran käyttäjinä.

Kehitys-version voi SVN-versionhallinnasta käydä hakemassa seuraavalla komennolla:

 svn co svn://scribus.info/Scribus/trunk

Kääntö- ja asennusohjeet löytyvät Scribuksen ohjeista sivulta Compiing and Installing using CMake

Jotta kehitysversiosta saataisiin kaikki irti, on käyttäjien oltava aktiivisia. Vain löydetyt bugit voidaan korjata. Alla on muutama kappale tekstiä bugeista ja toiveista. Kirjoitin tekstin Uudenkaupungin Scribus-kurssia varten.

Bugit ja toiveet
Bugeja eli ohjelmavirheitä ei toivoisi ohjelmasta löytyvän, mutta todennäköistä on, että ennemmin tai myöhemmin törmäät johonkin outoon ilmiöön, joka ei voi olla ohjelman normaalia toimintaa. Tällöin olet löytänyt bugin. Kun törmäät bugiin tai ohjelman outoon käyttäytymiseen, paina mieleesi, mitä teit kun se ilmaantui. Yritä samaa uudestaan ja jos bugi ilmestyy jälleen on sinulla ainekset ensimmäiseen bugiraporttiisi. Bugien hallintaan Scribus käyttää järjestelmää nimeltä Mantis. Työkalu löytyy osoitteesta http://bugs.scribus.net. Vielä ennen bugin raportointia tulee varmistaa seuraavat seikat:

1. Onko käytössäsi Scribuksen viimeisin versio? Jos vastauksesi on ”ei”, tulee sinun päivittää Scribuksesi uusimpaan versioon. Mielellään, jos mahdollista, Scribuksen viimeisimpään kehitysversioon. Bugien raportointi vanhoista versioista lisää kehittäjien työtaakkaa, koska saattaa olla, että juuri kyseinen bugi on jo korjattu Scribuksen uudemmassa versiossa. Saatat käyttäjänä ajatella, että kehittäjäthän sitten tutkivat nämä asiat. He kyllä tutkivatkin, mutta tällainen vie aikaa kaikelta muulta kehitystyöltä.

2. Pystytkö aiheuttamaan virhetilanteen uudestaan toistamalla jotkin tietyt toiminnot? Bugia raportoitaessa on tärkeää pystyä tarkasti kertomaan miten bugin saa Scribuksessa esille. Tämän avulla kehittäjät voivat omissa järjestelmissään tutkia bugia ja sen ilmaantumista. Korjaus helpottuu huomattavasti.

3. Onko samasta bugista olemassa jo raportti? Myös useat raportit samasta bugista lisäävät suotta kehittäjien työtaakka. He eivät ole laiskoja, mutta resurssit Scribuksen kaltaisessa projektissa on vähäiset. Ennen uuden raportin kirjoittamista käytä bugityökalun tarjoamia etsintäominaisuuksia ja yritä etsiä jo olemassa olevaa bugiraporttia omalle bugillesi. Jos sellainen löytyy, voit kirjoittaa bugiraporttiin omat kommenttisi ja havaintosi bugista. Jos raporttia ei löydy, lisää oma raporttisi järjestelmään.

Kun edellä oleviin kysymyksiin on löytynyt vastaukset ja ne yhä osoittavat bugiraportin tarpeellisuuden, on aika kirjoittaa varsinainen bugiraportti. Uuden bugiraportin voi jättää järjestelmään, kun on ensin luonut itselleen käyttäjätunnuksen. Tämän jälkeen uusi raportti aloitettaan järjestelmän linkistä ”Report a bug”. Lomake, jonka avulla raportti jätetään, on varsin selkeä. Täytä siinä olevat kentät ja lähetä raportti. Bugiraporttisi etenemistä pystyt seuraamaan järjestelmän lähettämien sähköpostiviestien avulla. Kun bugi merkitään korjatuksi, voit testata sen hakemalla kehitysversion versionhallintajärjestelmästä ja kääntämällä Scribuksen. Voit myös odottaa seuraavan version julkaisua ja testata sen kanssa onko bugisi todella korjattu.

Virheiden raportoinnin lisäksi Scribus käyttää Mantista myös ohjelman tulevien ominaisuuksien käsittelyssä. Jos Scribuksesta mielestäsi puuttuu ominaisuus, voit jättää pyynnön bugityökaluun. Ennen toiveen lisäämistä on syytä kuitenkin varmistaa, ettei kukaan muu ole ehtinyt toivoa samaista asiaa ennen. Jos näin on päässyt käymään, voit jättää omat toivetta koskevat mielipiteesi olemassa olevaan bugiraporttiin.