Symbol "№" in cm-super verursacht Probleme bei der PDF/A-Generierung durch die Bedeutungen des VeraPDF-Validators

Symbol "№" in cm-super verursacht Probleme bei der PDF/A-Generierung durch die Bedeutungen des VeraPDF-Validators

Derzeit versuchen wir, PDF/A-1b-kompatible Versionen unserer Zeitschriftenausgaben für die Staatsbibliothek zu erstellen.

Die Zeitschrift ist gemischtsprachig (Russisch/Englisch), daher verwenden wir kyrillische Schrift und einige für russische typografische Standards spezifische Symbole. Insbesondere das Symbol „№“ zur Nummerierung der Ausgaben und Zuschüsse aus russischen Fonds usw. Für den Schriftsatz verwenden wir die Vektorschriftart cm-super (Typ 1).

Das Problem ist: Dieses Symbol (№, \No, \textnumero) erzeugt den nächsten „Fehler“ (Fehler) im Sinne des VeraPDF-Validators (der wahrscheinlich von der Bibliothek verwendet wird) -

Spezifikation: ISO 19005-1:2005, Abschnitt: 6.3.6, Testnummer: 1 Für jede Schriftart, die in eine konforme Datei eingebettet und zum Rendern verwendet wird, müssen die Informationen zur Glyphenbreite im Schriftartwörterbuch und im eingebetteten Schriftartprogramm konsistent sein.

Als Lösungsvariante erwägen wir nun, das Schriftsymbol „№“ etwa so zu ändern:

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

Es sieht ähnlich aus, ist aber nicht dasselbe wie das Original „№“ in Typ 1, und beim Kopieren als Text aus PDF werden mehrere Symbole (Nein) generiert, was nicht gut ist. Aber es funktioniert.

Kennt jemand dieses Problem und kann mit anderen Lösungen helfen?

Hier ist einfacher Code:

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

AKTUALISIEREN: Wir haben es auch mit dem Verfahren „In PS – Distiller speichern“ in Acrobat Pro versucht, aber es führte bei der Validierung durch VeraPDF zum selben Ergebnis, der Adobe-Validator (Preflight) zeigt jedoch keinen Fehler an.

UPDATE2: Mit Hilfe von Freunden wurde ich weitergeleitet zuPDF/A mit Linux Libertine und Linux Biolinum unter Verwendung von pdfLaTeX und die Lösung, die gut funktioniert:

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

Es bedeutet wahrscheinlich, dass in textcompdiesem Symbol „besser“ definiert ist als in fontencmit t2aenc.dfu.

Antwort1

Mit Hilfe von Freunden wurde ich weitergeleitet zuPDF/A mit Linux Libertine und Linux Biolinum unter Verwendung von pdfLaTeX und habe die Lösung gefunden, die gut funktioniert:

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

Es bedeutet wahrscheinlich, dass in textcompdiesem Symbol „besser“ definiert ist als in fontencmit t2aenc.dfu.

Antwort2

Okay, Kollegen, die Lösung funktioniert gut, aber wie man sehen kann, ist sie nur eine Krücke. Das Problem des „schlechten“ Symbols besteht immer noch und mit der obigen Lösung ersetzen wir das „schlechte“, das in T2A deklariert ist, durch ein gutes, das in TS1 deklariert ist. Dies führt insbesondere dazu, dass wir zusätzliche Schriftkodierungen verwenden und als Ergebnis werden viele zusätzliche Schriftsymbole in pdf-a aufgenommen. Das ist nicht gut. Die Frage ist nun also: Ist es möglich, T2A (insbesondere in Bezug auf das \No-Symbol) auf CTAN zu korrigieren?

verwandte Informationen