El símbolo "№" en cm-super causa un problema con la generación de PDF/A según el significado del validador VeraPDF

El símbolo "№" en cm-super causa un problema con la generación de PDF/A según el significado del validador VeraPDF

Por el momento estamos intentando producir una versión compatible con PDF/A-1b de los números de nuestra revista para la biblioteca estatal.

La revista tiene un lenguaje mixto: ruso/inglés, por lo que utilizamos símbolos cirílicos y algunos específicos de los estándares tipográficos rusos. En particular, el símbolo "№" para numerar las emisiones y subvenciones de fondos rusos, etc. Para la composición tipográfica utilizamos fuentes vectoriales cm-super (Tipo 1).

El problema es: ese símbolo (№, \No, \textnumero) genera el siguiente "error" (fallo) según el significado del validador VeraPDF (que probablemente sea utilizado por la biblioteca).

Especificación: ISO 19005-1:2005, Cláusula: 6.3.6, Número de prueba: 1 Para cada fuente incrustada en un archivo conforme y utilizada para renderizar, la información de ancho de glifo en el diccionario de fuentes y en el programa de fuentes incrustado debe ser consistente.

Ahora estamos considerando como una variante de solución cambiar el símbolo de fuente "№" a algo como esto:

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

Se ve similar pero no igual al "№" original en Tipo 1 y al copiar como texto desde PDF genera varios símbolos (No) y eso no es bueno. Pero funciona.

¿Alguien conoce ese problema y puede ayudar con las otras soluciones?

Aquí hay un código simple:

\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}

ACTUALIZAR: También probamos con el procedimiento "Guardar en PS - Distiller" en Acrobat Pro, pero generó el mismo resultado en la validación de VeraPDF; sin embargo, el validador de Adobe (Preflight) no muestra ningún error.

ACTUALIZACIÓN2: Con la ayuda de amigos fui redirigido aPDF/A con Linux Libertine y Linux Biolinum usando pdfLaTeX y la solución que funciona bien:

%%% 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

Probablemente signifique que textcompese símbolo está "mejor" definido que fontenccon t2aenc.dfu.

Respuesta1

Con la ayuda de amigos fui redirigido aPDF/A con Linux Libertine y Linux Biolinum usando pdfLaTeX y encontré la solución que funciona bien:

%%% 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

Probablemente signifique que textcompese símbolo está "mejor" definido que fontenccon t2aenc.dfu.

Respuesta2

Bueno, compañeros, la solución funciona bien, pero como pueden ver es sólo una muleta. El problema del símbolo "malo" todavía existe y con la solución anterior estamos cambiando uno "malo", declarado en T2A, por uno bueno, declarado en TS1. Esto, en particular, nos obliga a utilizar codificación de fuentes adicional y, como resultado, se incluyen muchos símbolos de fuentes adicionales en pdf-a. No es bueno. Entonces, la pregunta ahora es: ¿es posible corregir T2A (especialmente con respecto al símbolo \No) en CTAN?

información relacionada