# [tex-live] bug in dvipdfmx wrt diacritics?

Reinhard Kotucha reinhard.kotucha at web.de
Sat Sep 10 01:41:01 CEST 2011

On 2011-09-09 at 22:44:33 +0900, Akira Kakuto wrote:

> Hi Norbert,
>
> > \documentclass{article}
> > \usepackage[T1]{fontenc}
> > \usepackage{charter}
> > \begin{document}
> > chass\'e du G\"obe
> > \end{document}
>
> Please try by removing the line
> \usepackage[T1]{fontenc}
>
> Probably the encoding should be the standard encoding for a SEAC,
> since dvipdfmx uses type 1C.

AFAIK the actual encoding of the font doesn't matter.  Glyphs within
Type 1 fonts have a name and an encoding vector is just an array of
such names.

The seac routine, however, takes numbers as arguments.  And these
numbers denote slot numbers in the StandardEncoding array.  It doesn't
mean that the font has to use StandardEncoding itself since every font
renderer must have StandardEncoding built-in.  A font doesn't have to
provide an encoding vector at all.  It's sufficient to provide a line

/Encoding StandardEncoding def

within the font.  A font may provide more glyphs than StandardEncoding
supports.  In order to access them, it has to be re-encoded.  This is
what the fontenc package does.  As far as the seac routine is
concerned, the only requirement is that the glyphs it uses have proper
names.  Let's consider bchr8a.pfb for example:

/eacute {
37 491 hsbw
212 182 0 101 194 seac
} ND

The first three arguments describe where to place the accent.  101 is
the slot number of /e and 194 that of /acute in StandardEncoding.
Since every font rendering software must have the StandardEncoding
vector built-in, this is quite independent of the actual font
encoding.

On 2011-09-09 at 19:32:51 +0900, Norbert Preining wrote:

> If you replace charter by lmodern, it works, so the bug may be in
> the font itself (Bitstream charter from texlive-fonts-recommended,
> version: 2009-11)

It's better to try it with a font which is using the seac routine.
Those produced by Thanh and Jacko don't.  The reason is that seac
doesn't allow you to add accents to already accented glyphs, which is
reqired for Vietnamese.  In order to solve this problem efficiently,
they put glyphs into subroutines and avoid seac completely.

In order to find out whether the font is broken, you can try with
texmf-dist/fonts/type1/adobe/courier/pcrr8a.pfb , which is using seac
as well.  But I doubt that it's a font issue because I don't see
anything abnormal within Bitstream Charter.  I already fixed broken
kerning pairs with FontForge and it didn't complain.  t1lint also
doesn't complain.

The error message

** WARNING ** Obsolete four arguments of "endchar" will be used for
Type 1 "seac" operator.

doesn't mention only seac but also endchar.  Since seac doesn't use
endchar itself, I suppose that dvipdfmx has problems with the glyphs
supposed to be combined, rather than with the seac routine itself.

In order to find out what the four arguments of "endchar"' are, you
have to stop the program when endchar is called and see what's on the
stack at this time.

Thus I think that the only reasonable solution is to pass the bug
report to the authors of dvipdfmx.  They know best under which
circumstances this error message is issued.  I doubt that the font is
the culprit.

BTW, since kerning in Bitstream Charter is hopelessly broken, I
recommend to switch to XeTeX or LuaTeX and to use CharisSIL instead.

Regards,
Reinhard

--
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
`