10

I've only recently started playing with metapost's "glyph". I've discovered (MWE below) an anomaly with the paths in serifs for the cm font set from these experiments.

Starting point: it seems that metapost gets the glyphs from the .pfb file for the font (e.g. .../texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb).

My question is which of the following is causing the anomalies, so I can figure out whether a bug report is warranted and who to send it to...

  1. There is a bug in the .pfb file. Since it is a path that almost doubles back on itself, which may not result in any pixels being filled, so no-one has noticed.
  2. I am wrong about where metapost gets the glyphs from, and the bug is wherever that is.
  3. There is a bug in the glyph code in metapost.
  4. Something else.

Things I have done:

  1. Checked that other programs that use these fonts use the same .pfb file (yes AFAICT for pdflatex and for latex|dvips|pstopdf) and looked at greatly magnified characters in the pdf output of these - no luck.
  2. Looked for other tools to extract glyphs from a .pfb - can't find any. (Tips on this would be nice)
  3. Checked the strokes in cmr.mf (actually cmbase.mf) - Knuth's serifs are a separate stroke to the rest of the letter, so no clue there.
  4. Looked up the various tools that may have been used to produce these type1 fonts (MFTOEPS etc) from Knuth's source, but decided that is beyond my expertise.
  5. Looked on texexchange and further afield
  6. Checked version info (MetaPost=v1.504, cmr10.pfb=v003.002) and checked the changelog for more recent metapost

My MWE shows the boundary of the glyph overshoots, then doubles back in the serif, and a small amount extra area within the glyph for "I" in cmr10. Due to the geometry of the serifs in cmti10 there is still the overshoot but no extra area. It also shows up in some other fonts (bold, slant) in the cm font set, and in serifs in both uppercase and lowercase.

picture pic[];
path p[];
pair d;

pic0=btex  I\it I etex; % <---- the text to be analysed
_i:=1;
for $ within pic0:
    p[_i]=pathpart glyph (textpart $) of (fontpart $) scaled 1/100 shifted llcorner $ scaled 20;
    _i:=_i+1;
endfor

beginfig(1)
for i = 1 upto 20:
    if known p[i]:
        fill p[i] withcolor (.8,.8,.9);
        for j = 0 upto (length(p[i])-1):
            draw point j of p[i]--postcontrol j of p[i] dashed withdots scaled 1/4;
            draw point j+1 of p[i]--precontrol j+1 of p[i] dashed withdots scaled 1/4;
            fill fullcircle scaled 0.5mm shifted point j of (p[i]);
            d:=direction j of p[i];
            if abs(d)=0: d:=point j+4 of p[i] - point j-4 of p[i]; fi
            a:= if abs(d)=0: 0 else: angle(d) fi;
            draw thelabel.lft(decimal j infont "cmbx5",(0,0))
                rotated (a+90)
                shifted (point j of (p[i] )) withcolor blue;
        endfor
        draw p[i] withpen pencircle scaled 0.1;
    fi
endfor
endfig;

bye

enter image description here

11
  • 1
    The Type1 version for the CM fonts has been produced several years ago by BlueSky Research; I don't know what they used, but surely it predates mftoeps.
    – egreg
    Dec 30, 2013 at 15:20
  • 1
    Looking at my local copy of CMTI10.pfb with Fontlab's Typetool shows no such horrid jags in the capital I, even though I get the same results as you from Metapost. This suggests the problem is with extracting the pic elements in mpost.
    – Thruston
    Dec 30, 2013 at 19:09
  • 1
    If you are on a Mac or using GNU/Linux, FontForge may be helpful for examining the glyphs and can provide a lot of information about fonts in general.
    – cfr
    Dec 30, 2013 at 22:27
  • 1
    Two different parts of metapost are involved here. If you do something simple like draw "I" infont "cmti12" scaled 20 you won't see the jag. But if you do draw pathpart glyph "I" of "cmti12" scaled 0.5 the jag is very obvious. Apparently the implementation of glyph ignores the flex feature. I'm not good enough at reading the web2c source to be sure but the fault appears to be in the mp_gr_unexport function (which has become mp_gr_import in v1.803) in mp.w.
    – Thruston
    Dec 31, 2013 at 11:39
  • 4
    I'm voting to close this question as off-topic because it is about a bug which has been fixed in mpost version 1.999.
    – LaRiFaRi
    Jul 19, 2015 at 12:53

1 Answer 1

6

This issue appears to be related to the use of pathpart on the picture returned by glyph. Consider the following program:

prologues := 3;
outputtemplate := "glyph%c.eps";
beginfig(1);
  picture a;
  a = glyph "I" of "cmti12";
  draw a withcolor .9 white;
  draw pathpart a withcolor red;
endfig;
end.

which produces the picture below. You can see the jags on the dished serifs clearly (in red) but notice that there are no jags in the grey part.

The glyph operator returns a picture of the given character in the given font. If I just draw that picture then the outline looks correct (the grey part of the image). But if I draw the path returned by pathpart then we get the extra jags on the dishes.

This shows that there is no fault in the font file, but rather that there is an issue with pathpart when applied to the picture returned by glyph. I've raised an issue with the MP development team -> http://tracker.luatex.org/view.php?id=935

Update: As of May 15, 2015 this bug is now fixed.

enter image description here

Here's the output using a newly compiled mpost version 1.999:

enter image description here

Not the answer you're looking for? Browse other questions tagged .