pgd@bbt.se (11/18/90)
The following is just for your information, in case you wonder what
will happen if you change the encoding for a type 1 font...
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".
If you define some other encoding for the type 1 font, and use seac,
the following will happen:
When the seac command is seen, and the characters for the seac are not
cached, it will use the characters according to the standard font
encoding. But if one (or both) characters are found in the font cache,
it will use the encoding that you defined for the font, instead.
The result is a complete mess.
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? It seems like that encoding the CharStrings in hex, like in
Ghostscript, works as well. That also have the added benefit that the
font is all ascii format, and the surrounding eexec is not needed.
This also reduces the size of the font to around half.taft@adobe.com (Ed Taft) (11/20/90)
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
pgd@bbt.se (11/28/90)
In article <8383@adobe.UUCP> taft@adobe.COM (Ed Taft) writes: >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. Thank you for your answer. I finally understand what you mean. I have struggled the whole day with that restriction, but now when I again read your text, I understand. You answer solves all my problems. I never understood the footnote in the book either. It says something about "composites", but nowhere could I found how to make those composites. That was exactly what I wanted to do. Now I finally know how to do it. I have some more related questions: What is the "ISOLatin1Encoding" (or something like that) symbol doing in the system dictionary? On the hard-disk of the Agfa 3400 PS laser-printer there are some files. One called "AdobeStd.ps", another "ISOAdobeStd.ps". Both seems to define an encoding where "A" is 1, "B" 2, and so on. That is, all characters in name-alphabetic order. What are those files doing there?