RFC1003 日本語訳

1003 Issues in defining an equations representation standard. A.R.Katz. March 1987. (Format: TXT=19816 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                          Alan Katz
Request for Comments: 1003                                       USC/ISI
                                                              March 1987

コメントを求めるワーキンググループアランキャッツRequestをネットワークでつないでください: 1003 1987年のUSC/ISI行進

        Issues in Defining an Equations Representation Standard

方程式表現規格を定義することにおける問題

Status of This Memo

このメモの状態

    This memo is intended to identify and explore issues in defining a
    standard for the exchange of mathematical equations.  No attempt is
    made at a complete definition and more questions are asked than are
    answered.  Questions about the user interface are only addressed to
    the extent that they affect interchange issues.  Comments are
    welcome.  Distribution of this memo is unlimited.

このメモは、数学の方程式の交換の規格を定義する際に問題を特定して、探ることを意図します。 完全な定義のときに試みを全くしないで、答えられるよりさらに多くの質問をします。 ユーザーインタフェースに関する質問は置き換え問題に影響するという範囲まで記述されるだけです。 コメントを歓迎します。 このメモの分配は無制限です。

I.  Introduction

I. 序論

    Since the early days of the Arpanet, electronic mail has been in
    wide use and many regard it as an essential tool.  Numerous mailing
    lists and newsgroups have sprung up over the years, allowing large
    numbers of people all over the world to participate remotely in
    discussions on a variety of topics.  More recently, multimedia mail
    systems have been developed which allow users to not only send and
    receive text messages, but also those containing voice, bitmaps,
    graphics, and other electronic media.

Arpanetの初期以来、電子メールは広く使用中です、そして、多くがそれを不可欠のツールと見なします。 多数のメーリングリストとニュースグループは数年間発生しています、さまざまな話題についての議論に離れて参加するために世界中に多くの人々を許容して。 より最近、ユーザがテキスト・メッセージだけではなく、声、ビットマップ、グラフィックス、および他の電子メディアを含むものも送って、受け取るマルチメディアメールシステムは、開発されました。

    Most of us in the Internet community take electronic mail for
    granted, but for the rest of the world, it is a brand new
    capability.  Many are not convinced that electronic mail will be
    useful for them and may also feel it is just an infinite time sink
    (as we all know, this is actually true).  In particular, most
    scientists (apart from computer scientists) do not yet use, or are
    just beginning to use, electronic mail.

インターネットコミュニティの私たちの大部分は電子メールを当然のことと思いますが、他の国々のために、それは真新しい能力です。 多くが、電子メールがそれらの役に立つと納得させられないで、また、それがただ無限の時間流し台であると感じるかもしれません(誰もが知っているとおり、これは実際に本当です)。 ほとんどの科学者(コンピュータ科学者は別として)が、電子メールを特に、まだ使用していなくて、ただ使用し始めています。

    The current NSF supercomputer initiative may change this.  Its
    primary purpose is to provide remote supercomputer access to a much
    greater number of scientists across the country.  However, doing
    this will involve the interconnection of many university-wide
    networks to NSF supercomputer sites and therefore to the NSF
    backbone network.  Thus, in the very near future we will have a
    large number of scientists in the country suddenly able to
    communicate via electronic mail.

現在のNSFスーパーコンピュータイニシアチブはこれを変えるかもしれません。 第一の目的ははるかに大きい数の科学者へのリモートスーパーコンピュータアクセスを国中に提供することです。 しかしながら、これをすると、多くの大学全体のネットワークのインタコネクトはNSFスーパーコンピュータサイトと、そして、したがって、NSF背骨ネットワークにかかわるでしょう。 このようにして、そして、近いうちに私たちには、突然電子メールを通って交信できる国に多くの科学者がいるでしょう。

    Generally, text-only mail has sufficed up until now.  One can dream
    of the day (not so far in the future) when everyone will have
    bitmapped display workstations with multimedia mail systems, but we
    can get by without it for now.  I believe, however, that the new NSF
    user community will find one other capability almost essential in
    making electronic mail useful to them, and that is the ability to

一般に、テキストのみメールは現在まで十分でした。 人は皆がマルチメディアメールシステムで表示ワークステーションをbitmappedしてしまうでしょうが、私たちが当分それなしでなんとかやっていくことができる日(将来、今までのところない)を夢にみることができます。 しかしながら、私は、新しいNSFユーザーコミュニティが、他の1つの能力が電子メールをそれら、およびそれの役に立つようにするのにおいて、能力があるのがほとんど不可欠であることがわかると信じています。

Katz                                                            [Page 1]

RFC 1003                                                      March 1987

1987年のキャッツ[1ページ]RFC1003March

    include equations in messages.

メッセージで方程式を含めてください。

    A glance through any scientific journal will demonstrate the
    importance of equations in scientific communication.  Indeed, papers
    in some fields seem to contain more mathematics than English.  It is
    hard to imagine that when people in these fields are connected into
    an electronic mail community they will be satisfied with a mail
    system which doesn't allow equations.  Indeed, with the advent of
    the NSF's Experimental Research in Electronic Submission (EXPRESS)
    project, scientists will begin submitting manuscripts and project
    proposals directly through electronic mail and the ability to handle
    equations will be essential.

どんな科学雑誌を通した一目は科学コミュニケーションにおける、方程式の重要性を示すでしょう。 本当に、いくつかの分野の書類は英語より多くの数学を含むように思えます。 これらの分野の人々が電子メール共同体に接続されるとき、彼らが方程式を許容しないメールシステムに満足すると想像しにくいです。 本当に、Electronic Submission(EXPRESS)プロジェクトにおける、NSFのExperimental Researchの到来で、科学者は電子メール直接を通した原稿と事業計画を提出し始めるでしょう、そして、方程式を扱う能力は不可欠になるでしょう。

    Currently, there exists no standard for the representation of
    equations.  In fact, there is not even agreement on what it is that
    ought to be represented.  Users of particular equation systems (such
    as LaTex or EQN) sometimes advocate just including source files of
    that system in messages, but this may not be a good long-term
    solution.  With the new NSF community coming on line in the near
    future, I feel the time is now right to try to define a standard
    which will meet the present and future needs of the user community.

現在、方程式の表現の規格は全く存在しません。 事実上、表されるべきであるそれが何であるかに関する協定さえありません。 特定の方程式システム(LaTexかEQNなどの)のユーザは、時々メッセージにただそのシステムに関するソースファイルを含んでいると提唱しますが、これは良い長期的な解決法でないかもしれません。 稼働中な近い将来の新しいNSF共同体の来ることで、私は、時間が現在ユーザーコミュニティの現在の、そして、将来の需要を満たす規格を定義しようとするために正しいと感じます。

    Such a standard should allow the interchange of equations via
    electronic mail as well as be compatible with as many existing
    systems as possible.  It should be as general as possible, but still
    efficiently represent those aspects of equations which are most
    commonly used.  One point to be kept in mind is that most equations
    typesetting is currently being done by secretaries and professional
    typesetters who do not know what the equations mean, only what they
    look like.  Although this is mainly a user interface consideration,
    any proposed standard must not require the user to understand an
    equation in order to type it in.  We are not interested here in
    representing mathematics, only displayed equations.

そのような規格は、電子メールを通して方程式の置き換えを許容して、同じくらい多くの既存のシステムが可能な状態で互換性があるべきです。 それはできるだけ一般的であるべきですが、それでも、効率的に最も一般的に使用される方程式のそれらの局面を表してください。 念頭に保たれる1ポイントはほとんどの方程式植字が現在方程式が言っていることがわからない秘書とプロの植字工によって行われているということです、それらが似ていることだけ。 これは主にユーザーインタフェースの考慮ですが、どんな提案された標準も、それをタイプするためにユーザが方程式を理解しているのを必要としてはいけません。 ここ、数学、表示された方程式だけを表したいと思いません。

    In this memo, I will try to raise issues that will need to be
    considered in defining such a standard and to get a handle on what
    it is that needs to be represented.  Hopefully, this  will form the
    basis of a discussion leading eventually to a definition.  Before
    examining what it is that could be or should be represented in the
    standard, we will first review the characteristics of some existing
    systems.

このメモでは、私はそのような規格を定義する際に考えられて、それが何であるかの表される必要があるハンドルを手に入れる必要がある問題を、提起しようとするでしょう。 うまくいけば、これは結局定義につながる議論の基礎を形成するでしょう。 それが何であるかを調べる前に、それは、あるべきであるかもしれないか、または規格で表されるべきであり、私たちは最初に、いくつかの既存のシステムの特性について調査するつもりです。

2.  Existing Systems

2. 既存のシステム

    There currently exist many incompatible systems which can handle
    equations to a certain extent. Most of these are extensions to text
    formatting systems to allow the inclusion of equations.  As such,
    general representation and standards considerations were not a major
    concern when these systems were initially designed.  We will examine
    the three main types of systems: Directive systems, Symbolic
    Language systems, and Full Display systems.

ある程度方程式を扱うことができる多くの両立しないシステムが現在、存在します。 これらの大部分は方程式の包含を許容するためにシステムをフォーマットするテキストへの拡大です。 これらのシステムが初めは設計されたとき、そういうものとして、一般的な表現と規格問題は主要な関心事ではありませんでした。 私たちは3つの主なタイプのシステムを調べるつもりです: 指向性のシステム、Symbolic Languageシステム、およびFull Displayシステム。

Katz                                                            [Page 2]

RFC 1003                                                      March 1987

1987年のキャッツ[2ページ]RFC1003March

    Some text editing facilities simply allow an expanded font set which
    includes those symbols typically used in mathematics.  I do not
    consider these systems as truly able to handle equations since much
    of mathematics cannot be represented.  It takes more than the Greek
    alphabet and an integral and square root symbol to make an equations
    system.

いくつかのテキスト編集施設が単に数学に通常使用されるそれらのシンボルを含んでいる拡張字体セットを許容します。 私は、本当に、これらのシステムが数学の多くを表すことができないので方程式を扱うことができるとみなしません。 方程式システムを作るにはギリシャ語アルファベットと不可欠、そして、平方根シンボルよりかかります。

    Directive systems are those which represent equations and formating
    information in terms of directives embedded in the text.  LaTex and
    EQN are two examples.  LaTex is a more friendly version of Knuth's
    Tex system, while EQN is a preprocessor for Troff, a document
    preparation system available under Unix.

指向性のシステムは、方程式を表すものとテキストに埋め込まれた指示で情報をフォーマットすることです。 LaTexとEQNは2つの例です。 LaTexはクヌースのTexシステムの、より好意的なバージョンです、EQNがTroffのためのプリプロセッサですが、Unixの下で利用可能なドキュメント準備システム。

    With these Directive systems, it is usually necessary to actually
    print out the document to see what the equations and formatted text
    will look like, although there are on-screen previewers which run on
    workstations such as the Sun.  Directive systems have the advantage
    that the source files are just text and can be edited with standard
    text editors (such as Emacs) and transferred as text in standard
    electronic messages (a big advantage considering existing mail
    interconnectivity of the various user communities).  Also, it is
    relatively easy to make global changes with the help of your
    favorite text editor (for example, to change all Greek letter
    alpha's to beta's or all integrals to summation signs in a document.
    This is generally impossible with the other types of systems
    described below).

これらのDirectiveシステムがあるので、通常、方程式とフォーマット済みのテキストが似ているものを見るために実際にドキュメントを印刷するのが必要です; 「前-ビューアー」がスクリーンの上にいますが、日曜日のDirectiveシステムなどのワークステーションにおけるどの走行にソースがファイルする利点があるかをただテキストであり、標準のテキストエディタ(Emacsなどの)で編集して、標準の電子メッセージ(様々なユーザーコミュニティの大きい利点考えている既存のメールの相互接続性)のテキストとして移すことができます。 また、あなたの好きなテキストエディタの助けがあるグローバルな変更を行うのも比較的簡単です。(例えば、ベータのものへのギリシアのアルファのすべての手紙ものか足し算へのすべてのintegralsを変えるのはドキュメントにサインインします。 一般に、他のタイプのシステムが以下で説明されている状態で、これは不可能です。).

    The primary disadvantage of these systems is that writing an
    equation corresponds to writing a portion of a computer program.
    The equations are sometimes hard to read, generally hard to edit,
    and one may make syntax errors which are hard to identify.  Also,
    people who are not used to programming, and typesetters who do not
    actually know what an equation means, only what it should look like,
    find specifying an equation in this language very difficult and may
    not be willing to put up with it.

これらのシステムの第一の難点は方程式を書くのがコンピュータ・プログラムの一部を書くと対応しているということです。 方程式は時々読みにくいです、一般に、編集しにくくて、特定しにくい構文エラーを作るかもしれません。 また、プログラミングに慣れていない人々、および実際に方程式が言っていることがわからない植字工、それが似るべきであることだけも、この言語の方程式を指定するのが非常に難しいのがわかって、それを我慢することを望んでいないかもしれません。

    Full Display Systems are those such as Xerox STAR and VIEWPOINT.
    The user enters an equation using the keyboard and sees exactly that
    equation displayed as it is typed.  At all times, what is displayed
    is exactly how things will look when it is printed out.
    Unfortunately, VIEWPOINT does not allow the user to place any symbol
    anywhere on the page.  There are many things (such as putting dots
    on indices) which are not possible.  For those things which are
    implemented, it works rather nicely.

完全なDisplay SystemsはゼロックスSTARやVIEWPOINTなどのものです。 ユーザは、キーボードを使用することで方程式に入って、それがタイプされるとき、まさにその方程式が表示されるのを見ます。 いつも、表示されることはちょうどそれが印刷されるとき、いろいろなことがどう見えるかということです。 残念ながら、VIEWPOINTはユーザにどんなシンボルもページで何処にも置かせません。 多くの可能でないもの(ドットをインデックスリストに載せなどなどの)があります。 実行されるそれらのもののために、それはかなりうまく働いています。

    Hockney's Egg is a display system which was developed at the UCLA
    Physics Department and runs on the IBM PC.  It has the advantage of
    being able to put any character of any font anywhere on the screen,
    thus allowing not only equations, but things like chemical diagrams.

ホックニーのEggはUCLA Physics部で開発されて、IBM PCで動くディスプレイ・システムです。 それには、できるのがどんな字体のどんなキャラクタもスクリーンにどこでも置く利点があります、その結果、化学ダイヤグラムのように方程式だけではなく、ものも許容します。

Katz                                                            [Page 3]

RFC 1003                                                      March 1987

1987年のキャッツ[3ページ]RFC1003March

    Interleaf's Workstation Publishing Software system is not strictly
    speaking an equations system, but equations may be entered via a cut
    and paste method.  At all times, what one sees is what will be
    printed out and one may put any symbol anywhere on the page.  The
    problem with this system is that one HAS TO put everything in a
    certain place.  It sometimes takes an enormous amount of work to get
    things to be positioned correctly and to look nice.

綴じ込み紙のWorkstation出版Softwareシステムは厳密に言うと方程式システムではありませんが、カットとペースト法で方程式は入られるかもしれません。 いつも、1つが印刷されるものと1であると考えるものはどんなシンボルもページにどこでも置くかもしれません。 このシステムに関する問題は1HAS TOが、ある一定の場所にすべてを置くということです。 正しく置かれて、格好よく見えるものを手に入れるのに時々仕事の巨額を要します。

    Generally, Full Display Systems are specific to a particular piece
    of hardware and the internal representation of the equations is not
    only hidden from the user, but is in many cases proprietary.

一般に、Full Display Systemsが特定のハードウェアに特定であり、方程式の内部の表現は、ユーザ隠されるだけではありませんが、多くの場合、独占です。

    Symbolic Language systems, such as Macsyma and Reduce, also allow
    the entry of equations.  These are in the form of program function
    calls.  These are systems that actually know some mathematics.  One
    can only enter the particular type of mathematics that the system
    knows.

また、MacsymaやReduceなどのシンボリックなLanguageシステムは方程式のエントリーを許容します。 これらはプログラムファンクションコールの形にあります。 これらは実際に何らかの数学を知っているシステムです。 1つはシステムが知っている特定のタイプの数学を入れることができるだけです。

    We next will look at what should be represented in an equations
    system.  We will want a representation standard general enough to
    allow (almost) anything which comes up to be represented, but does
    not require vast amounts of storage.

私たち、次に、方程式システムで表されるべきであるものは見るでしょう。 私たちは、表現規格に(ほとんど)何でも許容するほど一般的であって欲しいと思うつもりです(表されに来ますが、広大な量の格納を必要としません)。

3.  What Could be Represented?

3. どんなCould、Representedはそうですか?

    We will first examine what it is that could be represented.  At the
    most primative level, one could simply store a bitmap of each
    printed equation (expensive in terms of storage).  At the other end
    of the spectrum, one could represent the actual mathematical
    information that the equation itself represents (as in the input to
    Macsyma).  In between, one could represent the mathematical symbols
    and where they are, or represent a standard set of mathematical
    notation, as in EQN.

私たちは、最初に、それが何であるかを調べるつもりです。それは表すことができました。 最も多くのprimativeレベルでは、人は単にそれぞれの印刷された方程式(格納で高価な)のビットマップを格納できました。 範囲内で対照的に一方の側に、人は方程式自体が表す実際の数学の情報を表すことができました(Macsymaへの入力のように)。 中間で、人は、数学記号とどこを表すか、そして、または数学的表記の標準セットを表すことができました、EQNのように。

    It is useful to think of an analogy with printed text.  Suppose we
    have text printed in a certain font.  How could it be represented?
    Well, we could store a bitmap of the printed text, store characters
    and fonts, store words, or at the most abstract, we could store the
    meaning behind the words.

印刷されたテキストへの類推を考えるのは役に立ちます。 私たちが、ある字体でテキストを印刷させると仮定してください。 どうしたらそれを表すことができますか? さて、キャラクタと字体を格納するか、単語を格納する、私たちが印刷されたテキストのビットマップを格納できました、最も多くの要約では、私たちは単語の後ろに意味を格納できました。

    What we actually do, of course, is store characters (in ordinary
    text) and sometimes fonts (in text intended to be printed).  We do
    not attempt to represent the meaning of words, or even represent the
    notion of a word.  We generally only have characters, separated by
    spaces or carriage returns (which are also characters).  Even when
    we specify fonts, if a slightly different one happened to be printed
    out it would not matter greatly.

私たちが実際にもちろんすることは、店キャラクタ(普通のテキストの)と時々字体(印刷されることを意図するテキストの)です。 私たちは、単語の意味を表すか、または単語の概念を表すのさえ試みません。 一般に、私たちには、空間か復帰(また、キャラクタである)で切り離されたキャラクタがあるだけです。 私たちが字体を指定さえするとき、わずかに異なったものがたまたま印刷されるなら、それは大いに重要でないでしょうに。

    Equations may be considered an extension of ordinary text, together
    with particular fonts.  However, the choice of font may be extremely
    important.  If the wrong font happens to be printed out, the meaning

方程式は特定の字体に伴う普通のテキストの拡大であると考えられるかもしれません。 しかしながら、字体の選択は非常に重要であるかもしれません。 間違った字体が印刷されたアウト、たまたま意味であるなら

Katz                                                            [Page 4]

RFC 1003                                                      March 1987

1987年のキャッツ[4ページ]RFC1003March

    of the equation may be completely changed.  There are also items,
    such as growing parentheses, fractions, and matrices, which are
    particular to equations.

方程式を完全に変えるかもしれません。 方程式に特定の括弧、断片、およびマトリクスを発展などなどの項目もあります。

    We are not interested in representing the meaning of an equation,
    even if we knew how to in general, but in representing a picture of
    the equation.  Thus, we will not further consider the types of
    representations made in the Symbolic Language systems.  We still
    have Directive systems and the Full Display systems.  We shall
    assume that both of these will continue to exist and that the
    defined standard should be able to deal with existing systems of
    either type.

方程式の意味を表したいと思いません、私たちが一般ににもかかわらずの、表すことにおける、方程式の絵へのその方法を知ったとしても。 したがって、私たちはさらにSymbolic Languageシステムでされた表現のタイプを考えるつもりではありません。私たちには、DirectiveシステムとFull Displayシステムがまだあります。これらの両方が存続して、定義された規格がタイプの既存のシステムに対処できるべきであると思うつもりです。

    Assuming we do not want to just store a bitmap of the equation
    (which would not allow any easy editing or interfacing with existing
    systems), we are now left with the following possibilities:

ただ方程式(既存のシステムとのどんな簡単な編集や接続も許さない)のビットマップを格納したいと思わないと仮定して、私たちは今、以下の可能性と共に置き去りにされます:

         1.   Store characters, fonts and positions only.  Allow
              anything to be anywhere (this is what Interleaf does).

1. キャラクタ、字体、および位置だけを格納してください。 どこでも何でもあってください(これはInterleafがすることです)。

         2.   Store characters, fonts, and positions, but only allow
              discrete positions.  This makes it easier to place
              subscripts and superscripts correctly (this is what
              Hockney's Egg does).

2. キャラクタ、字体、および位置を格納しなさい、ただし、単に離散的な位置を許容してください。 これで、正しく添字と上付き文字を置くのは、より簡単になります(これはホックニーのEggがすることです)。

         3.   Use a language similar to EQN or LaTex, which has ideas
              such as subscripts, superscripts, fractions, and growing
              parentheses.  Generally positioning is done automatically
              when the typesetting occurs, but it is possible to do a
              sort of relative positioning of symbols with some work.

3. 添字や、上付き文字や、断片や、増加している括弧などの考えを持っているEQNかLaTexと同様の言語を使用してください。 植字が起こるとき一般に自動的に位置決めしますが、いくらかの仕事でシンボルの一種の相対位置決め方式をするのは可能です。

         4.   Use a language such as Troff or Tex, which is what EQN and
              Latex is translated into.

4. TroffかTexなどの言語を使用してください。(それは、EQNとLatexが何に翻訳されるかということです)。

         5.   Some combination of the above.

5. 上記の何らかの組み合わせ。

    In the next section, I will argue for a particular combination of
    the above as a tentative choice.  It may turn out, with more
    information and experience, that this choice should be modified.

次のセクションで、私は一時的な選択として上記の特定の組み合わせについて賛成の議論をするつもりです。 詳しい情報と経験でこの選択が変更されるべきであると判明するかもしれません。

4.  What I Think Should be Represented

4. I Think Shouldがものである、Represented

    Let us now take a stab at what sort of standard we should have.
    First of all, we would like our standard if at all possible to be
    compatible with all of the existing systems described previously.
    If the standard becomes widely accepted, it should be general enough
    not to constrain severely the design of new user interfaces.  Thus,
    while we should provide for efficiently representing those aspects
    of equations which are commonly used (subscripts, parentheses, etc.)
    we would like extensions to be possible which enable the
    representation of any symbol anywhere.

現在、私たちが持つべきであるどういう規格に一刺しを取ろうか。 まず、できれば、私たちの規格は以前に説明される既存のシステムのすべてと互換性がありたいと思います。 規格が広く受け入れるようになるなら、厳しく新しいユーザインタフェースのデザインを抑制しないほど一般的であるべきです。 したがって、私たちが効率的に一般的に使用される方程式(添字、括弧など)のそれらの局面を表すのに提供するべきである間、拡大は可能になりたいと思います(どこでもどんなシンボルの表現も可能にします)。

Katz                                                            [Page 5]

RFC 1003                                                      March 1987

1987年のキャッツ[5ページ]RFC1003March

    We would like standard mathematical symbols, as well as all Greek
    and Latin letters to be available.  We would also like any required
    typesetting knowledge to be in programs and not required of the
    user.

標準の数学記号、およびすべてのギリシアの、そして、ラテン語の手紙が利用可能になりたいと思います。 どんな必要な植字知識もプログラムにいて、また、ユーザを要求されたいと思いません。

    I feel that the exact position of a subscript or superscript should
    not have to be specified by the user or be represented (unless the
    user specifically wants it to be).  It is nice to be able to place
    any symbol anywhere (and indeed the standard ought to allow for
    this), but having to do this for everything is not good.  The
    standard should be able to represent the idea of a subscript,
    superscript, or growing fraction with no more specification.

私が、添字か上付き文字の正確な位置をユーザが指定する必要はないはずですし、表しもすると感じる、(それがユーザが明確にそうしたがっている、) どんなシンボルもどこでも置くことができてうれしいのですが(本当に、規格はこれを考慮するべきです)、すべてのためにこれをしなければならないのは役に立ちません。 規格は、より多くの仕様なしで添字、上付き文字、または断片を育てるという考えを表すことができるべきです。

    My suggestion, therefore, is for something like EQN, but with
    extensions to allow positioning of symbols in some kind of absolute
    coordinates as well as relative positioning (EQN does allow some
    positioning relative to where the next symbol would normally go).
    This has the advantage that the representation is in ordinary text,
    which can be sent in messages, the Directive systems can map almost
    directly into it, and it should allow representation for Full
    Display systems.  The ideas of subscript and superscripts (without
    having to specify a position), growing parentheses, fractions, and
    matrices, and special fonts are already there.

相対位置決め方式と同様にある種の絶対座標における、シンボルの位置決めを許すために、私の提案は、したがって、何かEQNのようなもののためにありますが、拡大であります(EQNはどこに比例して次のシンボルを置くかと通常、そうするいくつかに碁を許容します)。 これには、表現がメッセージで送ることができる普通のテキストにある利点があります、とDirectiveシステムは直接それにほとんど写像できて、それはFull Displayシステムの表現を許容するべきです。添字と上付き文字(位置を指定する必要はなくて)の考え、括弧、断片、およびマトリクスを発展して、および特別な字体が既にそこにあります。

    Most equations can be specified very compactly within EQN, and if
    positioning is provided as an extension, exceptions can be handled.
    (The same could be said for LaTex, however, I consider the syntax
    there to be somewhat unreadable and prefer EQN.  Essentially, either
    will do).

EQNの中で非常にコンパクトにほとんどの方程式を指定できます、そして、拡大として位置決めを提供するなら、例外を扱うことができます。 (LaTexのために同じくらい言うことができて、しかしながら、私は、いくらか読みにくく、EQNを好むためにそこで構文を考えます。 本質的には、どちらかがするでしょう。).

    User interfaces should be able to be easily constructed which would
    allow one to type in an EQN style specification and have the
    equation appear immediately on the screen.  For non-specialists, it
    may be better to use existing Full Display systems which are then
    translated in this EQN like standard (perhaps using a lot of the
    absolute positioning facility).

ユーザインタフェースは容易に組み立てることができるべきです(1つにEQNスタイル仕様をタイプして、すぐスクリーンに方程式を現れさせるでしょう)。 非専門家にとって、次に規格のようにこのEQNで翻訳される既存のFull Displayシステムを使用しているほうがよいかもしれません(恐らく多くの絶対位置決め方式施設を使用して)。

5.  Conclusions

5. 結論

    In summary:

概要で:

       1.   A standard for the efficient representation of mathematical
            equations should be defined as soon as possible in order to
            allow the interchange of equations in documents and mail
            messages and the transfer of equations between various
            existing internal representations.

1. 数学の方程式の効率的な表現の規格は、できるだけ早く、ドキュメントとメール・メッセージにおける、方程式の置き換えと様々な既存の内部の表現の間の方程式の転送を許容するために定義されるべきです。

       2.   Most equations entry is currently done by people who do not
            know what the equations mean, and are not programmers.  It
            may be that the optimal user interface for these people is

2. ほとんどの方程式エントリーが現在、方程式が言っていることがわからないで、またプログラマでない人々によって行われます。 多分、これらの人々のための最適のユーザーインタフェースはそうです。

Katz                                                            [Page 6]

RFC 1003                                                      March 1987

1987年のキャッツ[6ページ]RFC1003March

            different than for those who do know mathematics and/or are
            programmers.  An equations standard should not preclude
            this.

数学を知っている、そして/または、プログラマであるそれらより異なります。 方程式規格はこれを排除するべきではありません。

       3.   The standard should easily handle those aspects of equations
            which are common, such as the set of things provided in EQN.

3. 規格は容易に一般的な方程式のそれらの局面を扱うべきです、EQNに提供されたもののセットなどのように。

       4.   It should also be possible, however, to place any defined
            symbol anywhere and the standard should allow this type of
            specification when needed.

4. また、しかしながら、どんな定義されたシンボルもどこでも置くのも可能であるべきであり、必要であると、規格はこのタイプの仕様を許容するべきです。

       5.   As many of the existing systems (all of them if possible)
            should be able to be translated into the standard.

5. 既存のシステムの同じくらい多く、(それらのすべて、できれば)、規格に翻訳できるべきです。

       6.   The standard should not make requirements on the user
            interface such that the user must have much typesetting
            knowledge.  This knowledge should be in the user interface
            or printing routines.

6. 規格は、ユーザには多くの植字知識がなければならないように、ユーザーインタフェースの上で要件を作るべきではありません。 この知識はユーザーインタフェースか印刷ルーチン中であるべきです。

       7.   Full Display systems may be best for non-specialists and for
            non-programmers.  Directive systems, perhaps with the
            ability to preview the final equation on one's screen, may
            be best for the rest.

7. 非専門家と非プログラマにとって、完全なDisplayシステムは最も良いかもしれません。 恐らく人のスクリーンで最終方程式を下見する能力のために、残りに、指向性のシステムは最も良いかもしれません。

       8.   A distinction should be made between the representation of
            an equation (which we are dealing with here) and the
            mathematical knowledge it represents.

8. 方程式(私たちがここで対処している)の表現とそれが表す数学の知識の間で区別をするべきです。

    I suggest something like EQN as a standard with extensions to allow
    positioning of symbols in some kind of absolute coordinates as well
    as relative positioning.  This has the advantage that the
    representation is in ordinary text, which can be sent in messages,
    the Directive systems can map almost directly into it, and it should
    allow representation for Full Display systems.  The ideas of
    subscript and superscripts (without having to specify a position),
    growing parentheses, fractions, and matrices, and special fonts are
    already there.

私は、相対位置決め方式と同様にある種の絶対座標における、シンボルの位置決めを許すために規格としてのEQNのように拡大で示します。 これには、表現がメッセージで送ることができる普通のテキストにある利点があります、とDirectiveシステムは直接それにほとんど写像できて、それはFull Displayシステムの表現を許容するべきです。添字と上付き文字(位置を指定する必要はなくて)の考え、括弧、断片、およびマトリクスを発展して、および特別な字体が既にそこにあります。

Katz                                                            [Page 7]

キャッツ[7ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ATAN関数 逆タンジェント(アークタンジェント)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る