Isso é um bug no arquivo pfb ou no "glifo" do metapost?

Question

Eu só comecei recentementejogandocom o "glifo" do metapost. Eu descobri (MWE abaixo) uma anomalia com os caminhos em serifas para a fonte cm definida nesses experimentos.

Ponto de partida: parece que o metapost obtém os glifos do arquivo .pfb para a fonte (por exemplo, .../texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb).

Minha pergunta é qual das opções a seguir está causando as anomalias, para que eu possa descobrir se um relatório de bug é garantido e para quem enviá-lo...

1. Há um bug no arquivo .pfb. Por ser um caminho quequasedobra sobre si mesmo, o que pode não resultar no preenchimento de nenhum pixel, então ninguém percebeu.
2. Estou errado sobre de onde o metapost obtém os glifos, e o bug está onde quer que esteja.
3. Há um bug no código do glifo no metapost.
4. Algo mais.

Coisas que fiz:

1. Verifiquei que outros programas que usam essas fontes usam o mesmo arquivo .pfb (sim, AFAICT para pdflatexe para latex|dvips|pstopdf) e observei caracteres muito ampliados na saída em PDF deles - sem sorte.
2. Procurei outras ferramentas para extrair glifos de um .pfb - não consigo encontrar nenhuma. (Dicas sobre isso seriam legais)
3. Verifiquei os traços cmr.mf(na verdade cmbase.mf) - as serifas de Knuth são um traço separado do resto da carta, então nenhuma pista aí.
4. Pesquisei as várias ferramentas que podem ter sido usadas para produzir essas fontes type1 (MFTOEPS etc.) a partir da fonte de Knuth, mas decidi que isso está além da minha experiência.
5. Procurei no texexchange e em outros lugares
6. Verifiquei as informações da versão (MetaPost=v1.504, cmr10.pfb=v003.002) e verifiquei o changelog para metapost mais recente

Meu MWE mostra o limite dos excessos do glifo, depois dobra de volta na serifa e uma pequena área extra dentro do glifo para "I" em cmr10. Devido à geometria das serifas cmti10ainda há ultrapassagem, mas nenhuma área extra. Ele também aparece em algumas outras fontes (negrito, inclinado) no conjunto de fontes cm e em serifas em letras maiúsculas e minúsculas.

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

Answer 1

Este problema parece estar relacionado ao uso de pathpartna imagem retornada por glyph. Considere o seguinte programa:

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.

que produz a imagem abaixo. Você pode ver claramente os recortes nas serifas abauladas (em vermelho), mas observe que não há recortes na parte cinza.

O glyphoperador retorna uma imagem do caractere fornecido na fonte especificada. Se eu apenas usar drawessa imagem, o contorno parecerá correto (a parte cinza da imagem). Mas se eu desenhar o caminho retornado pathpart, teremos entalhes extras nos pratos.

Isso mostra que não há falha no arquivo de fonte, mas sim que há um problema pathpartquando aplicado à imagem retornada por glyph. Levantei um problema com a equipe de desenvolvimento do MP -> http://tracker.luatex.org/view.php?id=935

Atualizar: A partir de 15 de maio de 2015, esse bug foi corrigido.

Aqui está a saída usando uma mpostversão 1.999 recém-compilada: