RSS

EVT version 1.1.1 and version 2.0 alpha released!

Hello everybody,
we are back at you with what may be called a “double feature” release: two new versions of EVT at the same time! Here are the details.

EVT 1.1.1

This version is a follow-up to v. 1.1, which was released for the DH2016 conference, and adds support for yet another specific list (<listOrg>) besides a little refining. The 1.1 and following version was supposed to be a bug fix release, but we actually managed to include new features in it: EVT 1 is going to stay with us for a long time, which means that we definitely want to support it not only with bug fixes, but also with improvements when possible. Do not expect radical changes or brand new features in this version, however.

Here are the most important changes, please read the first item carefully:

  • changed the starting point of the transformation which is now based on <text> (also when using a <group> element): this is the most important difference compared to EVT 1.0, in fact note that the old method based on <div> does not work anymore, so please make sure to read the EVT 1.1.1 manual on this point;
  • added support for image formats other than JPEG;
  • added German language support thanks to Christian Schuster from Transylvania Digital Humanities Centre (DigiHUBB: http://centre.ubbcluj.ro/digihubb/) who actually translated the English localization file;
  • added a template to rend italicized <title>s in <note>s;
  • added files for custom XSLT templates (evt_builder-custom-templates.xsl) and CSS rules (evt_builder-custom-styles.css), check section 3 of the manual;
  • added a distinction between critical <note>s and comment <note>s;
  • renamed evt_builder-miscellaneous.xsl into evt_builder-general.xsl;
  • added initial support for original content encoded into a <front>;
  • added support for <listOrg>;
  • many bug fixes!

Download it from the usual place and please report to us any problem that it may present. Your feedback is very much appreciated, as usual.

EVT 2.0 alpha

As the “alpha” tag suggests, this is not even a beta version of the new EVT 2 version. Actually it is very stable and does what it was created to do (support for critical editions in TEI XML format) quite well, but still has to be refined and, most of all, it lacks many important features available in EVT 1, the most critical one being support for digitized manuscript images.

EVT2 - Testimone frammentario

This is a very important release, however, because it is the first one based on the Angular.js framework and on the MVC design pattern, chosen because it allows to separate the logics of data presentation from the core of their processing. We needed more flexibility and modularity in order to make the development of new features easier and faster, and this has led to a completely new infrastructure: the XSLT stylesheets have been abandoned in favor of a set of JavaScript parsers specifically written to retrieve edition content directly from the XML file. Edition data is then saved in a JSON structure, organized in such a way that it can be easily and rapidly accessed when needed. The final styling of documents is entrusted to CSS style­sheets and is easily customizable.

EVT2 - Filtri

EVT2 - Heat map

Note that the current Javascript parser can only process TEI XML documents, but it is possible to add new parsers for different formats so that they are converted to the intermediate JSON structure, e.g. it is possible to add a custom XML (non­-TEI) parser, a LaTeX parser, etc.

These are the main features available in EVT 2.0 alpha:

  • Critical Edition support: rich and expandable critical apparatus, variant heat map, witnesses collation and variant filtering are some of the main features developed for the critical edition.
  • Bookmark: direct reference to the current view of the web application, considering view mode, current document, page and edition level, eventual collated witnesses and selected apparatus entry.
  • High level of customization: the editor can customize both the user interface layout and the appearance of the graphical components.

EVT2 - Varianti e note critiche

You can go straight to the online test site, but if you want to experiment with it you only have to download the archive from SourceForge and unpack it on your hard drive, after that you click on the index.html file and you are ready to go. If you want to try one of your documents you can do this by simply copying your file in the data folder and then editing the config.json file in the config folder: make sure that the dataUrl variable points to your file, e.g.

"dataUrl"          : "data/my_critical_edition.xml",

This version is the focus of all new development, so please let us know what you think of it writing at the usual contact email. Your feedback is even more appreciated for EVT 2 because this is the first public version and we definitely need to know if the path we have chosen is appropriate.

Many thanks to Marjorie Burghart for the TEI Critical Apparatus Toolbox which allowed us to perform a preliminary test of the TEI Parallel Segmentation method. A modified version of its sample file is the default pseudo-edition text showed in EVT 2.0 alpha.

 

 
Lascia un commento

Pubblicato da su luglio 28, 2016 in articles, evt, release

 

Tag: , , , ,

Second beta of the Digital Vercelli Book available!

As hinted in my previous post, a second beta of the Digital Vercelli Book published using EVT 1.0 is now available here: http://vbd.humnet.unipi.it/beta2/.

VBD-beta2-03

VBD-beta2-01

VBD-beta2-02VBD-beta2-04

Full announcement available here:

 
Lascia un commento

Pubblicato da su marzo 23, 2016 in Uncategorized

 

EVT version 1.0 has been released!

After a couple of intermediate releases, EVT version 1.0 is finally available! There are many new features in this version:

  • a full text search engine, with result highlighting in the text frame;
  • support for named entities: name highlighting in the edition text, browsable full lists with links to single documents;
  • support for <listPlace> and <listPerson> elements;
  • support for diplomatic documents (regesto) and for general information about specific texts;
  • support for bibliography, manuscript and project information;
  • User Interface localization;
  • lots of bugs fixed!

Go download it and check for yourself on the SourceForge site. For more information about how to use and/or customize EVT please refer to the EVT Manual included in the archive you downloaded, just look in the “doc” folder.

Please send all feedback to evt.developers@gmail.com[1], we would love to hear from you: bug reports, suggestions, even your general impressions about how EVT has worked for you are more than welcome. If you want to check an actual edition made with EVT, possibly showing all the latest features, the excellent Codice Pelavicino Digitale [2] is just what you want to browse.

CP-03

Named entities highlighting in the Codice Pelavicino Digitale

Also watch this space for an announcement about the Digital Vercelli Book😉

EVT version 1.0 is the result of months of hard work by our development team:

  • Chiara Di Pietro
  • Raffaele Masotti
  • Julia Kenny
  • Ilaria Tiezzi
  • Chiara Alzetta
  • Jacopo Pugliese

Thank you all and congratulations for this achievement!

RRDT

[1] You can also drop me a line at roberto.rossellidelturco@gmail.com. If for any particular reason you would prefer to send feedback anonymously, you can do it using this form; note, however, that it may take a little longer before one member of the development team checks it.

[2] The default EVT example in the 1.0 archive is in fact a single document from the Codice Pelavicino manuscript.

 

 
Lascia un commento

Pubblicato da su marzo 7, 2016 in evt, Uncategorized

 

Tag: , , , ,

SDE design: The agony and the ecstasy I

During all phases of EVT development the team members have had quite a number of lively discussions about the many topics and problems that such a (relatively) complex project entails: which programming and markup languages to use, basic features to implement in the beta version, the license to adopt when releasing EVT as open source software, the roadmap leading to its first release and subsequent ones, and more. Even considering roadmap-related issues, strictly linked to the financial and human resources available (hint: never enough of both!), the most heated debates revolve about one fundamental issue: which User Interface design for Scholarly Digital Editions should be implemented in EVT. This is easily explained if you think that we share basic ideas about most, if not all, of the technical aspects of software development, and that in any case I can only listen and then give green light on most of those issues, since Chiara, Julia and Raffaele have a competence in strictly technical aspects far exceeding mine; furthermore, roadmap-related issues usually fall in a sort of “external agents” category, be they impending university exams, a deadline for external projects or papers to be delivered, or quite simply a lack of adequate funding for all the nice things we have in mind.

UI (and UX: User Experience) design, on the other hand, is both an aspect of development we all believe to be fundamental for the success of EVT, and an area where every team member has her/his own specific sensitivity/orientation, therefore each of us has her/his own vision with regard how to make EVT “right“. A UI/UX done “right” makes a difference between a research tool that can prove useful to get stuff done, and a way to enjoy exploring and reading a digital edition besides that. Everyone in the team aims at this second goal besides the first one, and everyone has his/her own ideas about how to reach it. UI/UX development for EVT, therefore, is more a bumpy country road, where sometimes you get to regret how slowly you have to walk, than a speedy motorway leading you to the final, commonly shared destination. Also, there are lots of detours, dead-end streets and, of course, suffering and whining because of all the bumps😉

design-ux

“Getting the UI/UX right” for a software such as EVT is of primary importance for a number of reasons:

  • first of all, what is visible and actionable on the screen is “the edition” for our perspective users: at a markup level the edition is already there, but of course it is “invisible” for the intended public since without a tool such as EVT it wouldn’t be possible to access it, browse it, use it for research purposes or to simply enjoy viewing the manuscript images, reading the texts, and more; “getting the UI/UX right” means “getting the edition right” for all EVT users, and thence it is as important as “getting the edition right” at the markup and editorial level; note that, conversely, the marked up text is invisible to users once the edition has been published with EVT;
  • as noted by several researchers (see for instance Porter 2013 and my own 2011 article), a digital edition is still at disadvantage when compared with traditional printed editions because 1. digital editions are in small or big ways all different 2. you have to learn how to use them, both because of 1 and because they often include tools, such as text search/analysis tools, that are simply not available for printed editions (and, again, are all different in some way while sharing some common UI features); “getting the UI/UX right” also means lowering the learning curve as much as possible, with the ideal goal of making the digital edition as intuitive to use as a printed one;
  • last but not least, on the strictly technical level some aspects of the UI/UX are firmly connected with the internal workings of the software: a convoluted navigation system, for instance, would probably cause unnecessary stress on the software layer devoted to that specific purpose; vice versa, an elegant internal architecture would make it easier to devise an effective navigation method.

The first two points should be clear to everybody involved in the critical digital editing field, both creators and users of electronic editions. Indeed, we have received a good feedback about EVT by users of the Digital Vercelli Book beta, and generally appreciative remarks for its simple and elegant UI. Things are going to get more complicated soon (see below), but it never fails to surprise me how people may not be able to describe exactly what they what, but invariably recognize it when they’re presented with it. This is the general feeling with EVT and the VBD beta, even considering all its limitations, and it was a good one.

UI-like-a-joke

There’s another aspect to feedback, however, and it’s a darker, more troubling one: often the same people who appreciate a well done digital edition, and who are interested in using such resources on the Web, are not interested in taking part, if not in the actual design of such resources, in theoretical discourse about how to improve general usability and effectiveness of Scholarly Digital Editions. There is a general feeling that somehow, somewhere, somebody will come up with exactly the kind of resources that they need; not only that, but also the deeply ingrained conviction that an editor should do just that, prepare critical editions of his/her texts, and avoid at all costs getting involved with how these texts may be displayed and used in a digital edition: after all, this is why we have IT departments and technical personnel, right? not real “textual criticism” in action, is it? I will not surprise anyone by writing that I couldn’t disagree more with this line of thinking: it really is hard for me to imagine how an ICT professional, however excellent in his area of expertise, could design (not implement!) the perfect digital edition tool. Think of the “different layers …” of a critical edition, or even just the complexity of a full critical apparatus: who, if not a textual criticism scholar, is going to “get it right” when it comes to how and where the information is organized and showed to the user? Explaining to a programmer what we have done so far with printed editions, the rationale for critical apparatus etc. is not enough, since it’s the reason why so many first-generation digital editions resemble printed editions so closely, with a fixed layout similar to how the space is used on a printed page for the edition text, the critical apparatus, commentary notes etc.

For real innovation to happen in the SDE area with regard to their UI/UX component we all need to get our hands “dirty” with User Interface design: which doesn’t mean that anyone researching or studying textual criticism has to go out and buy the latest publications in HCI studies, of course, just sending detailed feedback to those creating digital editions and online resources would be a great start and a very appreciated help.

Those actually working on UI design for digital editions, on the other hand, need not only to listen to their own current and prospective users: they also need to put in place an effective way to share, discuss, accept and test UI design proposals. This is not a simple task in any research team, a fact of life that we discovered early during EVT development. The next post will be devoted to the work flow we are currently using and improving (or trying to) to design the next EVT version.

References

Porter, Dorothy C., ‘Medievalists and the Scholarly Digital Edition’, Scholarly Editing: The Annual of the Association for Documentary Editing, Volume 34 (2013) <http://www.scholarlyediting.org/2013/essays/essay.porter.html > [accessed 20 April 2015].

Rosselli Del Turco, Roberto, ‘After the editing is done: designing a Graphic User Interface for Digital Editions’, Digital Medievalist Journal, 7 (2011). <http://www.digitalmedievalist.org/journal/7/rosselliDelTurco/ > [accessed 20 April 2015].

 
Lascia un commento

Pubblicato da su aprile 20, 2015 in articles, evt, UI/UX

 

Tag: , , ,

TEI Embedded Transcription support in EVT

Since it was originally born as part of the Digital Vercelli Book project (http://vbd.humnet.unipi.it/), EVT was developed to deal with the XML encoding of texts which had been prepared for that project, namely making use of the XML TEI P5 parallel transcription method (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PH-bov). When using this method, information about the scan and possibly the coordinates of sensible areas are separated from the transcription and aligned with it thanks to linking attributes.

EVT-0.1.48-02The Vercelli Book Digital beta version using EVT

But, as it is possible to read in the TEI Guidelines, the scholar can choose to emphasize the importance of the physical surface and to encode words and other written traces as subcomponents of the XML elements representing the physical surface carrying them, rather than independently of them. This kind of encoding scheme is known as embedded transcription (www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHZLAB), and thanks to support from EADH (see EADH Small Grant: Call for Proposals at http://www.eadh.org/support/eadh-small-grants-call-proposals) this feature was added to the EVT software. The development took place in the period between May and July 2014.

Main changes to the original software

The main changes we implemented are mainly related to the identification and split of the text into different folios and the creation of the structure for the image-text linking tool.

Since the Vercelli Book transcription was completely encoded according to the parallel transcription method, we used different texts in order to have proper examples of embedded transcription; in particular, we used the TEI examples available in the Guidelines (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHZLAB) and the encoded text of the Slovenian «Tri Pridige O Jeziku (three sermons on language)» (http://nl.ijs.si/e-zrc/slomsek/index-en.html).

EVT-Slomsek-diplomaticThe Tri Pridige O Jeziku edition, an ET transcription, using EVT

First of all, we added an automatic detection of the encoded scheme used in the text that is being transformed (Parallel Transcription or Embedded Transcription): this identification is based on the absence/presence of the <sourceDoc> element, which is only used in ET.

If the system finds at least one <sourceDoc> element, the text will be treated as being encoded in ET: thus, each <sourceDoc> will be handled as a different document and each <surface> element, both when child of <sourceDoc> and when child of a <surfaceGrp> element, will be used to generate a single textual fragment.

We decided to consider the <surfaceGrp> element just as a mere generic division inside the code that does not produce any particular output in the interface. Moreover, even if the possible nestings of <surfaceGrp> are infinite, at the present moment the software is only able to support two levels.

The most important element after <sourceDoc> and <surface> is the <zone> element. This will be used to create the elements required for the activation of the image-text linking tool and of the hotspot tool.

A <zone> can be an empty node linked to one or more textual nodes, making use of the <line> element, or it can contain the text directly, without any further sub-elements. We considered both cases, therefore the XSLT transformation for the image-text linking tool will be activated with:

  • a <zone> element that contains some text and has the spatial coordinates attributes @ulx, @uly, @lrx and @lry. In this case, each sensitive area of the image identified by the previous coordinates will highlight all the text that was nested in the <zone>, even if it is distributed on more lines.

ET-TEIexample-1-EVT

ET-TEIexample-1-code

  • an empty <zone> element that has the spatial coordinates attributes and a reference to the particular <line> element it is linked to. Similarly to the previous case, each sensitive area of the image identified by the coordinates will highlight the text inside the element linked to the particular <zone>.

When the <zone> is missing the spatial coordinates attributes, the text-linking tool will not work, but the corresponding text (both if it is inside or outside the <zone> itself) will be rendered in the interface and nested in a particular HTML container (<div class=” *edition_level*–Zone “>), in such a way that the user can visually distinguish the separation between the different <zone> elements; the specific class (one for each edition level configured) allows to easily customize the visualization of the <zone> on the browser.

Instead, if the <zone> element is an empty node and the reference between it and the textual node is missing or broken, the text will properly appear on the page, but the image-text linking tool will not work for it, even if the <zone> had the spatial coordinates attributes.

As said before, in some cases the <zone> element will be used to generate an HotSpot, that is a sensible area on the image directly linked to a HTML pop-up window. We have decided to consider as a hotspot:

  • every <zone> that has the spatial coordinates attributes and is nested inside another <zone>; in this case the textual box will contain the text of the innermost zone;

ET-TEIexample-2

  • every <zone> (even if a direct child of <surface>) that contains a <graphic> element with a @url attribute; in this case the textual box will contain the image referenced by the <graphic> element and the text inside the <zone> itself (if present).

ET-TEIexample-3

All hotspots that were handled by means of the @rendition attribute in texts encoded in PT, will likewise work fine with texts encoded in ET.

Future developments

The remarkable variety of possible encodings available when using the Embedded Transcription method has made the task of supporting it more complicated than we expected. As it is clear from the section above, at least in this phase of development our support is somewhat “prescriptive”, in the sense that not every possible encoding is supported. This means that text encoded according to “reasonable” principles will very likely work, while in other cases it may or may not work and thence require some modifications to the encoded text. Since this is the first version of EVT supporting the Embedded Transcription method, we expect further improvements on the basis of users’ feedback: as always, feel free to contact us with your remarks, suggestions and feature requests. We have contacted the authors of the «Tri Pridige O Jeziku (three sermons on language)» edition mentioned above, and will experiment together with them with the goal of fine tuning ET support in EVT.

Contact

EVT Project editionvisualizationtechnology@gmail.com
Roberto Rosselli Del Turco roberto.rossellidelturco@gmail.com

List of participants

Chiara Di Pietro (dipi.chiara@gmail.com)
Julia Kenny (julia.kenny90@gmail.com)
Raffaele Masotti (raffaele.masotti@gmail.com)

References

Digital Vercelli Book project: http://vbd.humnet.unipi.it/.
EADH Supported activities and reports: http://www.eadh.org/support/supported-activities-and-reports [full report submitted to EADH].
Edition Visualization Technology: http://sourceforge.net/projects/evt-project/.
Digital Vercelli Book beta version using EVT: http://vbd.humnet.unipi.it/beta.
TEI P5 Parallel Transcription: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PH-bov.
TEI P5 Embedded Transcription: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/
PH.html#PHZLAB.
Tri Pridige O Jeziku (three sermons on language), http://nl.ijs.si/e-zrc/slomsek/index-en.html.

Post based on the final report by Chiara Di Pietro and Julia Kenny, revised and modified by R. Rosselli Del Turco.

 
1 Commento

Pubblicato da su novembre 11, 2014 in articles, evt

 

Tag: , , ,

EVT development: an update (and quite a bit of history)

Quite a lot of time has passed since the last entry on this blog, and many things have happened with regard to EVT development. It seems to me a good idea to propose a quick recap of the latest events, starting with a bit of history first, though.

There have been several incarnations of EVT, right from the times when the idea of a Digital Vercelli Book was just taking shape and well before even an experimental encoding of the transcription had been attempted. As you can see from the images below, at the time (about 2002-03) I was thinking of a very simple viewer to show images and the corresponding transcription/commentary texts, with a few features to handle the former (magnifying lens, hot spots, graphic filters).

VBD-BOOK_rtf_423bc67aVBD-BOOK_rtf_m5c914a54

The reference model was that of the Electronic Beowulf edition by Kevin S. Kiern, which looked like an incredibly powerful software to me, something too complex to be effectively replicated with the available resources (at that time: no resources to speak of, actually).

After the transcription efforts were started for good, using analogue photos converted to digital images, I kept looking around and testing all digital editions I could land my hands on. I was quite impressed by the viewer created by B. Muir for the Junius Manuscript, the Electronic Exeter Book and other image-based editions: in spite of some problematic UI choices (see After the editing is done: Designing a Graphic User Interface for digital editions), it was a very effective tool, suitable for all the research activities (image analysis, text search, etc.) that I envisioned for the DVB. It came with a few limitations, though:

  • very hardware and software specific: it required a specific version of a specific browser, which of course was the one available for the most widely used operating system (Internet Explorer 5.5 for Windows), but not for Linux or MacOS;
  • everything was HTML-based: while a static conversion from TEI to HTML has never been a troubling prospect for me, giving up on all the semantic information slowly and carefully included in the encoded transcription was quite a big deal; note, however, that now HTML is much “smarter” and semantic-friendly (thanks to HTML5 and microdata);
  • the viewer was to be licensed, being proprietary software, and while I’m sure I could have bargained a good deal about a VBD-specific customization, I’m a big supporter of the open source concept: doing something good and having its use and circulation restricted didn’t really sound right to me; in any case, have I mentioned I had few resources at the time?

Another interesting software that I had a chance to see in action at about the same time (at Kalamazoo 2005 if I remember correctly) was the Elwood viewer: it sported a very similar mix of good (fast, effective, powerful, multi-platform) and less good (proprietary, some UI issues, still in development) characteristics, so I had to rule it out, too. The good news is that development is finished and that the author is going to open source it after a final code clean up, hopefully sooner rather than later: it’s an amazing piece of software, and my EVT development leader can’t wait to have a look at the code😉

One project that caught my attention, and with which I collaborated for a while, was the EPPT software whose development was directed by Kevin S. Kiernan: it offered very comprehensive features for creating an image-based edition, and the plan was to extend its capabilities to the edition visualization part. Unfortunately, it never received the resources necessary fulfil such an ambitious plan, and it didn’t make all the necessary progress with regard to the presentation part. At the moment the web site doesn’t seem to be reachable any more: the lead developer informed me that this is due to a new server going to replace the old one, which crashed and was retired from service. The really good news is that this software has already been open sourced and it’s available on the SourceForge platform. This is excellent because its production component is mature and very sophisticated; among other features, it allowed to overcome the infamous multiple hierarchy problem which is XML’s greatest limitation. An updated version that could save in TEI XML format would be a great asset to the digital philology community.

What about the TEI community? There have been several projects in the past, some of which have unfortunately been abandoned (TEIViewer, TeiPublisher), while others were, and still are, unsuitable for diplomatic and image-based editions (TEI Boilerplate). Furthermore, almost always I had issues with the UI, or with some other critical aspect, such as supported platforms and OSes etc., of the software. What can I say, I am that fastidious …

So, in spite of my aversion to the NIH syndrome, possibly the worst problem plaguing the open source/free software community, I started looking into a light weight, web-based solution for a digital edition of the Vercelli Book manuscript. Starting from 2008 onwards I was asked to teach text encoding at the University of Pisa, in a Digital Humanities degree course, and I came in contact with a good number of smart and talented students. It was natural, then, to propose EVT as a PBL (Project-Based Learning) subject, with the realistic purpose of having a good experimentation playground and the more distant goal of actually producing something usable. In fact, the first EVT version was already useful for an edition, so both expectations were met.

flos-1 flos-2

But the student who created this first version, Francesca Fiorentini, wasn’t interested in continuing its development, so I assigned the task to another student, Francesca Capochiani. EVT v. 2 was born as a completely new project, written from scratch, and looked particularly feature-rich:

EVT-FC

Well, perhaps even too much feature-rich: Francesca worked hard and developed her version in a very autonomous manner, so basically I was showed the end result of her efforts. Just while I was grumbling about the need of a full team of developers, one that would discuss and make decisions in a cooperative way, Francesca Capochiani decided to pursue other interests and dropped all EVT-related development. Which reminded me of another advantage of a development team: if you lose a single individual, the common knowledge acquired is shared and lives on, development can continue.

I was thinking about this kind of organizational problems when I met Raffaele Masotti, who worked on EVT first for a stage and then for his BA degree. Meeting Raffaele was crucial for the destiny of EVT in more than one way:

  • first of all, Raffaele brought in a careful, meditated approach: see what is working in the current code base, decide which features to put aside (at least for the moment), examine the several problems which still had to be solved; for me, who feared another “let’s rewrite it from scratch!” jump in the dark, this was quite a relief;
  • one of the problems that still had to be solved was quite a fundamental one: what is the best way to load your data in a web-based viewer? after quite some study and research, inspired by the recent TEI Boilerplate and another project adopting an XSLT-based strategy, Raffaele turned that question upside down in what is EVT’s approach: you don’t do that, you build the viewer around the data; that’s how EVT Builder was born;
  • so we ended up rewriting EVT from scratch, after all, but it was for a very good reason, a complete re-design of its basic architecture that proved to be simple and effective;
  • last but not least, Raffaele proved to be very capable in handling EVT development under several aspects: when a dev team was eventually created by accepting more students for EVT-related stages and dissertations, Raffaele took care of introducing his colleagues to the software’s inner workings, of assigning tasks, of merging inputs in the code tree and more.

This last point is particularly important because the dev team has grown quite a lot: first we had Julia Kenny implementing two fundamental features, the magnifying lens and the image-text linking; she also did an excellent job at modifying the XSLT build chain, in such a way that she can be considered a co-author of the software. After Julia we added Jacopo Pugliese and Chiara Di Pietro to the team, dealing with the search functionality and critical edition support, respectively. The four of them can be considered the current EVT core team, to which you could add Giancarlo Buomprisco, currently working on the Digital Lightbox functionality for the DigiPal project; hopefully we’ll see a “light” version of his work in EVT at some point during 2014.

EVT v. 0.1.29 1 EVT v. 0.1.29 2

The newly born EVT Builder was presented at the Easy Tools for Difficult Texts workshop (The Hague 18-19 April 2013). The presentation was well received, so I encouraged my valiant students to work on a poster for the TEI MM 2013 (Rome 2-5 October 2013). The TEI Conference was a great occasion to meet people and show our work, and again we got a fair bit of attention, but it was thanks to the support received by the Biblioteca Capitolare that we could push for a an acceleration in EVT development, which led to the beta release of the Digital Vercelli Book shortly before Christmas 2013. The weeks before it were quite hectic: we only met a few times in person, but all the team was constantly in contact through an assorted set of chatting tools, mails, shared docs and even, when necessary, old fashioned phone calls! The development repository on GitLab was hit with scores of commits every day, until the software was ready for its debut. The screenshot below shows the final version of the beta, uploaded on SourceForge soon after the release.

EVT-0.1.48-01 EVT-0.1.48-02 EVT-0.1.48-03

Thanks to the hard work of all the team EVT development continues, for the moment being aimed at fixing bugs and polishing the Digital Vercelli Book beta, after which more important features will be added. But that’s the subject for future posts:)

RRDT

 
1 Commento

Pubblicato da su gennaio 26, 2014 in articles, evt

 

Tag: , , ,

How Publishers Should Prepare for EPUB 3

By Jeremy Greenfield, Editorial Director, Digital Book World, @JDGsaid

The future of e-books is now.

The approval of a new coding language for e-books, developed by the International Digital Publishing Forum (IDPF), a global trade and standards organization for the promotion of electronic publishing, means that soon it will be a relatively simple matter for e-books to contain video, audio, dynamic content and all sorts of interactive features.

The catch? Many of the features of EPUB 3, as it’s called, can’t currently be rendered by most e-reading software. Meaning, if a book publisher created a new e-book using EPUB 3 to embed a Google map or a Twitter feed, the book wouldn’t work properly on most e-readers.

But that’s all about to change.

“2012 will be the year when retailers adopt EPUB 3,” said Bill McCoy, executive director of the IDPF.

For instance, Ingram Content Group, the country’s largest distributor of digital and physical books, said that its e-textbook reader, VitalSource Bookshelf, which is available as an application for the iPad, iPhone, Mac Windows, browsers, iOS clients, and Android in the near term, will begin to support EPUB 3 in April.

“VitalSource works with 200 education publishers, most of which are gearing up for EPUB 3,” said Rick Johnson, chief technology officer for VitalSource.

As more e-reader software supports more of EPUB 3, publishers need to prepare for changes in creative capabilities, workflow, hiring and, maybe most important of all, their relationship with booksellers.

More here: http://www.digitalbookworld.com/2012/how-publishers-should-prepare-for-epub-3/

 

 
1 Commento

Pubblicato da su gennaio 24, 2012 in Uncategorized

 

Tag: ,

 
Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.