lout-users
[Top][All Lists]
Advanced

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

Re: Another way of tweaking lout to support alien characters?


From: Valeriy E. Ushakov
Subject: Re: Another way of tweaking lout to support alien characters?
Date: Sun, 13 Dec 1998 08:42:45 +0300

On Fri, Dec 11, 1998 at 05:59:45PM -0600, James H. Cloos Jr. wrote:

> Note that seac is deprecated.  Adobe's docs (such as the t1 spec and
> update) suggest the use of subroutines rather than seac for accents.

As far as I understand for fonts based on StandardEncoding seac is
perfectly adequate.

Again, as far as I understand, a2ac tweaks AFM and relies on TeX do
the composition (but Lout doesn't do (yet?) composition itself).

accfont creates brand new font by merging existing charstrings.  Thus
it's a sort of a batch font editor, and it needs access to the
original font.  Furthermore the output from accfonts should be
included into Lout's output and that's what Matthew wants to avoid.

Using seac is the middle path.  We don't need to disassemble original
font (which a license might prohibit you from doing).  We can create
an AFM for the patched font from the AFM of existing font, but without
access to the font itself.  We can patch the font in place, right in
the printer.  We do the composition ourselves and do it in an
efficient manner (with Type 1 instructions).


Also Michael Piotrowski wrote:

> As far as I know, seac is deprecated.  I'm not sure, but I think it's
> seac which requires the accents used in compound characters to be in
> the encoding vector, wasting valuable space.  (Or is this rather a
> limitation of older PostScript interpreters?  Correct me if I'm wrong,
> I don't have the Black Book handy.)

The Black Book indeed states that 

| Both bchar and achar are codes that these characters are assigned in
| the Adobe StandardEncoding vector, given in an Appendix in the
| PostScript Language Reference Manual.  Furthermore, the characters
| represented by achar and bchar must be in the same positions in the
| font's encoding vector as the positions they occupy in the Adobe
| StandardEncoding vector.  If the name of both components of an
| accented character do not appear in the Adobe StandardEncoding vector,
| the accented character cannot be built using the seac command.

But I believe I read somewhere that this limitation was lifted in
later versions of PostScript interpreters (Type 1 rasterizers), though
I can't give you a xref.  As an argument for this I can only quote
from GhostScript source (zchar1.c):

    private int
    z1_seac_data(gs_font_type1 * pfont, int index, gs_const_string * pstr)
    {
        ref enc_entry;
        int code = array_get(&StandardEncoding, (long)index, &enc_entry);
    
        if (code < 0)
            return code;
        return z1_charstring_data(pfont, &enc_entry, pstr);
    }

which always looks up seac parameters via the /StandardEncoding, not
via font's /Encoding vector.


SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]