PAO de documents régulés et reconstruction in-place de PDF

Les PDF ne stockent pas le texte en tant que texte. Ils stockent le texte sous forme de séquence d'opérations de glyphes : « dessiner le caractère 67 de la police Helvetica aux coordonnées (123, 456) ». La plupart des agences utilisent un convertisseur PDF vers Word qui perd les informations de coordonnées et les références de police ; le résultat est modifiable mais visuellement sans rapport avec la source. Le niveau suivant d'agence utilise « Exporter vers InDesign » d'Adobe Acrobat — cela préserve davantage la mise en page mais échoue sur trois catégories de contenu :

• Glyphes vectorisés. De nombreux formulaires réglementaires (impots.gouv.fr, Steuererklärung allemande, AEMPS) vectorisent leurs libellés de texte en tracé vectoriel lors de la publication. L'extracteur d'Acrobat lit le texte vectorisé comme un graphique, pas comme une chaîne. Le traducteur ne voit jamais le libellé de champ et le régulateur ne revoit jamais son modèle.
• Champs de formulaire. Les champs AcroForm et XFA ont leurs propres références de texte et de police. Extraire le texte environnant mais pas les libellés de champs produit un document à moitié traduit.
• Hybrides numérisés. Un PDF partiellement vectoriel, partiellement matriciel (typique pour les documents fournis par les régulateurs avec un bloc de signature numérisé) nécessite l'OCR sur la partie matricielle et une extraction avec préservation des coordonnées sur la partie vectorielle. Un outil unique ne peut pas gérer les deux.

Nous avons conçu notre moteur PDF spécifiquement pour cette catégorie. Il énumère chaque opération de dessin de texte dans le PDF, y compris les glyphes vectorisés (en détectant les polices de libellés courantes et en remappant inversement le tracé vers les caractères), lit les libellés et infobulles des champs de formulaire, exécute l'OCR sur les régions matricielles, et produit un manifeste de traduction par segment. Le traducteur travaille dans le manifeste ; le moteur réécrit la traduction aux coordonnées sources. Les champs de formulaire sont préservés ; le régulateur voit le même formulaire, dans sa langue cible, avec les bons libellés de champs.

Une déclaration fiscale française qui ressemble à une déclaration fiscale française. Une notice CE allemande qui correspond au modèle du régulateur allemand. Une notice d'information patient que l'EMA accepte dès la première révision. Nous avons été conçus pour cela ; la plupart des agences ne l'ont pas été.

InDesign fournit un compositeur de paragraphe par défaut qui ne peut pas gérer l'arabe correctement — il casse les ligatures, se trompe dans la logique de saut de ligne, et n'applique pas les formes contextuelles. La solution consiste à activer le compositeur de paragraphe Adobe World-Ready (Texte → Paragraphe → Compositeur de paragraphe World-Ready dans l'édition InDesign ME, ou via un script dans l'édition standard). La plupart des agences utilisant InDesign standard ne l'activent pas et livrent de l'arabe visuellement cassé qu'un lecteur natif rejettera au premier coup d'œil.

Les glyphes arabes changent de forme selon qu'ils sont isolés, initiaux, médians ou finaux dans un mot. Un paragraphe arabe correctement composé applique automatiquement la forme correcte via les fonctionnalités OpenType init, medi, fina et isol. Les polices varient dans la qualité de leur implémentation de ces fonctionnalités — Tajawal, Cairo, Noto Sans Arabic et Adobe Arabic sont fiables. De nombreuses polices « arabes » sur les dépôts gratuits ne le sont pas, et produisent un texte qu'un lecteur natif reconnaît comme fabriqué à l'étranger au premier regard.

Un paragraphe arabe contenant un nom de marque anglais ou un nombre s'écoule dans les deux directions. L'algorithme bidirectionnel Unicode gère la plupart des cas, mais la ponctuation à la frontière (un point après une marque anglaise dans une phrase arabe) est souvent placée du mauvais côté de la marque. Nous utilisons les marques de formatage directionnel Unicode (RLM, LRM) pour ancrer correctement la ponctuation, et nous vérifions sur la mise en page finale — pas dans l'éditeur InDesign, où le comportement de l'algorithme diffère du PDF exporté.

Le contenu arabe peut utiliser des chiffres arabo-indiens (٠١٢٣٤٥٦٧٨٩) ou des chiffres occidentaux (0123456789) ; le choix dépend des conventions régionales et du style de maison du client. Nous confirmons avant de commencer et configurons le style de caractère InDesign pour garantir la cohérence dans tout le document. Un document qui mélange les deux est un bug régional.

Le persan et l'ourdou partagent l'écriture arabe mais ont des formes de glyphes différentes, des caractères supplémentaires (le پ persan, le ٹ ourdou), et des conventions typographiques différentes. Le nastaliq est la police ourdou dominante ; le naskh est dominant pour le persan. Traiter les trois comme de l'« arabe » est l'erreur la plus courante ; nous employons des compositeurs par langue.

Le chinois n'a pas d'espaces de mots ; les sauts de ligne peuvent se produire à n'importe quelle limite de caractère. Le compositeur CJC d'InDesign gère cela correctement lorsqu'il est activé. Les règles de kinsoku de ponctuation — la ponctuation chinoise pleine chasse ne peut pas apparaître au début d'une ligne — nécessitent une configuration explicite. La composition verticale (pour les contextes traditionnels, les livres et certaines mises en page marketing) nécessite un compositeur et une configuration de bloc séparés. Le chinois simplifié utilise un ensemble de conventions de ponctuation et l'orthographe RPC ; le chinois traditionnel en utilise un autre et nous vérifions selon le style de maison de Taïwan ou de Hong Kong selon la cible.

Le japonais mélange trois écritures (kanji, hiragana, katakana) avec des caractères latins et des chiffres. Le texte ruby (furigana — petites lectures phonétiques au-dessus des kanji) est requis pour certaines catégories de contenu (matériel scolaire, accessibilité). La composition verticale est courante dans les contextes traditionnels. Les règles de saut de ligne sont plus permissives que le chinois mais ont toujours des contraintes de kinsoku.

Le hangul coréen utilise des espaces de mots (contrairement au chinois et au japonais). La justification et le crénage se comportent différemment des écritures latines ; les lecteurs coréens s'attendent à un interlignage plus serré que la valeur par défaut latine. Les hanja (caractères chinois dans les contextes coréens) apparaissent dans les documents académiques et juridiques et nécessitent une gestion de police de secours.

Le thaï est l'écriture qui brise le plus souvent les compositeurs naïfs. Il n'y a pas d'espaces de mots — les sauts de ligne doivent être déduits d'un dictionnaire. Le compositeur thaï d'InDesign utilise un dictionnaire intégré ; pour les termes techniques absents du dictionnaire, une insertion manuelle d'espace de largeur nulle est nécessaire. Les marques de ton s'empilent au-dessus des consonnes et ne peuvent pas passer à la ligne suivante. La plupart des compositeurs britanniques n'ont pas d'opérateur thaï dans leur personnel ; nous en avons un.

Les écritures indiennes utilisent un façonnage complexe — les consonnes conjointes se combinent en ligatures qui dépendent du groupe de consonnes et des tables OpenType de la police active. Un compositeur naïf produira du devanagari visuellement cassé où les conjonctions ne se forment pas. Noto Sans Devanagari, Devanagari Sangam MN d'Adobe, et quelques autres gèrent correctement le façonnage. Nous testons sur la police finale, pas sur une police de secours. Pour les documents techniques, nous testons également sur les polices régionales que les régulateurs gouvernementaux attendent (par exemple, Mangal pour certains formulaires du gouvernement indien).

• Redimensionnement automatique des blocs — chaque bloc de texte dans le fichier InDesign source est configuré pour s'ajuster automatiquement à son contenu. Le bloc grandit ; la mise en page s'adapte. C'est la plus grande source de bugs liés à l'expansion et la plus simple à corriger.
• Budget d'expansion de la feuille de style — nous publions une feuille de style pour chaque langue cible montrant l'expansion maximale autorisée avant recomposition manuelle. Les traducteurs voient le budget pendant la traduction ; si une chaîne dépasse, ils peuvent demander une reformulation ou signaler la contrainte.
• Règles de recomposition — nous convenons des règles de recomposition par document lors du cadrage. Courant : les sauts de page peuvent se déplacer ; les titres de section ne doivent pas être coupés ; les tableaux peuvent déborder sur la page suivante ; les légendes de figures restent avec leur figure. Les règles sont documentées et appliquées de manière cohérente.
• Rapport de changement de nombre de pages — à la livraison, nous publions une comparaison du nombre de pages : source 40 pages, allemand 48 pages, arabe 47 pages, chinois 36 pages. Le client sait ce qu'il reçoit avant d'ouvrir le fichier.

Les notices d'information patient pharmaceutiques sont le cas à enjeux élevés. L'EMA et la MHRA exigent des titres de section spécifiques, dans un ordre spécifique, sans troncature. L'expansion allemande pousse régulièrement une PIL de 4 pages à 6 pages ; le régulateur accepte le changement de nombre de pages tant que l'intégrité de section est préservée. Nous travaillons selon le modèle QRD de l'EMA pour chaque PIL et vérifions par rapport à la version actuelle du modèle (le modèle change ; nous surveillons).

• PDF/X-1a:2001 — la norme héritée, CMJN uniquement, toutes les polices incorporées. Encore requis par certains imprimeurs et la plupart des systèmes de journaux.
• PDF/X-4 — norme moderne, prend en charge nativement la transparence, RVB et CMJN, profils de couleur ICC. Notre valeur par défaut pour les nouveaux travaux ; pris en charge par la plupart des presses modernes.
• PDF/A — pour l'archivage à long terme (souvent requis pour les dépôts réglementaires). PDF/A-1b est le choix conservateur ; PDF/A-2 et -3 ajoutent des fonctionnalités.
• Marques et fond perdu — marques d'imprimeur, marques de repérage, barres de couleur et 3 mm de fond perdu par défaut ; configurable selon le contrat d'impression.

La conversion CMJN doit connaître la presse cible : Fogra 39 / 51 pour les papiers couchés européens, GRACoL 2006 pour l'Amérique du Nord, JC2011 pour le Japon. Nous incorporons le profil ICC correct et vérifions l'épreuvage à l'écran si l'imprimeur fournit un profil. Les couleurs d'accompagnement Pantone sont préservées en tant que tons directs jusqu'à la fabrication des plaques.

Chaque police utilisée doit être incorporée dans le PDF final (PDF/X l'exige). Les licences de fonderie varient dans ce qu'elles permettent — les licences Monotype, Linotype et Adobe Originals sont explicites ; certaines polices commerciales interdisent l'incorporation et nécessitent un remplacement avant l'exportation. Nous auditons la pile de polices et substituons là où la licence l'exige.

Nous livrons le package InDesign (ou le PDF prêt à imprimer, selon le périmètre), une fiche de spécifications d'impression documentant le fond perdu, les marques, le profil de couleur et la recommandation de papier, et un PDF d'épreuvage à l'écran pour validation visuelle. Votre imprimeur devrait pouvoir graver le fichier sans aller-retour.

Les notices d'information patient et les résumés des caractéristiques du produit suivent le modèle QRD de l'EMA ; les brochures d'investigateur suivent les directives ICH E6 ; les formulaires de consentement éclairé suivent le modèle IRB ou REC. Nous travaillons selon la version actuelle du modèle (les modèles se révisent ; nous surveillons) et livrons selon le format de soumission du régulateur (XML pour RCP, PDF pour PIL, eCTD pour les soumissions complètes). Les pistes d'audit par segment sont obligatoires pour le travail pharmaceutique réglementé ; nous les publions.

Les dépôts de brevets ont des exigences de format qui diffèrent par office. L'OEB accepte XML et PDF ; l'USPTO exige des tailles de police et des marges spécifiques ; les soumissions PCT ont des résumés spécifiques à la langue. Nous travaillons selon la spécification actuelle de l'office et livrons conformément. Les dessins sont traduits séparément — légendes de figures dans la langue cible avec le même schéma de numérotation.

Les soumissions aux tribunaux britanniques nécessitent un format de dossier spécifique (PDF unique, paginé, indexé, avec hyperliens). Nous reconstruisons les dossiers dans la langue cible avec la même structure de pagination et d'index. Pour l'arbitrage international, nous travaillons selon les spécifications de l'ordonnance procédurale, qui varient selon le cas.

Les rapports annuels suivent les règles de cotation de chaque marché (LSE, AIM, NASDAQ, Euronext) pour les sections requises ; les prospectus suivent le règlement prospectus ; les DIC suivent PRIIPs. Nous nous coordonnons avec votre équipe de traduction financière (souvent nous — voir traduction financière) pour garantir que la prose, les chiffres et la mise en page sont synchronisés.

La catégorie la plus difficile pour la reconstruction PDF sur place car les formulaires varient selon les bureaux locaux. Nous avons traité impots.gouv.fr français, Steuererklärung allemande (plusieurs Bundesländer), formulaires de pharmacovigilance AEMPS espagnols, Agenzia Entrate italienne, et plusieurs formulaires HMRC britanniques. La convention de stockage PDF de chaque office est documentée dans notre bibliothèque interne ; nous savons à quoi nous attendre avant de commencer.