[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[comp.text.frame,comp.text.tex,comp.text.desktop,comp.text.sgml,comp.text.pdf] Re: [Query] Need advice for Scientific Publishing

	А так просто.

---- Begin included message ----
[Disclaimer: use of first-person pronouns in this post is not intended
to imply that the poster speaks for Tim O'Reilly, nor for his

Chris Lusena <lusena@cs.uky.edu> writes:

> Why? Not to flame SGML/XML but I've never found it nor any of its
> applications to be very good authoring languages, unless you need
> lots of structural markup. SGML/XML are very good, probably the
> best, at structural mark-up. But your a publisher you want ink on
> page, HTML on the net, PDF somewhere. These don't appear to me to
> need SGML/XML, though you could use it. This also appears to be in
> direct contradiction to point 12....

Speaking as a publisher who puts ink on page, HTML on the net, and PDF
somewhere, SGML makes this much easier than any other format.  If
something is tagged as a URL, I can make it italic in the book, and a
hyperlink to the page it identifies in the HTML.  I can feed the index
terms in the right format to whatever tool is getting them, or sort
them myself for HTML output.

Sufficiently rich LaTeX is equivalent to SGML (just with curly-braces
instead of pointy-brackets).  But tools for processing LaTeX are not
typically as programmable as SGML manipulation tools.

Carefully tagged Frame is almost as good, but there's not as much
structure and no attributes; plus, I don't trust black boxes, and the
HTML output has various bugs depending on which version you're using.
It's a great formatter, and I feed my SGML to it for printing (after
*I* convert it to MIF, not Frame).

With SGML, I can implement a completely free solution, or pay tens (or
hundreds) of thousands of dollars for top-line software.  No other
format really offers the range of options that SGML does.

(And since this is going to so many newsfroups, I'd better caveat
this.  I am a big fan of TeX for typesetting, and PDF is the thing to
use for on-line page fidelity.  But for storing *information*, SGML is
not currently unbeatable.  I have no great love for it; it's bizarre
and crufty, but it is currently the best thing going if you want to
get your information back out again.  Despite my .sig, I'm not a
zealot; in fact, I read all of the newsgroups this post is going to.)

> Now if there are some great awsome authoring tools out there for
> SGML/XML that whould be different, haven't found any that I could
> possably like yet.

I use Emacs, with or without psgml-mode.  The main advance I'm hoping
for from XML is cheap and usable structured document editors.  Many of
my authors are scared of pointy-brackets, and a good editor would save
me a lot of time converting between formats.  But I can tell you that
getting out of SGML is much easier than getting into it.

> On Fri, 10 Jul 1998, Paul Gillingwater wrote:
> > 3.  Our authors tend to provide EPS images up to several Megabytes
> > in size.  We want to be able to handle those elegantly, editing if
> > necessary, and convert to GIF/JPEG/PNG at will.  All nicely
> > hyperlinked of course.
> Hyperlinked? The way of putting such thing in HTML documents is
> nested <object> tags not hyperlinking. A hyperlinking package in
> LaTeX should give you what you want, and some dreaded PERL or
> equivalent scripts.  But you will have to pay someone to help you
> with this.

SGML gives it to you for free.  The document expresses the
relationship between things; converting that into the link language of
other formats (TeX, HTML, MIF, RTF) is easy.

> > 9.  We want hyperlinking in the source text to translate through
> > into the HTML/XML/PDF files too.
> Thats what Hyperlinking packages for TeX are for. The beauty of a
> decent authoring language is that someone else can to the tricky
> stuff and you just have to use their work. In SGML at least the
> extremely little that I one one ends up rewrite lots of repeated
> code over and over again.  Unless you have a good macro tool and
> know how to use it. Again as far as I can tell SGML and its
> application are not geared to authoring and one need additional
> tools on top.

I'm not sure what's hard about <xref linkend="chap-someterm"/>.  It is
trivial for any SGML application I've worked with to turn that into
"Chapter 10, _Discussion of Some Term_".  With a little more work, you
can turn it into "Chapter 10" unless it's the first such reference, in
which case it includes the text of the title.

TeX can do stuff like that (like Emacs, the answer to "Can TeX?" is
"Yes"), but it's not optimized for it.

> 12. A Pure TeX system won't be the easiest thing to teach your
> typesetters ect. Then again I don't think anything will be that
> easy.

True.  New is hard and scary.  Pointy brackets or curly braces are
going to scare them equally.

You may want to consider Frame+SGML, but it has some limitations.  (We
currently use it to assist in Frame-to-SGML conversions, but not to
actually format and print the SGML.  In that conversion, it damages
some things like index markers, and requires a bit of manual

> You will like bee better staying in M$-Win* with a commercial
> TeX. esp if you want support. I personally might go with just a pure
> TeX system.  if 1,7,12 are not that important. However 12 is not
> likely attainable. No system that will do everything you want will
> be easy to learn. The more powerful the tool the hard it is to
> learn.

Both TeX and SGML have dedicated and helpful user communities (such as
these newsgroups), which make it possible to get help cheap (as long
as you don't abuse it and end up in everyone's killfiles...).  But
both have commercial solutions that will provide varying levels of

Spend the money and the time to figure out exactly what your needs are
(and it sounds like you're firmly on the way).  With either TeX or
SGML, you can get your data back out again.  The primary argument in
favor of SGML, IMO, is validation.  Assuming you have a large number
of authors, you can restrict what they can do, and programmatically
check that they are following certain strictures.  With LaTeX, they
can still drop down into the lower-level language (if they know how,
and feel like it), and run amok with the formatting.  There's no
programmatic way to enforce the structure of your documents.

<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
---- End included message ----