# [NTG-pdftex] dvipdfmx

Hans Hagen pragma at wxs.nl
Thu Dec 22 23:02:30 CET 2005

```Vladimir Volovich wrote:

>"HH" == Hans Hagen writes:
>
> HH> - take relevant bit and pieces of aleph, esp r-l typesetting so
> HH> that pdftex+lua can replace aleph
> >> also very essential part of omega/aleph are the 16-bit fonts (or
> >> even 32-bit?).
> HH> that's where open type comes in
>
>in my understanding it is essential to have "font 16-bitness" on the
>abstract level of TeX (i.e. metric features; specific glyph
>representation is very much secondary), not connected to any specific
>font format like Opentype.
>
>
well, if you only want metric info then \wdcode, \htcode,
\dpcode,\iccode, \whatevercode can also be a solution

(pdftex already has many \*codes associated with characters)

>TeX has always been independent of physical font formats, and that is
>it's strength... [and omega's 16-bit fonts are no exception]
>
>
but -since many fonts don't demand much control- it's also a weakness
that tex cannot handle for instance afm files directly.

since tfm compatibility will remain, some kind of 32 bit native tex
format will probably show up (in the past there has been discussions
now that pdftex offers many font related features, it may as well make
sense to control such things at the macro level on top of regular fonts
and not using a dedicated font format; so, whatever will happen, there
will be much control over fonts and how they are used, but a more native
and direct support will also be provided.

> HH> - additional font features (beyond open type) - lua input
> HH> preprocessing (replacement for otp's)
> >>  will lua provide input processing as powerful as OTPs?
> HH> i dunno, but it will definitely be easier (and documented)
>
>are there any preliminary considerations or descriptions of how it
>will work (of course not detailed - just to understand the proposed
>idea of such a replacement of OTPs)?
>
>
no, and it's currently also not under discussion, just under