User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.18)
            Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <1295793648.2637194.1308604124163.JavaMail.fmail@mwmweb004>        
            <04DDF439-D2E2-4335-89D0-C410EE65935A@frycomm.com>
            <82376E2C-57BF-42D3-B6E8-91FA98DABA45@frycomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4E36B104.8060704@residenset.net>
Date:         Mon, 1 Aug 2011 15:58:28 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= <Lars.Hellstrom@RESIDENSET.NET>
Subject: Re: future
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <82376E2C-57BF-42D3-B6E8-91FA98DABA45@frycomm.com>
Precedence: list
Status: R

William Adams skrev 2011-08-01 14.24:
> On Aug 1, 2011, at 8:01 AM, William Adams wrote:
>
>> So I guess this has two questions:
>>
>> 1 - what is the optimal way to get non-standard characters like that into a text stream?
>
> There's an obvious corollary to this:
>
> 1b - Do we have a list of characters which are replaced by vector elements?

Probably not, but a quick grep for \glyphrule in fontinst/inputs/*mtx only 
turns up visiblespace, various compwordmarks, and missing glyphs. This 
confused me for a while, since I had expected underscore to be among the 
stuff faked too, but that is probably done by LaTeX rather than the fonts.

In that case, ltoutenc.dtx is your friend.

> If so, what should be done about them?

One thing that can be done is to insert \specials for PDF marked content -- 
this would also help a bit with newer Acrobat Readers that (for no good 
reason) get confused by old Expert fonts (made by the same company). I've 
experimented with putting such in VFs (which would avoid bloating DVIs), but 
there is no integrated implementation. A catch that needs to be worked 
around is that marked content operators seem to be ignored if the material 
they surround does not contain at least one glyph; I suppose that could be 
handled by using a space for that glyph.

> I believe that in any instance of the user issuing a command to output character(s) matching character(s) need to show up in the output.

That would be opening the old characters-versus-glyphs can of worms.

Lars Hellström