Utveckling av ett verktyg för produktkataloggenerering

LiU-ITN-TEK-G-13/009-SE
Utveckling av ett verktyg för
produktkataloggenerering
Jenny Fritz
2013-04-19
Department of Science and Technology
Linköping University
SE-601 74 Norrköping, Sweden
Institutionen för teknik och naturvetenskap
Linköpings universitet
601 74 Norrköping
LiU-ITN-TEK-G-13/009-SE
Utveckling av ett verktyg för
produktkataloggenerering
Examensarbete utfört i Tekniska informationssystem
vid Tekniska högskolan vid
Linköpings universitet
Jenny Fritz
Handledare Stefan Gustavson
Handledare Daniel Berglund
Examinator Jan Petersson
Norrköping 2013-04-19
Upphovsrätt
Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare
under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
Jenny Fritz
Abstract
Today, product catalogs are published and distributed by a large share of retail companies.
However, the process of catalog production can be both time consuming and resource heavy.
The purpose of this thesis has been to find a solution to that problem. This was done by
researching different needs and demands regarding catalog production which was then followed
by implementation of a software tool that could accomodate those needs. The goal was to
automatically produce a product catalog in PDF format out of an existing product database.
A pilot study showed that despite differences in existing catalog layouts, there still are
some common elements such as product image and price. This was used as a basis during the
implementation in which it was assumed that a product database, no matter the type of data
source, always contains specific information elements to be published. To allow for different
layouts of a product catalog, a separate template handler was implemented. The purpose
of this was to give the user an opportunity to configure for instance text field placements,
image dimensions and which background images to use - all in favor of individual needs and
oppinions.
To reach the goals the scope of the project was extended and during spring 2013 it was
finalized with the desired functionalities. Despite this, a whole lot of possibilities regarding
further development can be seen, especially since the need of a more efficient process of catalog
production seems to exist.
Sammanfattning
Produktkataloger publiceras och distribueras idag av många detaljhandelsföretag, stora som
små. Dock har det påvisats att katalogproduktion kan vara både tids- och resurskrävande. Detta
examensarbete har därför syftat till att finna en lösning på problemet genom att undersöka
behov och förutsättningar och därpå utveckla ett verktyg som kan underlätta arbetet med att
skapa produktkataloger. Målsättningen var att det resulterande verktyget per automatik skulle
framställa en produktkatalog i PDF-format utifrån ett befintligt artikelregister.
En förstudie visade att trots olikheter i befintliga produktkatalogers utformning finns
ändå vissa gemensamma element såsom produktbild och pris. Detta faktum utnyttjades vid
utvecklingsarbetet där det förutsattes att ett artikelregister, oavsett typ av datakälla, alltid
innehåller vissa informationselement som kan publiceras. För att sedan ge utrymme för
olikheter i den grafiska utformningen av en katalog implementerades en separat mallhantering.
Syftet med detta var att ge användaren möjligheten att justera exempelvis placering av textfält,
bilddimensioner och bakgrundsbilder efter eget behov och tycke.
För att komma i hamn tilläts projektet att växa i omfattning och under våren 2013 fungerade
kataloggenereringsverktyget i enlighet med de mål som satts upp. Trots detta ses fortfarande
stora möjligheter för vidareutveckling, särskilt som behovet av effektiviserad katalogproduktion
tycks stort.
i
Förord
Det här projektet har varit en stor personlig utmaning för mig och jag skulle inte ha lyckats
genomföra det om det inte vore för personerna i min närhet som stöttat och drivit på mig.
Jag vill först och främst tacka Kerstin och Kåwe Agentur. Det var tack vare denna kontakt
som jag fick idén till projektet från första början och den fria tillgången till Kåwe:s artikelregister
gav mig något att utgå ifrån. Tack till min familj och mina vänner som försiktigt manat på mig
och försökt uppmuntra mig när det varit jobbigt.
Till sist vill jag tacka min handledare Daniel Berglund som fått jobba minst lika hårt som
mig för att ro detta projekt i hamn. Tack för tekniskt stöd, hjälp att tänka och framför allt för
ett till synes oändligt tålamod. Nu är det äntligen över...
iii
Innehåll
1
2
3
Inledning
1.1 Bakgrund . . . . . . . . .
1.2 Syfte . . . . . . . . . . . .
1.3 Avgränsningar . . . . . . .
1.4 Mål . . . . . . . . . . . .
1.5 Metod . . . . . . . . . . .
1.5.1 PPS . . . . . . . .
1.5.2 Utvecklingsmetod
1.6 Disposition . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Förstudie
2.1 Kravspecifikation . . . . . . . . . . . . .
2.2 Produktkataloger . . . . . . . . . . . . .
2.2.1 Produktkatalogen som företeelse .
2.2.2 Innehålls- och layoutkonventioner
2.3 Behovsanalys . . . . . . . . . . . . . . .
2.4 Befintliga verktyg och tjänster . . . . . .
2.4.1 Layoutprogram . . . . . . . . . .
2.4.2 Katalogproduktion . . . . . . . .
2.4.3 Slutsats . . . . . . . . . . . . . .
2.5 Mjukvara . . . . . . . . . . . . . . . . .
2.5.1 Kort om Excel . . . . . . . . . .
2.5.2 PDF . . . . . . . . . . . . . . . .
2.5.3 Javabiblioteket iText . . . . . . .
2.5.4 Excel-import i Java . . . . . . . .
2.5.5 XML . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
2
2
3
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
6
10
12
12
12
16
16
16
17
20
21
22
Utveckling
3.1 Utvecklingsmiljö . . . . . . . . . . . . . . . .
3.2 Grafisk design . . . . . . . . . . . . . . . . . .
3.2.1 Övergripande kataloglayout och design
3.2.2 Artikellayout . . . . . . . . . . . . . .
3.2.3 Övrig layout . . . . . . . . . . . . . .
3.2.4 Grafiskt material . . . . . . . . . . . .
3.3 Programutveckling . . . . . . . . . . . . . . .
3.3.1 Verktygets funktionaliteter . . . . . . .
3.3.2 Implementering . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
26
29
29
30
30
31
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
Innehåll
4
Resultat och diskussion
41
4.1 Utvärdering av verktyget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Vidareutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Litteraturförteckning
45
Bilaga 1 Kravspeci kation
47
Figurer
1.1
Arbetsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Färgkodning i innehållsförteckning och i sidhuvud, exempel ur Biltemas katalog
2012/13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uppslag ur Biltemas katalog Höst/Vinter 2012/13 . . . . . . . . . . . . . . .
Uppslag ur Nevotex katalog 2012-2013 . . . . . . . . . . . . . . . . . . . .
EasyCatalog i InDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kataloggenerering i CMS-systemet Magento . . . . . . . . . . . . . . . . .
Sektionerna i en PDF-fil . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iText exempel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XML exempel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
7
8
9
14
15
19
21
23
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
Layout för artikel . . . . . . . . . . . . . . . . . . . . . . . . .
Gruppering av liknande artiklar . . . . . . . . . . . . . . . . . .
En artikel - flera bilder . . . . . . . . . . . . . . . . . . . . . .
Fullständig sido-layout . . . . . . . . . . . . . . . . . . . . . .
Layout för innehållsförteckning . . . . . . . . . . . . . . . . .
Layout för titelsida till kapitel . . . . . . . . . . . . . . . . . .
Programflöde . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utdrag ur artikelregistret . . . . . . . . . . . . . . . . . . . . .
XML-dokumentets strukturprincip . . . . . . . . . . . . . . . .
Flödesschema över katalogexport . . . . . . . . . . . . . . . . .
Flödesschema över generering och infogande av artikeldokument
Dialogruta vid fel sökväg till artikelregister . . . . . . . . . . .
Dialogruta då katalogfil redan existerar . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
28
29
30
30
30
32
33
35
37
38
38
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
Ordlista
.ps
Filformatet för PostScript.
.xls
Filformat för dokument skapade i MS Excel.
.xlsx
XML-baserat filformat för dokument skapade i MS Excel.
Adobe Acrobat
Kommersiellt datorprogram för att skapa och editera PDF-dokument.
Adobe Reader
Fritt datorprogram för att visa PDF-dokument.
AOT
Ahead-Of-Time kompilator. Kompilerar exempelvis Java-kod till
maskinkod för en specifik plattform.
Apache PDFBox
Öppet Java-bibliotek för att arbeta med PDF-filer.
Apache POI
Apache Poor Obfuscation Implementation. Fritt Java API för att
hantera digitala dokument.
API
Application Programming Interface
ASP.NET
Programspråk för att skapa dynamiskt webb-innehåll.
BFO
Syftar till Big Faceless Java PDF Library, ett öppet Java-bibliotek
skapat av BFO.
CMS
Content Management System. Webbaserat innehållshanteringssystem för elektronisk publicering.
CMYK
Färgmodell för fyrfärgstryck.
Dictionary
Objektstyp som beskriver innehållsobjekt i en PDF-fil.
DOM
Document Object Model. Konvention för trädstrukturerat
dokumentinnehåll.
Drupal
Öppet blogg- och innehållshanteringssystem.
DTD
Document Type Definition. Dokumentmall för XML-filer.
DTP
DeskTop Publishing. Datorstödd layout av trycksaker.
EasyCatalog
Plug-in modul till InDesign för databaskoppling och katalogproduktion.
ix
x
Ordlista
Eclipse
Utvecklingsmiljö för Java-applikationer.
F/OSS
Free and Open Source Software
GiBi sPrint
Plug-in modul till Joomla för att skapa produktkataloger.
GIF
Bildformatsstandard för icke-destruktiv komprimering.
GNU GPL
GNU General Public License. Upphovsrättslicens för fri programvara.
GNU LGPL
GNU Lesser General Public License. Upphovsrättslicens för fri
programvara utan distribution av tillhörande källkod.
HSSF
Horrible SpreadSheet Format. Java-bibliotek inom Apache POI för
att skapa och läsa .xls-filer.
Illustrator
Illustrationsprogram utvecklat av Adobe.
InDesign
Program för desktop publishing utvecklat av Adobe Systems.
ISO
Internationella StandardiseringsOrganisationen
iText
Öppet Java-bibliotek för att arbete med PDF-filer.
JAR
Java ARchive
JAXP
Java API for XML Processing. Fritt Java-bibliotek för XMLhantering.
JDK
Java Development Kit
JDOM
Fritt Java-bibliotek för XML-hantering.
JExcel
Fritt Java API för att hantera Excel-dokument.
Joomla
Öppet innehållshanteringssystem
JPEG
Bildformatsstandard för destruktiv komprimering. Lämpligt för
lagring av fotografier.
Litium Studio
Kommersiellt innehållshanteringssystem utvecklat av Microsoft.
Magento
Kommersiell webbapplikation för e-handel utvecklat av Varien.
MS Access
Databashanteringssystem utvecklat av Microsoft.
MS Publisher
Program för desktop publishing utvecklat av Microsoft.
MySQL
Databashanteringssystem som använder sig av frågespråket SQL.
ODBC
Open DataBase Connectivity. Standardiserad åtkomstmetod för
databaser.
Ordlista
xi
OLE2
Objekt Linking and Embedding Compound Document. Standard för
dokumentformat skapade av Microsoft.
OOXML
Office Open XML. Standard för dokumentformat.
Oracle Database
Databashanteringssystem utvecklat av Oracle Corporation.
osCommerce
Öppet webbutikssystem.
PDF
Portable Document Format. Standardiserat dokumentformat skapat
av Adobe Systems.
PDF Catalog Creator
Modul till osCommerce för att skapa produktkataloger.
PDF/A
Delmängd av PDF-standarden som särskilt berör bevarande av
dokument.
PDF/X
Delmängd av PDF-standarden som särskilt berör grafiskt utbyte
inom exempelvis tryckeribranschen.
PHP
Hypertext PreProcessor. Skriptspråk för att skapa dynamiskt webbinnehåll.
PNG
Bildformat lämpligt för lagring av icke-fotografiska bilder.
PostScript
Programspråk för att beskriva utseendet på sidor i digitala dokument.
PPS
Praktisk ProjektStyrning. Projektstyrningsmodell framtagen av
TietoEnator.
QuarkXPress
Program för desktop publishing utvecklat av Quark.
RIP
Raster Imaging Processor. Del i utskriftssystem som konverterar text
och bild till ett rastermönster.
SAX
Simple API for XML
SQL
Structured Query Language. Frågespråk för databashantering.
StAX
Streaming API for XML
SVN
Subversion. Versionshanteringssystem.
TIFF
Bildformat för bitmapsuppbyggda bilder.
VirtueMart Catalog
Plug-in modul till Joomla för att skapa produktkataloger.
Visma Administration
Vanligt förekommande ekonomisystem.
Wordpress
Öppet blogg- och innehållshanteringssystem.
WYSIWYG
What You See Is What You Get. Gränssnitt som återger slutresultatet
då dokument och innehåll skapas.
XML
EXtensible Markup Language
xii
Ordlista
XML Namespace
Specifikation av namnrymden i en XML-fil.
XML schema
Deklarerar egenskaper och regler för en XML-fil.
XPath
Frågespråk för hantering av XML-filer.
XSLT
Märkspråk för att transformera XML-dokument.
XSSF
XML SpreadSheet Format. Java-bibliotek inom Apache POI för att
skapa och läsa .xlsx-filer.
Kapitel 1
Inledning
Denna rapport är resultatet av ett examensarbete utfört på Institutionen för Teknik och
Naturvetenskap vid Linköpings Universitet inom högskoleingenjörsutbildningen Medie- och
Kommunikationsteknik. Rapporten utreder problematiken kring att implementera ett verktyg
som automatisk framställer produktkataloger.
1.1
Bakgrund
Det enskilt viktigaste som företagare inom detaljhandeln är att visa och marknadsföra sitt
produktsortiment för potentiella kunder. Många företag utnyttjar idag Internet och e-handel för
detta ändamål. Trots detta är den mer traditionella tryckta produktkatalogen ett utmärkt sätt att
nå ut till kunder, vilket fortfarande utnyttjas inom de flesta branscher. Detta kan särskilt sägas
för de mer traditionsbundna branscherna, samt där det inte finns benägenhet att ligga i den
tekniska utvecklingens framkant.
Som småföretagare kan det dock innebära att det saknas både tid och tillräcklig kunskap
inom nödvändig mjukvaruhantering för att kunna framställa en produktkatalog från grunden.
Alternativet att leja ut uppdraget kan istället innebära en större kostnad som inte kan motiveras
företagsekonomiskt. Utöver föregående problem finns alltid risken att infoga felaktig information vid manuell framställning av en produktkatalog. Möjligheten att kunna använda ett enkelt
mjukvaruverktyg som automatiskt framställer en produktkatalog från ett befintligt artikelregister skulle potentiellt kunna avhjälpa problemen ovan, samt underlätta vid uppdateringar av
materialet.
Idén till projektet uppkom från observationer av arbetet hos textilgrossistföretaget Kåwe
Agentur AB som flera gånger per år skickar ut uppdaterade tryckta produktkataloger till sina
kunder. Därför används företaget som fallstudie i syfte att utreda behov under förstudien samt
för att samla in artikeldata vilket ska användas vid tester av det resulterande verktyget.
1.2
Syfte
Syftet med examensarbetet är att genomföra en behovsanalys och teknikstudie kring hur ett
verktyg för att automatiskt generera produktkataloger kan utformas. Med utgångspunkt ur
slutsatser och resultat i denna förstudie ska sedan ett kataloggenereringsverktyg implementeras
som uppfyller kraven i en på förhand framtagen kravspecifikation vilken återfinns i bilaga 1.
1
2
Inledning
Under utvecklingen ska befintlig kunskap och teknik inom grafisk design och mjukvaruutveckling tillämpas.
Problematiseringen består i huvudsak av följande:
Hur den grafiska katalogdesignen kan generaliseras och på så vis vara applicerbar på
artiklar och produkter, oavsett produkttyp och/eller omfattning av produktsortiment.
Hur den grafiska katalogdesignen kan realiseras med hjälp av befintliga programbibliotek
samt hur nödvändigt data smidigast läses in i det resulterande verktyget.
Syftet med det färdiga verktyget är främst resursbesparingar samt att minska mängden felaktig
information i det färdiga materialet.
1.3
Avgränsningar
Utveckling av ett grafiskt användargränssnitt till verktyget skulle innebära att projektet även
omfattade design och tester för att optimera användarvänligheten vid interaktion. Då detta
bedöms som alltför omfattande för att rymmas inom examensarbetets tidsramar kommer endast
ett enklare gränssnitt utvecklas som fullgott uppfyller användningskraven i kravspecifikationen.
Det innebär även att användare av verktyget får ett begränsat inflytande över produktkatalogens
disposition och layout vid interaktion.
Eftersom projektet erbjuder en mängd utvecklingsmöjligheter får kravspecifikationen även
i övrigt sätta ramarna för vilken funktionalitet som ska utvecklas inom examensarbetet.
Vidareutveckling diskuteras i kapitel 4 - Resultat och diskussion.
1.4
Mål
Examensarbetet är avsett att resultera i ett enkelt och generellt verktyg för automatisk generering
av produktkataloger. Målet är nått när framtagen kravspecifikation uppfylls.
1.5
1.5.1
Metod
PPS
För att styra och planera genomförandet används PPS (Praktisk ProjektStyrning)1 som metod.
PPS bygger på att förbereda projektet väl genom att sätta upp tydliga mål och synliggöra risker
samt under projektets gång kontinuerligt stämma av progressen.
Inför examensarbetet har en projektplan tagits fram som bland annat beskriver idé och
mål, tidplan och milstolpar, projektets organisation och arbetsformer samt de risker som
bedöms kunna uppstå under projektets gång. Exempel på det senare kan vara att tidplanen
förskjuts och vilka åtgärder som krävs för att förebygga detta. Under examensarbetets gång
ska kontinuerliga möten hållas med den externa handledaren för projektet där avstämning görs
över det tillryggalagda arbetet samt över arbetsplan för kommande period. Syftet är att driva
projektet framåt och i rätt riktning.
1
Projektstyrningsmodell framtagen av TietoEnator
1.6 Disposition
1.5.2
3
Utvecklingsmetod
Utvecklingsmetoden har utgått från vattenfallsmodellen vilken grundar sig i stegvis utveckling.
Arbetsprocessen beskrivs i figur 1.1.
Figur 1.1. Arbetsprocess
Under förstudiefasen genomfördes en teknikstudie och behovsanalys. För att skaffa kunskap
inom relevant teknik utforskades till största delen online-resurser. Behovsanalysen baserades
på observationer vid Kåwe Agentur AB samt analyser av aktuella produktkataloger. Även
befintliga verktyg och tjänster för automatisk generering av elektroniska dokument utforskades.
Vid arbetet med den grafiska designen togs en preliminär grafisk layout för en produktkatalog fram. Under implementationsfasen modifierades och fastställdes den grafiska layouten
utefter de möjligheter och begränsningar som gavs.
Programutvecklingen skedde i en iterativ process. Ett första grovt utkast till verktyget
skapades vilket realiserade den grafiska design som tagits fram. På så vis synliggjordes en del
av de dataformat och programfunktioner som behövde implementeras vid arbetet med dataimport till verktyget. Då import och export realiserats förfinades och optimerades programmets
funktionalitet.
För att uppnå projektets mål genomfördes till sist ett funktionstest utformat så att varje krav
i kravspecifikationen kunde verifieras som uppfyllt.
1.6
Disposition
Rapporten är uppdelad i tre huvudkapitel: Förstudie, Utveckling samt Resultat och diskussion.
I Förstudie-kapitlet beskrivs resultatet av behovsanalysen och teknikstudien. Som inledning
förklaras den kravspecifikation som är ramsättande för projektet. Därefter lämnas en redogörelse över konventioner som gäller för utformningen av produktkataloger i dagsläget. Detta
följs av en behovsanalys där behovet av en effektivisering vid katalogproduktion klargörs
4
Inledning
och motiveras. Eftersom detta behov inte är någon nyhet finns flertalet lösningar redan på
marknaden. En analys av dessa görs i kapitel 2.4. Det sista kapitlet i förstudien beskriver den
mjukvara som undersökts inför implementeringsarbetet då verktyget skulle skapas.
I kapitlet om Utveckling lämnas en redogörelse över implementeringsarbetet vilket bestod av två huvudmoment: grafisk design samt programutveckling. Kapitlet inleds med en
beskrivning av de utvecklingsmiljöer som användes. Därefter redogörs för tillvägagångssätt
och resultat av designarbetet - hur en katalog skapad av verktyget skulle se ut. Till sist beskrivs
i kapitel 3.3 hur verktyget programtekniskt är uppbyggt - hur det hanterar import och export
samt vilka mjukvarutekniker som tillämpats för att uppnå önskade funktionaliteter.
Som avslutande del i rapporten analyseras och diskuteras resultatet av projektet - vad som
kunde lösts på ett bättre sätt samt hur pass väl syfte och mål uppfyllts. Till sist ges förslag på
hur verktyget kan förbättras och vidareutvecklas i framtiden.
Kapitel 2
Förstudie
Som inledande moment i examensarbetet genomfördes en förstudie. Syftet med denna var
att utreda behoven och förutsättningarna kring ett katalogverktyg samt utforska lämpliga
tekniker och de implementationsmöjligheter som dessa medförde. Som utgångspunkt för
förstudien har den kravspecifikation som uppkommit i samband med idéarbete och definition
av examensarbetet använts.
Kapitlet inleds med en kort beskrivning av den ramsättande kravspecifikationen vilken
följs av en redogörelse för konventioner kring produktkataloger i dagsläget. Med utgångspunkt
ur detta görs en behovsanalys samt en undersökning av befintliga verktyg och tjänster för
kataloggenerering. I sista avsnittet beskrivs de mjukvarumässiga tekniker som ansetts lämpa
sig bäst för att implementera katalogverktyget och uppfylla kravspecifikationen.
2.1
Kravspeci kation
Inför detta examensarbete togs en kravspecifikation fram för att beskriva innehållet samt sätta
ramarna för funktionaliteten i ett kataloggenereringsverktyg. Kravspecifikationen är indelad i
två avsnitt: Funktionella krav samt användningskrav. De funktionella kraven beskriver vilket
data samt de dataformat som verktyget ska ta in och vilket resultat verktyget ska generera. För
att beskriva detta kort ska verktyget ta in ett artikelregister i dokumentformatet MS Excel med
tillhörande bilder. Resultatet ska vara en produktkatalog i PDF-format över dessa artiklar, vilka
disponerats enligt en fördefinierad layoutmall. I användningskraven beskrivs den datormiljö
som förutsätts för användande av verktyget, samt hur gränssnittet mellan användare och verktyg
ska fungera.
Målet med implementeringsarbetet är att uppfylla de framtagna kraven. Den kompletta
kravspecifikationen återfinns i bilaga 11 .
2.2
2.2.1
Produktkataloger
Produktkatalogen som företeelse
Att publicera en produktkatalog är att som handlare, tillverkare eller grossist ge ut en förteckning över hela eller delar av sitt produktsortiment. Syftet är att marknadsföra sig och nå ut till
potentiella kunder; att i ett kompakt och lättöverskådligt format visa upp, lämna information
1
Fortsättningsvis kommer omnämnanden av kravspecifikation syfta till det dokument som återfinns i bilaga 1.
5
6
Förstudie
om sina produkter utanför företagets lokaler och till syvende och sist skapa merförsäljning.
Detta koncept att marknadsföra sitt sortiment har under modern tid utökats i och med intåget
av Internet och e-handel. Ett företags produktförteckning kan numera marknadsföras på ett dynamiskt och interaktivt sätt. Begränsningar en tryckt katalog medför, såsom räckvidd, inaktuell
information och rörliga produktionskostnader vid framställning, ersätts av att kunder lätt kan
anskaffa aktuell och eftersökt information i en centraliserad webbutik.
Dock associerar nog de flesta den traditionella produktkatalogen med en tryckt publikation
och trots fördelarna Internet erbjuder finns det situationer där en traditionell papperskatalog
lämpar sig bättre, eller åtminstone som komplement. Många företag erbjuder till exempel
tjänsten att beställa hem en tryckt produktkatalog via sin hemsida, förmodligen av den enkla
anledningen att vissa föredrar att sitta hemma i soffan och bläddra istället för framför en
datorskärm.
Vid en förutsättningslös utvärdering har följande fördelar med en tryckt produktkatalog
kontra en webbsida kunnat identifieras:
En produktkatalog kan aktivt användas som reklambroschyr för utskick. Företaget tar
kontakt med kunden istället för att passivt vänta på att kunden ska söka sig till dess
webbsida.
Trots att Internet-användandet ökar finns det målgrupper, exempelvis äldre, som inte kan
nås lika lätt via en webbsida.
En tryckt produktkatalog kan distribueras utanför datorskärmen, exempelvis i anslutning
till butikens lokaler eller via postförsändelser.
Inom vissa branscher råder en tradition att publicera en tryckt produktkatalog, något som
är etablerat bland ett företags kunder. Som exempel kan nämnas Clas Ohlson, Biltema
och IKEA. Marknadsföringsvärdet av tryckta produktkataloger är förmodligen därför
stort för dessa företag.
En tryckt publikation erbjuder större möjlighet till hög kvalitet på bilder, illustrationer
och layout, vilket tilltalar ögat och ökar marknadsföringsvärdet.
2.2.2
Innehålls- och layoutkonventioner
Inför detta avsnitt har flertalet produktkataloger inom detaljhandeln studerats. Syftet var att få
en överblick över innehålls- och layoutkonventioner och använda dessa slutsatser som grund
till den grafiska layouten i kataloggenereringsverktyget.
Allmänna konventioner
Innehållsmässigt har sex beståndsdelar identifierats vilka tycks finnas i de flesta produktkataloger oavsett sortiment och bransch:
En visuellt tilltalande pärm med företagets namn och den period för vilken produktkatalogen gäller.
Innehållsförteckning
2.2 Produktkataloger
7
Huvudinnehållet är hela eller delar av företagets produktsortiment.
Ett sökbart register över innehållet.
Kontaktinformation
Köp- och leveransvillkor.
Företag som kontinuerligt ger ut produktkataloger väljer också ofta att lyfta fram nyheter eller
kampanjvaror på något iögonenfallande sätt. För att höja marknadsföringsvärdet kan även lockande och stämningsfulla miljöbilder infogas, exempelvis för att visa applikationsmöjligheter
med en produkt.
Eftersom syftet med en produktkatalog främst är marknadsföring måste den tilltala läsaren
både visuellt och innehållsmässigt. Layout och grafik är här viktiga verktyg för katalogproducenten för att uppnå detta. Pärmen ska locka läsaren att öppna katalogen, innehållsförteckning,
register, köp- och kontaktinformation är hjälpmedel för läsaren som bör vara enkla och tydliga.
Ett exempel är att färgkoda innehållsförteckningen och motsvarande produktkategorisidor inne i
katalogen, särskilt användbart då produktsortimentet är omfattande. Se figur 2.1 för illustrerande
exempel. Den stora massan av en katalog består dock av artiklar ur produktsortimentet och dessa
bör förtecknas på ett strukturerat sätt så att läsaren hittar fram till för denne intressanta produkter.
Figur 2.1. Färgkodning i innehållsförteckning och i sidhuvud, exempel ur Biltemas katalog 2012/13
Strukturen kan beskrivas med hjälp av nivåer. På högsta nivå delas produkter in i
produktkategorier motsvarande katalogens kapitel. Vilken indelningen och ordningen ska vara
är subjektivt och bestäms av företages marknadsföringsstrategi. Dock bör en riktlinje vara att
läsaren intuitivt kan hitta fram till eftersökt produkt.
På nästa nivå struktureras produkterna inom respektive kapitel. Lika och liknande produkter inom samma artikelgrupp bör ligga tillsammans. Vilken den interna sortering mellan
produktgrupperna inom kapitlet ska vara är återigen en subjektiv bedömning.
8
Förstudie
Nästa strukturnivå motsvarar layouten av produkterna på varje enskild katalogsida. Efter
att ha studerat befintliga produktkataloger kan konstateras att det förmodligen finns lika många
layoutvarianter som kataloger. En eller flera kolumner, tät eller gles layout, bilder tillsammans
med produktbeskrivningar eller bilder för sig och text för sig. Valmöjligheterna är oändliga och
kan motiveras av ekonomiskt grundade frågeställningar såsom målgrupp, upplaga, omfattning
av produktsortiment med mera. Dock bör en katalog genomgående byggas upp av en konsekvent
sidlayout som är lätt för läsaren att tillgodogöra sig.
På lägsta nivå återfinns beskrivning och illustrering av varje enskild produkt. Vanligt
förekommande beståndsdelar är produktbild, artikelnummer, artikelnamn, beskrivning, förpackningsstorlek och pris. Vilka beståndsdelarna ska vara och layoutval såsom font och
textstorlek bör återigen vara konsekvent. Informationsmängd och kvalitet på text- och bildmaterial motiveras av marknadsföringsstrategier. Objektivt sett bör dock bilder vara av hög
kvalitet, tydliga och tillräckligt stora för att illustrera produkten. Bilden är det viktigaste
elementet i en artikels beskrivning. Texten bör inte vara för omfattande utan kort och kärnfull i
ett lättläst typsnitt så att läsaren lätt kan ta till sig informationen. Målet är ju att sälja.
Exempel
Följande avsnitt beskriver strukturen i två kataloger av olika typ för att ge konkreta exempel på
strukturbeskrivningarna ovan.
Figur 2.2. Uppslag ur Biltemas katalog Höst/Vinter 2012/13
Biltema är ett detaljhandelsföretag med produkter inom bland annat bil, bygg, fritid och
verktyg. De har över 100 varuhus i Norden och över 17 000 artiklar i sitt sortiment.
Biltemas produktkatalog hör till en av Nordens största ifråga om upplaga. Den ges ut två
gånger per år och trycks varje gång i över 14 miljoner exemplar [15]. Dessa delas ut till alla
2.2 Produktkataloger
9
hushåll runtom varuhusen samt finns fritt tillgängliga i butikslokalerna. Att producera, trycka
och ge ut katalogen är gissningsvis alltså en stor kostnadspost för företaget, vilket förhoppningsvis motiveras av den högre omsättning som utgivningen ger. Produktionskostnaden för
katalogen behöver alltså hållas nere. En åtgärd tycks vara att trycka katalogen på relativt tunt
papper samt litet format (19x21 cm). Den täta layouten, strukturerad i två till fyra kolumner
per sida, sparar också på utrymmet. Textstorleken är liten och produktinformationen kortfattad.
Produktbilderna är relativt små, oftast frilagda och flera liknande artiklar sammanfogas ibland
till en bild med nummerhänvisning till tillhörande textinformation. En risk med tät layout
är att en katalogsida upplevs som rörig och läsaren ser inte alla produkter. Den svenska
produktkatalogen för Höst/Vinter 2012/13 omfattar 532 sidor. Ett uppslag ur katalogen visas i
figur 2.2.
Figur 2.3. Uppslag ur Nevotex katalog 2012-2013
Nevotex är ett svenskt grossistföretag inom textilbranschen med norra Europa som marknad.
I deras sortiment finns till exempel beklädnadsmaterial såsom möbeltyger och verktyg för
textilindustrin. Deras kunder är företag relaterade till textilbranschen, till exempel tapetserare,
inredare, sömnadsateljéer och textildetaljister [11].
Nevotex ger ut sin produktkatalog vartannat år till befintliga kunder samt på begäran. En
subjektiv bedömning är att katalogen tycks mer stilren och av högre kvalitet än Biltemas katalog.
Katalogen trycks i A4-format på bestruket papper med betydligt högre ytvikt. Sidlayouten är
gles med mycket outnyttjat utrymme och betydligt färre artiklar per sida, dock konsekvent
10
Förstudie
genom hela katalogen med omfattande textinformation i ena kolumnen och stora tydliga bilder
i den andra kolumnen. Detta kan medföra att katalogen upplevs som mer lättläst. Dock saknas
prisuppgifter för produkterna inne i katalogen och ges istället ut i en separat prislista. En
orsak kan vara att Nevotex endast har företagskunder vilket medför att priser kan skilja sig
mellan kunder och köptillfällen, exempelvis på grund av mängd- och förmånsrabatter samt
varierande leverantörspriser. En fördel med att utelämna prisinformation är dock att en aktuell
produktkatalog kan ges ut med längre intervall eftersom sortimentet hålls relativt statiskt, vilket
kompenserar för den högre material- och produktionskostnad denna typ av katalog medför.
Den svenska produktkatalogen för 2012/2013 omfattar 280 sidor. Ett uppslag ur katalogen
visas i figur 2.3.
2.3
Behovsanalys
Detta kapitel beskriver de behov av integrering och effektivisering som observerats i samband
med framställning av en produktkatalog och hur en analys av dessa behov resulterat i idén att
skapa ett kataloggenereringsverktyg.
Omfattningen av en katalogproduktion kan variera kraftigt beroende på storlek på utgivande
företag, storlek på produktsortiment, kvalitetsnivå, budget, marknadsföringssyfte, kompetensnivå med mera. Ofta sätter ekonomiska incitament och resurser gränsen för omfattningen.
Variationerna kan illustreras med två tänkta ytterligheter:
Företag A är ett enmansföretag som ska ge ut ett produkthäfte om 10 sidor med säsongens
kampanjvaror. Häftet produceras av företagsinnehavaren med MS Word som layoutprogram.
Produktbilderna som ska användas i katalogen är tagna med en generisk kompakt digitalkamera
och efterbehandlas ej. Häftet skrivs ut med hjälp av en bläckstråleskrivare för hemmiljö i ett
hundratal exemplar vilka skickas per post till för företaget kända kunder.
Företag B är ett internationellt företag som producerar ett tiotal kataloger per år över
olika delar av sitt mycket omfattande produktsortiment. Dessa ska ges ut i en upplaga om 10
miljoner exemplar i ett flertal länder vilket medför att katalogerna måste produceras i ett antal
språkligt skilda versioner. Inom företaget finns en egen produktionslinje för katalogframställning och denna avdelning omfattar ett femtiotal anställda. Arbetsroller som förekommer är
flertalet fotografer, art director, formgivare och illustratörer, bildbehandlare, layoutpersonal,
trycktekniker med flera. Avdelningen har tillgång till resurser såsom fotostudio, professionella
bildbehandlings- och layoutprogram samt eget tryckeri.
Även om scenarierna ovan skiljer sig kraftigt har de, och alla varianter där emellan,
gemensamt att manuell katalogproduktion är relativt tidskrävande för respektive företag. Det
kan visas av en generell beskrivning av momenten i produktionsprocessen:
Insamling och produktion av text- och bildmaterial: För det första behövs en förteckning eller databas över de artiklar som ska finnas med i katalogen med tillhörande
information, eventuellt utökade produktbeskrivningar samt icke artikelrelaterad text. För
det andra ska bildmaterial samlas in eller skapas såsom illustrationer samt miljö- och
produktfotografier.
Eventuell bildbehandling: Till exempel retuschering, bildbeskärning och färgjustering.
2.3 Behovsanalys
11
Layoutarbete: Sammansättning av allt text- och bildmaterial till ett strukturerat katalogdokument.
Utskrift eller tryckning av katalogen.
Tidsåtgången vid katalogproduktion varierar beroende på om katalogen produceras för första
gången eller endast ska uppdateras för säsongen. I det första fallet kan processen vara tidsödande om alla produkter ska fotograferas och hela katalogdokumentet författas och utformas
från grunden. Påföljande upplagor kräver dock endast modifikation av befintligt dokument
och eventuell fotografering av nytillkomna produkter vilket därmed kräver betydligt mindre tidsåtgång. Eftersom tid är pengar inom företagsvärlden skulle en tidsbesparing vara
gynnande vid katalogproduktion. Ett sätt att lösa detta är att leja ut uppdraget till en produktionsbyrå, men detta medför förmodligen en större kostnad motsvarande uppdragets omfattning.
Manuell katalogproduktion kan även innebära att artikelinformation lagras redundant på
grund av flera informationskällor vilket medför risk för felaktigheter i katalogens innehåll.
Som illustrerande exempel kan nämnas proceduren vid Kåwe Agentur AB. Artikelregistret är
integrerat i det vanligt förekommande ekonomisystem Visma Administration där möjlighet ges
att exportera artikeldata som ett kalkylblad i MS Excel-formatet .xls. Registret innehåller bland
annat artikelnummer, artikelnamn, artikelgrupp, enhet och pris per enhet. En produktbild kan
lagras för varje artikel i Visma Administration, dock går det ej att lätt exportera denna bild
till en annan källa. Katalogproduktionen sker internt på företaget. MS Publisher används som
layoutprogram på ett system där tillgång ej finns till ekonomisystemet. Information från det
exporterade artikelregistret infogas eller uppdateras i katalogdokumentet. Produktbilder hämtas
direkt från lokala bildkataloger. I Visma Administration finns ej stöd för förpackningsstorlekar
utan företaget har istället valt att i vissa fall medföra detta i artikelnamnet jämte eventuella
mått på produkten. Produktbeskrivning och förpackningsstorlek författas vid layoutarbetet ur
information från artikelnamnet eller efterforskningar. Det färdiga katalogdokumentet lämnas i
PDF-format till ett tryckeri och trycks i en upplaga om 100 exemplar per gång. På grund av
den relativt lilla upplagan används digitaltryck som tryckteknik.
De mjukvaror som används vid Kåwe Agentur för katalogproduktion (Visma Administration, MS Excel och MS Publisher) anses vara mycket vanligt förekommande både i privat och
företagsmiljö, ha låga licenskostnader samt låga inlärningskurvor. Det finns därför anledning
att förutsätta att många företag, särskilt små företag utan tillgång till en välutvecklad IT-miljö,
använder sig av metoder snarlika den vid Kåwe Agentur.
Flera risker till felkällor har efter observationer kunnat konstateras. Exempelvis kan artikelinformation hinna förändras i ekonomisystemet under det tidsödande layoutarbetet samt
att det finns en risk för felaktigt val av produktbilder. Dessa risker skulle kunna minskas
om all nödvändig information fanns lagrad på ett och samma ställe. På marknaden finns
flertalet integrerade affärssystem som erbjuder denna lösning, vilket underlättar då produkter
ska publiceras i flera medier såsom tryckta produktkataloger och webbutiker. Vissa av dessa
system erbjuder även verktyg för generering av produktkataloger - för webbutik eller för tryck.
En snabb överblick av sådana system och verktyg ger dock uppfattningen att de har högre
inlärningskurvor samt innebär en större kostnad vid köp av licens. Exempel på befintliga
verktyg och tjänster för katalogproduktion beskrivs i nästa kapitel.
Sammanfattningsvis har observationer av hög tidsåtgång och risk för att infoga fel vid manuell katalogproduktion lett till idén om ett enkelt verktyg för automatiserad katalogproduktion.
12
2.4
Förstudie
Be ntliga verktyg och tjänster
Detta avsnitt beskriver ett antal befintliga verktyg och tjänster för katalogproduktion. Särskild
fokus kommer läggas på verktyg som underlättar layoutarbetet då denna tidstjuv bedöms
som den största olägenheten vid manuell katalogproduktion. För- och nackdelar i relation till
behoven i föregående kapitel tas upp.
2.4.1
Layoutprogram
Tre vanliga layoutprogram för DTP (DeskTop Publishing) är MS Publisher, Adobe InDesign
samt QuarkXPress.
MS Publisher anses generellt vara enkelt att använda och utan komplexa funktioner. Användargruppen består av privatpersoner, mindre företag samt andra användare som inte arbetar
med sidlayout på någon avancerad nivå [20], därav är kostnaden för en programlicens relativt
låg. Publisher är plattformsbundet till MS Windows. Tidigare versioner av programmet saknade
funktionalitet att konvertera ett dokument till PDF-format, vilket kan anses som hindrande vid
distribution av dokument. Senare versioner erbjuder dock denna möjlighet som ett inbyggt
verktyg.
Det kraftfulla Adobe InDesign är ett marknadsledande program för desktop publishing och
används på professionell nivå av användare inom den grafiska branschen [14]. På grund av
programmets komplexitet är inlärningskurvan relativt hög för att kunna utnyttja InDesigns alla
funktionaliteter, dock erbjuder det fler möjligheter jämfört med Publisher. Eftersom InDesign
hör till Adobes programbibliotek, jämte exempelvis bildredigeringsprogrammet Photoshop
och illustrationsprogrammet Illustrator, finns funktionalitet för konvertering av dokument till
PDF-format inbyggt. Som exempel på funktionalitet som Publisher saknar kan nämnas utökat
stöd för textbehandling, möjlighet att infoga rörligt innehåll samt stöd för automatisering vid
exempelvis databasstyrt innehåll.
En konkurrent till InDesign är QuarkXPress vilket är det layoutprogram som funnits längst.
Quark har tidigare ansetts som ledande program för DTP, men på senare tid har InDesign tagit
marknadsandelar och anses nu ha störst utbredning. InDesign och Quark finns för plattformarna
Mac och Windows.
2.4.2
Katalogproduktion
Funktioner inbyggda i layoutprogram
I alla tre program ovan finns inbyggd funktionalitet för automatiserad layout och koppling till
datakällor. Dessa funktioner kan utnyttjas för katalogproduktion. Då det gäller katalogproduktion på professionell nivå används förmodligen InDesign eller Quark. Publisher i egenskap av
enklare program har dock inte lika utvecklad funktionalitet som InDesign eller Quark.
I Publisher finns funktionen Koppla dokument/Katalog . Syftet är att skapa en layoutmall
vilken kopplas samman med en databas. I mallen för en post i databasen definierar användaren
vilka fält i databasen som ska infogas vart. Denna mall fylls vid sammankopplingen i med data
från databasen och upprepas så många gånger den får plats på en sida. Sidantalet i det färdiga
dokumentet blir dynamiskt mot storleken på databasen. Det finns stöd för att infoga både bilder
2.4 Be ntliga verktyg och tjänster
13
och text. Dock får datakällan endast innehålla text, vilket medför att bilder infogas med hjälp
av de sökvägar som anges i databasen. De datakällor som kan användas är exempelvis MS
Excel eller annan typ av databas via ODBC (Open DataBase Connectivity) brygga. Termen
ODBC förklaras vidare i kapitel 2.5.4.
I InDesign finns en liknande funktionalitet benämnd DataMerge [30]. Även här skapas
en layoutmall vilken kopplas samman med en databas. Jämfört med Publisher finns dock fler
möjligheter vid layoutarbetet såsom att sätta specifika avstånd mellan kolumner och rader,
alternativ för hur bilder ska fylla ut sina layoutbehållare samt att begränsa antalet infogade
poster per dokument. Funktionen DataMerge kan använda tab- eller kolonseparerade textfiler
som datakälla. I MS Excel finns stöd för att exportera kalkylblad till dessa format.
Jämfört med behoven som tagits upp i föregående kapitel finns flera för- och nackdelar med
de programspecifika funktionerna ovan. Om information i datakällan läggs till, tas bort eller
ändras, finns möjlighet att enkelt uppdatera tidigare automatgenererade dokument. Mycket
tid sparas vid layoutarbetet eftersom en mall bara behöver skapas. Dock innebär detta en
begränsning om layouten i en katalog önskas varieras - alla poster kommer ha samma storlek
och interna layout. I och med att storleken på varje behållare är konstant innebär det även
problem om exempelvis all text i ett fält inte ryms inom avgränsat område. Publisher har även
svårt att hantera stora dokument med många objekt på varje sida.
För övrigt innehåll finns möjligheten att infoga sidor manuellt, exempelvis pärm och
köpinformation. Dock finns inget stöd i funktionerna ovan för att infoga annat automatiskt
innehåll såsom innehållsförteckning eller register. I InDesign finns dock andra verktyg för att
exempelvis åstadkomma unika avsnittsnamn i sidhuvudet på varje sida.
Plug-in moduler
På marknaden finns ett antal fristående plug-in moduler för automatiserad dokumentproduktion
till både InDesign [26] och Quark. Generellt sett erbjuder dessa moduler utökad funktionalitet
och flexibilitet jämfört med de inbyggda funktionerna ovan exempelvis vid katalogproduktion.
En vanligt förekommande modul är 65Bit Softwares EasyCatalog [3] till InDesign. Modulen
blir helt integrerad i programmet vilket kräver viss kunskap i hantering av InDesign då katalogen
ska skapas. EasyCatalog erbjuder mycket större flexibilitet vid layoutdesign än funktionerna
som beskrivs i föregående avsnitt men det kräver istället mer tid för manuellt layoutarbete. Den
största styrkan med modulen är att risken för att infoga fel minskas betydligt.
Flera typer av datakällor kan användas - allt från tab-separerade textfiler till XML-filer
och databaser via ODBC-brygga. Data i datakällan visas som en uppdateringsbar tabell i en
separat panel i programmet och kan där sorteras, grupperas och filtreras enligt användarens
tycke. Vid layoutarbetet kan flera mallar skapas för hur en produkts enskilda beståndsdelar ska
disponeras, eller hur layouten på en hel katalogsida ska disponeras. Dessa mallar lagras i ett
mallbibliotek. Layoutarbetet baseras sedan på dra-och-släpp -metoden. Önskad mall infogas i
dokumentet och därefter dras önskad post från databasen till denna behållare. Figur 2.4 visar
hur denna arbetsmiljö ser ut. På så vis kan hela dokumentet byggas upp produkt för produkt
och layoutdesignen kan varieras efter tycke och smak. Det finns även möjlighet att automatiskt
generera ett sökbart register till katalogen.
Valbara påbyggnadsfunktioner i EasyCatalog kan bland annat öka automatiseringen så att
införseln av poster fungerar på liknande sätt som Koppla dokument/Katalog och DataMerge
14
Förstudie
ovan, samt uppdatera en ODBC-databas enligt de dataändringar som gjorts.
I dagsläget (oktober, 2012) kostar en licens för EasyCatalog i grundkonfiguration över
10.000 kronor och kräver även en licens för InDesign. Detta faktum tillsammans med det
att InDesign är ett mer avancerat layoutprogram, ger bedömningen att detta metodval för
katalogproduktion bör används på en mer professionell nivå.
Figur 2.4. EasyCatalog i InDesign
Integrerade funktioner i innehållshanteringssystem
Innehållshanteringssystem, eller CMS (Content Management System) [17], är en typ av
system som kommit upp i samband med att marknadsföring via Internet ökat och därmed
behovet av centralisering och integrering mellan ett företags alla funktioner. Ett CMS är
webbaserat och kan koppla samman ett företags webbpubliceringssystem med affärssystem
och dokumenthantering. I grunden finns en eller flera databaser och systemets funktioner kan
kommas åt via användarvänliga plats- och plattformsoberoende webbgränssnitt baserade på
exempelvis PHP, Java eller ASP.NET.
Den största funktionaliteten med ett CMS är att skapa och editera innehåll för webbpublicering och i många system finns färdiga grafiska och funktionsbaserade mallar för detta
ändamål. Ett CMS är ofta anpassningsbart och användaren väljer de moduler som behövs,
exempelvis för blogg, forum, e-handel eller statistik. Många CMS erbjuder även en mängd
påbyggnadsmoduler för annat än webbinnehåll, såsom trycksaksproduktion. Ett mycket stort
antal både fria och kommersiella system finns på marknaden [19]. Till fria och mest använda
CMS hör exempelvis Joomla, Drupal och Wordpress. Eftersom dessa system har öppen källkod
är det fritt fram för utvecklare att skapa anpassade lösningar och påbyggnadsmoduler. Bland
de kommersiella systemen kan Litium Studio och Magento nämnas.
Som illustrerande exempel beskrivs Magentos modul för att skapa kataloger i PDF-format
[12]. Katalogens utformning editeras via ett webbinterface och fylls med innehåll från den
2.4 Be ntliga verktyg och tjänster
15
produktdatabas som används vid webbpublicering. Användaren kan fritt editera en första och
sista sida via ett WYSIWYG (What You See Is What You Get) gränssnitt, samt välja vilka
fördefinierade produktkategorier som ska tas med i katalogen. Generella inställningar kan göras
för exempelvis typsnittsstorlek, sidhuvud och sidfot, dock har användaren ingen kontroll över
grafisk layout, bildstorlekar, vilka enskilda produkter som ska tas med eller vilka beståndsdelar
som ska visas för varje produkt. Modulen har inte heller stöd för en automatiskt genererad
innehållsförteckning eller ett register. Figur 2.5 visar arbetsmiljön för kataloggenerering i
Magento.
Figur 2.5. Kataloggenerering i CMS-systemet Magento
Motsvarande moduler i andra CMS kan erbjuda fler eller färre möjligheter. I VirtueMart
Catalog för Joomla [29] finns exempelvis möjlighet att inkludera priser eller ej samt klickbara
länkar i den genererade PDF-katalogen. GiBi sPrint är en alternativ modul för Joomla
[4]. Till skillnad från VirtueMart Catalog tillåts användaren här ange antalet produkter per
katalogsida. Ett tredje alternativ är PDF Catalog Creator som är en modul för webbutikssystemet
osCommerce [13]. Denna modul kräver en installation lokalt i och med att det är en fristående
applikation. Dock ges användaren många fler valmöjligheter. Exempelvis finns möjligheten att
välja på 22 stilmallar för den grafiska layouten av katalogen.
16
Förstudie
Trots den alltmer utbredda användningen av CMS, finns det många företag som inte
använder sig av sådana system. Orsaken kan exempelvis vara att företaget är litet och saknar
den kompetens som krävs för anskaffande och nyttjande. Kort sagt: Finns inte ett CMS utesluts
de integrerade funktioner som dessa erbjuder som alternativ vid kataloggenerering.
2.4.3
Slutsats
På mjukvarumarknaden finns många alternativ för att generera produktkataloger. Program för
DTP, med eller utan plug-in moduler, ger fler variationsmöjligheter och större kontroll över
den grafiska layouten. Dock krävs mer tid för arbetet samt en viss datorteknisk kunskapsnivå.
Funktioner i CMS sparar mycket tid tack vare automatiskt genererade kataloger. Nackdelen
är istället begränsningar i möjligheter för grafiska layout samt att användaren är låst till det
eventuella CMS som företaget nyttjar.
2.5
Mjukvara
En studie i lämpliga tekniker för att implementera och realisera kataloggenereringsverktyget
genomfördes. Primärt användes två av kraven i kravspecifikationen som utgångspunkter,
nämligen att verktyget i ena änden skulle kunna importera artikelregister i Excel-format och
i andra änden producera en katalog i PDF-format. Målet med teknikstudien var därför att
hitta program- och dokumentformat som kunder överbrygga gapet däremellan, och inte minst
uppfylla resterande krav. Den fullständiga kravspecifikationen återfinns i bilaga 1.
2.5.1
Kort om Excel
MS Excel är ett kalkylprogram som ingår i programsviten Microsoft Office och är förmodligen
ett program som de flesta datoranvändare känner till och har erfarenhet utav. I detta projekt
utnyttjas inte Excel i egenskap av ett kraftfullt kalkyl- och diagramverktyg utan snarare som
ett lätthanterligt databasverktyg för att lagra artikeldata. Excel utnyttjas även på grund av
dess integrerbarhet mot andra format och system vilket förmodligen kommer sig av dess
stora marknadsandel. Som nämnts ovan finns inbyggd funktionalitet i Visma Administration
att exportera artikelregister till Excel-formatet .xls och det finns anledning att förutsätta att
många andra ekonomisystem också erbjuder den möjligheten. Åt andra hållet finns många
exportformat i MS Excel. Bara det faktum att ett kalkylblad kan exporteras som tab-separerad
textfil gör att begränsningar för integrering i andra system är obefintliga.
Som renodlat databashanteringssystem finns det dock förmodligen kraftfullare och mer
väletablerade system såsom MySQL, Oracle Database eller MS Access. Det går exempelvis inte
att flera användare hanterar en Excel-databas samtidigt eftersom den lagras som en enskild fil.
En annan nackdel är att en Excel-databas inte på ett lätt sätt kan lagras som en relationsdatabas
på grund av att det inte finns stöd för unika nyckelfält. En relationsdatabas kan innehålla ett
antal tabeller och posterna i dessa relaterar till varandra via identifierande nyckelfält. På så
vis minskas mängden upprepande information och databasen blir mindre till storleken och
mer lättraverserad. I detta projekt finns dock inte behov av multipel åtkomst. Dessutom anses
mängden upprepande information i ett artikelregister vara relativt liten varför fördelarna Excel
erbjuder i form av lätthanterlighet och integrerbarhet anses överväga.
2.5 Mjukvara
2.5.2
17
PDF
PDF (Portable Document Format) är ett dokumentformat med syfte att på ett uniformt sätt
presentera och distribuera digitala dokument, oberoende av den plattform presentationen sker
på. Att PDF är ett väl etablerat och standardiserat dokumentformat är största anledningen till att
det valts för detta projekt, men även att det lämpar sig som format för högupplösta trycksaker
likväl som för webbpublicering eller något däremellan.
Bakgrund
PDF har sedan 1993 utvecklats av Adobe Systems som under resans gång släppt inte mindre
än nio versioner av formatet vilka alla utökat funktionaliteten och möjligheterna. Om det från
början var ämnat att presentera text tillsammans med vektor- och bitmapsgrafik, finns nu
funktionalitet för exempelvis länkar, kryptering, formulär, 3D-grafik, video och ljud. PDF är
ett öppet format som är väl etablerat och sedan juli 2008 är det publicerat i sin helhet som
en ISO standard. Tidigare har delmängder av formatet standardiserats, vilka varit avsedda
för särskilda användningsområden och branscher. PDF/X används för specifika krav inom
exempelvis tryckeribranschen, PDF/A definierar krav för dokument som ska långtidsförvaras,
med flera [22].
Program
För att användare ska kunna tillgodogöra sig PDF-dokument har Adobe Systems sedan version
2 fritt distribuerat Adobe Reader som bland annat finns som fristående program till de flesta
operativsystem, applikation till smartphones samt som plug-in till de flesta webbläsare. De
senare har förmodligen bidragit till att PDF idag anses vara gällande format för att distribuera
dokument via webben. Om PDF-formatet i sig är ett öppet format så krävs kommersiell
mjukvara för att framställa PDF-dokument. Adobe Acrobat är ett program som distribueras av
Adobe System och är ämnat för detta ändamål. Tack vare att PDF är ett öppet och numera
standardiserat format finns dock PDF-generering idag integrerad i många andra applikationer
och system, exempelvis Adobe Creative Suite, MS Office senare programsviter och Open
Office för att nämna några. För utvecklare är PDF-formatet fritt tillgängligt för att skapa
egna implementationer vilka kan generera, manipulera, visa och distribuera PDF-dokument hörnstenen i detta projekt.
Teknik
PDF är ett dokumentformat utvecklat ur programspråket PostScript. PostScript används främst
för att beskriva utseendet på sidor i digitala dokument där gränssnittet är en skrivare. PostScriptkod, strömmad eller lagrad i .ps-format, exekveras av hård- eller mjukvara med en inbyggd
Raster Image Processor (RIP). Som resultat skrivs dokumentet ut på en skrivare eller visas
på en datorskärm [23]. Även om syntaxen i PostScript och PDF liknar varandra kan PDF
istället ses som en byte-uppbyggd komprimerad delmängd av PostScript där exempelvis
flödeskontroll och vissa funktionsanrop skalats bort. Det kan liknas vid att PostScript-koden
redan processats av en RIP till entydiga grafiska objekt med tillhörande layout. Detta bidrar till
att de grafiska objekten i ett PDF-dokument är korrekta avbildningar av sina original samt att
skärmrepresentationen av dokumentet stämmer helt överens med det utskrivna resultatet. Dock
är PDF ett mer avancerat och smartare dokumentformat än PostScript i avseendet att det utöver
18
Förstudie
grafisk beskrivning innehåller ytterligare funktioner och dokumentinformation. Som exempel
kan nämnas följande:
Utökat system för bifogade fonter samt fontersättning. Detta säkerställer att typsnittsdesignen på dokumentet bevaras, även då filen visas på ett system där aktuell font
saknas.
Metadata, såsom titel, författare, nyckelord för indexering, ändringsdatum med mera.
Interaktiva objekt såsom interna eller externa hyperlänkar, knappar och ifyllbara formulär.
Innehållsförteckning i form av bokmärken.
Kryptering och behörighetsbegränsningar, vilket är särskilt användbart vid distribution.
Direktiv vid utskrift, exempelvis skalning, utskriftsområde och information om färgseparering vid flerfärgstryck.
Strukturen i en PDF-fil medför ytterligare en fördel jämfört med PostScript, nämligen att
innehållet kan kommas åt i slumpmässig ordning tack vare korsreferering mellan de objekt
som bygger upp filen. Detta skapar ett oberoende mellan sidor och grafiska objekt samt låg
informationsredundans. I praktiken innebär det att en användare direkt kan hoppa till sista sidan
i ett långt PDF-dokument och få en korrekt presentation på skärmen, medan ett motsvarande
PostScript-dokument helt måste processas innan sista sidan kan visas på ett korrekt sätt.
Som beskrivs på sidan 38 i standarden för PDF [5] består en PDF-fil i grunden av fyra
sektioner vilket illustreras i figur 2.6:
Header - anger bland annat PDF-version.
Body - uppbyggt av objekt som beskriver innehållet i dokumentet.
Korsreferenstabell - nödvändig för att kunna komma åt alla objekt i slumpmässig ordning.
Trailer - innehåller till exempel antalet objekt i filen, samt anger var i filen korsreferenstabellen kan hittas.
På sidan 13 i standarden för PDF [5] beskrivs de åtta typer av objekt som kan finnas i en
PDF-fil. Som exempel kan nämnas nummer, namn och dataströmmar. Vanligast är dock objektet Dictionary (ordlista) vilken är en gruppering av flera namngivna objekt (eller referenser
till andra objekt). En Dictionary kan sägas beskriva ett innehållsobjekt i dokumentet. Som
exempel kan en hel sida i ett dokument beskrivas av en Dictionary, vilken då anger vilka fonter
som används på sidan, vilka bilder som ska finnas med och vart de ska placeras, textinnehållet
med mera. Dessa kan i sin tur vara egna Dictionaries vilka beskriver egenskaper för respektive
objekt. Objekt 0 4 i figur 2.6 är ett Dictionary-objekt.
Ett objekt kan vara direkt eller indirekt. Indirekta objekt, i kombination med korsreferenstabellen, medför att ett objekt kan vara lokaliserat var som helst i filen och att en PDF-fil därför
inte behöver processas sekventiellt. Om ett objekt är indirekt, vilket är vanligast förekommande,
tilldelas detta per automatik ett indexnummer. Dessa nummer används av korsreferenstabellen
samt för referering mellan föräldra- och barnobjekt.
2.5 Mjukvara
19
Figur 2.6. Sektionerna i en PDF-fil
20
Förstudie
2.5.3
Javabiblioteket iText
Tidigt i projektet beslutades att utveckla kataloggenereringsverktyget i programmeringsspråket
Java. Eftersom dokumentformatet PDF är så pass utbrett och standardiserat som det är, undersöktes om det fanns färdiga programbibliotek för Java vilka kunde generera PDF-dokument.
Webb-sökningar resulterade i referenser till tredjeparts programbibliotek såsom Apache PDFBox,BFO:s Java-bibliotek samt iText. Flera faktor gjorde att iText snabbt bedömdes som ett
lämpligt val:
iText är ett öppet programbibliotek gällande under GNU Affero General Public License2
[7], därmed fritt att använda inom detta projekt.
Programbiblioteket har ett omfattande API (Application Programming Interface) för att
skapa, läsa och uppdatera PDF-dokument. Därav gjordes bedömningen att det borde
tillgodose behoven för detta projekt.
Enligt uppgift på sidan 5 i boken iText in Action [28] är iText världsledande som F/OSS
(Free and Open Source Software) bibliotek. Detta stöds även av att många oberoende
källor refererar till iText som ett lämpligt val för PDF-hantering.
iText är väl dokumenterat både med litteratur [28] samt med HTML-dokumentation
skapad i Java [6].
iText har varit under utveckling sedan 1998 och uppdateras ständigt med ny och utökad
funktionalitet. Det är därför rimligt att anta att det kommer finnas stöd för programbiblioteket länge än.
iText täcker in funktionaliteter för att programmatiskt skapa, läsa och manipulera PDFdokument på ett automatiserat sätt. Syftet med applikationer som använder sig av iText är alltså
att inget mellanliggande mjukvaruprogram för att manuellt skapa innehåll ska krävas för att
åstadkomma ett dokument i PDF-format. Detta lämpar sig särskilt för dynamiskt innehåll som
skapas i realtid från exempelvis en databas, eller då innehållet är mycket omfattande.
Generellt sett finns det mesta av funktionaliteten i PDF-standarden inbyggt i API:t för
iText. Det finns exempelvis stöd för kryptering, generering och automatiskt ifyllande av
formulär, direktkonvertering av XML till PDF, vattenstämplar, sammanfoga flera existerande
PDF-dokument till ett samt extrahera text, bara för att nämna en del.
Grundläggande arkitektur för att skapa ett PDF-dokument med iText består av fem steg:
Först skapas ett dokument-objekt till vilket innehållet ska adderas. Därefter anropas en instans av en så kallad PDFWriter som kan betraktas som en tolk vilken översätter adderade
Java-objekt till korrekt PDF-syntax. De sista tre stegen består i att öppna dokumentet, addera
innehåll och därefter stänga dokumentet. Figur 2.7 visar ett enkelt kod-exempel och dess resultat.
2
Upphovsrättslicens för fri programvara. Om en applikation använder programvara gällande under GNU GPL,
måste dess källkod göras allmänt tillgänglig vid distribution av applikationen.
2.5 Mjukvara
21
Figur 2.7. iText exempel
2.5.4
Excel-import i Java
Enligt det första kravet i kravspecifikationen ska kataloggenereringsverktyget kunna importera
ett artikelregister lagrat i något av formaten möjliga i MS Excel. Som nämnts tidigare är motivet
till detta att Excel har en utbredd användargrupp, vilket gör det troligt att många användare
har möjlighet att lagra artikelregister med hjälp av detta program. Dessutom motiveras detta
ytterligare av att det vanligt förekommande ekonomisystemet Visma Administration ger
möjlighet att exportera artikelregister till Excel-format.
Flera lagringsformat stöds av MS Excel, bland annat XML, tabbavgränsad textfil och
semikolonavgränsad textfil. Integrerbarheten mot andra applikationer bedöms därför som stor.
Grundformatet i Excel är dock det programspecifika .xls3 . En användbarhetsaspekt vid hantering av kataloggenereringsverktyget är att ju färre steg och åtgärder användaren behöver
3
För dokument skapade i MS Excel 2007 och senare gäller motsvarande .xlsx-formatet, men då kravspecifikationen endast kräver kompabilitet med ett Excel-format, kommer stöd för .xslx-filer ej implementeras
22
Förstudie
vidta för att skapa sin katalog, desto mer lätthanterligt upplevs verktyget samt att risken för
fel minskar. Då det bedöms som troligast att ett artikelregister skapat i Excel är lagrat som
.xls-fil behöver därför verktyget kunna importera artikelregister i detta format. Efterforskningar resulterade i två alternativa programbibliotek för Java vilka ansågs uppfylla behoven för
detta projekt: Apache POI samt JExcel. Även ett tredje mer generellt sätt för databasåtkomst
undersöktes.
Apache POI är ett fritt Java API skapat av Apache Software Foundation [1]. Syftet med
API:t är att kunna skapa, läsa och manipulera dokument i något av formaten baserade på
OOXML (Office Open XML) standarden samt OLE2 (Microsoft-formatet Object Linking and
Embedding Compound Document). Detta inkluderar bland annat dokument skapade i MS
Word, MS Publisher samt MS Excel. Apache POI består av flera programbibliotek - ett för
varje dokumentformat. Biblioteket HSSF stöder .xls-formatet och biblioteket XSSF stöder
.xlsx-formatet. Därav är Apache POI kompatibelt även med MS Excel 2007 och senare.
JExcel är ett Java API fritt att använda under GNU LGPL licens4 [8]. JExcel byggs upp av
ett programbibliotek med funktionalitet för att skapa, läsa och manipulera filer i .xls-format.
Funktionalitet som stöder .xlsx-formatet finns ej i dagsläget.
Nackdelen med dessa externa Java-bibliotek är dock att de båda kräver mycket minnesutrymme vid körning av mycket stora kalkylblad. Anledningen är att data från aktuellt kalkylblad
helt läses in i minnet, vilket kan ta tid, för att sedan därifrån behandlas av aktuell applikation.
Apache POI erbjuder ett så kallat Event API för att kringgå detta, men denna lösning fungerar
endast för .xls-dokument, ej .xlsx.
För att det inte ska finnas någon begränsning med kataloggenereringsverktyget för hur
omfattande ett artikelregister kan vara, har ett mer generellt sätt för databasåtkomst utretts.
Inom Java:s standard-API finns stöd för Open Database Connectivity (ODBC), vilket är en
standardiserad metod för åtkomst av databaser [21]. I en Java-applikation definieras en ODBCbrygga vilken gör att data från en viss typ av datakälla kan hämtas med hjälp av SQL-frågor
(Structured Query Language). Både i Windows- och MacOS-miljöer finns inbyggt stöd för
en ODBC-brygga där datakällan är ett Excel-dokument. Om denna metod implementeras i
kataloggenereringsverktyget motverkas minnesproblemet, samt att det öppnar upp för att lätt
byta till andra typer av datakällor än Excel.
2.5.5
XML
Extensible Markup Language (XML) är ett så kallat märkspråk vars syfte är att skapa en
standard för utväxling av data mellan olika informationssystem, då främst över Internet
[25]. XML-strukturen består av två komponenter: En textfil innehållande uppmärkt data i
en noduppbyggd trädstruktur, samt en tillhörande dokumentmall vilken beskriver regler för
den struktur efter vilken XML-dokumentet är uppbyggt. Båda delarna kan definieras av användaren vilket ger stora friheter och möjligheter med hur XML kan användas. En annan
egenskap med XML är dess enkelhet då människa som maskin kan läsa och tillgodogöra sig
innehållet i ett XML-dokument. Dessutom är syntaxen för XML mycket enkel vilket gör att
4
Om en applikation använder programvara gällande under GNU LGPL, tillåts distribution utan att göra
källkoden allmänt tillgänglig
2.5 Mjukvara
23
det inte är särskilt komplicerat att skapa ett XML-dokument. Ett enkelt exempel visas i figur 2.8.
Figur 2.8. XML exempel
Andra applikationer tillgodogör sig innehållet i ett XML-dokument genom att bearbeta
ett XML-dokument via en så kallad parser, eller tolk. För att denna bearbetning ska fungera
optimalt bör det aktuella XML-dokumentet inneha vissa egenskaper.
XML-dokumentet bör vara väl utformat. Detta innebär att syntax för XML följs,
exempelvis korrekt nästling av element, att endast tecken tillåtna i den teckenkodning
som specificerats finns i dokumentet samt att endast ett rotelement förekommer.
XML-dokumentet bör även vara giltigt. Detta innebär att en tillhörande dokumentmall,
eller schema, finns i vilken det bland annat är specificerat vilka element som få
förekomma, vilka attribut som är giltiga för respektive element, i vilken ordning
elementen får förekomma, samt vilken föräldra-barn struktur som är giltig. Vanligt
förekommande typer av dokumentmallar är DTD (Document Type Definition) samt
XML schema. XML schema anses ha en mer intuitivt syntax samt vara mer utbyggt
än DTD. Exempelvis finns möjligheten att ange hur många gånger ett viss element får
förekomma i XML-dokumentet.
I detta projekt ses möjligheter att definiera textuella layoutmallar samt programstrukturellt data
med hjälp av XML.
Tillämpningar av XML
Tack vare den enkelhet, flexibilitet och det plattformsoberoende XML medför finns idag många
tekniker som baserats på märkspråket. Bland specifikationer som är nära besläktade med XML
kan nämnas XML Namespace, XPath och XSLT. XML Namespace, eller namnrymd, används
för att undvika tvetydigheter vid namngivning av element. Två olika typer av element tillåts då
24
Förstudie
inte att namnges på samma sätt. XPath är ett frågespråk framtaget för att enkelt kunna adressera
sökta noder i ett XML-dokument. XSLT är ett märkspråk som används för att transformera
ett XML-dokument till något annat, exempelvis ett nytt XML-dokument bestående av utvalda
delar av det gamla, ett HTML-dokument eller ren text. XSLT utnyttjar XPath-uttryck i det
XSLT-schema som specificerar hur transformationen ska gå till.
Många nya programmeringsspråk som baseras på XML har utvecklats, exempelvis XHTML
för webbutveckling samt RSS för webbaserade nyhetsflöden. Dessutom baseras många nyare
dokumentformat för exempelvis ordbehandling, kalkylblad och presentation på XML. Till
dessa hör MS Excel:s format .xlsx.
I de flesta större programmeringsspråk finns API:n för att möjliggöra implementering av
XML då applikationer och program skapas.
Gränssnitt mellan Java och XML
I Java finns ett väl utbyggt stöd för XML-tillämpningar både i form av standardpaket och
fristående API:n för att tolka, bearbeta och skapa XML-dokument. Två huvudkategorier av
XML parsers kommer att tas upp: trädstrukturerade samt strömmande.
Det trädstrukturerade DOM (Document Object Model) är i grunden en plattforms- och
språkoberoende konvention som bygger på att innehåll i ett dokument representeras som objekt
i en trädstruktur [2] [16]. DOM-baserade XML-parsers tillåter godtycklig åtkomst av objekten
vilket görs möjligt av att hela eller delar av dokumentet vid varje givet ögonblick finns lagrat
i datorminnet. Detta medför att DOM-baserade applikationer är relativt minneskrävande, men
ger istället flexibilitet då ett objekt kan kommas åt när som helst. DOM-baserade parsers lämpar
sig bäst för mindre XML-dokument med en på förhand känd struktur eller då XML-dokument
ska manipuleras eller skapas.
Strömmande parsers, även benämnt SAX (Simple API for XML) traverserar ett XMLdokument seriellt från början till slut. På så vis krävs minimalt med datorminne på bekostnad
av att endast en ögonblicksbild av XML-dokumentet ges vid ett givet tillfälle. Strömmande
parsers lämpar sig bäst då det finns krav på låg minnesanvändning samt då innehållet i ett
XML-dokument ska trigga särskilda händelser i en applikation [24].
Exempel på vanliga Java API:n för XML-hantering är JAXP (Java API for XML Processing)
samt JDOM.
JAXP är ett API utvecklat av Sun Microsystems och innehåller stöd för olika typer av
parsers. DOM för godtycklig åtkomst av XML-data samt bygga XML-dokument, SAX för
seriell åtkomst och händelsestyrning samt StAX (Streaming API for XML) vilket kan ses som
ett mellanting av DOM och SAX. Dessutom finn ett XSLT gränssnitt för transformation av
XML-dokument [18].
JDOM är ett öppet programbibliotek med stöd för DOM, SAX, XPath och XSLT. JDOM
är inte lika komplext som JAXP och därmed mer effektivt att implementera XML med. Enligt
utvecklarnas utsago är JDOM intuitivt och lättare att börja använda då dess arkitektur är
uppbyggd särskilt för Java-plattformen och påminner mycket om standardimplementeringar i
Java [9].
Kapitel 3
Utveckling
Målet med utvecklingsarbetet var att ta fram en grafisk kataloglayout lämplig för automatisk
katalogframställning samt implementera ett verktyg som skapar en produktkatalog för ett givet
artikelregister där den fördefinierade layouten utnyttjas. Målet skulle vara nått då kraven i
kravspecifikationen uppfyllts, se bilaga 1. Under förstudiearbetet gjordes efterforskningar i
konventioner kring kataloglayouter, befintliga verktyg för katalogframställning samt lämpliga
tekniker. Resultaten av förstudien tillämpades under utvecklingsarbetet vilket beskrivs i detta
kapitel. Som inledning redogörs för de utvecklingsmiljöer som utnyttjades under arbetets
gång. Därpå beskrivs arbetet med framtagning av grafisk kataloglayout följt av hur verktyget
programtekniskt implementerades.
3.1
Utvecklingsmiljö
Grafik utvecklades till största delen i Adobe Illustrator, främst på grund av stöd för vektorgrafik
samt möjligheten att konvertera bilder till PDF-dokument. Motivet till detta förklaras närmare
i kapitel 3.3.2 fjärde avsnittet nedan.
Ett tidigt val gjordes att programvaran skulle utvecklas i programmeringsspråket Java. För
detta krävdes tillgång till Java Development Kit (JDK) vilket innefattar utvecklingsverktyg
samt ett omfattande programbibliotek kallat Java API. För att underlätta utvecklingen användes
den fria programmeringsmiljön Eclipse. Eclipse är en populär utvecklingsmiljö som används
av många Java-utvecklare och ansågs därför som ett pålitligt och lämpligt utvecklingsverktyg.
I Eclipse finns stöd för kompilering och syntaxkontroll on-the-fly vilket avsevärt minskar tid
för felsökning.
För ytterligare utvecklingsstöd användes det öppna versionshanteringssystemet Subversion
(SVN). Versionshantering grundar sig i att exempelvis dokument, filer och källkod sparas i
versioner vilket gör det möjligt att backa tillbaka till och återskapa en tidigare version om
detta skulle önskas. Det ger även möjlighet till parallell utveckling av flera versioner vilket kan
vara användbart om en gammal utgåva av ett projekt behöver rättas. Versionshantering anses
särskilt användbart vid programvaruutveckling eller då flera användare skapar och manipulerar
filer inom ett och samma projekt samtidigt.
Inom detta projekt utnyttjades SVN särskilt för att lätt kunna backa tillbaka till tidigare
versioner av källkoden samt för att sätta milstolpar i form av utgåvor av verktyget. SVN
utnyttjades även som ett sätt att säkerhetskopiera allt digitalt innehåll i projektet.
25
26
3.2
Utveckling
Gra sk design
Design av den grafiska kataloglayouten skedde inkrementellt: Ett första utkast togs fram
vars resultat grundade sig i förstudiearbetet och visade det grafiska slutresultat som skulle
eftersträvas under implementeringen. Under utvecklingens gång fick dock vissa modifikationer
och nedskalningar göras beroende på vad som tidsmässigt och tekniskt var möjligt att realisera
inom ramarna för examensarbetet. Bilder och illustrationer nedan över den grafiska designen
visar det slutgiltiga resultatet.
3.2.1
Övergripande kataloglayout och design
Enligt kravspecifikationens krav K6 skulle den resulterande produktkatalogen innehålla vissa
beståndsdelar. Därav togs designförslag fram för en katalog i A4-format bestående av följande
komponenter:
Pärm med företagets namn samt säsong
Kontaktuppgifter
Köpinformation
Innehållsförteckning
Artiklar sorterade på artikelgrupp
Register
En övergripande riktlinje vid design av dessa delar var att hålla grafiken neutral och enkel
för att passa och tilltala en bred målgrupp, både vad gäller användare av katalogverktyget och
läsare av resulterande kataloger. Framför allt var syftet att grafiken skulle lämpa sig bra för
produktsortiment av vitt skilda typer.
Som diskuterades och visades i förstudiekapitel 2.3 - Behovsanalys, sker den mesta
katalogproduktion idag mer eller mindre manuellt. På bekostnad av tid tillåter detta att en
produktkatalogs utformning anpassas på ett intuitivt sätt mot dess innehåll. Via WYSIWYGgränssnitt kan katalogproducenten måla upp katalogen artikel för artikel och sida för sida.
Utmaningen då layouten ska skapas per automatik är att åstadkomma ett lika välformat resultat
som om katalogen skapats för hand. Vid designarbetet behövde därför hänsyn även tas till de
varierande behov av layout som kataloggenereringsverktyget var tänkt att stödja.
3.2.2
Artikellayout
Det viktigaste i en produktkatalog är dess produktförteckning varför största delen av designarbetet lades på artikellayouten. Ett första beslut var att designa mot en gles artikellayout vilket
grundade sig i flera motiv.
I enlighet med principer för användarcentrerad utveckling genomfördes en informell
undersökning där olika typer av produktkataloger visades för ett antal personer. Åsikter från
denna undersökning visade på att kataloger med gles artikellayout är mer estetiskt tilltalande
samt upplevs som mer lättlästa och mindre röriga då produktbilder och textstorlek kan vara
större och ett kataloguppslag innehåller färre antal artiklar.
3.2 Gra sk design
27
En gles artikellayout kräver mindre dynamik då artiklar ska disponeras över en sida
i exempelvis en enda kolumn. Därav underlättas mjukvaruutvecklingen då ett färre antal
eventualiteter behöver täckas in.
Då en gles artikellayout innehåller mycket tomma utrymmen tillåter det en större variation
av informationsinnehållet för en enskild artikel. Som exempel kan nämnas textmängd, bildstorlek och bildförhållande samt ett varierande antal bilder per artikel.
Ett designförslag för en artikel i en gles enkolumnslayout togs fram. De informationselement som enligt kravspecifikationen skulle ingå för en artikel var följande, med tillägg för
variant:
A. Artikelgrupp (ingår ej i artikellayouten)
B. Artikelnamn
C. Artikelinformation
D. Artikelnummer
E. Enhet, exempelvis styck, meter, kilogram
F. Förpackningsmängd
G. Pris per enhet
H. Bild
I. Variant (tillägg)
Figur 3.1 nedan visar disponeringen av respektive element. Artikelgrupp ingår inte i artikellayouten utan används endast i sorteringssyfte.
Figur 3.1. Layout för artikel
Disponeringen av respektive informationselement grundade sig i konventioner som enligt
förstudiekapitel 2.2.2 - Innehålls- och layoutkonventioner visat sig råda för katalogproduktion.
För textelement valdes typsnittet Quicksand som upplevdes som lättläst och tilltalande oavsett
storlek och visningsmedium. Vikt lades även vid att typsnittet skulle inneha en öppen licens
eftersom katalogverktyget är avsett att användas för kommersiellt bruk [10]. Avdelare och
tomrum utnyttjades för att underlätta läsbarheten. Produktbilder tilläts uppta en tredjedel av en
sidas bredd samt en femtedel av dess höjd då bilder ansågs som de viktigaste elementen för
läsaren. För den eventualitet att produktbild saknas skapades även en ersättningsbild med syfte
att informera om detta.
28
Utveckling
Med stöd ur förstudien ansågs dock vissa layout-variationer förekomma varför utkast för
dessa också togs fram enligt följande. I de fall flera liknande artiklar skulle visa en och samma
bild togs beslut att gruppera dessa, vilket visas i figur 3.2. Här kommer tillägget Variant väl
till pass för att som läsare kunna skilja liknande artiklar åt. Detta visas vid pil I i figur 3.2.
Detta skulle exempelvis kunna förekomma då endast färg eller storlek skiljer artiklar åt. Det
omvända förhållandes skulle också kunna förekomma, det vill säga att en artikel behövde visa
flera bilder. Hänsyn togs även till varianter där ett eller flera informationselement utelämnats.
De två senare layout-varianterna visas i figur 3.3, men dessa funktionaliteter implementerades
dock ej i verktyget.
Figur 3.2. Gruppering av liknande artiklar
Figur 3.3. En artikel - flera bilder
Ett kataloguppslag som illustrerar den fullständiga sido-layouten visas i figur 3.4.
3.2 Gra sk design
29
Figur 3.4. Fullständig sido-layout
3.2.3
Övrig layout
Artiklarna skulle enligt kravspecifikationen sorteras på artikelgrupp. Detta öppnade för att
dela in katalogen i kapitel, ett per artikelgrupp. Design för innehållsförteckning över dessa
kapitel togs fram, se figur 3.5, samt för titelsidor till varje kapitel, se figur 3.6. Här togs även
beslutet att koda varje kapitel med en unik färg i innehållsförteckning samt i sidhuvudet på
motsvarande sidor för att ge överblick samt underlätta sökbarheten i katalogen1 . Funktionen
med titelsidor inför varje kapitel implementerades dock ej i verktyget. Till sist skapades design
för artikelregister, sida för kontakt- och köpinformation samt pärm.
3.2.4
Gra skt material
En grundläggande idé vid designarbetet var att varje grafiskt element i kataloglayouten lätt
skulle kunna bytas ut. Syftet med detta var att underlätta för användare av verktyget att anpassa
katalogen mot exempelvis ett företags grafiska profil. Därav lagrades all grafik som bild-filer,
en för varje grafiskt element såsom linjer, bakgrunder samt logotyper, vilka lätt kunde bytas ut.
Denna möjlighet underlättade även implementeringen av verktyget.
1
Som visades i förstudien verkar färgkodning vara en vedertagen konvention bland många katalogproducenter.
30
Utveckling
Figur 3.5. Layout för innehållsförteckning
3.3
Figur 3.6. Layout för titelsida till kapitel
Programutveckling
Då ett första utkast till grafisk layout av katalogen var fastställt, var det dags att implementera
denna och önskad funktionalitet i kod. Riktlinjer under implementeringen var en modulär
uppbyggnad av programmet samt att möjliggöra utveckling av utökad funktionalitet i framtiden.
3.3.1
Verktygets funktionaliteter
Målet med programutvecklingen inom ramarna för examensarbetet var att implementera
kataloggenereringsverktyget med de funktionaliteter som listats i kravspecifikationen. Som
beskrivits i förstudien består dessa funktionaliteter grovt i att generera en produktförteckning
i dokumentformatet PDF där informationsinnehållet hämtats från ett artikelregister och den
grafiska utformningen från en fördefinierad mall. Dessa funktionaliteter illustreras i figur 3.7
över programflödet.
Figur 3.7. Programflöde
3.3 Programutveckling
3.3.2
31
Implementering
För att implementera funktionaliteterna ovan i Java användes utöver standardpaket de fristående programbibliotek som beskrivits i förstudien. Apache POI användes för att importera
artikelregister lagrade i MS Excel-format, JDOM för att importera XML-data såsom grafisk
mall lagrad i XML samt informationsdata att infogas i katalogen. För att exportera till formatet
PDF användes utvalda delar av Java-biblioteket iText.
Import och hantering av artikelregister
Stor vikt lades vid att importera data från ett artikelregister på ett strukturerat sätt då detta
sågs som en grundsten i projektet. En Java-klass skapades för att hantera import av data
ur ett Excel-dokument, men data i sig lagrades artikel för artikel i en datastruktur vilken var
oberoende av det format som artikeldatabasen lagrades i. På så vis skapades möjlighet att byta ut
importklassen för att kunna hantera andra databasformat i framtiden. För importen från Excelregister gjordes för enkelhets skull antagandet att kolumner för exempelvis artikelnummer, pris
samt sökväg för bild var sorterade i en viss förutbestämd ordning. (Figur 3.8 visar ett utdrag
ur det artikelregister som användes under examensarbetet.) Detta antagande grundade sig i två
saker. Dels att ekonomisystemet Visma exporterade artikelregister till Excel-format med en
viss kolumnordning, dels att kolumnordningen hade betydelse för de klasser som användes
ur Apache POI. Vid import med hjälp av dessa klasser refereras nämligen till en specifik
cell i kalkylbladet varur data ska hämtas. Därför var det viktigt att i ett första skede anpassa
importklassen så att exempelvis artikelnummer importerades till rätt fält i datastrukturen. En
framtida målsättning är dock att i en extern XML-fil, jämte databastyp, kunna ange egenskaper
för databasen såsom datatyper och kolumnordning. På så sätt ökas anpassningsbarheten vid
användning av verktyget.
Ett av syftena med detta projekt var även att kunna importera och publicera en obegränsad mängd artiklar med hjälp av verktyget. Här lämpade sig Apache POI bra då det
finns funktionalitet i programbiblioteket för att ta reda antalet rader som utnyttjas i ett kalkylblad. Detta i kombination med iteration ger möjlighet att hantera en obegränsad mängd
artiklar. En möjlig begränsning som togs upp i förstudien men dock inte undersöktes var
om resursen av datorminne som verktyget skulle allokera skulle räcka till för en stor mängd
artiklar. Möjligheten fanns här att använda en så kallad JDBC-ODBC-brygga för att skapa
äkta databasstöd och på så vis motverka eventuella minnesproblem. Dock skulle denna lösning innebära en större ändring i import-klassen varför detta i nuläget ännu inte implementerats.
Variationer och fel antogs kunna förekomma i ett artikelregister i Excel-format. Hantering
av de som ansågs vikigast implementerades i verktyget. Till dessa hörde särskilt avsaknad
av data. För de artikelposter som innehöll en eller flera tomma celler ersattes dessa fält i
datastrukturen med förutbestämda värden. Som exempel kan nämnas att saknad sökväg till
produktbild ersattes med sökväg till en fördefinierad bild-saknas -bild samt att ett streck
infogades då textuellt eller numerärt data saknades. Fält som nyttjades för intern strukturering
och sortering av artikelposterna skulle dock av förklarliga skäl inte godtas som tomma.
Punkt K6 i kravspecifikationen angav att artiklarna skulle vara sorterade i artikelgruppsordning. Detta för att möjliggöra en kapitelindelning på artikelgruppsnivå i den färdiga
katalogen. Ett mål med implementeringen var därför att strukturera importerat artikeldata för
att uppfylla detta krav. Beslut togs att sorteringen skulle ske på två nivåer: i första hand på
32
Utveckling
Figur 3.8. Utdrag ur artikelregistret
artikelgrupp och i andra hand på artikelnamn. Därav kunde alltså dessa fält inte godtas som
tomma i artikelregistret. Den sorterade datastrukturen skulle därefter vara färdig att exportera
löpande till ett katalogdokument. Dock återstod denna sorteringsfunktionalitet att implementera vid programutvecklingens slut. I nuläget importeras därför ett redan på förhand sorterat
artikelregister.
Import och hantering av gra sk mall
Punkt K5 i kravspecifikationen angav att verktyget vid körning skulle utnyttja en grafisk
mall för layoutkomponeringen av katalogen. Syftet med detta krav var att som användare
av verktyget lätt kunna ange och ändra egenskaper för layout såsom koordinater för objekt
i katalogdokumentet, typsnitt för text, storlek på produktbilder med mera. Beslut togs att
skapa denna mall som ett XML-dokument där sådana egenskaper kunde anges som data i väl
uppmärkta element. Hophörande element grupperades även i en trädstruktur för att underlätta
hantering av och sökbarhet i dokumentet. Strukturprincipen illustreras i figur 3.9.
I verktyget skapades därefter en datastruktur till vilken grafiskt data kunde importeras.
Även här, liksom för import av artikelregistret ovan, skapades en särskild Java-klass för att
hantera import av data i just XML-format. I en framtida utveckling av verktyget ges på så vis
möjlighet att byta filformat och tillhörande importklass för grafiskt data utan att datastrukturen
behöver implementeras om. För att sedan importera ett särskilt element från XML-dokumentet
med hjälp av JDOM behövde detta i import-klassen adresseras specifikt hela vägen från
rot-elementet. Därav behövde strukturen i XML-dokumentet vara definierad på förhand.
3.3 Programutveckling
33
Figur 3.9. XML-dokumentets strukturprincip
I ett första skede implementerades endast import för de grundläggande grafiska egenskaperna. Till dessa hörde bland annat dimensioner för den yta en artikel skulle allokera på en
katalogsida, relativa koordinater för varje text- och bildobjekt inom en artikel samt storlek på
produktbild. Många fler egenskaper skulle dock kunna anges externt i mallen för katalogen.
Som exempel kan nämnas marginaler i katalogdokumentet samt i vilken ordning katalogens
delar ska förekomma. Vissa användare skulle exempelvis kunna föredra att köpinformationen
presenteras sist istället för först.
Import och hantering av informationsdata
Förutom artikeldata fanns även krav på import av informationsdata såsom köpinformation,
sökväg till företagets logotyp och kontaktuppgifter. Även här togs beslutet att lagra dessa data i
ett XML-dokument på samma sätt som för den grafiska mallen. Undantaget var köpinformation
som baserat på förstudien bedömdes kunna vara omfattande i textmängd. Därför lagrades
34
Utveckling
endast sökvägen till en extern fil innehållande denna köpinformation i XML-dokumentet.
Trots att import av informationsdata skulle ske på samma sätt som för den grafiska mallen,
skapades en separat klass för detta. Motivet var återigen modularitet - att vid framtida utveckling
kunna byta format och metod för enskilda delar av verktyget. Allt XML-lagrat informationsdata
importerades med hjälp av en JDOM-baserad import-klass. Även här skapades en separat
datastruktur för att lagra detta data i datorminnet. Undantaget var köpinformationen vilken
importerades seriellt via en filström till en separat minnesbuffert varifrån det sedan hämtades
av export-klassen nedan.
Export av katalog
Det mesta av arbetet med implementeringen lades på exportfunktionen i verktyget. Många både
hög- och lågnivåfunktioner i Java-biblioteket iText användes för att skapa en produktkatalog
som ett PDF-dokument. Bland högnivåfunktioner utnyttjades bland annat enkla kommandon
för att infoga nya sidor sist i dokumentet eller hela textstycken där positionering, rad- och sidbrytningar skedde per automatik. Lågnivåfunktioner gav istället möjligheten att placera objekt
såsom bilder och textstycken vid absoluta koordinater2 , ange typsnitt, storlek och justering för
angivet textstycke eller arbeta i olika lager på en dokumentsida. Just lågnivåfunktioner kom väl
till pass för att implementera de layoutinställningar som angavs i den externa grafiska mallen.
En iText-baserad export-klass skapades i vilken en katalog genererades i två iterationer.
Figur 3.10 illustrerar flödesschemat. Under första iterationen skapades PDF-dokumentet och
katalogens respektive delar adderades i kronologisk ordning3 . Under andra iterationen öppnades det redan genererade PDF-dokumentet på nytt och innehållsförteckning, sidhuvuden och
sidfötter adderades innehållande sidreferenser som kalkylerats under första iterationen.
Som inledande momentet i första iterationen angavs katalogens genomgående egenskaper
såsom sidformat, marginaler och typsnitt (a). Därefter kunde innehåll börja infogas. Katalogens
fram- och baksida samt sida för kontakt- och köpinformation ansågs rymma mestadels icke dynamiskt innehåll varför objekt placerades vid absoluta koordinater. På framsidan (b) placerades
textfält för titel och säsong samt bildobjekt för företagets logotyp och en miljöbild. Tack vare en
bildklass i iText kunde dessa bildobjekt ges en maximal bredd och höjd vilket tillät användning
av bilder med alla tänkbara höjd/bredd förhållanden. Klassen stödjer även import av bilder av
många olika format såsom JPEG och PNG. Även PDF-dokument kunde importeras som bilder4
med hjälp av denna klass varför den användes frekvent genom hela katalogens konstruktion.
Därmed uppfylldes krav K3 i kravspecifikationen om de bildformat som skulle kunna tas in i
verktyget. På baksida (g) samt sida för kontakt- och köpinformation (c - d) placerades textfält
för kontaktuppgifter såsom adress och telefonnummer. Då köpinformationen bedömdes kunna
vara omfattande i textmängd avsattes en större yta för detta textfält och en högnivåfunktion i
iText för att fördela texten över flera kolumner utnyttjades.
2
Standardenheten inom PDF användes som måttenhet vilket motsvarar 72 enheter per tum. Koordinatsystemet
för en dokumentsida utgår från nedre vänstra hörnet. I iText finns dock möjlighet att använda exempelvis
millimeter som måttenhet istället.
3
I en framtida utveckling ses dock ett behov att ange ordningen för katalogens respektive delar i den externa
grafiska mallen. Därav behöver export-klassen struktureras om för att öka dynamiken och på så vis göra detta
möjligt.
4
PDF utnyttjades här som ett PostScript-baserat vektorformat
3.3 Programutveckling
35
Figur 3.10. Flödesschema över katalogexport
Artiklarna adderades till PDF-dokumentet i en iterativ process (e). Här utnyttjades återigen
möjligheten att infoga andra PDF-dokument som bilder i ett nytt dokument. Varje artikel, eller
grupp av hophörande artiklar, skapades nämligen först som ett litet komplett PDF-dokument
som lagrades i en minnesbuffert. Detta dokument infogades sedan som bild vid en kalkylerad
koordinat på sista sidan i huvuddokumentet. Processen började sedan om för nästa artikel, eller
grupp av artiklar. Figur 3.11 på sidan 37 visar processen. Som referens visar figur 3.2 på sidan
28 ett resulterande artikel-dokument.
36
Utveckling
Till att börja med skapades ett artikel-dokument med en fast bredd och höjd som angetts i
den grafiska mallen (e1). I nuläget motsvarar detta bredden av en A4-sida samt en höjd som
tillåter fem artiklar, eller grupper av artiklar, att lagom rymmas på en A4-sida. Sannolikheten
att höjden för ett artikel-dokument skulle behöva vara dynamisk bedömdes dock som stor
eftersom textinnehållet skulle kunna variera kraftigt. I skrivandets stund är dock stöd för detta
ännu inte implementerat. Textuella och grafiska komponenter för innevarande artikel eller
grupp av artiklar placerades ut vid de relativa koordinater och med de mått som angivits i den
grafiska mallen (e2 - e9). Här kunde antalet rader med artikelspecifikationer variera varför rad
2 och uppåt placerades vid kalkylerade koordinater.
Då artikel-dokumentet färdigställts skulle detta infogas i huvuddokumentet (e10). Placeringen avgjordes av flera faktorer: Om artikeln var den första på ett nytt kapitel skapades
en sidbrytning och artikel-dokumentet placerades högst upp på den nya sidan. Detta gällde
även då artikeln inte hörde till ett nytt kapitel, men när föregående sida var helt fylld. Då
artikel-dokument skulle placeras under andra artiklar gjordes en enkel koordinatberäkning. Vid
varje sidbrytning genomfördes även ett extra moment. En implementerad händelsehanterare
triggades varpå artiklar som placerats ut på innevarande sida gavs dess sidnummer. Syftet med
detta var att kunna skriva ut sidnummer för artiklarna i det sökbara registret. Om sidbrytning
skedde på grund av kapitelbyte spårades och lagrades även föregående kapitels start- och
slutsida för innehållsförteckningens skull.
Som nämnts ovan placerades artikel-dokumenten ut som bilder vid specifika koordinater
på en sida. I iText finns dock en högnivåfunktion för att placera ut objekt i en tabell. Denna
funktion sköter själv var på en dokumentsida nästa tabellrad ska infogas samt om en sidbrytning
i tabellen behövs. Därav skulle beräkning av koordinater samt kontroll om sidbrytning behövdes inte behövt implementerats. Dock skulle denna metod inneburit att händelsehanteraren
inte triggats vid sidbrytning mitt i en tabell varpå spårning av sidnummer för artiklar och
innehållsförteckning skulle fallerat.
Som sista moment i första iterationen infogades ett register (se åter figur 3.10, f). Här
placerades artikelnamn samt tillhörande sidnummer ut i tre kolumner på en sida med hjälp av
en högnivåfunktion i iText vilken fördelade text över flera kolumner. Artikelnamnen listades i
bokstavsordning. Dubbletter där både artikelnamn samt tillhörande sidnummer överensstämde
placerades inte ut.
En andra iteration tillfogade innehållsförteckning (h), sidhuvuden och sidfötter (i) till
katalogdokumentet. Att innehållsförteckning inte skapades i första iterationen berodde främst
på att ett kapitels sidomfattning inte kunde vara känt innan alla artiklar placerats ut. För
enkelhets skull allokerades endast en sida för innehållsförteckningen direkt innan första
kapitlet och innehållet skalades för att få plats på denna sida. Här adderades objekt i två lager. I
det undre lagret lades på förhand skapade färgfält som bilder på kalkylerade koordinater, i det
övre lagret lades textfält med kapitelnamn och tillhörande sidreferenser på samma koordinater.
Sidnummer för respektive kapitel hämtades från en global datastruktur som skapats under
första iterationen och som baserades på fältet artikelgrupp i artikelregistret. Figur 3.5 på sidan
30 visar resultatet.
3.3 Programutveckling
Figur 3.11. Flödesschema över generering och infogande av artikeldokument
37
38
Utveckling
Till sist adderades sidhuvuden och sidfötter sida för sida till alla sidor utom fram- och
baksida. Även här lades på förhand skapade färgfält som bilder i ett undre lager högst upp och
längst ner på sidan. Textfält infogades sedan i det övre lagret och dess placering var beroende av
innevarande sidnummer: Vänsterjustering för jämna sidor respektive högerjustering för udda
sidor. Textinnehåll och val av färgfält var beroende av sidallokering per kapitel som lagrats i
den globala datastruktur som nämndes ovan. Resultatet för sidhuvud och sidfot visas i figur 3.4
på sidan 29.
Gränssnitt mot användaren
Redan innan projektet startades togs beslutet att inte utveckla ett grafiskt gränssnitt mot användaren, men enligt kravspecifikationen skulle vissa användarfunktioner ändå implementeras.
I kapitel 3.3.2 tredje avsnittet ovan har möjligheten att ange sökvägar till indata, sökväg för
var den färdiga katalogen ska sparas, kontaktuppgifter med mera redan avhandlats. Däremot
behövde funktionalitet för att ge varningar till användaren enligt krav K11-K12 implementeras.
Det handlade om fall då sökvägar till indata visade sig vara felaktiga eller då en katalogfil
med angiven sökväg redan existerade. I det första fallet användes felhantering inbyggd i Java
API för att hantera inmatningsfel. Här gjordes ett tillägg att visa en dialogruta för användaren
som gav upplysning om felet samt avbryta exekveringen, se figur 3.12 nedan. I det andra
fallet kontrollerades om den fil som angetts i inställningsfilen redan existerade. Även här
genererades en dialogruta där användaren hade möjlighet att avbryta exekveringen, skriva
över den befintliga filen eller via dialogrutan ange ett nytt filnamn, se figur 3.13 nedan. Båda
funktionaliteterna implementerades i import-klasserna som beskrevs tidigare.
Figur 3.12. Dialogruta vid fel sökväg till artikelregister
Figur 3.13. Dialogruta då katalogfil redan existerar
3.3 Programutveckling
39
Som sista moment i utvecklingen skulle krav K8-K9 om hur verktyget skulle exekveras
uppfyllas. För att göra verktyget exekverbart via en fil valdes att utnyttja exportfunktioner
inbyggda i utvecklingsmiljön Eclipse. Alla skapade klasser och nödvändiga Java-bibliotek
packades till en exekverbar JAR-fil (Java ARchive). Externa resurser såsom bilder, artikelregister och inställningsfiler behövde dock ligga i en mapp utanför detta arkiv för att vara
åtkomliga och manipulerbara för användaren av verktyget. En nackdel med denna metod var
dock att krav K8 om systemförsutsättningar där verktyget skulle användas inte helt kunde
uppfyllas. Enligt kravet behövde systemet inte inneha någon JRE (Java Runtime Environment)
vilket är en förutsättning för att kunna exekvera en JAR-fil. Det finns dock lösningar för att
komma runt detta problem. Ett exempel är att bifoga en installationsfil med verktyget vilken
vid behov installerar nödvändig version av JRE via ett skript på det lokala systemet första
gången verktyget exekveras. Försök att implementera detta gjordes dock inte innan projektet
avslutades.
Kapitel 4
Resultat och diskussion
Detta projekt gick ut på att skapa ett verktyg för att enkelt och automatiskt skapa kataloger i
PDF-format utifrån ett på förhand känt artikelregister. Syftet med verktyget var att spara tid
och resurser vid katalogproduktion, särskilt för småföretagare där tid och resurser kan vara en
bristvara. Verktyget skulle även syfta till att minska risken för att infoga fel i katalogmaterialet.
Målet med projektet skulle vara uppnått när dessa krav uppfyllts. I detta kapitel utreds hur väl
syfte och mål uppnåtts samt lämplig vidareutveckling av verktyget i framtiden.
4.1
Utvärdering av verktyget
Under projektets gång har ett kataloggenereringsverktyg utvecklats i Java med funktioner
enligt den kravspecifikation (se bilaga 1) som tagits fram på förhand. Då utvecklingen var klar
genomfördes ett funktionstest för att testa om respektive krav uppfyllts.
Verktyget kan nu importera ett artikelregister i formatet MS Excel med de artikeldata
som specificerats, exempelvis artikelnamn, pris och sökväg till produktbild. Ett antagande
gjordes att artikelregistret exporterats från ekonomisystemet Visma med viss förutbestämd
kolumnordning vilket utvecklingen baserats på. Även om stor tidsbesparing och minskad
felrisk uppnås på detta vis, krävs dock viss manipulering av registret fortfarande såsom att
manuellt ange sökväg till produktbilden. Här ses även ett behov att bygga in stöd för en större
variation i ett Excel-registers utformning. Detta skulle exempelvis kunna uppnås genom att
användaren anger kolumnordningen i en inställningsfil, förslagsvis den XML-fil där alla andra
fördefinierade värden anges.
Verktyget kan importera produktbilder i formaten JPEG, PNG och i vektorbaserat PDFformat, samt skala dem till en angiven storlek. Tack vare bild-klassen i iText fungerar detta på
ett bra sätt och dessutom accepteras många fler bildformat såsom GIF och TIFF. Ansvaret för
kvalitet på produktbilderna överlåts däremot till användaren.
Som grafisk mall används ett XML-dokument där exempelvis sökväg till företagslogotyp
samt koordinater för textuella och grafiska objekt angetts. Även informationsdata såsom
telefonnummer och adress anges i detta dokument. Här ses en möjlighet att ange många fler
dynamiska indata till programmet. Som nämndes ovan skulle detta exempelvis kunna vara
kolumnordningen i artikelregistret, men det skulle även kunna vara ordningen på katalogens
beståndsdelar eller hur artiklar ska sorteras inom ett kapitel med mera. Detta för att öka
användarens inflytande över katalogens utformning. Dock ses en viss nackdel med att ange
indata direkt i ett XML-dokument. För en ny användare kräver det att alla element redan
41
42
Resultat och diskussion
existerar i dokumentet och endast behöver editeras med andra koordinater, sökvägar och
liknande. Det kan inte krävas av användaren att denne ska ha tillräcklig kunskap om XMLstrukturen för att kunna ange nya element. Utöver detta bedöms risken att infoga fel i
det befintliga XML-dokumentet som väldigt stor. Något så enkelt som att råka ta bort ett
element eller skriva in ett decimalt värde med kommatecken istället för punkt skulle orsaka
exekveringsproblem. Ett sätt att minska risken för editeringsfel skulle vara att skapa en DTD
till XML-dokumentet i vilken XML-strukturen definieras. För att utnyttja DTD:n skulle även
validering av denna behöva implementeras i verktyget. På så vis skulle användaren kunna få
varningar när XML-dokumentet inte är rätt utformat. Ett grafiskt användargränssnitt skulle
dock markant öka användbarheten av verktyget samt minska felrisken. Detta tas upp i avsnitt
4.3 - Vidareutveckling.
Vad gäller export framställer nu verktyget ett PDF-dokument i A4-format vilket innehåller
pärm, innehållsförteckning, kontakt- och köpinformation, register samt en produktförteckning
innehållande allt det data som artikelregistret rymmer. Utformningen bedöms som tillräckligt
generell för att vara applicerbar på produktsortiment av vitt skilda typer. Detta eftersom en
färdig katalog innehåller de beståndsdelar som under förstudien visats ingå i de flesta produktkataloger på marknaden samt att grafiska element har hållits neutrala i sin utformning. Även
kravet om objektsseparering är uppfyllt. Enskilda objekt går att markera i PDF-dokumentet och
på så vis finns möjligheten att manuellt editera dokumentet i efterhand.
Till sist har användningskraven testats. Användaren kan i inställningsfilen ange sökväg till
artikelregister, filnamn för den färdiga katalogen, kontaktinformation med mera. Verktyget kan
köras via en exekverbar JAR-fil samt ge varningar när sökvägarna ovan är felaktiga eller en
katalog med angivet filnamn redan existerar. Det enda krav som inte uppfyllts helt är det om
den datormiljö där verktyget ska exekveras. Som nämnts i kapitlet om utveckling krävs tillgång
till JRE eftersom verktyget i nuläget exekveras som JAR-fil. En lösning som avhandlades var
att inkludera nödvändig version av JRE med distributionen, men det finns även andra alternativ
[27]. Ett sätt är använda en så kallad Ahead-Of-Time (AOT) kompilator. Denna kompilerar
Java-koden och skapar en exekverbar fil vilken är anpassad mot den plattform där verktyget
ska köras. Detta kräver dock tillgång till ett verktyg för AOT Java Compilation samt att det
skapar ett plattformsberoende vilket motverkar syftet med Java - att vara plattformsoberoende.
Som komplement till kraven om användning skulle även ett användartest kunnat utföras där
verktyget utvärderades i skarpt läge. Detta skulle ha synliggjort fel som ännu inte hanteras av
verktyget, samt gett en uppfattning om hur användaren upplever verktyget. Utifrån ett sådant
test skulle säkerligen fler förbättringar av verktyget kunnat göras. För framtida utveckling av
verktyget är detta något som rekommenderas.
4.2
Resultat
Slutsatsen är att syften och mål med projektet i det stora hela har uppnåtts. En studie i hur
ett kataloggenereringsverktyg kunde utformas har genomförts. Därefter har ett sådant verktyg
skapats som tillåter stora resursbesparingar vid katalogproduktion, främst vad gäller tid. Risken
för att infoga fel minskas betydligt då ett artikelregister innehållande data som exporterats direkt
från ett ekonomisystem används samt att verktyget medför stor minskning vad gäller manuell
editering av katalogmaterialet. Alla krav, förutom krav K8 om datormiljö, har uppfyllts.
4.3 Vidareutveckling
4.3
43
Vidareutveckling
Vid eventuell vidareutveckling av verktyget ses många möjligheter och behov som kan täckas
in. Inom ramarna för examensarbetet ingick inte att utveckla ett grafiskt användargränssnitt
(se avsnitt 1.3). Om ett sådant togs fram skulle användaren kunna ange data i exempelvis ett
mer formulärliknande gränssnitt, välja bland fördefinierade data i rullister eller till och med
välja bland flera layout-mallar utifrån grafiska representationer av dessa. Ett XML-dokument
kan i detta läge fortfarande användas för lagring av indata, men användaren slipper manipulera
XML-dokumentet direkt. Användbarheten ökar och risken för fel minskar.
Ett annat sätt att öka användbarheten av verktyget är att implementera stöd för olika
typer av artikeldatabaser såsom MySQL, Oracle samt MS Access. Under förstudien nämndes
ODBC-brygga som i ett sådant läge skulle kunna fungera som nav mellan aktuell databas och
applikationen. Här borde även användaren ges möjlighet att i användargränssnittet mappa upp
de artikelfält i databasen som ska användas. På så vis ökas även flexibiliteten med verktyget.
Flexibilitet i utformningen av den färdiga katalogen kan även uppnås genom att ett flertal
typer av layout-mallar skapas, om inte annat för att tillmötesgå olika tycke och smak. Här
kan diskuteras om dessa mallar endast bör utformas av utvecklare av verktyget, eller om
användarna själva ska ges möjlighet att skapa egna mallar. Det senare alternativet skulle
förmodligen innebära utveckling av ett mer avancerat gränssnitt där användaren grafiskt kan
skapa och manipulera sådana mallar. I nuläget lagras en layout-mall som XML-data, men i
läget av grafisk editering skulle en mall även kunna lagras som ifyllbara PDF-formulär. Stöd
för formulär i PDF-format ingår i PDF-standarden.
Vad gäller innehållet i den färdiga produktkatalogen ses ett flertal implementationsmöjligheter. Några exempel listas nedan:
Möjligheten att exkludera artiklar i artikelregistret vid export till katalog.
Möjligheten att ange vilka artiklar som är nyheter för säsongen.
Möjligheten att endast välja ut en eller flera artikelgrupper att publicera.
Tillåta mer än en produktbild per artikel eller gruppering av artiklar.
Möjligheten att infoga titelsidor inför varje kapitel i katalogen.
Möjligheten att skapa en katalog med en separat prislista. Detta kan vara användbart då
ett produktsortiment är relativt konstant, men priser ändras med mycket högre frekvens.
Stöd för olika pappersformat utöver A4.
Anpassa katalogen för tryck med exempelvis ett jämnt antal sidor i dokumentet, använda
färgsystemet CMYK, bedöma om upplösningen är tillräckligt hög på produktbilder, utfall
med mera.
44
Resultat och diskussion
Till sist finns en vision att utveckla verktyget med ett webb-gränssnitt där användaren
laddar upp eller länkar till artikeldatabas och katalogmaterial, men själva exekveringen sker
på server-nivå. Användare skulle kunna välja mellan flertalet layout-mallar vilka uppdaterades
med kontinuerliga nytillskott, kanske till och med erbjudas möjligheten att skapa och editera
egna. Detta skulle dock kräva en radikal förändring både av gränssättande krav och implementationen hittills. Fördelen skulle dock vara att tillgängligheten av verktyget ökar markant
samt att plattformsberoendet och behovet av distribution elimineras. Men det ligger många
utvecklingstimmar framåt i tiden...
Litteraturförteckning
[1] Apache POI - the Java API for Microsoft Documents.
http://poi.apache.org/ , Juli 2012.
[2] Document Object Model (DOM).
http://www.w3.org/DOM/ , December 2012.
[3] EasyCatalog Features.
http://www.65bit.com/products/easycatalog/features/features.shtm , Juni 2012.
[4] GiBi sPrint.
http://extensions.gibilogic.com/index.php?option=com_zoo&task=item&item_id=1 ,
Oktober 2012.
[5] ISO Standard - PDF 32000-1:2008.
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs
/PDF32000_2008.pdf , September 2012.
[6] iText, a Free Java-PDF library 5.3.0 API.
http://api.itextpdf.com/itext/ , Oktober 2012.
[7] iText and the Affero General Public License.
http://itextpdf.com/terms-of-use/agpl.php , April 2012.
[8] Java Excel API - A Java API to read, write, and modify Excel spreadsheets.
http://jexcelapi.sourceforge.net/ , April 2012.
[9] JDOM Mission.
http://www.jdom.org/mission/index.html , November 2012.
[10] License for font Quicksand.
http://www.fontsquirrel.com/license/Quicksand , November 2012.
[11] Nevotex - Om Företaget.
http://www.nevotex.se/en-us/svenska/omföretaget.aspx , Oktober 2012.
[12] PDF catalog - Export products and Categories in PDF.
http://www.magazento.com/english/pdf-export , September 2012.
[13] PDF Catalog Creator.
http://www.hanmingsoft.com/products/catalog2pdf/ , Oktober 2012.
[14] Wikipedia - Adobe InDesign.
http://en.wikipedia.org/wiki/Adobe_InDesign , Oktober 2012.
45
46
Litteraturförteckning
[15] Wikipedia - Biltema.
http://sv.wikipedia.org/wiki/Biltema , Oktober 2012.
[16] Wikipedia - Document Object Model.
http://en.wikipedia.org/wiki/Document_Object_Model , December 2012.
[17] Wikipedia - Innehållshanteringssystem.
http://sv.wikipedia.org/wiki/Innehållshanteringssystem , Oktober 2012.
[18] Wikipedia - Java API for XML Processing.
http://en.wikipedia.org/wiki/JAXP , November 2012.
[19] Wikipedia - Lista över webbpubliceringssystem.
http://sv.wikipedia.org/wiki/Lista_över_webbpubliceringssystem , Oktober 2012.
[20] Wikipedia - Microsoft Publisher.
http://en.wikipedia.org/wiki/Microsoft_Publisher , Oktober 2012.
[21] Wikipedia - ODBC.
http://en.wikipedia.org/wiki/ODBC , Oktober 2012.
[22] Wikipedia - Portable Document Format.
http://en.wikipedia.org/wiki/Portable_Document_Format , September 2012.
[23] Wikipedia - PostScript.
http://en.wikipedia.org/wiki/PostScript , September 2012.
[24] Wikipedia - Simple API for XML.
http://en.wikipedia.org/wiki/Simple_API_for_XML , November 2012.
[25] Wikipedia - XML.
http://en.wikipedia.org/wiki/XML , Maj 2012.
[26] Erdman, Paul: Database to InDesign.
http://www.creativeprogression.com/database-to-indesign/ , Maj 2012.
[27] Leskov, Dmitry: Convert Java to EXE.
http://www.excelsior-usa.com/articles/java-to-exe.html , Juli 2012.
[28] Lowagie, Bruno: iText in Action. Manning Publications Co, 2011, ISBN 9781935182610.
[29] Rozenberg, Bert: VirtueMart Catalog.
http://www.mrose.nl/virtuemartcatalog , Oktober 2012.
[30] White, Terry: Use Data Merge to build personalized documents.
http://www.adobe.com/designcenter-archive/indesign/articles/indcs2at_datamerge.html ,
Oktober 2012.
Bilaga 1
Kravspeci kation
Skallkrav
Funktionella krav
K1: Verktyget skall kunna ta in ett artikelregister producerat i minst ett av formaten möjliga
i MS Excel.
K2: Verktyget skall kunna ta in följande artikeldata i deras grundkonfiguration:
Artikelnummer
Artikelnamn
Artikelgrupp
Artikelinformation
Förpackningsmängd
Enhet
Pris per enhet
Bild som länk till fil och/eller bilddata
K3: Verktyget skall kunna ta in bilder av formaten JPEG, PNG och/eller något PostScriptbaserat vektorformat.
K4: Verktyget skall kunna skala bilder till angiven höjd och bredd.
K5: För grafisk layoutkomponering skall verktyget vid körning utnyttja en eller flera fördefinierade mallar. Dessa mallar skall vara grafiska eller textuella till karaktären.
(forts.)
47
48
Kravspeci kation
K6: Verktyget skall vid körning framställa en katalog i PDF-format i storlek A4 innehållande
följande:
Artiklar med tillhörande data ingående i importerat artikelregister. Artiklarna skall
vara sorterade i artikelgruppsordning.
Fram- och baksida
Innehållsförteckning
Kontaktinformation
Köpinformation
Register
K7: PDF-katalogen skall vara objektsseparerad1 .
Användningskrav
K8: Verktyget skall gå att använda på en laptop med följande egenskaper:
Operativsystem Windows XP eller senare.
Adobe Reader
MS Excel
Åtkomst mot Internet upp- eller nedkopplad.
K9: Verktyget skall kunna köras som exekverbar fil.
K10: Verktyget skall efter programstart kunna konfigureras via en dialogruta eller en inställningsfil i vilka användaren kan ange följande:
Sökväg till befintligt artikelregister som skall användas vid katalogframställningen.
Filnamn och sökväg där katalogen skall läggas.
Sökväg till framsidesbild.
Kontaktinformation.
Sökväg till textfil innehållande köpinformation.
K11: Verktyget skall ge varning till användaren när sökvägar till artikelregister, framsidesbild
eller köpinformationsfil saknas.
K12: Verktyget skall kunna ge varning till användaren när katalog med angivet filnamn och
sökväg redan existerar med valmöjlighet att avbryta eller fortsätta. Vid valet att fortsätta
skall den tidigare katalog-filen skrivas över.
1
Med objektsseparerad menas att varje bild- och textobjekt i det resulterande PDF-dokumentet ska gå att
markera var för sig. Detta i syfte att kunna editera dokumentet manuellt i efterhand.