On 11/14/2013 8:06 PM, Pablo Rodriguez wrote:

On 11/14/2013 03:08 PM, Thomas A. Schmitz wrote:

...

Dear list,

today, I have an announcement to make and a call for contributions. We have obtained a medium-sized grant at my university to further development of ConTeXt. Specifically, our project wants to facilitate typesetting critical editions after the TEI xml standard and bibliographical data. Luigi will be employed as a full-time developer for the next 6 months (he signed his contract today); Hans will coordinate the work flow.

Thomas,

congratulations for the excellent news.

...

So this is good news. Now for the call for contributions: we invite you to send in examples in those two areas (critical editions, i.e. linenotes cum suis, and bibliographical data, aka bib-module) which show where ConTeXt could be developed. So please send examples to the list that show limitations or bugs, ask for new features, etc. If you want new features in the bibliography department, please do not send vague requests ("it would be nice if we could have hungarian reference systems") but small examples which show a precise feature and a possible syntax for it.

Are the requests to be addressed to this mailing list? Or do you plan something like a GitHub repository?

...

Of course, I can't promise that we will be able to act on all your submissions, but I'm optimistic that this project will make our favorite software better!

Many thanks for this project, because it benefits us all.

Just send initial requests to the list so that others also know about it. Luigi will collect and organize all that and put things in a repository. Then we will decide on what to take into account (on top of Thomas' requirements). There will be a repository (svn or so) on a dedicated machine at Thomas' faculty. Among the direct context related things are - a rewrite of bib modules (partially already done) - extensions to the (line)note mechanisms etc - the ability to plug in a bib processor (bibtex, mlbibtex, whatever we like) I'll probably start with that next month. There might be other new things showing up, and we might also look at some pending luatex opening op that relate to our problems. One thing that will also be done, is document the reasonable subset of tei for doing the kind of things Thomas does so we're talking of pure tex approaches alongside context-xml driven workflows. As Thomas said: we're not going to act on vague requirements that lack examples. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

·········

On 11/14/2013 9:40 PM, Philipp Gesang wrote:

...

What I’d consider the most pressing issue, pertaining both to Context and to TeX as a whole, would be text streams a.k.a. parallel typesetting. It was discussed on the list a couple times already and at one point someone collected examples [1]. Also, I sketched the current state of parallel texts elsewhere [2].

Maybe .. i have some ideas on that but might as well do columnsets first (not related to critical editions).

No problem, I wouldn’t have an immediate use for it anyways.

...

Looking forward to status reports! Will the improvements be directly merged into Context or do you prefer releasing it as a self-contained module?

It will be merged into the core but I can imagine a module with tei mapping snippets.

Thanks! Philipp

Hi Thomas, Am 14.11.2013 um 21:55 schrieb Thomas A. Schmitz :

On 11/14/2013 09:40 PM, Philipp Gesang wrote:

...

What I’d consider the most pressing issue, pertaining both to Context and to TeX as a whole, would be text streams a.k.a. parallel typesetting. It was discussed on the list a couple times already and at one point someone collected examples [1]. Also, I sketched the current state of parallel texts elsewhere [2].

For certain values of "pressing" :-) Two pessimistic remarks about that: (1) I experimented with a mechanism that Hans build for mkii a while ago, and I found it difficult to decide how to define what was expected of parallel typesetting. In the end, I wasn't convinced that an entirely automated version was possible at all. (2) I'm afraid that's not part of the present project and is related neither to critical editions nor to bibliographies.

I have to strongly disagree with you here. A critical edition is only a specialized case of parallel texts! You two or more editions that are contrasted/compared to each other. Naturally, it must be bibliographically annotated and there are the comments of the author of the critical edition. The editions have to be typeset in parallel. There are many ways how an author can lay this out. In the far past it was common just to stack the contrasted versions on top of each other! Very very ugly. Lots of examples in libraries. More recent ways are to use column. Yet, the more editions involved the harder it is to place on one page. For such cases it would be best to spread them across two facing pages. The problem with the two page setup is synchronizing the comments, notes, discussion of the critical edition's author. For a half way pleasing layout these should interplaced between the contrasted editions across the two pages. Yes, not an easy task. I agree that it is hard to automate the synchronization of text passages. The only viable approach would be at the paragraph level. A line level approach can only be achieved by interaction of the author of the critical edition with synchronization marks of some sort inside the editions. Early, in my education in Computer Linguistics, decades ago, we had project where we wrote a program for entry of critical editions. The editions/texts and comments were entered in parallel on the tty-terminal screen and stored in a database. At that time we where no interested in fancy output and used a simple stacked output. As you probably know yourself, it is the entry and synchronization of the editions that is the problem an not as much the layout itself, though that is hard enough by itself. I do not see any way to do this in a normal linear single pass process. The question is in how far ConTeXt can support this task. 1) provide possibilities of laying out the texts synchronized in columns, stacks and two page layouts. Footnotes, under, columns, pages or across either. Another, nice feature would be the availability of marginals in a synchronized way. This should be a generalized module or set of commands as it can be used in many other fields be critical editions. In other words a parallel texts layout package: \defineparalleltextlayout[name][…] \setupparalleltextlayout[name][…]{…} \defineparalleltextpart[name][..] \setupparalleltextpart[name][…]{…} \startparalleltext[name][…] \stopparalleltext . . . 2) providing commands that define which parts belong together I would suggest that this be done mostly on the Lua side as you can then develop a database of sorts and worry about the layout/typesetting of the critical edition later. A package for marking up the editions directly. \defineeditionslayout[name][…] \setupeditionslayout[name][…]{…} \defineedition[name][..] \setupedition[name][…]{…} \starteditionsl[name][…] \stopeditions \starteditiontext{name}{text} \stopeditiontext \startauthorremarks \stopauthorsremarks . . . desired MWE: % definitions and setups \starttext % some text \starteditions[style1] \starteditiontext{edition1} % some text \stopeditiontext \starteditiontext[edition2] % some text \stopeditiontext \starteditiontext[edition3] % some text \stopeditiontext \startauthorremarks % remark \stopauthorremarks \stopeditions % some more text \starteditions[style1] \starteditiontext{edition2} % some text \stopeditiontext \starteditiontext{edition1} % some text \stopeditiontext \startauthorremarks % remark \stopauthorremarks \starteditiontext{edition3} % some text \stopeditiontext \stopeditions % some more text \starteditions[style2] \starteditiontext{edition1} % some text \stopeditiontext \starteditiontext{edition2} % some text \stopeditiontext \starteditiontext{edition3} % some text \stopeditiontext \stopeditions \stoptext 3) Provide Lua Tools to help automate the process of synchronization of large texts. This would provide a database/knowledge base of the texts which can be then integrated into a critical edition typeset in ConTeXt. A package could already integrate the commands from 2 or that can be converted into a file(s) with commands of 2 that then gets edited by the author of the critical edition. I have just a brain stormed possible starting point. It as you can see it has quite some felixiblity as to how the texts is entered and ConTeXt does some rearranging during typesetting. One type of critical edition we have not discussed is when the author whats to work on a word basis. But, that is even a bigger can of worms for collating the data/texts. Most of what I have describe it probably obvious to you, yet Hope this helps regards Keith.

...

Looking forward to status reports! Will the improvements be directly merged into Context or do you prefer releasing it as a self-contained module?

During development, we need to keep the code separate since we need to document what we do for our funding agency, but it will be part of ConTeXt.

Thomas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

Am 15.11.2013 um 13:06 schrieb Hans Hagen :

On 11/15/2013 11:31 AM, Keith J. Schultz wrote:

...

Hi Thomas,

[snip, snip ]

...

The problem with the two page setup is synchronizing the comments, notes, discussion of the critical edition's author. For a half way pleasing layout these should interplaced between the contrasted editions across the two pages. Yes, not an easy task.

a lot depends on proper coding ... typesetting parallel texts is not per se the same as multiple streams ... it all depends on what one wants to achieve Like I had said in my post, a critical editions is a special case of parallel texts. How the different versions are brought together is a different matter. That one can have the texts in different files and bringing them together.

Also, one way of looking at a two page layout is to assmune a multicolumn layout of a page that is 2 pages wide and 1 page high. After the columns have been layout, rearrange the columns onto the proper page size. That is the approriate boxes! I do not how difficult this would be.

also, if > 1 page is used then we should not limit to 2 pages (or columns) in parallel

Like I said above there are approaches which facilitate a modular layout. True enough, this is not necessarily a TeX way of approaching the problem, yet should help to make the process as automated as possible. True enough that such an approach is not efficient, yet get the job done. I believe a modular approach should be chosen. It allows for the best possible flexibility and using the parallel text for the low-level typeset gives the author the best way of laying out the critical edition, instead of just putting simply texts next to each. That would not be academically sensible, because creating a critical edition is far far more!

...

I agree that it is hard to automate the synchronization of text passages. The only viable approach would be at the paragraph level. A line level approach can only be achieved by interaction of the author of the critical edition with synchronization marks of some sort inside the editions.

indeed. one cannot have the best of all worlds (perfect justification, perfect note handling, perfect synchronization) because the solition space gets too small

(one thing Thomas and I discussed shortly is more advanced pdf's with more embedded info and so ... something for later)

we also need to look into ebook like things ...

This is something quite different an IMHO can be done relatively easily and lots of coding by creating commands for proper ebook production (mainly HTML 5 for epub and mobi output) and mapping those commands back to the ConTeXt commands for the production of pdfs if needed.

...

Early, in my education in Computer Linguistics, decades ago, we had project where we wrote a program for entry of critical editions. The editions/texts and comments were entered in parallel on the tty-terminal screen and stored in a database. At that time we where no interested in fancy output and used a simple stacked output.

As you probably know yourself, it is the entry and synchronization of the editions that is the problem an not as much the layout itself, though that is hard enough by itself. I do not see any way to do this in a normal linear single pass process. The question is in how far ConTeXt can support this task. ...

time, motivation, etc ...

...

I have just a brain stormed possible starting point. It as you can see it has quite some felixiblity as to how the texts is entered and ConTeXt does some rearranging during typesetting.

One type of critical edition we have not discussed is when the author whats to work on a word basis. But, that is even a bigger can of worms for collating the data/texts.

Most of what I have describe it probably obvious to you, yet

well, keep collecting demands and examples ... best that we know what is needed (and by how many people, for how many years to come, as it makes no sense to develop code that is used once and then discarded because one moves to newer technologies) ...

we also need to keep in mind that this kind of things are author driven as publishers are not paying for this kind of things nor willing to invest / support development of tools (if they are interested in anything else than 25-50% profits at all).

Critical editions are very special and not that wide spread. Why do you think that there are not any very useful tools out in the wild. They are almost always coming from the Humanities and such authors are generally that "computer savvy" or versed in TeX let alone xml. That is why I strongly suggest using a modular approach, with a simplistic interface as possible. Most that are looking for tools in ConTeXt will say well if I have to learn that much first forget it. So, please design carefully. quick solutions are the worst. Just look at some of the messes that use TEI or TEI itself. Full of special cases which do many things that are alike, yet just a slight bit different. ConTeXt is far better organized and modular. It solution should work along that basis. regards Keith