Fw: Re: [Aleph] OpenType-to-TeX and other musings...

Hans Hagen pragma at wxs.nl
Thu Dec 22 10:22:20 CET 2005


Idris Samawi Hamid wrote:

> 1. From what I have seen, pdfetex's present rl is nowhere as good as  
> aleph's, so using the aleph code is an option;

i think so

>
> 2. Replacing the otp's with lua seems like a good idea. It would be 
> nice  to be able to, e.g. use actual font names for the final font 
> filters in  addition to hexadecimal numbers. lua has a table mechanism 
> that may be  able to replace otp tables in a more user-friendly way;

indeed

(but we may need some additional rl related features in order to support 
proper typesetting/layout design)

>
> 3. We still need to support the 16-bit level-0 ovf fonts. Even with  
> opentype, a large virtual font format is needed and ovf's perform  
> excellently in my experience (though some of the utilities are buggy). 
> In  any case, I hope it's not too much to ask that pdfetex++ support 
> the old  ovf's lying around...

what makes those ovf fonts unique? can't they be replaced by open type 
variants?

>
> Another reason for moving to pdfetex is taking advantage of and 
> augmenting  microtypography. For example:
>
> One very important feature which may work better at the 
> primitive/engine  level (a la microtypography): glyph substitution 
> that depends on the  paragraph. For example: In traditional Arabic 
> typography, one way to  compensate for "underfull" paragraphs is to 
> substitute a "swash" version  of a letter. Another way is by 
> stretching the cursive tie between joining  characters (which is 
> already implemented in my own Arabic system). It  would be nice to 
> implement these microtypographic features at the ground  level, which 
> neither Word nor InDesign are capable of (as far as I know).  Combined 
> with HZ we can get some pretty interesting high-level options,  
> effects, etc. that the user can choose etc.

indeed, recent additions concern control over pre/post character 
spacing/kerning and the more pdftex and aleph divert, the worse it gets 
to support both from macro packages.

>
> My indication is that the pdfetex production team is serious about  
> addressing the needs of aleph users in the short term. On that basis 
> I  give my full support to the pdfetex++ effort.

thanks -)

Hans


More information about the Aleph mailing list