🚀 go-pugleaf

In article <1990Nov17.174853.9476@bbt.se> pgd@bbt.se writes:
>The command "seac" stands for "standard encoding accented character".
>In the black book it says that the encoding of the font must use the
>standard encoding to be able to use this command.
>That is true. Which also means that all adobe type 1 fonts must use
>"StandardEncoding".

Perhaps I can clarify things a bit. The red book and the Type 1 book
describe different rules for accented characters. This is because the red
book describes the full PostScript language as understood by PostScript
interpreters, whereas the Type 1 book describes a very restricted subset of
the language understood by non-PostScript interpreters such as Adobe Type
Manager.

The PostScript rule for accented characters is this: If an accented
character is referenced anywhere in the font's Encoding, the components of
the character (that is, the base character and the accent) must also appear
somewhere in the Encoding. It doesn't matter where they appear. (This rule,
with different terminology, is documented in a footnote at the end of
section 5.4 of the red book.)

The Type 1 rule is more severe: If an accented character appears anywhere in
the Encoding, the components must also appear in the Encoding in the SAME
positions as in StandardEncoding.

Thus, you can download a font into a PostScript interpreter and then change
its Encoding to suit the application, observing only the red book rule.
Applications do this all the time, and it works fine. The PostScript
interpreter keeps track of characters based on their names, not their
character codes.

However, it is inadvisable to create a Type 1 font program with an encoding
other than StandardEncoding if the seac command is used in any of its
charstrings. Although such a font will still work with a PostScript
interpreter (if it follows the red book rule), it will be unacceptable to
ATM.

The seac command is admittedly a very limited mechanism. We hope to
introduce a more general facility for describing multiple-component
characters in some future extension to Type 1.

>Another statement in the manual is:
>
>       	"Note: The RD, NP, and ND functions must be implemented by
>	PostScript language procedures and must be invoked by a single
>	name as shown in the program example. These functions may not
>	be implemented by equivalent in-line code."
>
>Why this?

Once again, this is a Type 1 rule, not a PostScript rule. The rule exists to
enable Type 1 fonts to be parsed by a simple interpreter that does not
understand the full PostScript language. In particular, the ATM parser
expects charstrings to follow a specific pattern; it does not actually
execute the PostScript language definitions for RD, NP, and ND. If you are
building a font for consumption only by full PostScript interpreters, you
can structure it any way you desire.


Ed Taft      taft@adobe.com      ...decwrl!adobe!taft