Re: [vvv@vvv.vsu.ru: Q: typeface code for Literaturnaya]

[Vladimir Volovich <vvv@vvv.vsu.ru>]

"BKPH" == Berthold K P Horn writes:

 >> Forwarding this for discussion, I don't really understand the
 >> 8r=faked characters stuff.

 BKPH> I suspect the fonts he refers to have ready-made accented
 BKPH> characters that go beyond the "standard" Western 58 in typical
 BKPH> Type 1 fonts - which are referred to 8r.  If he then used an 8r
 BKPH> reencoded version of the fonts he is interested in, he would
 BKPH> loose access to the other accented charcacters (perhaps things
 BKPH> like Zdotaccent, Eogonek ?)

exactly :) the "almost T1 encoded" fonts include really almost all
glyphs from T1, so if we will take 8r as an encoding for raw fonts, we
will lose a lot of ready glyphs from type1 fonts and instead will be
forced to fake them (by putting accents/descenders/etc) which seems
not correct. OTOH, we'd like to add some fake glyphs like
`visualspace' in the `final' T1-encoded fonts, so we need to name the
raw fonts by some names. currently, i've chosen names like rtl6r8t
(where `l6' is a new code for literaturnaya family just registered by
K.Berry; i used `li' till now, so `raw' fonts were named rtlir8t, and
real fonts were named tlir8t).

the similar situation exists for `almost TS1-encoded fonts' (the
situation here is worse than for T1), and for `almost iso-8859-5
encoded fonts'. in all cases we'd like to provide fonts which are more
correct WRT encoding support, so we need separate names for raw fonts
and for final fonts.

BTW, the current version of the virtual fonts which support T2A, T1,
TS1, OT1 encodings (as well as type1 fonts) could be downloaded from

        ftp://ftp.vsu.ru/pub/tex/literat.zip
        ftp://ftp.vsu.ru/pub/tex/literat-19990520.zip

 BKPH> In which case he could use as a base the font as is, if all
 BKPH> characters appear in the encoding or some form reencoded to
 BKPH> something that does expose everything.

yes. and, as we need to also add/correct something, it is not
sufficient to ReEncodeFont, but we need to use virtual fonts, and thus
have separate names for raw `almost correctly encoded' fonts and for
`final' fonts.

i think that it is a dead idea to try to reserve an additional
encoding name for these `almost correct' encodings, because there are
TONS of such variants out there.

 BKPH> 8r=faked characters, I think refers to the need to built up
 BKPH> composite characters that are not amongst the 58 in 8r (but
 BKPH> that may very well be ready-made in his fotn).

yes, thanks for understanding. :-)

	Best regards, -- Vladimir.
-- 
COBOL:
	An exercise in Artificial Inelegance.