ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Keith J. Schultz" <schultzk@uni-trier.de>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: announcement and call
Date: Sat, 16 Nov 2013 16:49:25 +0100	[thread overview]
Message-ID: <4F21D23D-AC44-4035-BB3C-44DB2B38709C@uni-trier.de> (raw)
In-Reply-To: <52860E35.5080301@wxs.nl>


[-- Attachment #1.1: Type: text/plain, Size: 5279 bytes --]


Am 15.11.2013 um 13:06 schrieb Hans Hagen <pragma@wxs.nl>:

> 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
	


[-- Attachment #1.2: Type: text/html, Size: 8856 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________

      reply	other threads:[~2013-11-16 15:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-14 14:08 Thomas A. Schmitz
2013-11-14 19:06 ` Pablo Rodriguez
2013-11-14 20:23   ` Hans Hagen
2013-11-14 20:30   ` Thomas A. Schmitz
2013-11-14 20:40 ` Philipp Gesang
2013-11-14 20:47   ` Hans Hagen
2013-11-14 20:56     ` Philipp Gesang
2013-11-14 20:55   ` Thomas A. Schmitz
2013-11-15 10:31     ` Keith J. Schultz
2013-11-15 12:06       ` Hans Hagen
2013-11-16 15:49         ` Keith J. Schultz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F21D23D-AC44-4035-BB3C-44DB2B38709C@uni-trier.de \
    --to=schultzk@uni-trier.de \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).