#6 TFMError "width_index should not be zero"

closed
None
5
2012-10-16
2003-06-25
Gert Ingold
No

Hello,

I am trying to use a commercial font (Garamond Standard
from Softmaker) with PyX 0.3.1. Unfortunately, a
TFMError "width_index should not be zero" is raised. A
closer look at the TFM files shows indeed that CHARWD
is zero for certain characters, namely "17x in the T1
encoding (8t) and "17x and "1Fx in the TS1 encoding
(8c). Character "17x is defined as /compoundwordmark
while "1Fx is /ffl. The font tables in
CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf
don't show glyphs for compoundwordmark in the T1 and
TS1 encodings and for the ffl ligature in the TS1
encoding (of course, the ffl ligature is present in the
T1 encoding).

The same problem arises if I use the package mathptmx
while the use of the palatino package leads to:
After parsing this message, the following was left:
*(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd)
If the described effect is caused by PyX checking the
CHARWD's of all
characters, this should, in my opinion, be considered a
bug.

Best regards,
Gert

Discussion

  • Andre Wobst

    Andre Wobst - 2003-06-26

    Logged In: YES
    user_id=405853

    I'm just considering the problem of loading fd-files
    triggered by TeX when processing some expressions. By
    default, those messages are errors in PyX 0.3.1. I've just
    checked in a special handler for font description file
    loading, enabled by default via texmessagedefaultrun. Thus
    fd-file loading is not considered to be an error anymore.
    Beside that, your report about tfm-file handling is still
    open. PyX might be just to strict in that sence.

     
  • Jörg Lehmann

    Jörg Lehmann - 2003-06-26

    Logged In: YES
    user_id=390410

    Please check whether the changes made in the CVS head fix
    this problem.

    Jrg

     
  • Andre Wobst

    Andre Wobst - 2003-06-26

    Logged In: YES
    user_id=405853

    Fix looks fine to me. I can get marvosym running by that
    (which didn't work previously due to the same bug). Consider
    this minimal example:

    from pyx import *

    text.set(mode="latex")
    text.preamble("\usepackage{marvosym}")
    c = canvas.canvas()
    c.text(0, 0, "\EUR")
    c.writetofile("test")

    Unfortunately you have to do two things for getting this
    working:
    1. You have to copy marvosym.pfb to fmvr8x.pfb
    (the name used intenally)
    2. You have to modify the PostScript output test.eps,
    namely you have to change the selectfont from
    /FMVR8X 9.962640 selectfont
    to
    /Martin_Vogels_Symbole 9.962640 selectfont
    The information can be found in marvosym.map

    To be implemented ... ?!

     
  • Gert Ingold

    Gert Ingold - 2003-06-27

    Logged In: YES
    user_id=809523

    The changes to text.py fixed the original problem. However,
    there is still
    a problem (basically already described by Andr in his
    message of June 26).
    Apparently, the map-files are not evaluated so that
    replacement fonts are used. This behavior can already be
    obtained with the standard TeX fonts
    and \usepackage[T1]{fontenc}. The solution suggested by
    Andr is not very
    practical so that the question mark in "To be implemented
    ... ?!" should be
    replaced by (at least two) exclamation marks.

     
  • Gert Ingold

    Gert Ingold - 2003-06-27

    Logged In: YES
    user_id=809523

    One more comment concerning the workaround proposed by Andr:
    Things become of course more complicated if reencoding takes
    place
    (e.g. when the map file contains the statement
    "TeXBase1Encoding ReEncodeFont"). What was meant to be a
    (germandbls), i.e. character
    255 in EC, will turn out as ydieresis in TeXBase1. In order
    to obtain a ,
    one would have to ask for a \SS=Germandbls=character 223. If
    this is not
    done, the glyph is not even extracted from the pfb-file so
    that changing the
    eps-file would not be an option anymore.

     
  • Jörg Lehmann

    Jörg Lehmann - 2003-08-26

    Logged In: YES
    user_id=390410

    This problem should be fixed in PyX 0.4.

    Thanks,
    Jrg

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks