Símbolo "№" em cm-super causa problema na geração de PDF/A pelos significados do validador VeraPDF

Símbolo "№" em cm-super causa problema na geração de PDF/A pelos significados do validador VeraPDF

No momento, estamos tentando produzir versões compatíveis com PDF/A-1b de nossas edições de periódicos para a biblioteca estadual.

O diário é misto - russo/inglês, por isso usamos cirílico e alguns símbolos padrão tipográficos específicos para russo. Particularmente - símbolo "№" para numerar as emissões e subvenções de fundos russos e assim por diante. Para composição, usamos fontes vetoriais cm-super (Tipo 1).

O problema é: esse símbolo (№, \No, \textnumero) gera o próximo "erro" (falha) pelo significado do validador VeraPDF (que provavelmente é usado pela biblioteca) -

Especificação: ISO 19005-1:2005, Cláusula: 6.3.6, Número de teste: 1 Para cada fonte incorporada em um arquivo conforme e usada para renderização, as informações de largura do glifo no dicionário de fontes e no programa de fontes incorporado devem ser consistentes.

Agora estamos considerando como uma variante de solução alterar o símbolo da fonte "№" para algo assim:

\def\ourNo{N\kern-.05em-\kern-.37em\raise.75ex\hbox{\scriptsize o}\@}

Parece semelhante, mas não igual ao "№" original no Tipo 1 e ao copiar como texto de PDF gera vários símbolos (Não) e isso não é bom. Mas funciona.

Alguém conhece esse problema e pode ajudar com as outras soluções?

Aqui está um código simples:

\documentclass{article}
%\usepackage{cmap} - disabling or enabling have no effect on the problem
\usepackage[a-1b]{pdfx}
%\usepackage{hyperref} - disabling or enabling have no effect on the problem
\usepackage[russian,english]{babel}
\usepackage[T2A]{fontenc}
\usepackage[cp1251]{inputenc}

\begin{document}
\end{document}

ATUALIZAR: Também tentamos o procedimento "Salvar no PS - Distiller" no Acrobat Pro, mas causa o mesmo resultado na validação pelo VeraPDF, porém o validador Adobe (Preflight) não apresenta erro.

ATUALIZAÇÃO2: Com a ajuda de amigos fui redirecionado paraPDF/A com Linux Libertine e Linux Biolinum usando pdfLaTeX e a solução que funciona bem:

%%% Solving \textnumero problem in russian pdflatex
%%% Don't know how to explain why this works
\UndeclareTextCommand{\textnumero}{T2A}
\usepackage{textcomp} %depending on previous font packages this may be second call to package

Provavelmente significa que nesse textcompsímbolo está "melhor" definido do que em fontencwith t2aenc.dfu.

Responder1

Com a ajuda de amigos fui redirecionado paraPDF/A com Linux Libertine e Linux Biolinum usando pdfLaTeX e encontrei a solução que funciona bem:

%%% Solving \textnumero problem in russian pdflatex
%%% Don't know how to explain why this works
\UndeclareTextCommand{\textnumero}{T2A}
\usepackage{textcomp} %depending on previous font packages this may be second call to package

Provavelmente significa que nesse textcompsímbolo está "melhor" definido do que em fontencwith t2aenc.dfu.

Responder2

Ok, colegas, a solução funciona bem, mas como se pode ver é apenas uma muleta. O problema do símbolo “ruim” ainda existe e com a solução acima estamos trocando o símbolo “ruim”, declarado em T2A, por um símbolo bom, declarado em TS1. Isto, particularmente, nos faz usar fontencoding adicional e, como resultado, muitos símbolos de fontes adicionais são incluídos no pdf-a. Não é bom. Portanto, a questão agora é: é possível corrigir o T2A (especialmente com relação ao símbolo \No) no CTAN?

informação relacionada