From: Henning Hraban Ramm <hraban@fiee.net>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Scribus vs ConTeXt
Date: Wed, 29 Feb 2012 21:25:27 +0100 [thread overview]
Message-ID: <CAPm68Zgb38y6fMCkw=1ErVo1cvY6rg=vxGUsQ7KKQZFptCbqXg@mail.gmail.com> (raw)
In-Reply-To: <1330546240.3130.17.camel@kip-laptop>
Am 29. Februar 2012 21:10 schrieb Kip Warner <kip@thevertigo.com>:
> One other thing too that I don't know if anyone has ever raised anywhere
> is that other typesetting applications that store their project files in
> some kind of proprietary or binary format will probably not be very diff
> friendly. A big advantage to anything TeXish is that it makes
> collaboration on a large document much easier because it can be typeset
> using plaintext documents.
At least InDesign's and Scribus' files have a XML representation and
would be diffable/versionable in that format.
InDesign's XML format is widely used e.g. in editorial systems; you
can also save just snippets (layout parts).
I'd like to add that the mentioned GUI programs all are scriptable -
Scribus in Python (AFAIK), InDesign in JavaScript or AppleScript;
don't know about the current state of XPress, in old versions on the
Mac it supported Frontier, then AppleScript.
I've some experience in remote controlling ID by Python appscript
(i.e. sending AppleScript events from Python); it works, but is not
very reliable, mostly due to missing/wrong documentation on Adobe's
side and quirks of AppleScript. Scripting TeX is much easier; I still
seldom use Lua, but write ConTeXt sources from Python scripts.
Greetlings, Hraban
___________________________________________________________________________________
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
___________________________________________________________________________________
next prev parent reply other threads:[~2012-02-29 20:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 19:34 Kip Warner
2012-02-28 19:43 ` Khaled Hosny
2012-02-29 0:43 ` Kip Warner
2012-02-28 20:20 ` Jaroslav Hajtmar
2012-02-28 22:26 ` Henning Hraban Ramm
2012-02-28 22:40 ` Jaroslav Hajtmar
2012-02-29 0:43 ` Kip Warner
2012-02-29 16:29 ` William Adams
2012-02-29 17:41 ` Marco Pessotto
2012-02-29 18:02 ` Michael Hallgren
2012-02-29 19:30 ` Martin Schröder
2012-02-29 19:40 ` Marco Pessotto
2012-02-29 20:08 ` Kip Warner
2012-02-29 20:35 ` Aditya Mahajan
2012-02-29 19:55 ` William Adams
2012-02-29 20:10 ` Kip Warner
2012-02-29 20:25 ` Henning Hraban Ramm [this message]
2012-02-29 21:02 ` Kip Warner
2012-03-01 12:56 ` William Adams
2012-03-01 16:15 ` Martin Schröder
2012-03-01 17:29 ` William Adams
2012-02-29 20:01 ` Khaled Hosny
2012-02-29 20:06 ` Kip Warner
2012-02-29 20:08 ` Kip Warner
2012-02-29 21:27 ` Alan Braslau
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='CAPm68Zgb38y6fMCkw=1ErVo1cvY6rg=vxGUsQ7KKQZFptCbqXg@mail.gmail.com' \
--to=hraban@fiee.net \
--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).